Was ist ein Error Budget?
Ein Error Budget definiert, wie viel Ausfallzeit oder Fehlerrate ein Service tolerieren darf, bevor Stabilisierung Vorrang vor neuen Features bekommt. Bei einem SLO von 99,9 % Verfügbarkeit sind das 8,76 Stunden pro Jahr. Ist das Budget aufgebraucht, wird die Entwicklung neuer Features gestoppt, bis die Zuverlässigkeit wiederhergestellt ist.
Auch bekannt als: Fehlerbudget · Error Budgeting · SLO-Fehlerbudget
Ist Error Budget bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Das Error Budget entsteht in drei Schritten. Zuerst bestimmt das Team einen Service Level Indicator (SLI), also die Messgröße für Zuverlässigkeit, etwa den Anteil erfolgreicher Anfragen oder die Verfügbarkeit. Dann legt es ein Service Level Objective (SLO) fest, den Zielwert für diese Größe über einen Zeitraum, zum Beispiel 99,9 Prozent. Die Formel für das Budget lautet 100 Prozent minus SLO. Bei 99,9 Prozent bleiben 0,1 Prozent, das sind 43,2 Minuten in einem 30-Tage-Fenster, rund 43,8 Minuten in einem durchschnittlichen Kalendermonat und 8,76 Stunden im Jahr. Jede Störung und jedes fehlerhafte Deployment zieht von diesem Betrag ab.
Das Budget ist eingeplante Unzuverlässigkeit. Es beziffert, wie viel Risiko sich ein Service leisten kann, bevor die Nutzer es merken, und macht Zuverlässigkeit damit zu einer Größe, über die man entscheiden kann. Ein SLO ohne Budget bleibt ein Wunsch. Ein Budget ohne vereinbarte Konsequenz ist eine Zahl im Dashboard, die niemand anschaut.
Sein eigentlicher Zweck ist, den Dauerkonflikt zwischen Entwicklung und Betrieb über eine Regel zu entscheiden. Solange Budget übrig ist, dürfen Teams neue Features ausrollen und experimentieren. Ist es aufgebraucht, dreht sich die Priorität: Stabilisierung geht vor, bis der Service wieder im Zielkorridor liegt. Die Regel ist ein Kernwerkzeug des Site Reliability Engineering (SRE). Im Alltag merkt man sie daran, dass die Eskalationsrunde zwischen Entwicklung und Betrieb ausfällt, weil der Budgetstand die Frage schon beantwortet hat.
Für die laufende Steuerung nutzen Teams die Burn Rate. Sie gibt an, wie schnell ein Service sein Error Budget im Verhältnis zum Zeitraum verbraucht. Eine Burn Rate von 1 heißt, das Budget reicht genau bis zum Periodenende. Bei 14,4 ist ein 30-Tage-Budget nach gut zwei Tagen verbraucht, in einer Stunde gehen 2 Prozent des Monatsbudgets verloren. Das Google SRE Workbook empfiehlt deshalb Alarme über mehrere Zeitfenster: Hohe Burn Rates wecken die Rufbereitschaft, eine Burn Rate von 1 über drei Tage erzeugt ein Ticket. Alarmiert wird damit nach der Wirkung auf die Nutzer statt nach starren Schwellwerten für CPU oder Speicher.
In der Industrie hilft das Konzept gegen die reflexhafte Forderung nach 100 Prozent Verfügbarkeit, die technisch unbezahlbar und meist unnötig ist. Wer diese Forderung aus dem Lenkungskreis kennt, kann mit dem Error Budget eine Rechnung vorlegen: was jede weitere Neun kostet und was die Nutzer davon merken würden, ohne dass jemand die Forderung als naiv abtun muss. Der häufigste Fehler ist ein SLO ohne Bezug zu den tatsächlichen Anforderungen. Ein zu hohes Ziel verbraucht das Budget sofort und blockiert jede Weiterentwicklung, ein zu niedriges schützt den Service nicht. Wirksam ist das Budget nur, wenn Management und Teams die Konsequenzen vorher gemeinsam vereinbaren.
Vier Wochen Feature-Stopp bei verbrauchtem Budget
Ein Plattform-Team verhandelte nach jeder größeren Störung neu, ob das nächste Release warten muss. Es vereinbart mit Produktmanagement und Geschäftsführung, dass bei aufgebrauchtem Error Budget vier Wochen lang nur Stabilisierungsarbeit ausgerollt wird. Als das Budget im Herbst tatsächlich leer ist, greift die Regel ohne Diskussion, weil sie schon vor dem Anlass unterschrieben war.
99,99 Prozent für die Steuerungsschicht, 99,5 für das Reporting
Ein Industrieunternehmen hatte für alle Services dasselbe Verfügbarkeitsziel und verteilte seine Engineering-Zeit entsprechend gleichmäßig. Es setzt für die sicherheitskritische Steuerungsschicht ein SLO von 99,99 Prozent und für ein internes Reporting-Tool 99,5 Prozent. Das Reporting darf nun gut dreieinhalb Stunden im Monat ausfallen, und die eingesparte Zeit fließt in die Schicht, deren Budget bei rund vier Minuten liegt.
Wie führen Sie Error Budgets ein?
Ein Error Budget übersetzt Zuverlässigkeit in eine steuerbare Größe — Voraussetzung sind SLOs. Zwei Klicks zeigen, wo Sie ansetzen.
Wie weit sind Sie?
- Wie berechnet man das Error Budget?
- Error Budget = (100 Prozent minus SLO) mal Zeitraum. Bei einem SLO von 99,9 Prozent und einem 30-Tage-Fenster sind das 0,1 Prozent von 43.200 Minuten, also 43,2 Minuten; bei 99,95 Prozent bleiben 21,6 Minuten, bei 99,99 Prozent nur noch 4,3 Minuten. Dieselbe Rechnung funktioniert mit Fehlerraten statt Zeit: Bei 1.000.000 Requests im Monat und einem SLO von 99,9 Prozent erfolgreicher Antworten dürfen 1.000 fehlschlagen. Zieht man davon ab, was Ausfälle und fehlerhafte Deployments bereits verbraucht haben, bleibt der Rest. Dieser Rest entscheidet, ob heute noch deployt wird.
- Wie hängt das Error Budget mit dem SLO zusammen?
- Das Error Budget ist die zulässige Abweichung vom SLO, also 100 Prozent minus Zielwert. Bei 99,9 Prozent Verfügbarkeit liegt das Budget bei 0,1 Prozent, das sind 8,76 Stunden Ausfall pro Jahr. Es ist damit die in Zahlen gefasste Toleranz für Fehler.
- Was ist der Unterschied zwischen SLI, SLO und Error Budget?
- Der SLI ist die gemessene Größe, das SLO der Zielwert dafür und das Error Budget der Abstand zwischen Zielwert und 100 Prozent. Ein Beispiel: Der SLI misst den Anteil erfolgreicher Anfragen, das SLO verlangt 99,9 Prozent über 30 Tage, und das Error Budget erlaubt 0,1 Prozent fehlgeschlagene Anfragen in diesem Zeitraum. Liegt der gemessene SLI bei 99,95 Prozent, ist die Hälfte des Budgets verbraucht.
- Was ist ein SLO im SRE?
- Ein Service Level Objective (SLO) ist der interne Zielwert für die Zuverlässigkeit eines Service, gemessen über einen SLI und einen festen Zeitraum, etwa 99,9 Prozent erfolgreiche Anfragen in 30 Tagen. Es liegt bewusst strenger als ein vertragliches SLA (Service Level Agreement), damit das Team reagieren kann, bevor Vertragsstrafen drohen. Ein gutes SLO orientiert sich an dem, was Nutzer tatsächlich bemerken, nicht an dem, was technisch gerade erreichbar ist.
- Was passiert, wenn das Error Budget aufgebraucht ist?
- Üblicherweise wird die Auslieferung neuer Features gestoppt und das Team konzentriert sich auf Stabilisierung, bis die Zuverlässigkeit wieder im Zielkorridor liegt. Diese Konsequenz muss vorab vereinbart und vom Management mitgetragen werden, sonst bleibt das Budget folgenlos.
- Warum strebt man nicht einfach 100 Prozent Verfügbarkeit an?
- Jede zusätzliche Neun in der Verfügbarkeit kostet überproportional mehr Aufwand, während der Nutzen für die meisten Services gegen null geht. Zwischen 99,9 und 99,99 Prozent schrumpft das Monatsbudget von 43 auf gut 4 Minuten, und kaum ein Nutzer bemerkt den Unterschied. Das Google-SRE-Buch begründet das mit dem Smartphone und dem Netz des Nutzers, die selbst weit unzuverlässiger sind als der Service. Ein bewusst gewähltes Error Budget lässt Raum für neue Features und kalkuliertes Risiko, den ein 100-Prozent-Anspruch vollständig blockieren würde.
- Wer entscheidet über das Error Budget?
- Das Error Budget wird von Entwicklung, Betrieb und Management gemeinsam getragen. Site-Reliability-Engineering-Teams überwachen seinen Verbrauch. Die Konsequenz bei Erschöpfung, etwa ein Feature-Stopp, muss aber vorab verbindlich vereinbart sein, sonst bleibt das Budget folgenlos.
- Was ist die Burn Rate eines Error Budgets?
- Die Burn Rate misst, wie schnell ein Service sein Error Budget relativ zum geplanten Zeitraum verbraucht. Burn Rate 1 heißt: Das Budget reicht genau bis zum Periodenende. Bei Burn Rate 14,4 ist ein 30-Tage-Budget nach rund 50 Stunden leer. Das Google SRE Workbook schlägt für diesen Wert einen sofortigen Alarm an die Rufbereitschaft vor, sobald er eine Stunde lang anhält.
Wo steht Ihr Team bei Error Budget?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Weiterführende Primärquellen zu Error Budget: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01Google SRE BookEmbracing Risk(externe Seite, öffnet in neuem Tab)
Das Kapitel, das Fehlerbudgets als Verhandlungsgrundlage zwischen Tempo und Stabilität einführt.
- /02Google SRE WorkbookImplementing SLOs(externe Seite, öffnet in neuem Tab)
Praktische Anleitung, SLOs zu setzen und daraus ein Fehlerbudget abzuleiten.
- /03Google Cloud BlogSRE fundamentals: SLIs, SLAs and SLOs(externe Seite, öffnet in neuem Tab)
Kompakte Abgrenzung der drei Begriffe mit Rechenbeispiel.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance