Was ist Site Reliability Engineering? SRE einfach erklärt

Was ist Site Reliability Engineering? Im Kern ist es der Ansatz, Betrieb wie ein Softwareproblem zu behandeln. Man legt ein messbares Zuverlässigkeitsziel fest, zählt, wie oft es verfehlt wird, und lässt diese Zahl entscheiden, ob neue Features oder Reparaturen Vorrang haben. Google hat den Begriff geprägt, aber die Idee funktioniert in jeder Größenordnung. Für einen Solo-Entwickler mit einer App und ein paar Dutzend Nutzern heißt das vor allem: vorab festlegen, wie viel Ausfallzeit man akzeptiert.

Das Problem in der Praxis: Die meisten Side Projects haben so eine Zahl nicht. Sie sind "oben", bis jemand eine E-Mail schreibt. Dieser Artikel erklärt SRE in einfachen Worten und schrumpft es auf etwas, das eine Person an einem Wochenende aufsetzen kann.

Was SRE wirklich bedeutet

Die kürzeste Fassung stammt aus dem SRE-Buch von Google: SRE ist das, was herauskommt, wenn man einen Software-Ingenieur ein Betriebsteam entwerfen lässt. Statt dass Menschen Server von Hand neu starten, schreibt man Code, der das erledigt, und misst die Ergebnisse.

Drei Ideen tragen den Großteil. Zuverlässigkeit ist ein Feature mit einem Ziel, kein Bauchgefühl. Wiederkehrende Handarbeit, die das Buch Toil nennt, ist ein Fehler, der automatisiert werden sollte. Und Ausfälle gehören dazu, deshalb plant man, wie man aus ihnen lernt, statt wie man Schuldige findet.

DevOps und SRE überschneiden sich stark. Der praktische Unterschied: DevOps ist eine Kultur, Code gemeinsam auszuliefern und zu betreiben. SRE liefert konkrete Werkzeuge, um darüber mit Zahlen zu streiten. Man muss sich für keines der beiden Lager entscheiden, um die Zahlen zu nutzen.

Im Alltag eines SRE in einem großen Unternehmen geht die Zeit auf Bereitschaftsdienst, Incident-Management, Kapazitätsplanung und Automatisierung. Das Google-Buch empfiehlt, die operative Last auf etwa die Hälfte der Arbeitszeit zu begrenzen, damit der Rest in Engineering fließt. Diese Grenze ist eine Gestaltungsvorgabe, kein nettes Extra. Die wiederkehrende Arbeit sieht dabei so aus:

• SLOs zusammen mit Produktteams festlegen und bei Budget-Verbrauch alarmieren, nicht bei jedem Ausreißer

• Bereitschaftsrotationen führen und Runbooks schreiben, damit die Nachtmeldung um 3 Uhr eine Checkliste hat

• Incidents leiten und danach ein Postmortem ohne Schuldzuweisung schreiben

• Alles automatisieren, was man mehr als ein paarmal von Hand macht

• Releases vor dem Livegang auf Zuverlässigkeitsrisiken prüfen

Feature Flags sind ein gutes Beispiel für diese Denkweise. Ein Flag lässt dich ein fehlerhaftes Release in Sekunden abschalten, ohne neu zu deployen, und das schont das Budget. Ob du dafür ein gehostetes Tool brauchst, hängt davon ab, wie viele Flags du hast: Für die ersten drei reicht eine Umgebungsvariable.

SLI, SLO, SLA: drei Abkürzungen, eine Idee jeweils

Ein SLI (Service Level Indicator) ist etwas, das man misst. Bei einer Web-App ist das meist der Anteil erfolgreicher Requests oder der Anteil, der in unter 300 ms antwortet. Wähle einen oder zwei. Nicht zwölf.

Ein SLO (Service Level Objective) ist das Ziel für diese Messung, zum Beispiel "99,9 % der Requests sind über 30 Tage erfolgreich". Das ist intern. Es ist ein Versprechen an dich selbst.

Ein SLA (Service Level Agreement) ist ein Vertrag mit einem Kunden, meist mit Rückerstattung, falls er verfehlt wird. Wenn dir niemand für Verfügbarkeit Geld zahlt, hast du noch kein SLA, und du solltest keins versehentlich in den Text deiner Preisseite schreiben.

Error Budgets: der Teil, der die Arbeitsweise ändert

