Was ist Site Reliability Engineering? Einfach erklärt

Was ist Site Reliability Engineering? Es ist die Praxis, Produktionssysteme mit Software-Engineering statt mit manuellen Betriebsabläufen zu führen. Ein SRE-Team legt ein numerisches Zuverlässigkeitsziel fest, misst dagegen und automatisiert die wiederkehrende Arbeit, die Dienste am Laufen hält. Wenn Sie jeden Monat um drei Uhr nachts wegen desselben Festplattenalarms geweckt werden, ist das genau das Problem, das SRE beseitigen soll.

Google hat den Begriff um 2003 geprägt. Heute wird die Idee weit über Google hinaus genutzt, von Startups mit 20 Leuten bis zu Banken. Was sich dazwischen ändert, ist der Umfang, nicht die Kernmechanik.

Was macht ein Site Reliability Engineer eigentlich?

Ben Treynor Sloss, der das SRE-Team bei Google aufgebaut hat, bringt es im einleitenden Kapitel des Google-SRE-Buchs auf den Punkt: SRE ist das, was entsteht, wenn man einen Software-Ingenieur bittet, ein Betriebsteam zu entwerfen. Die Arbeit ist Betrieb, der mit Code erledigt wird.

In einer normalen Woche bedeutet das vier Dinge. Sie legen fest, was »funktionieren« für einen Dienst heißt. Sie bauen das Monitoring, das Ihnen meldet, wenn es nicht funktioniert. Sie reagieren, wenn etwas kaputtgeht, und Sie schreiben den Fix, damit die nächste Person nicht für dieselbe Sache geweckt wird.

Zwei Beispiele machen das greifbar. Ein Team, das jeden Donnerstag von Hand ausliefert, baut eine Pipeline mit automatischem Rollback. Ein Team, das einen undichten Dienst jede Nacht neu startet, sucht den Leak. Beide verwandeln eine wiederkehrende Pflicht in ein einmaliges Projekt, und genau darum geht es.

Der vierte Teil wird am häufigsten übersprungen. Ein SRE, der nur auf Vorfälle reagiert, ist ein Ops-Ingenieur mit neuem Titel. Der Engineering-Anteil macht die Rolle erst zu einer anderen.

Worin unterscheidet sich SRE von DevOps?

DevOps ist eine Kultur: Entwickler und Betreiber teilen sich die Verantwortung dafür, was ausgeliefert wird und wie es läuft. Es sagt Ihnen, dass die Mauer zwischen den Teams ein Problem ist. Es sagt Ihnen aber nicht, wie viel Ausfall akzeptabel ist oder wann Sie mit dem Ausliefern aufhören sollten.

SRE liefert die Zahlen. Es stellt Service Level Objectives, Error Budgets und eine Obergrenze für manuelle Arbeit bereit. Googles eigene Sichtweise ist, dass SRE eine konkrete Umsetzung der DevOps-Ideen ist.

Die Debatte, welches Modell »besser« ist, können Sie sich sparen. Wenn Sie ein Team mit acht Personen führen, übernehmen Sie aus beiden Welten. Die nützliche Frage lautet, ob Ihr Team in einem Satz beantworten kann, wie zuverlässig ein bestimmter Dienst sein muss.

Was sind SLIs, SLOs und SLAs, und warum sind sie wichtig?

Drei Abkürzungen tragen den Großteil des Gewichts in SRE, und sie werden ständig verwechselt.

• SLI (Service Level Indicator): eine Messgröße. Zum Beispiel der Anteil der HTTP-Anfragen, die ohne 5xx-Antwort in unter 300 ms beantwortet werden.

• SLO (Service Level Objective): das Ziel für diese Messgröße. Zum Beispiel 99,9 % der Anfragen über ein rollierendes Fenster von 28 Tagen.

• SLA (Service Level Agreement): der Vertrag mit Konsequenzen, meist Rückerstattungen, wenn das Ziel verfehlt wird. Ihr SLA sollte lockerer sein als Ihr SLO.

Der Grund, sich damit zu beschäftigen: »Die Seite soll schnell und zuverlässig sein« lässt sich nicht testen. Ein Ziel wie »99,9 % der Checkout-Anfragen sind in unter 500 ms erfolgreich« lässt sich testen, und damit lassen sich Diskussionen beenden.

