SRE vs DevOps: who owns reliability when it breaks?

Crowd of passengers having fun in a bustling city on a vibrant floor

Published on August 2020 by Arjan Franzen

Two responsibilities meeting at one clear handover.

Most comparisons of SRE and DevOps are definitional, and definitions are the least useful thing here. Both terms are broad enough that you can make either one mean almost anything. The question teams actually have is narrower and more practical:

When production breaks at 2am, who is responsible — and who gets to say "we are not shipping this week"?

Answer that, and the rest of the distinction follows.

The shortest honest distinction

DevOps is a set of practices for reducing the distance between writing code and running it. It has no job title attached, no defined artefacts, and no mechanism for saying no.

SRE is a role with a specific job: keep the service within an agreed reliability target, and hold a budget that runs out. When the error budget is spent, releases stop. That is a mechanism with teeth.

The practical difference is not philosophy. It is that SRE has a veto and DevOps does not.

Where they genuinely overlap

In day-to-day work, most of it: automating deploys and treating infrastructure as code, measuring delivery through deploy frequency and lead time and change failure rate and MTTR, running blameless postmortems, and having developers carry pagers for their own services.

If your team does all of the above, arguing about which label applies is not a good use of an afternoon. The overlap is where most of the value is, and it is available under either name.

Where they actually conflict

Three places, and they are the reason the distinction matters at all.

Who decides whether to ship. Under DevOps, shipping decisions belong to the team, moderated by judgement. Under SRE, the error budget decides: spent means frozen, regardless of the roadmap. Teams that adopt SRE vocabulary without adopting the freeze have adopted the paperwork and skipped the point.
Whether reliability is a feature or a constraint. DevOps treats reliability as a quality of good work. SRE treats it as an explicit number that trades against feature velocity — and expects you to spend the budget, not hoard it. 100% uptime means you were too conservative, not that you did well.
Where the expertise sits. DevOps distributes operational skill across every team. SRE concentrates it in people whose job is reliability, then argues about how to attach them: embedded, platform, or centralised. That argument only exists because SRE is a role.

Which one does your team need?

Under ~15 engineers, one or two services — DevOps practices. An SRE function is overhead you cannot staff.
Growing, and reliability incidents now cost real money — DevOps practices plus explicit SLOs and an error budget. Adopt the mechanism before the job title.
Multiple teams, shared platform, contractual uptime — an SRE function. Decide the attachment model separately.
Someone has already promised a customer 99.9% — SLOs immediately, regardless of size. You have an SLA without the measurement.

The case that catches most teams is the second. You can adopt the useful half of SRE — measurable targets and a budget that constrains releases — without hiring anyone. That is the highest-value move for most organisations, and it is why "SRE vs DevOps" is a false choice for teams under about fifty engineers.

How you would know it is working

Whichever label you use, the same numbers tell you whether reliability work is paying off.

Change failure rate falling while deploy frequency holds or rises. If deploys slow down to protect reliability, you bought stability with velocity and should say so out loud.
MTTR falling faster than incident count. Incidents are inevitable; recovery time is the controllable part.
Error budget consumption that is neither 0% nor 100%. Consistently unspent means the target is too loose to constrain anything.

The short version

DevOps removes the distance between building and running. SRE adds a number that can stop a release. Most teams need the first, and need the mechanism of the second long before they need the job title.

If you are choosing between them, you are probably asking the wrong question. Ask instead: what is our reliability target, who is allowed to stop a release, and are we measuring the thing that would tell us?