What is SRE?

The Treynor definition, the relationship to DevOps, and the eight SRE principles.

Overview

What SRE is

Site Reliability Engineering (SRE) was created at Google in 2003 by Ben Treynor Sloss. His one-line definition, quoted across the SRE Book, is "what happens when you ask a software engineer to design an operations team." SRE is an engineering discipline whose product happens to be production reliability, not ops with code on the side.

> [!IMPORTANT] SRE is measured by its artifacts. Without SLOs and an error-budget policy, a team is not doing SRE, whatever it is called.

SRE and DevOps

The SRE Workbook sums up the relationship in a chapter title: class SRE implements interface DevOps. DevOps is the broad cultural philosophy. SRE is one prescriptive implementation of it with opinionated, measurable artifacts.

What it is — Cultural philosophy — Prescriptive implementation
Core ideas — No silos, change should be gradual, accidents are normal, measurement is crucial — SLOs, error budgets, a 50% toil cap, blameless postmortems
Relationship — The interface — One class implementing it

The eight SRE principles

1 — Operations is a software problem — SREs write code and are hired at a software-engineering bar
2 — Manage by SLOs, not by uptime — Reliability targets come from users, not from 100%
3 — Minimize toil — Aggregate ops work capped at 50%
4 — The wisdom of production — Be near production, not above it
5 — Automate this year's job away — Engineering time removes future toil
6 — Move fast by reducing the cost of failure — Small, reversible changes
7 — Share ownership with developers — Pages can go back to the dev team
8 — Use the same tooling regardless of function — No separate ops toolchain

> [!TIP] In an interview, open with Treynor's definition, then name the artifacts. That is what separates SRE from a renamed ops team.

Key concepts

SRE: "What happens when you ask a software engineer to design an operations team." (Ben Treynor Sloss, Google)
DevOps: The cultural philosophy SRE implements (no silos, gradual change, blameless culture, measurement).
50% cap: Hard ceiling on aggregate ops work per SRE; the rest must be engineering that reduces future toil.
Wisdom of production: SRE staffing pattern: 50–60% standard SWEs + 40–50% engineers with deep UNIX/networking. Both write code; both go on-call.
class SRE implements interface DevOps: SRE Workbook Ch 1 framing — DevOps is the interface, SRE is one concrete class implementing it.

When to use it

"Tell me about SRE" — opens with Treynor's definition, then differentiates from DevOps
Distinguishing SRE from a renamed-ops team — point at SLO-with-consequences as the test
Justifying the 50% cap to skeptical product or engineering leadership
Explaining why SREs write code and have SWE-tier hiring bars

Interview questions

Define SRE in one sentence and contrast it with DevOps.
What's the 50% rule and why does it exist?
Why does SRE care so much about reliability vs feature velocity, instead of just maximising uptime?
Why is "rename our ops team to SRE" not a real adoption strategy?