SRE

WHAT IT IS. Site Reliability Engineering is Google's answer to a hard question: when your product team wants to ship constantly and your users want the service to never break, who decides? SRE decides with numbers. A Service Level Objective states exactly how unreliable the service is allowed to be in a window (99.9% of requests successful in 30 days). The remaining allowance — the error budget — is a resource the team spends on change. When the budget burns too fast, releases freeze until reliability recovers; when it is healthy, nobody argues about deploys. WHY IT EXISTS. "Reliable" and "fast" are usually settled by whoever shouts loudest. SRE replaces the argument with a negotiated, written contract — the error-budget policy — that both product and engineering signed. It also names the silent tax on operations: toil, the manual, repetitive, automatable work that grows until it consumes the team. SRE caps toil explicitly and spends the freed time building systems that make the service run itself. WHEN TO USE IT. The moment a service has users who lose money, trust, or patience when it fails. Before that, SLOs are ceremony. It scales down honestly: a three-person team can run one SLO and a one-paragraph budget policy; that IS SRE at small scale. What does not scale down is skipping the policy — an SLO without a consequence attached is a dashboard, not a contract. WHO OWNS IT. Service teams own their SLIs, SLOs, and the budget they spend; a reliability or platform group owns the shared machinery — telemetry, alerting, the release-freeze automation — and acts as an internal contractor with explicit engagements, not a permanent owner of other teams' pages. Product management co-signs the error-budget policy because it trades their release velocity. WHAT GOOD LOOKS LIKE. Every tier-1 service has a user-felt SLI (not CPU, but successful checkouts), an SLO baselined from real traffic, a written budget policy that has actually paused a release at least once, alerts that page only on budget burn or explicit user symptoms, and a toil ledger showing manual operations shrinking quarter over quarter. Google's SRE book and workbook (linked below) are the primary sources; the error-budget chapter is the one to read twice. HOW TO IMPLEMENT. Pick the one service whose outage would hurt most. Define one SLI from existing telemetry, set the SLO where current reality is (not where you wish it were), write the one-paragraph policy — "burned budget this week means releases hold until it recovers, here is who can waive it" — and wire one multi-window burn-rate alert. One service done honestly beats five done as paperwork. HOW TO ASSESS YOURSELF. The production readiness assessment scores SLO management, alerting quality, and toil directly — see /assess. The maturity ladder below stages L1 (no SLOs, firefighting) to L5 (budgets steer roadmap). Related: /observability-engineering supplies the telemetry SLOs depend on, /incidentops runs the failure side, /resilience-engineering extends budgets into rehearsed failure.