SLIs, SLOs, SLAs und Error Budgets

Drei Begriffe, eine Idee

Kapitel 2 hat Verfügbarkeitsziele und die Neunen eingeführt (Abschnitt 2.5) und gezeigt, dass 99,9 % über 30 Tage 43,2 Minuten übrig lassen. Dieser Abschnitt macht aus dieser Rechnung eine Betriebsdisziplin. Das Vokabular stammt aus Googles Buch Site Reliability Engineering (Beyer, Jones, Petoff und Murphy, O’Reilly, 2016) und seinem Begleitband The Site Reliability Workbook (2018) und wird heute weit über Google hinaus verwendet.

Ein Service Level Indicator (SLI) ist ein sorgfältig definiertes, quantitatives Maß für einen Aspekt des Service, den Nutzer erhalten. Die nützlichste Form ist ein Verhältnis: gute Ereignisse geteilt durch gültige Ereignisse. Der Anteil der Checkout-Anfragen, die innerhalb von 800 ms eine erfolgreiche Antwort liefern, gemessen am Load Balancer ist ein SLI. Es reicht von 0 % (nichts funktioniert) bis 100 % (nichts ist kaputt), und die Verhältnisform bedeutet, dass sich jedes SLI auf dieselbe Weise lesen, vergleichen und mit Alerts versehen lässt.

Ein Service Level Objective (SLO) ist ein Ziel für ein SLI über ein festgelegtes Zeitfenster: 99,9 % der Checkout-Anfragen sind gut, gemessen über gleitende 28 Tage. Es ist ein internes Versprechen, auf das sich das Team, der Product Owner und die Menschen einigen, die von dem Service abhängen. Ein Service Level Agreement (SLA) ist ein Vertrag mit Kunden, der Konsequenzen benennt, meist Service-Gutschriften, wenn ein Niveau verfehlt wird. Viele Services haben SLOs, aber kein SLA; interne Plattformen haben fast nie SLAs.

Die Idee, die alle drei verbindet, ist das Error Budget. Liegt das Ziel bei 99,9 %, dürfen 0,1 % der Ereignisse schlecht sein, ohne dass jemand versagt hat. Diese 0,1 % sind keine Verschwendung; sie sind der Spielraum, den das Team hat, um Risiken einzugehen: Features ausliefern, Migrationen durchführen, mit der Konfiguration experimentieren. Das Budget macht aus einer Diskussion über Gefühle (Ist der Service zuverlässig genug?) eine Diskussion über Zahlen (Haben wir unser Budget verbraucht?) und gibt Produkt und Engineering eine gemeinsame Regel dafür, wann man schnell vorangeht und wann man bremst.

Gute SLIs wählen

Ein SLI ist nur so nützlich, wie es nah an dem liegt, was Nutzer erleben. Das Workbook bietet eine kurze Auswahl, die die meisten Services abdeckt. Anfragegetriebene Services (APIs, Webseiten) brauchen Verfügbarkeit (der Anteil gültiger Anfragen, die erfolgreich bedient werden), Latenz (der Anteil, der schneller als ein Schwellenwert bedient wird) und manchmal Qualität (der Anteil, der ohne Einschränkung bedient wird, etwa eine Speisekarte, die ohne personalisierte Empfehlungen angezeigt wird, weil diese Abhängigkeit ausgefallen war). Datenpipelines brauchen Aktualität (der Anteil der Daten, die vor kürzerer Zeit als ein Schwellenwert aktualisiert wurden), Korrektheit (der Anteil der Ausgabe, der stimmt) und Abdeckung (der Anteil der verarbeiteten Eingabe). Speichersysteme ergänzen Dauerhaftigkeit (der Anteil geschriebener Daten, der noch gelesen werden kann).