Beginnen Sie mit zwei oder drei SLIs pro Dienst. Mehr, und niemand erinnert sich daran.

Wählen Sie SLIs, die Nutzer tatsächlich spüren. CPU-Auslastung ist eine Ursache, kein Symptom. Fehlgeschlagene Checkouts, langsame Seitenaufbauten und veraltete Daten sind das, was Kundschaft bemerkt.

Wie funktionieren Error Budgets?

Ein Error Budget ist die Unzuverlässigkeit, die Ihr SLO erlaubt. Es ist schlicht 1 minus SLO. Ein Verfügbarkeitsziel von 99,9 % lässt 0,1 % übrig, also etwa 43 Minuten Ausfall in einem Monat mit 30 Tagen.

Hier ist eine kleine Version in Code, weil die Rechnung die ganze Idee ist:

slo = 0.999
window_minutes = 30 * 24 * 60          # 43.200
budget = (1 - slo) * window_minutes    # 43,2 Minuten
spent = 31                              # Minuten schlechter Verfügbarkeit bisher
print(f"{budget - spent:.1f} Minuten übrig")  # 12.2 Minuten übrig

Solange Budget übrig ist, liefert das Team schnell aus. Ist es aufgebraucht, werden Feature-Releases angehalten und die Arbeit verlagert sich auf Zuverlässigkeit. Das Beispiel einer Error-Budget-Richtlinie im SRE Workbook zeigt, wie ein Team diese Regel niederschreibt.

Es geht nicht um Strafe. Die Zahl ersetzt den alten Streit, in dem Entwickler ausliefern wollen und Betreiber Stabilität wollen, durch einen gemeinsamen Wert, den beide Seiten lesen können. Das funktioniert nur, wenn die Führung vorab zustimmt, die Pause zu respektieren. Eine Budget-Richtlinie, die jedes Quartal überstimmt wird, ist reine Dekoration.

Warum gibt es die 50-%-Regel für Toil?

Toil ist manuelle, repetitive Arbeit, die mit Ihrem Dienst wächst und nichts Bleibendes hinterlässt. Einen hängenden Worker von Hand neu zu starten, ist Toil. Den Health Check zu schreiben, der ihn automatisch neu startet, ist Engineering.

Die SRE-Organisation bei Google strebt an, Toil unter 50 % der Zeit jedes Ingenieurs zu halten, wie im Kapitel über das Eliminieren von Toil beschrieben. Der Rest fließt in Projekte, die künftigen Toil verringern oder Funktionen hinzufügen. Die Begründung ist nüchtern: Toil füllt 100 % der Zeit aller, wenn ihn niemand stoppt.

Behandeln Sie die 50 % als Obergrenze, nicht als Ziel. Ein gesundes Team mit einem ausgereiften Dienst liegt deutlich darunter. Liegen Sie ein Quartal lang darüber, betreiben Sie kein SRE mehr, sondern eine Ops-Warteschlange.

Ein einfacher Einstieg: Zwei Wochen lang markieren Sie jedes Ticket und jeden Alarm als Toil oder Projekt. Dann sortieren Sie den Toil nach Stunden. Die drei größten Posten sind Ihr Automatisierungs-Backlog.

Was ändern schuldfreie Postmortems?

Wenn etwas kaputtgeht, fragt das Postmortem, wie das System einer Person erlauben konnte, diesen Fehler zu machen, nicht wer ihn gemacht hat. Schuldzuweisung bringt Menschen bei, Informationen zu verstecken. Ein schuldfreier Review bringt ihnen bei, sie aufzuschreiben.

Ein brauchbares Postmortem ist kurz und hat vier Teile: eine Zeitleiste, die beitragenden Ursachen, was gut lief, und Maßnahmen mit Verantwortlichen und Terminen. Maßnahmen ohne Verantwortliche sind Wünsche.

Der größte Nutzen entsteht bei der Nachverfolgung. Gehen Sie offene Maßnahmen monatlich durch. Taucht dieselbe Ursache innerhalb von sechs Monaten zweimal auf, ist das erste Postmortem gescheitert, egal was im Dokument stand.

Welche Tools braucht ein SRE-Team zuerst?

Nicht viele. Fangen Sie bei den Signalen an, dann kommen Bereitschaftsdienst und Automatisierung dazu.

