In der Site Reliability Engineering-Praxis ist das Error Budget ein zentrales Werkzeug, um das Spannungsfeld zwischen Stabilität und Innovationstempo handhabbar zu machen. Das Konzept ist einfach: Jedes Service Level Objective definiert implizit, wie viel Fehler ein System im Betrachtungszeitraum haben darf – das ist das Fehlerbudget. Wird es nicht ausgeschöpft, haben Entwicklerteams Spielraum für risikoreichere Deployments. Wird es aufgebraucht, sinkt die Toleranz für weitere Änderungen, bis sich das Budget erholt.
Soweit die Theorie. In der Praxis scheitern viele Teams nicht an der Idee des Error Budgets, sondern daran, es operativ zu nutzen. Der entscheidende fehlende Baustein ist meist die Burn Rate – also die Geschwindigkeit, mit der das Fehlerbudget verbraucht wird.
Bildquelle: Hugovanmeijeren, CC BY-SA 3.0, via Wikimedia Commons – Serverracks im CERN-Rechenzentrum
Was die Burn Rate eines Error Budgets bedeutet
Die Burn Rate gibt an, wie schnell ein Team sein Fehlerbudget relativ zur definierten Laufzeit verbraucht. Eine Burn Rate von 1 bedeutet: Das Budget wird in genau dem Tempo aufgebraucht, das dem SLO entspricht – am Ende des Betrachtungszeitraums ist es erschöpft, aber nicht überschritten. Eine Burn Rate von 2 bedeutet doppeltes Tempo: Das Budget reicht nur noch halb so lang. Eine Burn Rate von 0,5 bedeutet, dass die Hälfte des Budgets am Periodenende noch übrig sein wird.
Die mathematische Grundlage ist einfach. Wenn ein Dienst ein SLO von 99,9 % Verfügbarkeit über 30 Tage hat, sind das 43,2 Minuten erlaubte Ausfallzeit. Wenn in einer einzelnen Stunde 30 Minuten Downtime auftreten, hat das Team in dieser Stunde eine Burn Rate von ca. 41 (30 von 43 erlaubten Minuten in 1 von 720 Stunden). Diese Burn Rate ist nicht für immer problematisch – aber sie zeigt, wie dramatisch einzelne Ereignisse das Budget beeinflussen können.
Warum Burn Rate wichtiger ist als rohe Budget-Nutzung
Das Error Budget allein sagt nur, wie viel noch übrig ist. Die Burn Rate sagt, wie schnell es schwächelt – und das ist für Entscheidungen relevanter. Ein Team, das 20 % seines Budgets in den ersten drei Tagen eines 30-tägigen Zeitraums verbraucht hat, sollte anders reagieren als eines, das 20 % gleichmäßig über den Monat verteilt verbraucht hat.
Google hat in seinem SRE-Buch zwei Burn-Rate-Schwellwerte als Ausgangspunkt für Alerting-Regeln empfohlen:
- Kurzfristig hohe Burn Rate: Wird das Budget in wenigen Stunden in einem Maß verbraucht, das den gesamten Monat gefährdet, ist sofortiges Handeln angesagt – unabhängig davon, ob das absolute Budget noch hoch ist.
- Mittelfristig erhöhte Burn Rate: Liegt die Burn Rate über mehrere Stunden konstant über einem Schwellwert, der auf vollständige Erschöpfung im aktuellen Zeitraum hindeutet, ist ebenfalls Alarmierung sinnvoll – aber mit weniger Dringlichkeit.
Burn Rate als Alerting-Basis: Multi-Window-Multi-Burn-Rate
Ein bewährtes Muster aus der Google-SRE-Praxis ist die Kombination mehrerer Zeitfenster und Burn-Rate-Schwellwerte für SLO-basierte Alerts:
- Sehr schnelle Erschöpfung (5-Min und 1-Std-Fenster, hohe Burn Rate): Seiten-Alert, sofortige Eskalation – wahrscheinlich liegt ein akuter Ausfall vor.
- Schnelle Erschöpfung (30-Min und 6-Std-Fenster, mittlere Burn Rate): Seiten-Alert mit etwas mehr Kontext, On-Call wird informiert.
- Langsame Erschöpfung (6-Std und 3-Tage-Fenster, niedrige Burn Rate): Ticket oder Slack-Nachricht, kein Wecken – aber Aufmerksamkeit für das nächste Deployment.
Diese Kombination reduziert Alert-Fatigue erheblich im Vergleich zu einfachen Schwellwert-Alerts, ohne dass relevante Probleme übersehen werden.
Burn Rate und Deployment-Entscheidungen
Eine der praktisch wichtigsten Anwendungen der Burn Rate ist die Integration in den Deployment-Prozess. Teams, die ihre aktuelle Burn Rate im Blick haben, können bewusst entscheiden, wann ein Deployment riskant ist – nicht nach Bauchgefühl, sondern auf Basis von Daten.
Eine sinnvolle Faustregel: Liegt die aktuelle Burn Rate über 1 und das Fehlerbudget ist bereits zu mehr als 50 % verbraucht, sollten Deployments mit neuem Risikopotenzial pausiert oder besonders abgesichert werden (Feature Flags, gestuftes Rollout, verstärktes Monitoring in den ersten Minuten).
Umgekehrt gilt: Ein hohes verbleibendes Fehlerbudget bei niedriger Burn Rate signalisiert, dass das System zuverlässiger läuft als das SLO fordert. Das ist kein Grund zur Selbstzufriedenheit, aber es gibt Entwicklerteams legitimen Spielraum für mutigere Änderungen ohne vorherigen Bremsreflex aus der SRE-Ecke.
Burn Rate berechnen und visualisieren
In Prometheus-basierten Setups lässt sich die Burn Rate direkt als Recording Rule ausdrücken. Das Grundprinzip:
- Error Rate = Anteil der fehlerhaften Requests im Beobachtungsfenster
- Error Budget-Verbrauchsrate = Error Rate / (1 - SLO-Ziel)
- Burn Rate = Ist-Fehlerrate / erlaubte Fehlerrate gemäß SLO
Grafana-Dashboards können diese Kennzahlen in kombinierten Ansichten darstellen: verbleibendes Budget in Stunden oder Minuten, aktuelle Burn Rate auf verschiedenen Zeitfenstern und eine Prognose, wann das Budget aufgebraucht sein wird – falls die aktuelle Rate anhält. Diese Visualisierung macht aus einer abstrakten Kennzahl ein konkretes Entscheidungswerkzeug.
Häufige Fehler bei der Burn-Rate-Nutzung
Der häufigste Fehler ist, die Burn Rate nur zu messen, ohne sie an Prozesse zu koppeln. Eine Kennzahl ohne Konsequenz ist Informationsrauschen. Teams brauchen klare Antworten auf die Frage: Was tun wir, wenn die Burn Rate Schwellwert X überschreitet?
Ein weiterer Fehler ist die falsche Granularität. Wer nur die monatliche Gesamtnutzung des Fehlerbudgets betrachtet, verpasst kurzfristige Spitzen, die zwar das Budget noch nicht erschöpfen, aber auf echte Probleme hinweisen. Die Burn Rate auf kurzen Zeitfenstern (5 Minuten bis 1 Stunde) ist der Frühwarnindikator – die Gesamtbudget-Ansicht die strategische Übersicht.
Schließlich: Burn Rate ist kein Schuldinstrument. Sie soll Teams helfen, bessere Entscheidungen zu treffen – nicht dazu führen, dass Entwickler bei jeder Deployment-Anfrage defensiv werden. Wer die Burn Rate als Kontrollmechanismus missversteht, statt als Informationsquelle, untergräbt genau die Zusammenarbeit, die SRE-Prinzipien fördern sollen.
Burn Rate als Grundlage für konstruktive SRE-Entwickler-Dialoge
Das Schönste an der Burn Rate als Konzept ist, dass sie Diskussionen objektiviert. Statt „ihr habt zu oft deployed" oder „ihr seid zu risikoscheu" kann das Gespräch lauten: „Unsere aktuelle Burn Rate liegt bei 1,8 – was ändert sich an unserem Deployment-Plan?" Das ist eine sachliche Frage mit einer datenbasierten Grundlage, auf die beide Seiten antworten können.
Und wenn das Fehlerbudget nach einem größeren Incident aufgebraucht ist, gibt die Burn-Rate-Historie Auskunft darüber, wie schnell das Ungleichgewicht entstand und ob strukturelle Veränderungen – bessere Tests, mehr Canary-Rollouts, redundantere Infrastruktur – gerechtfertigt sind.
Fazit
Die Burn Rate des Error Budgets ist eines der nützlichsten Werkzeuge im SRE-Baukasten – aber nur, wenn sie operativ verankert ist: als Alert-Grundlage, als Deployment-Signal und als Grundlage für das Gespräch zwischen SRE-Teams und Produktentwicklung. Wer sie nur als Dashboard-Kennzahl führt, schöpft ihr Potenzial nicht aus. Wer sie in seine Prozesse integriert, gewinnt ein klares, datenbasiertes Steuerungsinstrument für den Balanceakt zwischen Zuverlässigkeit und Veränderungsgeschwindigkeit.
Quellen: Google SRE Book (2016, O'Reilly), The Site Reliability Workbook – Kapitel „Alerting on SLOs", Prometheus Alerting Best Practices (prometheus.io)
