SRE Principles and Practices
The core idea
Site Reliability Engineering treats operations as a software problem. Instead of staffing production with people who only run systems, SRE staffs it with engineers who write code to run systems. The discipline rests on a few interlocking principles: reliability is a feature with a cost, so you must embrace risk rather than chase zero downtime; service reliability is defined objectively through SLIs and SLOs; the gap between the SLO and 100% is an error budget that funds releases and experimentation; and work that scales with service size without adding value - toil - must be capped and automated away.
Two structural commitments follow. First, SREs spend no more than about 50% of their time on operations (on-call, tickets, manual work) and the rest on engineering that permanently reduces operational load. Second, SRE shares ownership with product teams: the error budget is the shared currency, and an agreed error budget policy decides what happens when it runs out.
Traps candidates fall for
- Treating SRE as rebranded system administration. The distinguishing test is whether the team writes software that removes operational work.
- Confusing SRE with DevOps. DevOps is a broad philosophy and cultural movement; SRE is one concrete implementation of it, with specific mechanisms (SLOs, error budgets, the 50% rule, blameless postmortems).
- Assuming SRE targets 100% availability. The framework explicitly rejects this as both impossible and harmful to velocity.
- Believing SRE owns all operations. Teams that own their services in production (‘you build it, you run it’) remain accountable; SRE provides the framework, tooling and, sometimes, the pager.
Rule of thumb
If a team's operational load exceeds 50% of its capacity for more than a quarter, that is a signal to stop adding services, escalate, and invest in automation - not to add more people to the pager rotation.