Site Reliability Engineering

Also known as: SRE

framework · computer science · organizing-schema

Google's approach treating operations as a software problem with SLOs and error budgets.

Site Reliability Engineering was developed by Ben Treynor Sloss at Google beginning in 2003, with the founding insight that hiring software engineers to do operations work would lead them to automate away repetitive operational tasks rather than scaling operational headcount linearly with system size. SRE was substantially codified in the 2016 book Site Reliability Engineering: How Google Runs Production Systems (edited by Betsy Beyer and colleagues), with subsequent volumes (The Site Reliability Workbook 2018, Building Secure and Reliable Systems 2020) extending coverage. The framework's central operational mechanisms are Service Level Indicators (SLIs — quantitative measures of service performance), Service Level Objectives (SLOs — target levels of SLI performance), and the Error Budget (the difference between 100% and the SLO, representing how much unreliability is acceptable in a given period). When the error budget is consumed, the reliability work takes priority over feature development; when budget remains, feature velocity is preferred. SRE prescribes that engineers spend at most 50% of time on operational work (toil), with the remainder on engineering improvements that reduce future toil. SRE complements DevOps — Treynor Sloss has described SRE as 'a specific implementation of DevOps' with opinions about how to do it.

Originators

Ben Treynor Sloss (founder at Google); subsequent codification by Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Murphy, and Google SRE community high

Year / Decade

2003 (Google founding); 2016 (Site Reliability Engineering book); 2018 (Workbook) high

Primary sources

Beyer, B., Jones, C., Petoff, J. & Murphy, N. (eds.) (2016). Site Reliability Engineering: How Google Runs Production Systems, Beyer, B. et al. (eds.) (2018). The Site Reliability Workbook high

Core components

Service Level Indicators (SLIs)
Service Level Objectives (SLOs)
Error Budgets
Toil reduction (capping operational work at 50%)
On-call practices and incident response
Blameless post-mortems and learning culture
Capacity planning
Release engineering and progressive deployment
Production readiness review
Distinction from traditional ops via software-engineer staffing and automation focus

Primary use case

Reliability engineering in technology companies, particularly large-scale internet platforms; foundation for the SRE job category and substantial professional ecosystem; basis for SLO-based reliability practice that has spread well beyond Google; complementary discipline to DevOps in larger organizations; reference framework in cloud-platform engineering and platform engineering.

Common criticisms

Google's specific scale and engineering culture make some practices difficult to transfer to smaller organizations — the model assumes substantial software-engineering capacity for operations work that smaller orgs cannot afford
SRE certification and tooling industry has grown around the framework with varying alignment to the original principles
SLO-driven decision-making requires organizational capacity to actually slow feature delivery when error budget is exhausted, which many organizations lack
toil-50% target is aspirational and difficult to enforce
tension between SRE teams and product teams over reliability vs feature velocity is structural
small companies often label release engineers as 'SREs' without adopting the framework's actual discipline
on-call burdens fall disproportionately on individuals despite framework intent.

Lineage

Child of: DevOps
Siblings: DevOps, CI/CD
Derived from: DevOps