What is Site Reliability Engineering (SRE)?
Site reliability engineering is the discipline of applying software engineering methods to operations problems. It originated at Google and commonly uses measurable reliability targets and error budgets to balance reliability with delivery priorities.
What SRE actually prescribes
SRE is distinguished from general operations work by a few concrete mechanisms. SLOs define what reliability level is required, in numbers. Error budgets convert the SLO into a quantity of failure that can be spent, and exhausting it changes release policy automatically.
Toil budgets cap how much of an SRE's time goes to manual repetitive work, commonly at fifty percent, with the remainder protected for engineering that reduces future toil. Production readiness reviews define the operational floor a service must meet before launch.
Why the SRE model works
Each mechanism converts a judgment call that would otherwise be relitigated constantly into a rule with a number attached.
- Reliability has a target: work stops when the SLO is met rather than continuing indefinitely.
- Conflict resolution: ship versus stabilize is answered by budget remaining.
- Protected engineering time: the toil cap prevents operations from consuming the whole team.
- Consistent standards: readiness reviews apply the same floor to every service.
Limits and misapplications
The most common failure is adopting the title without the mechanisms. An operations team renamed to SRE, with no SLOs, no error budgets, and no toil cap, is an operations team with a new name and the same problems.
The model also assumes organizational willingness to act on the error budget. If leadership overrides a freeze whenever the budget is exhausted, the entire mechanism collapses, because the budget only has force if exhausting it actually changes what happens next.
SRE vs DevOps vs platform engineering
DevOps is a philosophy about shared ownership between building and running. It sets a direction without specifying mechanisms.
SRE is a specific implementation of that philosophy with concrete practices: SLOs, error budgets, toil budgets, readiness reviews. Platform engineering is a different response to the same problem, building internal products that make the reliable path the easy path for product teams. Many organizations run all three: DevOps as the cultural premise, SRE for reliability mechanisms, platform engineering for the tooling that makes both practical at scale.
Key takeaways
- SRE is defined by concrete mechanisms: SLOs, error budgets, toil budgets, and production readiness reviews.
- Each mechanism replaces a repeatedly relitigated judgment call with a number and a rule.
- Adopting the title without the mechanisms produces an operations team with a new name.
- The error budget only functions if the organization actually honors it when it is exhausted.
Frequently asked
Sources
- Google SRE: introductionsre.google