Site Reliability Engineering (SRE) ist eine Disziplin, die klassische Operations-Aufgaben mit Software-Engineering-Methoden verbindet. SRE-Teams sind verantwortlich für Verfügbarkeit, Latenz, Performance, Effizienz, Change-Management, Monitoring, Capacity Planning und Incident Response produktiver Systeme — und automatisieren diese Aufgaben weitgehend in Code. Zentrale Konzepte sind Service Level Indicators (SLIs), Service Level Objectives (SLOs), Error Budgets, Toil-Reduktion sowie Incident- und Postmortem-Kulturen. Wenn das Error Budget eines Dienstes verbraucht ist, werden weitere Releases zugunsten von Stabilisierung pausiert.
Eingesetzt wird SRE in großen Internetunternehmen, SaaS-Anbietern, Plattformproduktteams und in Embedded-SRE-Modellen, in denen kleine SRE-Teams mehrere Anwendungsteams unterstützen. Werkzeuge umfassen Observability-Stacks (Prometheus, Grafana, Datadog, Honeycomb), Incident-Management-Plattformen (PagerDuty, Opsgenie, FireHydrant, Rootly), Chaos-Engineering-Werkzeuge sowie Postmortem-Templates und Run-/Playbook-Sammlungen. Capacity Planning, Disaster Recovery Drills, Game Days und Load Tests sind regelmäßige SRE-Aktivitäten.
Der Einsatzzweck und das gelöste Problem liegen in der Spannung zwischen Innovationsgeschwindigkeit und Stabilität. Reine "Dev-vs-Ops"-Strukturen führen zu Konflikten zwischen schnellen Releases und stabilem Betrieb. SRE löst dieses Problem durch ein klares, zahlenbasiertes Modell: SLOs definieren das tolerierbare Fehlerrisiko, das Error Budget legt offen, wie viel Risiko-Spielraum übrig ist. So lassen sich Deployment-Frequenz und Risiko explizit gegeneinander abwägen.
Historisch wurde SRE bei Google ab 2003 von Ben Treynor Sloss eingeführt, der in einem oft zitierten Vortrag SRE als "what happens when you ask a software engineer to design an operations team" beschrieb. Die SRE-Praxis wurde 2016 mit dem Buch "Site Reliability Engineering" (Beyer, Jones, Petoff, Murphy) öffentlich dokumentiert; weitere Bücher wie "The Site Reliability Workbook" (2018) und "Seeking SRE" (David N. Blank-Edelman, 2018) haben das Themenfeld vertieft. Konzepte wie SLI/SLO/SLA, Error Budget Policy, Toil und Postmortems sind heute auch außerhalb von Google Standardvokabular.
Eingeführt wurde SRE bei Google von Ben Treynor Sloss. Im SRE-Buch wird ausführlich diskutiert, dass eine perfekte Verfügbarkeit (5 Neunen oder mehr) ökonomisch und technisch nicht sinnvoll ist, weil ihr Grenznutzen sehr niedrig ist und Innovationsgeschwindigkeit massiv senkt. Diese Erkenntnis — dass das Streben nach Perfektion ein Anti-Pattern sein kann — ist eine der subversiveren Botschaften der SRE-Bewegung.