Was ist SRE — und was nicht?
Site Reliability Engineering wurde bei Google entwickelt, um ein grundlegendes Problem zu lösen: Wie betreibt man Systeme zuverlässig, die so groß und komplex sind, dass manueller Betrieb nicht mehr skaliert? Die Antwort: Man behandelt Betrieb als Software-Engineering-Problem.
Das klingt nach einer Selbstverständlichkeit, ist es aber nicht. In vielen Unternehmen ist der IT-Betrieb noch immer geprägt von manuellen Runbooks, reaktivem Troubleshooting und der stillen Hoffnung, dass die Bereitschaft nicht gerade in der eigenen Schicht klingelt. SRE bricht mit dieser Denkweise — nicht durch neue Tools, sondern durch ein anderes Betriebsmodell.
SRE und DevOps: Geschwister, keine Zwillinge
Die Frage „Was ist der Unterschied zwischen SRE und DevOps?" taucht in praktisch jedem Gespräch auf. Die kurze Antwort: DevOps ist eine Philosophie, SRE ist eine konkrete Implementierung. Oder wie Google es formuliert: „SRE implements DevOps."
DevOps beschreibt Prinzipien — Zusammenarbeit, Automatisierung, Feedback, kontinuierliches Lernen. SRE macht daraus konkrete Praktiken mit messbaren Zielen:
- Service Level Objectives (SLOs): Quantifizierte Zuverlässigkeitsziele, die gemeinsam von Entwicklung und Betrieb festgelegt werden
- Error Budgets: Das „erlaubte" Mass an Unzuverlässigkeit. Solange das Error Budget nicht aufgebraucht ist, kann das Team neue Features deployen. Ist es aufgebraucht, hat Stabilität Vorrang.
- Toil Reduction: Die systematische Beseitigung manueller, repetitiver Betriebsarbeit durch Automatisierung
- Blameless Postmortems: Strukturierte Nachbereitung von Incidents ohne Schuldzuweisung
SLOs: Das Herzstück von SRE
Service Level Objectives sind mehr als technische Metriken. Sie sind ein Kommunikationswerkzeug zwischen Entwicklung, Betrieb und Business. Ein SLO wie „99,9 % der API-Anfragen werden innerhalb von 200ms beantwortet" ist eine Aussage, die alle Beteiligten verstehen können.
Der Trick dabei: 99,9 % klingt nach „fast perfekt", bedeutet aber auch 8,7 Stunden Downtime pro Jahr. Das ist eine bewusste Entscheidung. Mehr Zuverlässigkeit ist möglich, aber teurer — exponentiell teurer. Der Sprung von 99,9 % auf 99,99 % kostet typischerweise ein Vielfaches.
SLOs zwingen Teams dazu, diese Abwägung explizit zu treffen. Und sie geben Entwicklern die Freiheit, schnell zu iterieren, solange die Zuverlässigkeitsziele eingehalten werden. Das ist ein fundamentaler Unterschied zu „wir machen keine Fehler" — einer Haltung, die in der Praxis zu Stillstand führt.
Error Budgets in der Praxis
Das Error Budget ist die vielleicht cleverste Idee im SRE-Modell. Es berechnet sich direkt aus dem SLO: Bei einem Ziel von 99,9 % Verfügbarkeit dürfen 0,1 % der Anfragen fehlschlagen. Dieses Budget wird laufend gemessen.
Ist noch Budget vorhanden, darf das Team Risiken eingehen — neue Features deployen, Architektur-Änderungen durchführen, Experimente wagen. Ist das Budget aufgebraucht, wird der Fokus auf Stabilität gelegt: Bug-Fixes, Performance-Optimierungen, Verbesserung des Monitorings.
Dieser Mechanismus löst einen der häufigsten Konflikte in Softwareorganisationen: Den Konflikt zwischen „schnell liefern" und „stabil betreiben". Beide Seiten bekommen ein objektives Kriterium, anhand dessen Entscheidungen getroffen werden.
Der Einstieg: Pragmatisch statt dogmatisch
Nicht jedes Unternehmen ist Google, und nicht jedes Team braucht eine dedizierte SRE-Rolle. Aber die Prinzipien lassen sich schrittweise übernehmen:
- SLOs definieren: Starten Sie mit einem oder zwei Services. Was ist für Ihre Nutzer wichtig? Verfügbarkeit? Latenz? Fehlerrate?
- Messen: Haben Sie die Daten, um Ihre SLOs zu überprüfen? Wenn nicht, ist Observability der erste Schritt.
- Toil identifizieren: Welche Betriebsaufgaben erledigen Ihre Teams manuell und wiederholt? Das sind die Kandidaten für Automatisierung.
- Postmortems einführen: Nach jedem relevanten Incident eine strukturierte Nachbereitung — ohne Schuldzuweisung, mit konkreten Action Items.
Fazit
SRE ist kein Allheilmittel und kein Ersatz für DevOps. Es ist ein bewährtes Framework, das DevOps-Prinzipien mit konkreten Praktiken und messbaren Zielen unterfüttert. Für Teams, die bereits auf dem DevOps-Weg sind und den nächsten Reifegrad erreichen wollen, ist SRE ein logischer nächster Schritt.