1. Metriken und Dashboards. Genug, um Ihre SLIs zu berechnen. Grafana und Prometheus sind eine verbreitete Open-Source-Kombination, Datadog und New Relic sind der gehostete Weg.

2. Alerting auf Basis der SLOs. Alarmieren Sie, wenn das Budget schnell verbrannt wird, nicht wenn ein einzelner Host kurz ausschlägt. Weniger Pages, bessere Pages.

3. Feature Flags und graduelles Rollout. Grob gesagt werden die meisten Ausfälle durch eine Änderung ausgelöst, also ist der günstigste Zuverlässigkeitsgewinn, Änderungen umkehrbar zu machen. LaunchDarkly und Statsig decken das ab.

4. Ein schriftliches Runbook für jede Page. Hat ein Alarm kein Runbook, schreiben Sie eins oder löschen Sie den Alarm.

Kaufen oder selbst bauen, in dieser Reihenfolge. Teams, die mit einem Tool-Kauf ohne SLO beginnen, enden mit schönen Dashboards für nichts Bestimmtes.

Wo passt das Lesen fremden Codes in SRE?

Das steht selten in der Stellenbeschreibung. Während eines Vorfalls muss ein SRE oft einen Dienst verstehen, den er nicht geschrieben hat, in einem Repository, das er seit Monaten nicht geöffnet hat. Die Frage ist selten abstrakt. Sie lautet: »Wo lebt diese Retry-Schleife, und was passiert bei einem Timeout?«

Das kennen Sie: grep, blame, dann die Person fragen, die die Datei zuletzt angefasst hat. Bei einem Repository mit 80.000 Zeilen funktioniert das. Bei zwölf Diensten von sechs Teams frisst es die ersten 20 Minuten eines Vorfalls, und diese Minuten zählen gegen das Budget.

Hier lohnt sich ein Suchwerkzeug für den Code, das Fragen zum eigenen Repository beantwortet, etwa wo ein Dienst seine Timeouts setzt und welche Aufrufer davon abhängen. Es behebt den Ausfall nicht. Es verkürzt die Zeit, die Sie mit Lesen verbringen, bevor Sie handeln können, und diese Zeit lässt sich messen.

Ist SRE für Ihr Team zu viel, und wie fangen Sie an?

Auf ein eigenes SRE-Team können Sie verzichten, wenn Sie einen Dienst haben, eine Handvoll Ingenieure und Nutzer, die eine gelegentlich schlechte Stunde ertragen. Sie brauchen dann kein Team. Sie brauchen ein SLO, einen brauchbaren Alarm und jemanden, der den Bereitschaftsdienst verantwortet.

Denken Sie darüber nach, sobald eines davon zutrifft: Ausfälle kosten echten Umsatz, der Bereitschaftsdienst zermürbt Menschen, oder Entwickler werden durch ad hoc-Betriebsanfragen ausgebremst. Viele Unternehmen machen zuerst ein oder zwei Ingenieure zu SREs in Teilzeit und schauen, wie es läuft.

Ein häufiger Fehler ist, das Ops-Team umzubenennen, ohne die Arbeitsweise zu ändern. Besitzt das Team weiterhin Tickets, manuelle Deployments und kein Error Budget, hat sich nur der Titel geändert.

So fangen Sie nächste Woche an

Sie brauchen keine Reorganisation. Wählen Sie den nutzersichtbaren Dienst, der am meisten wehtut, und tun Sie fünf Dinge.

1. Schreiben Sie einen SLI und ein SLO dafür. Halten Sie beides schlicht.

2. Berechnen Sie das Error Budget und stellen Sie es auf ein Dashboard, das das ganze Team sieht.

3. Erfassen Sie zwei Wochen lang den Toil und wählen Sie den größten Posten zur Automatisierung.

4. Halten Sie für Ihren nächsten Vorfall ein schuldfreies Postmortem mit verantwortlichen Maßnahmen.

5. Legen Sie schriftlich fest, was passiert, wenn das Budget auf null fällt.

Wenn das Team in einem Monat weniger darüber streitet, ob es ausliefern soll, und mehr darüber, was die Zahlen sagen, funktioniert es. Bewegt sich das Budget nie, weil das SLO zu locker ist, ziehen Sie es an.