Publiziert:

SRE (Site Reliability Engineering)

Zuverlässigkeit wird gemessen und budgetiert, nicht erhofft

SRE (Site Reliability Engineering) ist eine von Google entwickelte Disziplin, die Software-Engineering-Prinzipien auf den IT-Betrieb anwendet. SREs wenden Software-Engineering-Prinzipien auf Reliability-Probleme an. Google setzt dabei auf Software-Engineers mit selten vorkommenden System- und Netzwerkkenntnissen; die Praxis zeigt vielfältige Hintergründe. SRE bringt Zuverlässigkeit und Änderungs- bzw. Innovationsgeschwindigkeit in Balance, indem es den Zielkonflikt über SLOs und Error Budgets explizit macht.

SRE löst das fundamentale Dilemma: Entwicklungsteams wollen schnell deployen, Operations-Teams wollen Stabilität. Das Error Budget schafft einen gemeinsamen Rahmen.

Kernkonzepte

  • SLI (Service Level Indicator): Eine messbare Kennzahl für Zuverlässigkeit (zum Beispiel Erfolgsrate von Anfragen, Latenz).
  • SLO (Service Level Objective): Ein konkretes Ziel für den SLI (zum Beispiel "99.9% aller Anfragen unter 200ms").
  • Error Budget: Der Anteil erlaubter Ausfälle innerhalb des SLOs. Bei 99.9% SLO und zeitbasierter Messung über einen 30-Tage-Monat: rund 43 Minuten Ausfallzeit. Request-basierte SLOs rechnen anders. Budget aufgebraucht? Je nach vereinbarter Error-Budget-Policy: Release-Verlangsamung, Reliability-Sprint oder Ausnahme-Review durch das Management.
  • Toil: Manuelle, repetitive, automatisierbare Arbeit im Betrieb. SREs messen und reduzieren Toil aktiv. Zielwert: unter 50% der Arbeitszeit.
  • Postmortem: Blameless, strukturierte Analyse nach relevanten Vorfällen oberhalb der team-internen Schweregrad-Schwelle (siehe Post-Mortem).

SRE vs. DevOps

SRE ist eine spezifische Implementierung von DevOps-Prinzipien. DevOps ist eine Kultur und Philosophie, SRE ist eine konkrete Rolle und ein Werkzeugkasten mit definierten Praktiken.

Der Fokus: Zuverlässigkeit als Feature

Reliability ist kein technisches Nebenthema, sondern ein Geschäftsziel. SRE macht die Kosten von Unzuverlässigkeit sichtbar und schafft Anreize für nachhaltige Systeme.

Error Budget als Moderationswerkzeug

Wenn das Error Budget konsumiert ist, greifen die vereinbarten Policy-Regeln. Typische Optionen:

  1. Release-Verlangsamung oder Einfrierung neuer Features.
  2. Priorität wechselt zu Reliability-Arbeit.
  3. Ausnahme-Review durch Management bei zwingenden Releases.
  4. Nach Erholung des Budgets: normaler Entwicklungstakt.

Das Budget ist ein Verhandlungswerkzeug, kein Schuldvorwurf. Es macht die Risikotoleranz des Business explizit.

FAQ

Brauchen wir ein dediziertes SRE-Team?

In kleinen Organisationen übernehmen Entwicklungsteams SRE-Praktiken (embedded SRE). Dedizierte SRE-Teams lohnen sich ab einer kritischen Systemgrösse, bei der Reliability eine Vollzeit-Spezialisierung erfordert.

Wie beginnen wir mit SRE ohne Google-Masstab?

Der Einstieg gelingt mit einem SLO für den wichtigsten Service. Gemessen wird, das Error Budget wird diskutiert. Das reicht für den Anfang.

Referenzen

Verwandte Themen