SLOs und Error Budgets in der Praxis

Das Meeting lief schon zwanzig Minuten. Das Team wollte ein großes Refactoring deployen, der Infrastruktur-Lead zögerte. “Wir hatten letzte Woche schon zwei Incidents.” Der Entwicklungs-Lead: “Der Rollback dauert zwei Minuten, das Feature-Flag ist drin.” Stalemate.

Das ist genau der Moment, für den Error Budgets gebaut sind.

Ein SLO ist eine Vereinbarung: “Unser Payment-Prozess hat eine Availability von 99,9 Prozent über 30 Tage.” Das macht rund 43 Minuten erlaubte Downtime pro Monat — das Error Budget. Wenn das Budget noch voll ist, können Teams risikofreudiger deployen. Wenn es aufgebraucht ist, wird der Release eingefroren, bis das Budget sich regeneriert.

Die Magie liegt nicht im Konzept, sondern in der Konsequenz. Statt “wir haben letzte Woche viel deployt” gibt es eine messbare Zahl. Das Budget steht bei 70 Prozent. Die Risk-Policy des Teams: unter 20 Prozent kein Rollout ohne expliziten Sign-off. 70 Prozent ist grün, das Deployment kann gehen. Keine Argumentation mehr auf Basis von Gefühlen.

Der SLI entscheidet, ob das Ganze funktioniert

SLI — Service Level Indicator — ist die Metrik, die den SLO misst. Für Availability typischerweise: erfolgreiche Requests geteilt durch alle Requests. Für Latenz: Anteil der Requests unter einem Schwellwert — nicht das p95 selbst, sondern „Anteil der Requests unter 300 ms”, weil sich das sauber als Verhältnis budgetieren lässt.

Hier wird es schnell konkret unscharf, und jede Unschärfe rächt sich später. Zählen 4xx-Antworten als Fehler? Meistens nicht — ein invalider Request des Clients ist kein Verfügbarkeitsproblem des Services. Zählen Healthcheck- und Bot-Requests in den Nenner? Besser nicht, sie verwässern den SLI mit Traffic, der keine User-Erfahrung repräsentiert. Misst du am Load Balancer oder im Service? Am Load Balancer siehst du auch die Requests, die den Service nie erreicht haben — näher an der User-Erfahrung, aber schwerer einem Team zuzuordnen. Diese Entscheidungen gehören schriftlich in die SLO-Definition, sonst werden Auswertungen zu Interpretationsspielen — und das erste ernsthafte Budget-Gespräch endet in einer Debatte über die Messung statt über das Risiko.

Technisch ist der SLI dann eine PromQL-Ratio, wie sie im Artikel zur RED Method hergeleitet wird, als Recording Rule vorberechnet.

Burn-Rate-Alerts statt Schwellwert-Gepiepse

Der zweite Praxisgewinn von SLOs, der oft übersehen wird: sie machen Alerting besser. Ein klassischer Schwellwert-Alert (“Error-Rate über 1 %”) weckt nachts auch für Blips, die das Monatsbudget kaum anfassen. Burn-Rate-Alerts fragen stattdessen: wie schnell verbrennt das Budget gerade?

Eine Burn Rate von 1 heißt: das Budget reicht exakt den Budget-Zeitraum. Eine Burn Rate von 14,4 über eine Stunde heißt: in diesem Tempo ist das 30-Tage-Budget in zwei Tagen weg — das ist ein Page. Das bewährte Setup kombiniert zwei Fenster: schnelle Burn (hohe Rate über 5 Minuten und 1 Stunde gleichzeitig, weckt jemanden) und langsame Burn (moderate Rate über 6 und 24 Stunden, wird ein Ticket). Das Multi-Window-Konstrukt verhindert, dass ein einzelner kurzer Spike pagt, der sich schon wieder erholt hat.

Diese Regeln von Hand zu schreiben ist fehleranfällig. Tools wie Sloth oder Pyrra generieren aus einer kompakten SLO-Definition die Recording Rules und Multi-Window-Alerts für Prometheus — genau die Infrastruktur, die ein Platform-Team als Shared Service bereitstellen kann, damit nicht jedes Team die Burn-Rate-Mathematik selbst herleitet.

Woran SLO-Einführungen scheitern

Drei Muster tauchen immer wieder auf. Erstens: SLOs top-down einführen, ohne dass Teams verstehen warum. Ein SLO, das das Platform-Team definiert und das Entwicklungsteam nicht selbst gebaut hat, wird ignoriert oder als Kontroll-Instrument wahrgenommen. Zweitens: zu ambitionierte Ziele. 99,99 % klingen professionell, sind aber 4,3 Minuten Budget pro Monat — ein einziges holpriges Deployment, und das Team ist den Rest des Monats im Release-Freeze. Wer dann den Freeze ignoriert, hat dem ganzen System die Zähne gezogen. Lieber mit 99,5 % starten und nachschärfen, wenn die Realität es hergibt. Drittens: ein Error Budget ohne vereinbarte Konsequenz. Wenn beim aufgebrauchten Budget nichts passiert, ist das SLO ein Dashboard, kein Steuerungsinstrument — die Policy (“unter X Prozent: nur noch Fixes, Postmortem-Actions zuerst”) muss vor dem ersten Budget-Engpass stehen, nicht währenddessen verhandelt werden.

Was funktioniert: Teams helfen, ihre eigenen SLOs zu definieren. Wo klagen User? Was ist wirklich geschäftskritisch? Dann die Measurement-Infrastruktur stellen und die erste Budget-Entscheidung gemeinsam durchspielen.

Zurück zum Meeting: mit Error Budget als gemeinsamer Referenz wird die Diskussion sachlich. Budget-Stand, Risk-Policy, Entscheidung. Nicht “ich hab ein schlechtes Gefühl”, sondern Zahlen — und eine Regel, auf die sich beide Seiten vorher geeinigt haben.