Site Reliability Engineering has been adopted broadly as a label and unevenly as a discipline. Many teams now have SRE in their titles; fewer practice the structural disciplines Google introduced and the field has refined since. The label is easy to adopt; the disciplines change how engineering teams operate in ways the label alone does not. Teams operating SRE seriously produce reliability outcomes that teams calling themselves SRE in name only do not, and the difference compounds across years.
What Distinguishes SRE From DevOps and Traditional Operations
Traditional operations was responsible for keeping things running, with limited authority to push back on engineering decisions that made things harder to run. DevOps reduced the operations/development split by giving engineers operational responsibility. SRE adds something neither of these has — quantitative reliability management. The team measures reliability in defined terms (service level objectives), allocates error budget against those objectives, and makes engineering trade-offs against budget consumption. When reliability degrades to budget exhaustion, the team prioritises reliability work over feature work explicitly. This structural mechanism is what produces sustained reliability rather than aspirational reliability.
SLOs and Error Budgets
A Service Level Objective is a quantitative target for reliability — typically expressed as availability (99.9%), latency (95% of requests under 300ms), or error rate (fewer than 0.1% of requests fail). The objective sits below the Service Level Agreement (what is promised externally) and above the Service Level Indicator (what is measured). The error budget is the gap between perfect reliability and the SLO — 99.9% availability allows 0.1% unavailability per period as the budget. When the budget is consumed, reliability work takes priority; when budget is available, feature work proceeds. This explicit trade-off is the operational core of SRE.
Toil Elimination
Toil is the manual, repetitive operational work that scales linearly with service growth — restarting services, clearing queues, manually scaling, handling routine alerts. SRE explicitly caps the proportion of an engineer's time spent on toil (typically 50%) and invests the rest in eliminating toil through automation and engineering. Without this cap, teams drift toward all-toil operation as service scale grows, and the reliability work that prevents incidents never gets done. With the cap enforced, teams continuously reduce the manual operational load and free capacity for higher-leverage engineering.
A pattern in teams calling themselves SRE: titles changed, error budgets discussed in slides, toil cap mentioned in the team charter, none of these actually enforced operationally. The team's daily reality continues to look like traditional operations or pure DevOps. The cultural shift to actually enforce the disciplines — refusing feature work when error budget is exhausted, refusing additional toil when the cap is hit — is what produces the outcomes the label promises. Adopting the label without the enforcement produces label.
Blameless Post-Mortems
SRE inherited and refined the blameless post-mortem from earlier operations traditions. The discipline applies to every meaningful incident — structured analysis of what happened, what allowed it to happen, and what systemic changes would prevent recurrence. The blameless framing is structural — focusing on systems and processes rather than individual judgement — and it is what makes the post-mortems produce honest analysis. SRE teams that maintain post-mortem discipline produce reliability that compounds; teams that skip post-mortems or allow them to drift toward blame produce the same incidents repeatedly.
When SRE Is the Right Operating Model
For services where reliability is a material business attribute — customer-facing platforms, regulated services, infrastructure that supports critical business processes. For organisations operating at scale where manual operations cannot keep up with growth. For teams whose reliability has been a recurring problem and where the current operating model is not producing improvement. For these contexts, SRE is the structural discipline most likely to produce sustained reliability. For smaller-scale services or services where reliability is not material, the SRE overhead may exceed the benefit; traditional operations or pure DevOps may be sufficient.
Practical Components of an SRE Practice
- Defined SLOs per service with documented reasoning for the chosen levels
- Error budget tracking integrated into engineering decision-making, not just dashboards
- Toil cap enforced; capacity above the cap spent on reliability engineering
- Blameless post-mortems on every meaningful incident with tracked action items
- On-call discipline that distributes load and prevents burnout
- Reliability work prioritised when error budget is exhausted, regardless of feature pressure
- Cultural commitment from engineering leadership; SRE fails when leadership is not aligned