SRE Has Become the Janitorial Department of Engineering

A service fails. A deployment stalls. A job needs another manual restart. The request lands with SRE because somebody has to deal with it, and SRE is the team that reliably answers.

That seems reasonable until you look at what the team spends its week doing. The same recoveries. The same escalations. The same questions about services somebody else built and nobody quite owns after deployment.

Somewhere along the way, being responsible for reliability turned into being responsible for whatever everyone else left behind.

There is nothing beneath an engineer about operational work. Production needs people who can diagnose a failure, recover a service, and make a difficult decision under pressure. The problem starts when the organization makes that cleanup permanent and keeps postponing the work that would make it unnecessary.

The queue keeps winning

Imagine a batch job that fails every Monday because a previous run leaves a lock behind. Someone checks that the old process is gone, clears the lock, restarts the job, and waits for it to finish.

The recovery takes fifteen minutes. Getting interrupted, recovering context, and returning to the original task takes longer. The ticket records a successful resolution. The application backlog barely notices.

Next Monday, it happens again.

An SRE writes a script to collect the evidence and clear the lock. That is useful. Recovery is safer and quicker. But the team still has to decide whether the script is safe to run, and the application still leaves the lock behind.

If that temporary workaround becomes the operating model, the organization has made the failure cheaper to tolerate. It has also made it easier to delay fixing it.

This is where a good responder gets trapped. Every interruption has an immediate consequence. Prevention can always wait until next sprint. The more dependable the team is at recovering the service, the less urgent the underlying defect appears.

The cost belongs with the service

A central operations queue can make this surprisingly hard to see. One service produces five incidents, another needs repeated manual deployments, and a third requires daily data repairs. On a dashboard, it all becomes SRE workload.

That description leaves out who is creating the work and who can actually change it.

I want recurring interventions attached to the service they come from. What failed? How often? What did someone have to do? Which team can remove the need for that intervention?

The answer might involve an application change, better infrastructure, a missing recovery mechanism, or an external dependency nobody can fully control. The point is to make that conversation possible. Counting resolved tickets without connecting them to their source mostly tells you how busy the responders were.

A repeated lock cleanup should be visible in the application's reliability backlog, with an owner and a decision about the fix. Otherwise, feature delivery looks inexpensive because another team is quietly paying part of its operating cost.

Shared ownership needs somewhere to land

“Developers should own production” sounds simple when nobody has to explain the arrangement.

Does that include an on-call rotation? Can the application team see the relevant telemetry? Can it safely recover its own service? Does it have time to address defects, or will every reliability change lose to another feature deadline?

Giving a team responsibility without those conditions just changes who gets interrupted.

SRE should help build the operating model: useful alerts, recovery procedures, failure testing, safe deployment paths, and clear escalation. Sometimes SRE also owns shared infrastructure or a difficult piece of the service itself. Those responsibilities need to be explicit.

When a service needs repeated specialist help, I want the response to produce something lasting. Pair on the investigation. Improve the runbook. Fix the failure path. Give the application team the access and context it needs to handle the next occurrence safely.

There will still be incidents worth escalating. The goal is for an escalation to draw on expertise, rather than substitute for an ownership decision that never happened.

A script is a start

Google's SRE book describes toil as repetitive operational work that leaves little lasting improvement and grows with the service. That definition is useful because running a script by hand can still consume an operator every time the service misbehaves.

I am happy to automate a safe recovery. I also want to know whether it reduces interruptions or just makes the same interruption faster.

For the batch job, a durable fix might handle stale locks correctly, reject overlapping runs, and expose enough state to distinguish a slow execution from an abandoned one. Any automated recovery needs limits and evidence. Repeating a dangerous action unattended is a different problem.

The same question applies to the workflow around the recovery. If everyone still waits for someone to decide whether a restart is safe, connecting the ticketing system to a script has left the hardest part untouched.

Prevention needs a place on the calendar

I want to see what the reliability team made unnecessary this month.

Which recurring failure stopped happening? Which manual intervention disappeared? Which service can its owning team now recover without starting another group chat?

Those improvements need time that survives contact with the incident queue. They also need application owners and managers willing to change priorities when a service keeps creating work. A team cannot engineer its way out of an interruption load if nobody lets it stop responding long enough to do the engineering.

Keep asking the same people to absorb the same preventable failures and eventually they start protecting their time. By then, the loss of enthusiasm can look like the problem, even though the queue has been providing evidence for months.

Close the incident. Then give someone the time, authority, and responsibility to stop the next one.

Otherwise, we will be back on Monday, clearing the same lock.