Site Reliability Engineering (SRE) ist die Disziplin, die Betrieb als Softwareproblem behandelt; Ben Treynor Sloss prägte den Begriff bei Google. Service Level Indicators und Objectives messen die Zuverlässigkeit, und das Fehlerbudget, also die Unzuverlässigkeit, die ein SLO erlaubt, wird für Entwicklungsgeschwindigkeit und Risiko ausgegeben. Dazu kommen Toil eliminieren, schuldlose Postmortems, die vier goldenen Signale sowie automatisiertes Release- und Kapazitäts-Engineering, wie es das O'Reilly-Buch von 2016 von Beyer, Jones, Petoff und Murphy beschreibt.

Site Reliability Engineering

Details
Vollständiger Name

Site Reliability Engineering (SRE)

Auch bekannt als

"Betrieb als Softwareproblem", Google SRE

Kernkonzepte:

Betrieb als Softwareproblem

Software-Engineering auf Betriebsaufgaben anwenden statt manueller Administration.

SLI / SLO / SLA

Service Level Indicators messen das Verhalten; Objectives setzen interne Ziele; Agreements sind externe Zusagen.

Fehlerbudget

100 % Verfügbarkeit ist das falsche Ziel; die erlaubte Unzuverlässigkeit (1 − SLO) ist ein Budget für Entwicklungsgeschwindigkeit und Risiko.

Risiko akzeptieren

Zuverlässigkeit wird gegen Kosten und Änderungsgeschwindigkeit abgewogen, nicht blind maximiert.

Toil eliminieren

Wiederkehrende, manuelle, automatisierbare Betriebsarbeit reduzieren; die Betriebslast begrenzen (~50 %), um Zeit für Engineering zu schützen.

Schuldlose Postmortems

Aus Vorfällen lernen, indem Systeme und Prozesse analysiert werden, statt Schuld zuzuweisen.

Monitoring & Observability

Die vier goldenen Signale messen — Latenz, Traffic, Fehler, Sättigung.

Release- & Kapazitäts-Engineering

Launches, Rollouts und Kapazitätsplanung automatisieren, um Änderungen sicher und wiederholbar zu machen.

Schlüsselvertreter

Ben Treynor Sloss (prägte den Begriff bei Google); Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy ("Site Reliability Engineering", O’Reilly 2016, und "The Site Reliability Workbook")

Wann zu verwenden:

  • Betrieb von Produktivdiensten, deren Zuverlässigkeit gemessen und gesteuert werden muss

  • Definition von SLOs und Fehlerbudgets, um Zuverlässigkeit und Entwicklungsgeschwindigkeit abzuwägen

  • Etablierung von On-Call, Incident Response und schuldlosen Postmortems

  • Reduzierung von betrieblichem Toil durch Automatisierung

  • Abgrenzung der Verantwortung für Zuverlässigkeit von allgemeiner DevOps-Kultur

Verwandte Anker:

Aktueller Stand:

  • Der Prior bedient den Kanon gut: SRE Book (2016) und Workbook (2018) — SLOs, Error Budgets, Toil, Postmortems — bleiben maßgeblich, und Google stellt alle drei Bücher inklusive "Building Secure and Reliable Systems" (2020) frei unter sre.google/books bereit

  • Bewegt hat sich seitdem der organisatorische Rahmen: SRE-Praxis konvergiert zunehmend mit Platform Engineering — Reliability-Fähigkeiten wandern in interne Plattformen statt in eigenständige SRE-Teams; nachzulesen in Googles eigener Platform-Engineering-Anleitung