Das Error Budget ist schlicht 100 % minus dein SLO. Ein Ziel von 99,9 % über 30 Tage lässt etwa 43 Minuten erlaubte Ausfallzeit. Dieses Budget ist das, was du für riskante Deployments, Migrationen und Experimente ausgeben kannst.

Ein Beispiel aus der Praxis: Du deployst am Dienstag eine Migration, die zwölf Minuten Ausfall verursacht. Bei 99,9 % ist das gut ein Viertel des Monatsbudgets, und die Zahl wirkt als Bremse. Der nächste riskante Umbau wartet dann bis nach einer ruhigen Woche. Niemand muss dir sagen, dass du vorsichtiger sein sollst. Die Zahl sagt es dir.

Der nützliche Teil ist die Regel dahinter. Solange Budget übrig ist, wird ausgeliefert. Ist es aufgebraucht, stoppst du Features und behebst Zuverlässigkeitsprobleme, bis sich das Budget erholt. Das Kapitel des Buchs zum Risiko beschreibt das als Weg, den Streit zwischen "schneller werden" und "nichts kaputt machen" mit einer gemeinsamen Zahl zu entscheiden statt mit einer endlosen Verhandlung.

Es enthält außerdem einen unbequemen Hinweis, der sich lohnt zu wiederholen: 100 % ist fast nie das richtige Ziel. Nutzer im schwachen Mobilfunknetz merken keinen Unterschied zwischen 99,99 und 99,9 %, und jede weitere Neun kostet deutlich mehr als die vorherige. Das Ziel ist damit nicht perfekt. Es ist aber brauchbar.

Wenn du den konkreten Ablauf zum Festlegen von Indikatoren und dem ersten Ziel willst, ist das Workbook-Kapitel zur Umsetzung von SLOs das praktischste und dabei ziemlich kurz.

Brauchst du SRE, wenn du allein baust?

Drei Gründe dafür, einer dagegen.

Dafür spricht: Dein eigenes Projekt wird dich irgendwann wecken. Ein schriftliches Ziel hält dich davon ab, zu überkonstruieren. Und "Ich betreibe Produktion mit einem SLO" wirkt gut, wenn jemand entscheidet, ob er dich einstellt oder dir vertraut. Dagegen spricht: Hat dein Projekt noch keine Nutzer, übst du für ein Problem, das du nicht hast. Erst bauen, messen, sobald jemand davon abhängt.

Ein typischer Fall: Du bist im Urlaub, und das Projekt ist seit zwei Stunden nicht erreichbar, weil ein Zertifikat abgelaufen ist. Mit einem Health-Check und einem Push-Alarm hättest du es vor der ersten Nutzer-Mail gewusst.

Also lass das volle Instrumentarium weg. Miete für ein Hobbyprojekt keinen Pager-Dienst, betreibe kein Kubernetes, nur um seriös zu wirken, und schreib keine zehnseitige Incident-Vorlage. Lohnend wird es, sobald zehn echte Nutzer da sind: ein Health-Check, ein SLO und ein Ort, an dem du nachsiehst, wenn es bricht.

Ein Gedanke zur Karriere: Ob SRE etwas für dich ist, hängt davon ab, was dir Freude macht. Rollen in diesem Bereich passen zu Leuten, die Systeme, Fehlerbilder und Automatisierung mehr mögen als das Ausliefern von Oberflächen. Wenn dich befriedigt, dass der Pager ruhiger wird, wirst du es mögen. Wenn du lieber siehst, wie Nutzer dein neues Feature anklicken, eher nicht. Der Einstieg führt meist über Backend- oder Infrastrukturarbeit, Linux-Grundlagen, Netzwerk und einen Cloud-Anbieter. Side Projects sind ein fairer Ort, all das zu üben, weil du das ganze Team bist.

Ein SRE-Setup für ein Side Project an einem Abend

Hier ist das Minimum, das tendenziell auch bei 10.000 Nutzern hält. Es dauert einen Abend. Getestet, nicht optimal. Warum wir es trotzdem so machen: Es ist langweilig, und Langweiliges hält.

Erstens: Wähle einen SLI, den Anteil der HTTP-Requests, die keinen 5xx-Fehler liefern. Zweitens: Setze das SLO auf 99,5 % über 30 Tage. Das sind etwa 3,6 Stunden Budget. Starte locker und zieh später nach. Drittens: Richte einen externen Uptime-Check ein, der einen echten Health-Endpunkt aufruft.

Ein Health-Endpunkt ist nur etwas wert, wenn er die Dinge prüft, die tatsächlich brechen, und nicht nur, ob der Prozess noch lebt:

