Ein kleiner Bug trieb die Fehlerrate um 0,05% nach oben. Der erste Reflex des Bereitschaftsingenieurs ist, sofort alles zurückzurollen. Doch ein Rollback unter Druck bringt sein eigenes Risiko mit: ein neues Deployment, eine neue Fehlerfläche, eine Entscheidung im Panikmodus. Der erfahrene SRE tat etwas anderes — er schaute auf das verbleibende Error Budget. Mit 98% des Monatsbudgets, das noch übrig war, blieb reichlich Raum für ein ruhiges Fix-forward, und ein Notfall-Rollback hätte nur Instabilität hinzugefügt. Das ist kein Versagen — es ist geplante Unvollkommenheit, genau das, wofür das Budget da ist.
Der gesamte Wert des SLO-Ansatzes ruht auf einer einzigen Idee: bevor du auf eine Abweichung reagierst, schau auf das Budget. Ein hoher Restbestand bedeutet Zeit für eine durchdachte Korrektur. Ein niedriger bedeutet: jetzt mitigieren, das Postmortem später schreiben. Eine Zahl statt eines Streits.
Ein Budget für Risiko, nicht für Perfektion
SLI ist eine messbare Metrik dessen, was der Nutzer tatsächlich spürt: der Anteil erfolgreicher Requests, der Anteil der Requests schneller als 200 ms. SLO ist der Zielwert dieser Metrik über ein Fenster (etwa 99,9% über 30 Tage). Und Error Budget = 1 − SLO ist der zulässige „Anteil des Schlechten“. Für 99,9% über einen Monat ergibt das Budget rund 43 Minuten Ausfallzeit.
Der entscheidende mentale Wandel: Diese 43 Minuten sind nichts, wofür man sich schämen müsste — sie sind eine Ressource, die man ausgeben darf. Für riskante Releases, für Experimente, für Migrationen. Das Budget bis auf null zu verbrennen ist ein Signal, keine Katastrophe.
Daraus folgt auch, dass das Streben nach „fünf Neunen“ (99,999%) fast immer kontraproduktiv ist. Die Kosten der Zuverlässigkeit wachsen exponentiell, und oberhalb von 99,9% stößt man an die SLOs der eigenen Abhängigkeiten — den Cloud-Loadbalancer, DNS, externe APIs. Realistische Ziele sind bodenständiger: ein internes Admin-Tool lebt bei 99%, eine öffentliche Website bei 99,9%, eine kritische API bei 99,95%, Zahlungen bei 99,99%. Ein Ziel von „99,999% und schneller“ inspiriert ein Team nicht — es demoralisiert es.
Die Error Budget Policy — ein Hebel, keine Dekoration
Für sich genommen ist das Budget nur eine Zahl. Kraft verleiht ihm eine Policy: im Voraus vereinbarte Maßnahmen, gekoppelt an den verbleibenden Rest.
- Über 50% übrig — Features frei ausliefern.
- 20–50% — vor Prod eine Bewährungszeit in Staging verlangen (etwa einen Tag).
- Unter 20% — unkritische Änderungen einfrieren, Fokus auf Zuverlässigkeit.
- Budget erschöpft — vollständiger Freeze, der ganze Sprint geht in Reliability-Arbeit.
Der Sinn dieser Tabelle ist, dass sie den ewigen Streit über „sollen wir jetzt einfrieren“ beendet. Die Entscheidung ist an eine Zahl gebunden, nicht daran, wer im Chat am lautesten ist. Das Business erhält ein Werkzeug, um den Trade-off zwischen Geschwindigkeit und Stabilität zu steuern, ohne PromQL lesen zu müssen.
Aber eine Policy ohne Zähne ist nutzlos. Wenn das Budget erschöpft ist und das Team wegen „der Deadline“ weiter Features ausliefert, ist das Budget dekorativ und das ganze Konstrukt verliert seinen Sinn. Eine Policy wirkt nur so weit, wie die Organisation bereit ist, ihr zu folgen.
Multi-Burn-Rate: wie das Budget zum Alert wird
Ein typischer Fehler ist, einen Alert für „das SLO ist unter 99,9% gefallen“ zu verdrahten. Diese Schwelle feuert bei einem Verlust von weniger als einem Prozent und weckt die Bereitschaft umsonst. Weit präziser ist es, die Burn Rate — die Geschwindigkeit, mit der das Budget verbraucht wird — über mehrere Fenster gleichzeitig zu messen.
Die Logik ist einfach. Verbrennen wir 2% des Monatsbudgets in einer Stunde, ist das kritisch und ein Page mitten in der Nacht gerechtfertigt (Fast Burn, burn_rate_1h > 14,4 × 0,001, bestätigt durch ein kurzes 5-Minuten-Fenster). Gehen 5% in sechs Stunden, ist das ernst, aber ein Ticket am Tag genügt (Slow Burn, burn_rate_6h > 6 × 0,001 mit einer 30-Minuten-Bestätigung). Das Doppelfenster — ein langes plus ein kurzes bestätigendes — filtert Fehlalarme aus einem zufälligen Spike heraus.
Die Multiplikatoren 14,4 und 6 sind keine Magie; es sind die Standardtabellen aus dem SRE Workbook für ein 99,9%-SLO. Generatoren wie Sloth erzeugen diese Regeln aus einer kurzen YAML-Spezifikation und ergänzen Recording Rules für die Fenster 5m/30m/1h/6h, damit Grafana und die Alerts fertige Metriken lesen, statt bei jedem Render schweres PromQL zu rechnen.
Dieselbe Burn Rate dient auch als Deploy-Gate: eine Regel „bei einer 10×-Burn-Rate Rollouts stoppen“ ist für CI/CD transparent. Die Arithmetik überzeugt — 10× bei 99,9% verbrennt das Monatsbudget in drei Tagen; liefert man in diesem Moment eine Regression aus, kommt das vollständige Ausbrennen in Stunden. Das greift in die Policy: ein erschöpftes Budget bedeutet einen vollständigen Freeze, eine hohe Burn Rate einen vorbeugenden.
Zusammengenommen sind SLO, Error Budget und Multi-Burn-Rate keine drei getrennten Praktiken, sondern eine einzige Kette: die Metrik misst den Schmerz des Nutzers, das Budget verwandelt ihn in eine Ressource, und Policy und Alerts verwandeln diese Ressource in Entscheidungen. Das Budget wird zu einer gemeinsamen Sprache, in der Business und Ingenieure sich einigen können — ohne Panik und ohne Streit.