Latenz-SLIs werden als Anteile geschrieben, nicht als Mittelwerte: 99 % der Speisekarten-Anfragen schneller als 300 ms. Das knüpft direkt an die Perzentile aus Abschnitt 2.4 an: Zu sagen, 99 % der Anfragen müssen unter 300 ms liegen, ist dasselbe wie zu sagen, p99 muss unter 300 ms liegen, aber die Anteilsform lässt sich sauber über Zeit und Server addieren (man zählt die guten und die gültigen), Perzentile dagegen nicht. Üblich sind zwei Latenzschwellen, zum Beispiel 90 % unter 200 ms und 99 % unter 800 ms, um sowohl das typische als auch das Tail-Erlebnis zu erfassen.

Wo Sie messen, ist ebenso wichtig wie was Sie messen. Das Workbook trennt die SLI-Spezifikation (das für Nutzer relevante Ergebnis, etwa erfolgreich aufgegebene Bestellungen) von der SLI-Implementierung (wie Sie es zählen: Serverlogs, Load-Balancer-Metriken, synthetische Probes oder Instrumentierung in der Mobil-App). Wer im Anwendungsserver misst, verpasst Anfragen, die ihn nie erreicht haben, weil DNS, das Content Delivery Network oder der Load Balancer ausgefallen ist. Wer im Client misst, sieht alles, erfasst aber auch schlechte Mobilverbindungen der Nutzer und kommt verspätet an. Die meisten Teams beginnen mit Load-Balancer-Metriken, die günstig und nah am Rand sind, und ergänzen synthetische Probes für Pfade mit wenig Traffic.

Legen Sie genau fest, was als gültig und was als gut zählt, denn die Grenzfälle entscheiden, ob die Zahl etwas bedeutet. Ist ein 404 für eine vertippte URL schlecht? Meist nicht: Es ist eine korrekte Antwort. Ist eine 429-Antwort wegen Rate Limiting schlecht? Das hängt davon ab, ob der Client innerhalb seines vereinbarten Kontingents lag. Sind Health Checks und Lasttests gültige Ereignisse? Nein; schließen Sie sie aus, sonst verwässern sie das Verhältnis. Schreiben Sie diese Regeln neben das SLO.

Das Ziel festlegen

Ein Ziel ist eine geschäftliche Entscheidung, keine technische. Die Kosten jeder weiteren Neun steigen steil, während Nutzer ab einem gewissen Punkt keine Verbesserungen mehr bemerken, weil ihr eigenes Mobilfunknetz, ihr WLAN und ihre Geräte häufiger ausfallen. Googles SRE-Buch sagt es unverblümt: 100 % anzustreben ist für fast alles falsch, weil es kein Budget für Änderungen lässt, ein Vermögen kostet und ohnehin nicht erreichbar ist. Ein Ziel von 100 % macht außerdem jeden einzelnen Ausfall zu einem Policy-Verstoß, was Menschen lehrt, das SLO zu ignorieren.

Gute Ausgangspunkte sind die bisherige Leistung (was hat der Service im letzten Quartal erreicht, und waren die Nutzer zufrieden?), die Ziele der Services, von denen Sie abhängen (Sie können keine 99,99 % auf einer Datenbank mit 99,9 % versprechen, wie Abschnitt 6.1 für Aufrufketten gezeigt hat), und die geschäftlichen Kosten mangelnder Zuverlässigkeit. Für die Essenslieferplattform kosten fehlgeschlagene Bestellungen zur Mittagszeit Umsatz und Kundenvertrauen, daher sind 99,9 % bei der Bestellaufgabe vertretbar; Aktualisierungen der Kurierposition sind weniger kritisch, und 99 % genügen. Beginnen Sie etwas unterhalb der aktuellen Leistung, damit das Team nicht sofort im Verstoß ist, und verschärfen Sie später anhand von Belegen.

Wählen Sie das Zeitfenster bewusst. Ein gleitendes Zeitfenster wie die letzten 28 Tage entspricht der Art, wie Nutzer sich an Ausfälle erinnern (sie vergessen sie nicht am Monatsersten), und 28 Tage enthalten genau vier von jedem Wochentag, was wöchentliche Muster fair hält. Kalendermonate eignen sich für Berichte und Verträge. Ereignisbasierte Services wie ein Ticket-Vorverkaufsstart brauchen unter Umständen ein SLO pro Ereignis, weil eine Stunde Ausfall während des Vorverkaufsstarts weit mehr zählt als eine ruhige Woche.

