Was SRE löst
Willkommen bei Site Reliability Engineering
Site Reliability Engineering (SRE) begann 2003 bei Google. Ben Treynor Sloss übernahm ein kleines Ops-Team und baute es so um, als würden Ingenieure und nicht menschliche Pager die Produktion betreiben. Das Ergebnis wurde zum Standardmodell für den Betrieb großer Internetdienste.
Traditionelle Operations-Teams hielten Dienste durch manuelle Arbeit am Laufen: diesen Server neu starten, diesen Engineer pagen, ein Runbook schreiben und hoffen, dass es hält. Dieses Modell bricht bei Skalierung. Ein Team von fünfzig Operatoren kann nicht manuell fünftausend Server neu starten. Ab einer bestimmten Größe wird manuelle Arbeit zu einer Steuer, die jede produktive Stunde verbraucht.
SRE dreht das Modell um. Anstatt bei wachsenden Systemen mehr Operatoren einzustellen, stellt SRE Software Engineers ein und sagt ihnen: Schreibt Code, der die operativen Aufgaben für euch erledigt. Eure Arbeit zählt als Software Engineering, angewandt auf Operations-Probleme. Euer Output: Automatisierung, Monitoring und engineered Reliability – keine manuellen Eingriffe.
Drei grundlegende Ideen treiben die SRE-Praxis an:
- Service Level Objectives (SLOs): numerische Zuverlässigkeitsziele, die im Voraus vereinbart werden
- Error Budgets: das Gegenstück zu einem SLO, das für Risikobereitschaft genutzt wird
- Toil-Elimination: jede operative Arbeit, die linear mit der Systemgröße skaliert, muss eliminiert werden
Diese drei Ideen fließen in jede SRE-Praxis ein: Postmortems, On-Call-Rotationen, Kapazitätsplanung, Monitoring und Release Engineering.
Traditionelle Ops versus SRE
Warum traditionelle Ops bei Skalierung versagt
Ein typisches Ops-Team wächst linear mit den Systemen, die es verwaltet. Verdoppeln sich die Server, verdoppelt sich auch die Anzahl der Operatoren. Das ist bei kleinen Deployments finanziell sinnvoll, bei großer Skalierung jedoch katastrophal: Man kann sich nicht aus einem quadratischen Problem heraus einstellen.
SRE begrenzt operative Tätigkeiten auf maximal fünfzig Prozent der Arbeitszeit eines Engineers. Die andere Hälfte muss für Engineering-Aufgaben verwendet werden: Tools bauen, Prozesse automatisieren und den Toil beseitigen, der erst zu den fünfzig Prozent geführt hat. Überschreitet der Toil-Anteil dauerhaft fünfzig Prozent, muss das Team Arbeit an ein Entwicklungsteam zurückgeben oder zusätzliche SREs einstellen. Die Fünfzig-Prozent-Regel verhindert, dass ein SRE-Team unter anhaltendem Druck zu einem traditionellen Ops-Team wird.
Vergleichen Sie die Failure Modes:
- Traditionelles Ops: Mehr Incidents führen zu mehr manuellen Reaktionen, die weniger Zeit für Prävention lassen, was wiederum mehr Incidents erzeugt. Eine Doom-Loop.
- SRE: Mehr Incidents lösen Postmortems aus, die Automatisierungsmöglichkeiten aufzeigen und die Reaktionszeit beim nächsten Incident verkürzen. Eine Virtuous Loop, wenn sie funktioniert.
SLI, SLO, SLA
Drei Buchstaben, die die Produktion steuern
Zuverlässigkeit ohne Messung ist Theater. SRE macht Zuverlässigkeit zu einer Zahl, die im Voraus vereinbart und von allen überprüfbar ist.
Service Level Indicator (SLI): eine Messung des Dienstverhaltens. Beispiele: Anfragelatenz, Fehlerrate, Durchsatz, Warteschlangentiefe. Ein SLI ist etwas, das man grafisch darstellen kann.
Service Level Objective (SLO): ein Zielwert oder -bereich für einen SLI. Beispiel: „99,9 % aller HTTP-Anfragen werden innerhalb eines rollierenden 28-Tage-Fensters erfolgreich bearbeitet.“ Ein SLO ist ein Versprechen, das man sich selbst und den Nutzern bezüglich der akzeptablen Dienstqualität gibt.
Service Level Agreement (SLA): eine vertragliche Verpflichtung, in der Regel mit finanziellen Strafen bei Verstoß. Beispiel: „Wir erstatten 10 %, wenn die monatliche Verfügbarkeit unter 99,9 % fällt.“ Ein SLA ist ein durch Anwälte durchsetzbares Versprechen.
Wichtige Unterscheidung: Ihr SLA muss immer lockerer sein als Ihr SLO. Wenn Sie intern 99,9 % anstreben und extern 99,9 % vertraglich zusichern, haben Sie keinen Puffer. SREs setzen SLOs typischerweise eine Neun strenger als das SLA an: 99,95 % Zielwert, 99,9 % Vertrag. Die Lücke gleicht die unvermeidbare schlechte Woche aus.
Error Budgets: Das Inverse SLO
Von Zuverlässigkeitszielen zu technischen Entscheidungen
Ein SLO definiert ein Zuverlässigkeitsziel. Das Error Budget ist das, was übrig bleibt: die Menge an Fehlern, die Sie ausgeben können, bevor Sie das Ziel verfehlen.
Wenn Ihr SLO 99,9 % Erfolg über 28 Tage verspricht, beträgt Ihr Error Budget 0,1 % der Anfragen – oder etwa 40 Minuten vollständiger Ausfallzeit pro Monat. Dieses Budget können Sie nach Belieben ausgeben: für geplante Releases, experimentelle Features, Chaos Engineering oder um eine unzuverlässige Abhängigkeit zu tolerieren.
Error Budgets lösen den Konflikt zwischen Entwicklung und Betrieb auf. Ohne Budget führt jeder Ausfall zu Streit darüber, wer die schlechte Änderung ausgerollt hat und wie man den nächsten verhindert. Mit einem Budget gilt:
- Budget vorhanden: schneller ausliefern, mehr Risiken eingehen, Experimente durchführen. Das Budget deckt die Kosten.
- Budget aufgebraucht: keine neuen Features mehr ausrollen, riskante Änderungen einfrieren, Fokus auf Zuverlässigkeitsarbeit bis das Budget wieder aufgebaut ist.
Dadurch wird Zuverlässigkeit von einer emotionalen Diskussion zu einer messbaren Ressource. Engineers können das Budget bewusst ausgeben – wie jeden anderen Produktionsfaktor.
Toil definieren
Was als Toil gilt
Nicht jede operative Aufgabe zählt als Toil. SRE definiert Toil präzise: Arbeit, die manuell, repetitiv, automatisierbar, taktisch, ohne dauerhaften Wert und linear mit dem Wachstum des Dienstes skaliert.
Alle sechs Eigenschaften müssen zutreffen. Eine einmalige Datenmigration ist manuell, aber nicht repetitiv: das zählt nicht als Toil. Ein Senior Engineer, der eine neue Service-Architektur entwirft, trifft eine taktische Entscheidung, schafft aber dauerhaften Wert: das zählt nicht als Toil.
Beispiele, die als Toil gelten:
- Manuelles Neustarten eines Dienstes nach einem Absturz durch Speicherleck
- Einfügen von Log-Fragmenten in einen Chat-Kanal während der Incident-Triage
- Ausfüllen eines Ticket-Formulars zur Bereitstellung einer neuen Datenbank
- Manuelles Erstellen eines vierteljährlichen Kapazitätsberichts
- Einzelne Routine-Deployment-Anfragen nacheinander genehmigen
Die Fünfzig-Prozent-Regel begrenzt Toil auf die Hälfte der Arbeitszeit einer SRE. Liegt der Anteil über 50 %, muss das Team Verantwortung an ein Produktteam zurückgeben oder zusätzliche Engineers einstellen. Das Ziel bleibt jedoch klar: Toil auf null reduzieren, indem man ihn durch automatisierte Systeme ersetzt, die dieselbe Arbeit ohne menschliches Eingreifen erledigen.
Automatisierung spart nicht nur Zeit. Sie eliminiert eine ganze Klasse menschlicher Fehler. Ein Skript, das eine Datenbank provisioniert, vergisst keine Schritte nach einer langen Schicht.
Toil-Audit-Begründung
Ihr Team verfolgt, wie seine Zeit genutzt wird. Im letzten Quartal ergab sich folgende Aufteilung: 30 % Deployments, 25 % Incident Response, 20 % Kapazitätsarbeit, 15 % Feature-Entwicklung, 10 % einmalige Anfragen von Produktteams.
On-Call-Hygiene
Engineers, Not Pagers
On-Call hat echte Kosten. Der Schlaf wird gestört, Wochenenden werden unterbrochen, und der Stress durch unbekannte Probleme summiert sich. SRE betrachtet On-Call als begrenzte Ressource, die nachhaltig bleiben muss – kein heldenhafter Kraftakt, den diejenigen tragen, denen es am meisten liegt.
Gesunde On-Call-Rotationen folgen mehreren Prinzipien:
- Kompensierte Zeit: On-Call-Stunden werden mit Freizeit, zusätzlicher Bezahlung oder einem vergleichbaren Vorteil ausgeglichen. Unbezahltes On-Call führt zum Burnout des Teams.
- Angemessene Rotationstiefe: Ein Sechs-Personen-Team mit primärer und sekundärer Bereitschaft bedeutet, dass jede Ingenieurin alle drei Wochen eine Schicht übernimmt. Zwei-Personen-Rotationen zerstören Karrieren.
- Seitenvolumen-Budget: Das SRE-Buch von Google empfiehlt maximal zwei Paging-Ereignisse pro zwölfstündiger Schicht. Darüber hinaus muss das Team Engineering-Zeit in die Reduzierung der Alert-Menge investieren, statt sie nur zu ertragen.
- Nur handlungsrelevante Alerts: Jede Seite muss menschliches Handeln erfordern. Wenn eine Seite ignoriert, automatisiert oder während des Normalbetriebs wiederholt ausgelöst wird, sollte sie nicht existieren. Alert Fatigue ist ein Reliability-Defekt.
- Follow-the-Sun-Übergaben: Global verteilte Teams geben Schichten an Zeitzonengrenzen weiter, sodass niemand um 3 Uhr morgens alarmiert wird, es sei denn, das System kann wirklich nicht bis zum Morgen warten.
Blameless Postmortems
Wie Ausfälle zu Verbesserungen werden
Jeder schwerwiegende Vorfall erhält ein Postmortem: eine schriftliche Analyse dessen, was passiert ist, warum, was ihn behoben hat und welche Änderungen ein erneutes Auftreten verhindern. Das Postmortem ist das SRE-Äquivalent von Zinseszins: jedes einzelne fügt dem System dauerhaft mehr Zuverlässigkeit hinzu.
Blameless bedeutet, dass das Dokument Fehler Systemen und Prozessen zuschreibt, niemals einzelnen Personen. Wenn eine Ingenieurin den falschen Befehl ausgeführt hat, fragt das Postmortem: Warum hat das System diesen Befehl zugelassen? Warum hat keine Schutzmaßnahme ihn abgefangen? Welche Änderung am System, der Dokumentation oder den Werkzeugen würde verhindern, dass die nächste Ingenieurin denselben Fehler macht?
Blamelessness existiert aus einem einzigen Grund: Menschen verbergen Fehler, wenn sie Bestrafung fürchten. Verborgene Fehler werden zum nächsten Vorfall. Die Kosten einer blameless-Kultur sind im Vergleich zu den Kosten der Anhäufung unentdeckter Defekte gering.
Postmortems decken typischerweise ab:
- Zusammenfassung: ein Absatz zur Beschreibung des Vorfalls und seiner Auswirkungen
- Zeitachse: minutengenaue Rekonstruktion mit Zeitstempeln
- Ursachenanalyse: technische und prozessbezogene Faktoren, die den Ausfall ermöglicht haben
- Erkennung: wie das Team vom Vorfall erfahren hat und wie lange es gedauert hat
- Behebung: die Maßnahmen zur Wiederherstellung des Dienstes
- Lessons Learned: was funktioniert hat, was nicht
- Maßnahmen: konkrete, zugewiesene, terminierte Engineering-Aufgaben
Maßnahmen werden in einem Tracker verwaltet. Sie werden wie jede andere Engineering-Arbeit priorisiert. Postmortems ohne Maßnahmen bleiben reine Erzählung. Die Arbeit ändert nichts.
Die vier Golden Signals
Was jeder Service messen muss
Googles SRE-Buch schlägt vier Signale vor, die jeder benutzerorientierte Service bereitstellen muss: Latenz, Traffic, Fehler und Sättigung. Zusammen beschreiben sie die Gesundheit des Services aus Sicht der Nutzer. Mit weniger Signalen bleiben blinde Flecken; mit Hunderten von Metriken erstickt das Team in Alert Fatigue.
Latenz: wie lange Anfragen brauchen. Verfolgen Sie Verteilungen, nicht Durchschnitte. p50 (Median) beschreibt die typische Erfahrung. p99 beschreibt die schlechtesten 1 % der Nutzer. Der Durchschnitt allein verbirgt lange Schwänze: Ein Service mit Median 50 ms und p99 5.000 ms sieht beim Durchschnitt gut aus, ruiniert aber einen von hundert Nutzern.
Traffic: die Last auf dem Service. Bei einem Web-Service bedeutet das Anfragen pro Sekunde. Bei einem Streaming-Service gleichzeitige Verbindungen. Bei einem Batch-Job verarbeitete Elemente pro Minute. Traffic korreliert mit Kapazitätsentscheidungen und zeigt Workload-Anomalien.
Fehler: die Rate fehlgeschlagener Anfragen. Explizite Fehler (HTTP 500), implizite Fehler (HTTP 200 mit korrupten Daten) und Policy-Fehler (Antwort zu langsam für das SLO) zählen alle. Die Unterscheidung ist wichtig: Ein 200 mit schlechter Nutzlast schadet Nutzern oft mehr als ein ehrliches 500.
Sättigung: Wie voll das System läuft. CPU-Auslastung, Warteschlangentiefe, Memory-Pressure, Connection-Pool-Belegung. Sättigung prognostiziert zukünftige Latenz: ein System bei 95 % CPU hat nur noch wenig Spielraum, bevor die nutzerseitige Latenz stark ansteigt.
Die meisten SRE-Alarme leiten sich von diesen vier Signalen ab. Symptom-basiertes Alerting (Alarm, wenn Nutzer es bemerken würden) ist wirksamer als Ursachen-basiertes Alerting (Alarm, wenn die CPU 80 % überschreitet). Die vier Golden Signals beschreiben Symptome.
SRE-Karrierewege
Wo SRE-Kenntnisse sich auszahlen
SRE-Karrieren verzweigen sich je nachdem, welchen Teil der Disziplin ein Engineer am meisten genießt:
Infrastructure SRE: baut die Plattformen, auf denen andere Teams laufen. Kubernetes, Service Meshes, internes Cloud. Starke Systemtechnik, Theorie verteilter Systeme und Plattformdesign. Wird bei großen Unternehmen extrem gut bezahlt, weil die Arbeit skaliert: ein Infrastructure SRE unterstützt Hunderte von Produktentwicklern.
Embedded SRE: arbeitet mit einem Produktentwicklungsteam zusammen, um die Zuverlässigkeit eines bestimmten Dienstes zu verbessern. Halb Ingenieur, halb Coach. Starke Kommunikations- und Code-Review-Fähigkeiten sind genauso wichtig wie technische Tiefe. Oft der beste Weg für Ingenieure, die gerne unterrichten.
Reliability Tooling: baut den Observability-Stack: Monitoring, Alerting, Dashboards, Postmortem-Tools, Incident-Management-Plattformen. Starke Frontend- und Data-Engineering-Arbeit. Die Ergebnisse werden von allen anderen Teams genutzt.
Production Engineering: der Begriff von Facebook/Meta für SRE mit Fokus auf Kapazität, Deployment und Traffic-Management. Starke Netzwerk- und Systemarbeit.
Technische Zertifizierungen, die sich lohnen: die Google Cloud Professional Cloud Architect, AWS Solutions Architect Professional und CNCF-Zertifizierungen (Kubernetes Administrator, Kubernetes Application Developer) signalisieren Cloud-Native-Kompetenz. Zertifizierungen der Linux Foundation zeigen Systemtiefe. Keine dieser Zertifizierungen ersetzt Portfolio-Arbeit, aber sie helfen, Recruiter-Screens zu bestehen.
Zusammenfassung
Was Sie jetzt wissen
Site Reliability Engineering begann als Googles Antwort auf ein Skalierungsproblem und hat sich zu einer Disziplin entwickelt, die heute branchenweit praktiziert wird. Sie haben behandelt:
- Der Übergang von manuellen Operationen zu engineered Reliability
- SLIs, SLOs, SLAs und das Inverse-SLO-Konzept von Error Budgets
- Toil-Definition, die 50%-Regel und engineering-getriebene Reduktion
- Nachhaltige On-Call-Rotationen und blameless Postmortem-Praxis
- Die vier Golden Signals als Ausgangspunkt für Service-Monitoring
- SRE-Karrierewege und die Zertifizierungen, die Türen öffnen
Zwei Ideen sind am wichtigsten. Zuverlässigkeit ist eine Zahl, die im Voraus vereinbart wird. Und Toil ist ein Defekt, keine Jobbeschreibung. Wenn du diese beiden Prinzipien mitnimmst, ergibt sich der Rest von SRE ganz natürlich.
Empfohlene Lektüre: Googles SRE-Buch (kostenlos online: sre.google/books/), das SRE Workbook mit praktischen Übungen und Charity Majors’ Texte zum Thema Observability. Die begleitende „geometry-of“-Lektion geht tiefer auf die visuelle Struktur unter der SRE-Praxis ein: Latenzverteilungen, Error-Budget-Kegel, Abhängigkeitsgraphen und Dashboard-Layouts.