Ein Error Budget (Fehlerbudget) ist das Maß an Unzuverlässigkeit, das ein Service innerhalb eines Zeitfensters haben darf, ohne sein SLO zu verletzen. Es entspricht 100 Prozent minus SLO-Ziel: Ein Verfügbarkeits-SLO von 99,9 Prozent über 30 Tage erlaubt 0,1 Prozent schlechte Ereignisse, etwa 43 Minuten Totalausfall. Teams entscheiden anhand des Restbudgets zwischen neuen Features und Zuverlässigkeitsarbeit.
Was ist ein Error Budget (Fehlerbudget)?
Ein Error Budget (Fehlerbudget) ist der Anteil der Requests oder die Zeitspanne, die innerhalb eines SLO-Fensters fehlschlagen darf. Es macht aus einem Zuverlässigkeitsziel etwas, das ein Team ausgeben kann. Verlangt das SLO, dass 99,9 Prozent der Requests über 30 Tage erfolgreich sind, dürfen 0,1 Prozent fehlschlagen. Diese 0,1 Prozent sind das Budget.
Die Idee, bekannt geworden durch Googles Site-Reliability-Engineering-Praxis, beruht auf einer einfachen Beobachtung: 100 Prozent Zuverlässigkeit sind weder erreichbar noch erstrebenswert. Jede zusätzliche Neun kostet mehr Engineering-Aufwand und bremst Änderungen, während Nutzer ab einem gewissen Punkt keinen Unterschied mehr bemerken. Ein Error Budget macht diesen Zielkonflikt explizit. Solange Budget übrig ist, darf das Team releasen, experimentieren und vertretbare Risiken eingehen. Ist es aufgebraucht, hat Zuverlässigkeit Vorrang.
Error Budget berechnen
Error_Budget = 1 - SLO_Ziel
erlaubte_schlechte_Ereignisse = Error_Budget * gültige_Ereignisse
Restbudget = 1 - (tatsächliche_schlechte_Ereignisse / erlaubte_schlechte_Ereignisse)Zeitbasiert lässt sich das Budget als gleichwertige Totalausfallzeit in einem 30-Tage-Fenster ausdrücken:
| SLO-Ziel | Error Budget | Entspricht Ausfallzeit pro 30 Tage |
|---|---|---|
| 99 % | 1 % | 7 h 12 min |
| 99,5 % | 0,5 % | 3 h 36 min |
| 99,9 % | 0,1 % | 43 min 12 s |
| 99,95 % | 0,05 % | 21 min 36 s |
| 99,99 % | 0,01 % | 4 min 19 s |
Ein illustratives Beispiel mit einem request-basierten SLI: Ein Service verarbeitet in 30 Tagen 20 Millionen gültige Requests bei einem SLO von 99,9 Prozent. Das Budget beträgt 20.000 fehlgeschlagene Requests. Sind nach zwei Wochen 8.000 fehlgeschlagen, bleiben 60 Prozent übrig. Auch Teilausfälle zählen: Eine Stunde, in der 2 Prozent der Requests fehlschlagen, verbraucht bei gleichem Traffic etwa so viel Budget wie 1,2 Minuten Totalausfall.
Burn Rate und Alerting
Die Burn Rate beschreibt, wie schnell das Budget im Verhältnis zum Fenster verbraucht wird. Eine Burn Rate von 1 verbraucht genau das gesamte Budget bis zum Ende des Fensters. Eine Burn Rate von 14,4 über eine Stunde verbraucht 2 Prozent eines 30-Tage-Budgets, ein klares Signal für eine Alarmierung. Gängige Multi-Window-Regeln kombinieren ein schnelles Fenster für akute Probleme mit einem langsameren für schleichende Verschlechterungen, zum Beispiel:
- Alarmierung: Burn Rate über 14,4 in 1 Stunde, bestätigt über 5 Minuten.
- Alarmierung: Burn Rate über 6 in 6 Stunden, bestätigt über 30 Minuten.
- Ticket: Burn Rate über 1 in 3 Tagen.
Diese Werte sind verbreitete Startpunkte, keine allgemeingültigen Regeln. Passen Sie sie an Ihren Traffic und Ihre Toleranz für Rauschen an.
Die Error-Budget-Policy
Ein Budget verändert das Verhalten nur, wenn vorab vereinbart ist, was bei knappem Budget passiert. Eine Error-Budget-Policy ist eine kurze, schriftliche Vereinbarung zwischen Engineering, Produkt und Betrieb. Typische Bestandteile:
- Budget ausreichend: normaler Release-Rhythmus, Experimente und geplante Wartung sind möglich.
- Budget unter einer Schwelle, etwa 25 Prozent: Releases brauchen zusätzliche Prüfung, riskante Migrationen werden verschoben, Canary-Phasen verlängert.
- Budget aufgebraucht: Feature-Releases pausieren, ausgenommen Fixes und Sicherheitspatches. Das Team arbeitet an den größten Budgetverbrauchern, bis sich das rollierende Fenster erholt.
- Ausnahmen: Wer die Policy aussetzen darf und wie diese Entscheidung dokumentiert wird.
Unser Blogbeitrag zu SLOs in der Praxis und Release Gates zeigt, wie sich eine solche Policy in eine Delivery-Pipeline einbinden lässt.
Best Practices
- Wählen Sie SLO-Ziele danach, was Nutzer brauchen, nicht danach, was das System gerade erreicht. Ein Ziel, das immer erfüllt wird, hat ein Budget, das nie genutzt wird.
- Erfassen Sie den Budgetverbrauch nach Ursache, etwa Deployments, Abhängigkeiten oder Infrastruktur, um zu sehen, wo sich Zuverlässigkeitsarbeit lohnt.
- Korrelieren Sie Budgeteinbrüche mit Deployments, um Regressionen zu erkennen und automatische Rollbacks zu unterstützen.
- Besprechen Sie Budgets regelmäßig in der Planung, nicht nur während Incidents.
- Geben Sie Budget bewusst aus: Geplante Wartung oder Chaos-Experimente sind legitime Verwendungen.
Häufige Fehler
- Ein Budget ohne Policy festzulegen, sodass sich nichts ändert, wenn es aufgebraucht ist.
- Das Error Budget als Leistungskennzahl für Einzelpersonen zu nutzen. Das fördert das Verschweigen von Incidents.
- Ausfälle von Abhängigkeiten aus dem Budget herauszurechnen, obwohl Nutzer sie erleben.
- Für alle Services dasselbe Ziel festzulegen, unabhängig von ihrer Bedeutung.
- Das Budget zum Monatswechsel zurückzusetzen statt ein rollierendes Fenster zu nutzen. Das verleitet zu riskanten Releases am Monatsanfang.
- Das SLO-Ziel nach jedem verfehlten Monat zu lockern, statt die Ursachen des Budgetverbrauchs anzugehen.
Wie Obseria hilft
Obseria berechnet Error Budgets für jedes SLO aus Ihren SLIs, zeigt Restbudget und Burn Rate über rollierende Fenster und alarmiert mit Multi-Window-Burn-Rate-Regeln. Deployment-Marker zeigen, welche Releases Budget verbraucht haben, und Automation kann Rollbacks auslösen oder Releases blockieren, wenn eine Policy-Schwelle überschritten wird.