Error Budgets in Zahlen

Das Error Budget lässt sich in Zeit oder in Ereignissen zählen. Zeitbasierte Budgets passen zu Services, die entweder laufen oder ausgefallen sind; anfragebasierte Budgets sind fairer für Services mit ungleichmäßigem Traffic, weil ein Ausfall um 03:00 weniger Nutzer trifft als einer zur Mittagszeit.

Error-Budget-Policies

Ein Budget bedeutet nichts, wenn nichts passiert, sobald es aufgebraucht ist. Eine Error-Budget-Policy ist ein kurzes Dokument, das Engineering, Produkt und Leitung im Voraus vereinbaren und das festlegt, was das Team tun wird. Die Beispiel-Policy im Workbook misst das Budget über die zurückliegenden vier Wochen; überschreitet der Service sein Budget, stoppen alle Änderungen und Releases außer dringenden Fixes (P0-Probleme) und Sicherheitsfixes, bis der Service wieder innerhalb seines SLO liegt. Sie verlangt außerdem ein Postmortem mit mindestens einer Maßnahme höchster Priorität, wann immer ein einzelner Incident mehr als 20 % des Vier-Wochen-Budgets verbraucht, und eskaliert Meinungsverschiedenheiten an den Chief Technology Officer.

Der Wert einer Policy liegt darin, dass sie vereinbart ist, bevor sie greift. Mitten im Release-Endspurt will niemand einfrieren; mit einer unterzeichneten Policy ist der Freeze eine vorab vereinbarte Regel statt eines Streits zwischen einer SRE und einem Produktmanager. Gute Policies legen auch fest, was nicht zulasten des Teams geht: ein unternehmensweiter Netzwerkausfall, eine Abhängigkeit, die selbst eingefroren ist, oder Traffic außerhalb des Geltungsbereichs des SLO, etwa ein Lasttest.

Fachleute sind uneins darüber, wie mechanisch die Policy sein sollte. Manche Teams wenden sie streng an, weil Ausnahmen das Vertrauen in das ganze System untergraben. Andere sehen das Budget als Information für ein Gespräch und argumentieren, dass ein harter Freeze genau die Fixes verzögern kann, die die Zuverlässigkeit wiederherstellen würden. Ein Mittelweg ist verbreitet: riskante Feature-Releases automatisch einfrieren, Zuverlässigkeitsfixes weiter ausliefern und einer benannten Führungskraft erlauben, dokumentierte Ausnahmen zu gewähren. Auch der umgekehrte Fall zählt: Ein Team, das sein Budget nie ausgibt, ist wahrscheinlich zu vorsichtig und könnte schneller ausliefern, mehr Experimente durchführen oder seine Kosten senken.

Burn Rate und Alerting auf SLOs

Alerting auf rohe Fehlerraten (alarmieren, wenn mehr als 1 % der Anfragen 5 Minuten lang fehlschlagen) ist laut: Kurze Ausreißer wecken nachts Menschen für Probleme, die das SLO nie gefährden würden, während eine stetige Fehlerrate von 0,5 % still den Monat aufbrauchen kann, ohne je die Schwelle zu überschreiten. Die Antwort des Workbook ist, auf die Burn Rate zu alarmieren: wie schnell das Budget verbraucht wird, verglichen mit der Rate, die es genau am Ende des Zeitfensters aufbrauchen würde.

