What is Site Reliability Engineering (SRE)?

#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

What is the difference between SRE and operations?

SRE applies software engineering to operational problems and protects time for that work through an explicit toil cap. Traditional operations rarely has that protection.

Does a team need dedicated SREs?

Not necessarily. The mechanisms can be adopted by product teams. Dedicated SREs become useful when service count and complexity make specialized focus worthwhile.

What is the toil budget?

A cap on manual repetitive work, commonly fifty percent of time, with the remainder reserved for engineering that reduces future toil.

#Sources

• Google SRE: introduction