Site Reliability Engineering

Definition

Site Reliability Engineering (SRE) is an engineering discipline, pioneered at Google, that applies software engineering practices to operations problems, treating reliability as a measurable, engineered property of a system rather than a purely reactive operations function.

Overview

SRE was created at Google in the early 2000s by Ben Treynor Sloss, who famously described it as "what happens when you ask a software engineer to design an operations function." Rather than staffing operations with a separate team that manually reacts to incidents, SRE teams write software to automate operational work, and they hold engineering and operations to the same rigor, using metrics and error budgets instead of intuition to decide how much risk a system can absorb. Central to SRE is the concept of the error budget: instead of chasing 100% uptime, a service defines a reliability target — say, 99.9% availability — via a Service Level Objective (SLO), and the small remaining margin of allowed unreliability becomes an error budget that product teams can spend on shipping new features and taking calculated risks. When the error budget is exhausted, feature launches pause in favor of reliability work, which aligns incentives between engineers who want to ship quickly and the need to keep the system stable. SRE also formalizes toil reduction — the practice of identifying and automating away repetitive, manual operational work — as a core team responsibility, typically capping the fraction of an SRE's time spent on toil so there's always room for engineering improvements. Google published the discipline's principles in the widely read "Site Reliability Engineering" book (2016), and practices like blameless postmortems, chaos engineering tools such as Chaos Monkey, and on-call rotations with clearly defined escalation paths have since become standard across the industry, adopted well beyond Google under the SRE label or the closely related DevOps and platform engineering movements.

Key Concepts

• Error budgets that quantify and formally allocate acceptable unreliability
• Service Level Objectives (SLOs) and Service Level Indicators (SLIs) as measurement tools
• Automating repetitive operational work instead of performing it manually
• Blameless postmortems that focus on systemic causes over individual blame
• Capping toil to ensure time remains for engineering and automation work
• Shared ownership of reliability between engineering and operations
• Structured on-call rotations with defined escalation and incident response
• Data-driven decisions about when to prioritize features versus reliability

Use Cases

Frequently Asked Questions

Related in DevOps