// GET /healthz
app.get("/healthz", async (req, res) => {
  try {
    await db.query("select 1");          // Datenbank erreichbar
    await cache.ping();                  // Cache erreichbar
    res.status(200).json({ ok: true });
  } catch (err) {
    res.status(503).json({ ok: false });
  }
});

Viertens: Schick Alarme dorthin, wo du sie wirklich siehst, also als Push auf das Handy und nicht in ein Postfach. Fünftens: Führe eine einfache Textdatei namens postmortems.md und trage nach jedem Ausfall vier Zeilen ein: was passiert ist, warum, wie lange, und was sich ändert. Diese Datei ist das am meisten unterschätzte Zuverlässigkeitswerkzeug, das du besitzen wirst.

Wo KI-Tools helfen und wo nicht

KI-Assistenten sind brauchbar bei der Handarbeit: den Health-Check schreiben, das Terraform für einen Uptime-Monitor, einen ersten Entwurf eines Runbooks oder ein Skript, das Logs nach der 5xx-Rate durchsucht. Schlecht sind sie darin, dein SLO festzulegen, denn das ist eine Produktentscheidung darüber, was deine Nutzer tolerieren.

Im Incident ist Vorsicht angebracht. Ein Assistent kann eine plausible Lösung vorschlagen, die du um 2 Uhr nachts auf Produktion anwendest, ohne sie gelesen zu haben. Nutze ihn, um einen Stack-Trace zu erklären oder das Postmortem danach zu entwerfen, und lass die Rollback-Entscheidung bei einem Menschen, der wach ist.

Qualitäts-Gates gehören in dieses Bild ebenfalls. Viele Ausfälle lassen sich auf eine Änderung zurückführen, die im Review harmlos aussah. Statische Analyse in der CI bringt dir keine Zuverlässigkeit von selbst, aber sie entfernt eine Klasse dummer Fehler, bevor sie Budget kosten.

Postmortems und Burn-Rate-Alarme

Halte ein Postmortem kurz und ohne Schuldzuweisung. Ohne Schuldzuweisung heißt nicht, dass niemand Verantwortung trägt. Es heißt, dass du fragst, was im System den Fehler möglich gemacht hat, und nicht, wer ihn gemacht hat. Wenn du das einzige Teammitglied bist, wiegt das schwerer, als es klingt, weil die Versuchung groß ist, sich schlecht zu fühlen und das Protokoll zu überspringen.

Vier Überschriften reichen: was passiert ist, warum es passiert ist, wie lange Nutzer betroffen waren und was sich ändert. Die letzte sollte eine Aktion benennen, die du wirklich umsetzt, mit Datum. "Künftig vorsichtiger sein" ist keine Aktion. "Vor dem nächsten Release eine Staging-Prüfung für Migrationen ergänzen" schon. Über ein Jahr wird diese Datei zu einer Karte deiner Schwachstellen. Taucht dieselbe Ursache zweimal auf, automatisiere sie. Nach drei Ausfällen durch dasselbe abgelaufene Zertifikat war die Erneuerungsüberwachung in einem Abend eingerichtet, und seitdem ist das nicht wieder passiert.

Ein typischer Anfängerfehler ist, sich bei jedem einzelnen fehlgeschlagenen Request zu alarmieren. Nach einer Woche stummschaltest du den Kanal. Ein besseres Signal ist die Burn Rate: wie schnell du das Error Budget verbrauchst, verglichen mit dem Tempo, das es genau am Ende des Zeitfensters aufbrauchen würde.

Für ein Side Project bleibt das grob. Schick eine Push-Benachrichtigung, wenn die Fehlerrate der letzten zehn Minuten über 5 % liegt, und eine E-Mail-Zusammenfassung, wenn die Wochenrate auf ein Verfehlen des SLO zuläuft. Damit hast du zwei Stufen: jetzt aufwachen oder am Montag nachsehen. Alles Ausgefeiltere kann warten, bis sich Nutzer über die erste Stufe beschweren.

Was als Nächstes bauen

Nimm eines deiner laufenden Projekte, auch eine kostenlose App, und schreib den SLI, das SLO und die genaue Aktion auf, die du ergreifst, wenn das Budget aufgebraucht ist. Wenn du nicht sagen kannst, was du dann abschalten würdest, ist die Zahl nur Dekoration. Welches deiner Projekte würdest du bemerken, wenn es ausfällt, bevor ein Nutzer es dir sagt?