Site Reliability Engineering

Site reliability engineering, or SRE, is an approach to running production systems that treats operations as a software problem. It was developed at Google in the early 2000s, when a team of software engineers was asked to run the company's services and chose to automate the work instead of doing it by hand. Site reliability engineers write code to deploy, scale, monitor, and repair systems, and they share responsibility for reliability with the developers who build the features.

SRE starts by measuring reliability from the user's point of view. Teams pick service level indicators (SLIs), such as the share of requests that succeed, set service level objectives (SLOs) for them, and treat the gap between the target and 100% as an error budget. While budget remains, teams ship quickly; when it runs out, they slow down releases and focus on stability. Other core practices include limiting toil, meaning repetitive manual work, sustainable on-call rotations, and blameless postmortems after incidents.

SRE is common at companies that run large online services, and many organizations have SRE or platform teams that support several product teams at once. A useful comparison is an airline's maintenance crew: they don't expect planes that never need repairs, but they define strict safety margins, follow checklists, study every incident, and build tools that catch problems before takeoff.

SRE is often confused with DevOps. DevOps is a broad culture and set of practices for bringing development and operations together, while SRE is one concrete way to put it into practice, with specific roles, metrics, and rules such as error budgets. A popular way to put it is class SRE implements DevOps: SRE is one specific implementation of the broader DevOps idea.