Site Reliability Engineering (SRE)
Pioneered by Google
Site Reliability Engineering (SRE) is an engineering discipline that applies software-engineering practices to operations problems, using measurable reliability targets and automation to keep systems available, performant, and maintainable…
Definition
Site Reliability Engineering (SRE) is an engineering discipline that applies software-engineering practices to operations problems, using measurable reliability targets and automation to keep systems available, performant, and maintainable at scale.
Overview
SRE was developed at Google in the early 2000s as an answer to a simple tension: developers want to ship features fast, while operations teams want systems to stay stable. Rather than treating reliability as a separate operations concern, SRE embeds it directly into engineering work — reliability targets are defined quantitatively, and the team that builds a service is also responsible, in large part, for keeping it running. The core mechanism is the Service Level Objective (SLO): a target for how reliable a service should be, expressed as a measurable indicator like request success rate or latency. The gap between 100% reliability and the SLO becomes the error budget — a quantified allowance for risk that governs how aggressively a team can ship new changes. When the error budget is healthy, teams move fast; when it's exhausted, the team's priority shifts to stability work until it recovers. SRE teams typically spend a capped share of their time on manual operational work ('toil') and the rest on engineering — building automation, improving observability, refining incident management processes, and writing postmortems that turn outages into durable fixes. This is distinct from a traditional ops role, where firefighting and manual intervention are often the primary job description rather than something to be systematically engineered away. Many of the practices SRE popularized — blameless postmortems, runbooks, structured on-call rotations, and chaos experiments — have since spread well beyond Google and are now taught as standard practice across the DevOps and platform engineering community, including in courses like CI/CD with GitHub Actions that cover the automation side of reliable delivery.
Key Concepts
- Reliability defined and tracked quantitatively via SLIs and SLOs, not gut feeling
- Error budgets that formally balance the pace of feature releases against stability
- A cap on manual operational toil, with the freed time reinvested in automation
- Blameless postmortem culture focused on systemic fixes, not individual blame
- Structured on-call rotations backed by clear escalation paths and runbooks
- Heavy investment in observability — metrics, logging, and tracing — as a first-class engineering concern
- Shared ownership: the team that builds a service also operates and is accountable for it