Burn Rate = beobachtete Fehlerquote / erlaubte Fehlerquote. Bei einem SLO von 99,9 % liegt die erlaubte Quote bei 0,1 %, also entspricht eine Fehlerquote von 0,1 % einer Burn Rate von 1 (das Budget reicht genau für das Zeitfenster), 1 % einer Burn Rate von 10 und 100 % (ein Totalausfall) einer Burn Rate von 1000. Der Anteil des Budgets im Zeitfenster, der während eines Alerting-Fensters verbraucht wird, ist Burn Rate x Alerting-Fenster / SLO-Fenster. Bei einem Fenster von 30 Tagen (720 Stunden) verbraucht eine Burn Rate von 14,4 über eine Stunde 14,4 × 1 / 720 = 0,02, also 2 % des Monatsbudgets; bei dieser Rate wäre das ganze Budget nach 720 / 14,4 = 50 Stunden aufgebraucht.

Das Workbook empfiehlt einen Multi-Window-, Multi-Burn-Rate-Alert als sinnvollen Standard für ein SLO von 99,9 %: alarmieren, wenn 2 % des Budgets in einer Stunde (Burn Rate 14,4) oder 5 % in sechs Stunden (Burn Rate 6) verbraucht werden, und ein Ticket eröffnen, wenn 10 % in drei Tagen (Burn Rate 1) verbraucht werden. Jede Bedingung muss über ein langes und ein kurzes Fenster gelten, wobei das kurze Fenster ein Zwölftel des langen ist (jeweils 5 Minuten, 30 Minuten und 6 Stunden). Das lange Fenster stellt sicher, dass das Problem erheblich ist; das kurze stellt sicher, dass es noch andauert, sodass der Alert wenige Minuten nach einem Fix aufhört auszulösen, statt eine Stunde lang rot zu bleiben.

SLO = 0.999                 # 99.9% of requests good
PERIOD_H = 30 * 24          # 720-hour SLO window

def burn_rate(bad, total, slo=SLO):
    """Observed error ratio divided by the ratio the SLO allows."""
    if total == 0:
        return 0.0
    return (bad / total) / (1 - slo)

def budget_spent(rate, window_h, period_h=PERIOD_H):
    """Fraction of the whole window's budget used in window_h hours."""
    return rate * window_h / period_h

def page(w1h, w5m, w6h, w30m):
    """Each argument is (bad, total) for that window."""
    fast = burn_rate(*w1h) >= 14.4 and burn_rate(*w5m) >= 14.4
    slow = burn_rate(*w6h) >= 6 and burn_rate(*w30m) >= 6
    return fast or slow

print(round(burn_rate(bad=288, total=20_000), 1))   # 14.4
print(budget_spent(14.4, window_h=1))               # 0.02, i.e. 2%

Die Schwellen legen auch die Erkennungszeit fest. Fällt die Bestell-API vollständig aus (Fehlerquote 100 %, Burn Rate 1000), überschreitet die Ein-Stunden-Fehlerquote 1,44 % nach 0,0144 × 60 = etwa 0,9 Minuten, die Alarmierung erfolgt also in unter einer Minute. Schlagen 2 % der Anfragen fehl (Burn Rate 20), erreicht die Ein-Stunden-Quote 1,44 % nach 0,72 × 60 = etwa 43 Minuten. Schwere Probleme alarmieren schnell; leichte nur, wenn sie anhalten, und genau dieses Verhalten wünscht man sich um drei Uhr morgens.

Services mit wenig Traffic sprengen diese Rechnung: Bei 10 Anfragen pro Stunde ist ein einziger Fehlschlag eine Fehlerquote von 10 % und eine Burn Rate von 100. Die Abhilfen des Workbook sind synthetischer Traffic, der Signal hinzufügt, das Zusammenfassen verwandter Services mit wenig Traffic unter einem SLO, einzelne Fehlschläge durch Wiederholungen und Fallbacks weniger ins Gewicht fallen zu lassen oder ein längeres Zeitfenster zu akzeptieren. Für das Ticketsystem, das zwischen Vorverkaufsstarts fast leerläuft und dann extrem ausgelastet ist, funktionieren SLOs pro Ereignis mit Burn-Rate-Alerts während des Ereignisfensters besser als eine Monatszahl.

SLAs und Service-Gutschriften

