Publiziert: Zuletzt aktualisiert:

SRE (Site Reliability Engineering)

SRE (Site Reliability Engineering) ist eine von Google entwickelte Disziplin, die Software-Engineering-Prinzipien auf den IT-Betrieb anwendet. SREs sind Softwareentwickler, die an Reliability-Problemen arbeiten, nicht Operations-Menschen, die Skripte schreiben. Das Ziel: Zuverlässigkeit und Innovationsgeschwindigkeit gleichzeitig maximieren.

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 (z. B. Erfolgsrate von Anfragen, Latenz).
  • SLO (Service Level Objective): Ein konkretes Ziel für den SLI (z. B. "99.9% aller Anfragen unter 200ms").
  • Error Budget: Der Anteil erlaubter Ausfälle innerhalb des SLOs. Bei 99.9% SLO: 43 Minuten Ausfallzeit pro Monat. Budget aufgebraucht? Deployments stoppen, bis stabilisiert.
  • Toil: Manuelle, repetitive, automatisierbare Arbeit im Betrieb. SREs messen und reduzieren Toil aktiv. Zielwert: unter 50% der Arbeitszeit.
  • Postmortem: Blameless, strukturierte Analyse nach jedem Vorfall (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 Toolset 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:

  1. Neue Features werden gestoppt.
  2. Priorität wechselt zu Reliability-Arbeit.
  3. 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?

Startet mit einem SLO für euren wichtigsten Service. Messt es. Diskutiert das Error Budget. Das reicht für den Anfang.

Reference Guide

Verwandte Themen

Offene Punkte