Ein SLA verlagert das Ziel vom Engineering ins Vertragsrecht. Es definiert den abgedeckten Service, wie Verfügbarkeit gemessen wird, Ausschlüsse (geplante Wartung, Missbrauch durch Kunden, höhere Gewalt), die Abhilfe und wie ein Kunde sie geltend macht. Die übliche Abhilfe ist eine Service-Gutschrift: ein Prozentsatz der Monatsgebühr, der erstattet wird, gestaffelt danach, wie deutlich das Niveau verfehlt wurde. Gutschriften sind typischerweise klein im Vergleich zum tatsächlichen Schaden des Kunden; deshalb versteht man SLAs besser als Signal für das Vertrauen des Anbieters denn als Versicherung; Kunden, deren Schäden groß wären, brauchen eigene Resilienz, keine größere Gutschrift.

Betrachten Sie ein illustratives SLA, das die Essenslieferplattform Restaurantpartnern für ihre API zur Bestellannahme anbieten könnte: 99,5 % monatliche Verfügbarkeit, mit einer Gutschrift von 10 % auf die Plattformgebühr dieses Monats unter 99,5 % und 25 % unter 99,0 %. Das interne SLO liegt bei 99,9 %. Die Lücke dazwischen ist gewollt: Das Team sollte sein SLO-Budget erschöpfen, seine Policy anwenden und sich erholen, lange bevor der Vertrag gefährdet ist. Setzen Sie das SLO nie gleich dem SLA; Sie würden erst von Problemen erfahren, wenn Sie bereits Geld schulden.

Daraus folgen zwei architektonische Konsequenzen. Erstens kann ein SLA nur ehrlich sein, wenn Sie die SLAs Ihrer eigenen Abhängigkeiten kennen (Cloud-Anbieter, Zahlungsdienstleister, Kartenanbieter) und wissen, wie sie sich kombinieren. Zweitens brauchen SLAs Belege: Die Messmethode im Vertrag muss eine sein, die Sie aus Ihrer eigenen Telemetrie liefern können; das ist eine Anforderung an das Design der Observability.

Häufige Fehler

Zu viele SLOs. Ein Service mit dreißig SLOs hat keines, weil niemand über sie nachdenken oder danach handeln kann. Beginnen Sie mit zwei oder drei pro kritischem Nutzerpfad: meist einem Verfügbarkeits- und einem oder zwei Latenz-SLOs. Das Falsche messen. CPU-Auslastung, Queue-Tiefe und Replikationsverzögerung sind nützliche Ursachen zum Beobachten, aber keine SLIs, weil Nutzer sie nicht direkt erleben. An der falschen Stelle messen. Serverseitige Erfolgsquoten sehen perfekt aus, während das CDN Fehler liefert. Mittelwerte bilden. Ein SLO auf die mittlere Latenz verbirgt den langsamen Tail, über den Nutzer sich beschweren.

Ziele ohne Konsequenzen. Ein SLO ohne Budget-Policy und ohne Burn-Rate-Alerts ist Dashboard-Dekoration. Ziele, die nur Engineers festlegen. Der Product Owner muss zustimmen, weil das SLO Features gegen Zuverlässigkeit abwägt. Nie überarbeiten. Überprüfen Sie SLOs jedes oder jedes zweite Quartal: Beschweren sich Nutzer, während das SLO grün ist, ist das SLI oder das Ziel falsch; wird das Budget nie angetastet, ist das Ziel vielleicht zu locker oder das Team zu vorsichtig. Ein SLO für sehr unterschiedliche Nutzerpfade. Wer das Durchsuchen der Speisekarte und die Zahlung in einem Verhältnis zusammenwirft, lässt reichliche, günstige Anfragen die Fehlschläge bei den seltenen, wertvollen verdecken.

SLOs sind mit dem Rest dieses Kapitels verbunden. Burn-Rate-Alerts sind die symptombasierten Alerts, die unter Observability empfohlen werden; Incidents, die das Budget verbrauchen, fließen in Post-Incident-Reviews ein; und das Antwortmaß eines SLO ist eine natürliche Fitness Function für die Architektur.