Ein Error Budget (Fehlerbudget) ist das Maß an Unzuverlässigkeit, das Ihr SLO über einen Zeitraum erlaubt: 100 % minus Zielwert. Ein SLO von 99,9 % über 30 Tage lässt ein Error Budget von 43 Minuten und 12 Sekunden Ausfallzeit, oder eine fehlgeschlagene Anfrage auf tausend. Solange Budget übrig ist, kann das Team ausliefern und Risiken eingehen. Ist es aufgebraucht, hat Zuverlässigkeitsarbeit Vorrang, bis sich das Zeitfenster erholt hat.
Diese eine Regel macht aus einem Zuverlässigkeitsziel konkrete Entscheidungen. Dieser Leitfaden zeigt, wie Sie ein Error Budget berechnen, was es verbrauchen sollte und was nicht, wie Sie erkennen, wie schnell Sie es verbrauchen, und wie Sie eine Policy für den Fall schreiben, dass es aufgebraucht ist.
So berechnen Sie ein Error Budget
Sie brauchen zwei Dinge: ein SLO, also das Zuverlässigkeitsziel, das Sie sich selbst setzen, und ein Zeitfenster, über das es gemessen wird. Das Error Budget ist der Abstand zwischen dem Ziel und Perfektion.
Error Budget = (100 % − SLO) × Zeitfenster
Für ein SLO von 99,9 % über 30 Tage (43.200 Minuten): 0,1 % × 43.200 = 43,2 Minuten, also 43 Minuten und 12 Sekunden. Die Tabelle zeigt dieselbe Rechnung für gängige Zielwerte, auf die Sekunde abgerundet.
SLOBudget pro 30 TageBudget pro 90 Tage99 %7 h 12 min21 h 36 min99,5 %3 h 36 min10 h 48 min99,9 min 12 s2 h 9 min 36 s99,95 min 36 s1 h 4 min 48 s99,99 %4 min 19 s12 min 57 s
Der SLA- und Uptime-Rechner erledigt das für jeden Zielwert und Zeitraum. Er rechnet mit dem durchschnittlichen Monat (ein Jahr geteilt durch 12) und zeigt für 99,9 % daher 43 Minuten und 49 Sekunden statt des 30-Tage-Werts oben.
Zeitbasiert oder anfragebasiert
Ein Error Budget lässt sich in zwei Einheiten zählen, je nachdem, welcher SLI hinter Ihrem SLO steht:
Zeitbasiert: Minuten Ausfallzeit, gemessen durch Checks von außen. Das ist einfach, leicht zu erklären und passt dazu, wie die meisten Kunden-SLAs formuliert sind. Ein monatliches SLO von 99,9 % erlaubt etwa 43 Minuten.
Anfragebasiert: der Anteil fehlgeschlagener Anfragen, gezählt aus Load-Balancer- oder Anwendungslogs. Bei 2 Millionen Anfragen im Monat und 99,9 % beträgt das Budget 2.000 fehlgeschlagene Anfragen. Stoßzeiten zählen hier mehr als ruhige Stunden, was näher an dem liegt, was Nutzer erleben – setzt aber Logs voraus, denen Sie vertrauen.
Viele Teams nutzen beides: ein zeitbasiertes Budget aus externen Checks für den Dienst als Ganzes und anfragebasierte Budgets für die wichtigsten Endpunkte, etwa den Checkout oder die API.
Wozu überhaupt ein Error Budget?
Ohne Budget ist Zuverlässigkeit Verhandlungssache. Das Produktteam will ausliefern, die Entwicklung will bremsen, und wer zuletzt spricht, gewinnt. Ein Budget ersetzt die Diskussion durch eine Zahl, auf die sich beide Seiten vorher geeinigt haben.
Es macht 100 % zum falschen Ziel. Ein Ziel von 100 % lässt kein Budget übrig, also wird jedes Deployment zu einem Risiko, das niemand eingehen darf. Über ihr eigenes WLAN und Mobilfunknetz können Nutzer 99,99 % ohnehin nicht von 100 % unterscheiden.
Es macht Risiko planbar. Eine große Migration, eine neue Region oder ein riskantes Release lässt sich so planen, dass es in das Budget passt, das in diesem Monat noch übrig ist.
Es setzt die Prioritäten für Sie. Ist das Budget aufgebraucht, legt die Policy fest, was als Nächstes passiert. Niemand muss erst ein Meeting gewinnen, um Zuverlässigkeitsarbeit auf die Roadmap zu bringen.
Was das Budget verbraucht
Alles, was Ihr SLI als schlecht zählt, verbraucht Budget. Legen Sie das beim Schreiben des SLO fest, nicht während des Vorfalls.
Bestätigte Ausfälle: Der Dienst hat nicht geantwortet, mit einem Fehler geantwortet oder mit falschem Inhalt geantwortet.
Langsame Antworten, wenn Ihr SLI eine Anfrage über einem Grenzwert als fehlgeschlagen zählt. Eine Seite, die 30 Sekunden lädt, ist erreichbar, aber nicht nutzbar.
Fehlgeschlagene Deployments und Rollbacks, für die Minuten, in denen Nutzer Fehler gesehen haben.
Ausfälle bei Ihren Anbietern. Fällt Ihr Zahlungsanbieter oder DNS-Hoster aus, können Ihre Nutzer trotzdem nicht bezahlen. Das verbraucht Ihr Budget, auch wenn die Lösung nicht bei Ihnen liegt – ein guter Grund, die Dienste zu überwachen, von denen Sie abhängen.
Geplante Wartung, aber nur, wenn das SLO es so festlegt. Viele Teams nehmen angekündigte Wartungsfenster aus, mit einer Obergrenze pro Monat.
Was es nicht verbrauchen sollte: Fehlalarme. Ein einzelner fehlgeschlagener Check wegen einer kurzen Netzwerkstörung ist keine Ausfallzeit. Bestätigen Sie einen Fehler mit einem zweiten Check, bevor Sie ihn zählen, sonst schmilzt Ihr Budget wegen Problemen, die Nutzer nie bemerkt haben.
Burn Rate: wie schnell Sie das Budget verbrauchen
Das Budget sagt Ihnen, wie viel Ausfall Sie sich leisten können. Die Burn Rate sagt Ihnen, wie schnell Sie es aufbrauchen. Googles SRE Workbook definiert sie als die Geschwindigkeit, mit der der Dienst das Error Budget im Verhältnis zum SLO verbraucht (Alerting on SLOs).
Bei einer Burn Rate von 1 ist das gesamte Budget genau am Ende des Zeitfensters aufgebraucht.
Bei einer Burn Rate von 2 ist es nach der Hälfte des Zeitfensters weg: nach 15 Tagen eines 30-Tage-Monats.
Ein Komplettausfall hat bei einem SLO von 99,9 % eine Burn Rate von 1.000, denn jede Minute Ausfall ist das Tausendfache der erlaubten Rate. Zwanzig Minuten davon verbrauchen 46 % eines 30-Tage-Budgets.
Als Ausgangspunkt für ein SLO von 99,9 % empfiehlt das Workbook, jemanden zu alarmieren, wenn 2 % eines 30-Tage-Budgets innerhalb einer Stunde verbraucht werden (Burn Rate 14,4) oder 5 % innerhalb von sechs Stunden (Burn Rate 6), und ein Ticket zu eröffnen, wenn 10 % innerhalb von drei Tagen verbraucht werden (Burn Rate 1). Jeder Alarm prüft zusätzlich ein kurzes Zeitfenster, damit er bald nach dem Problem auch wieder aufhört.
Bei einem harten Ausfall lösen ein Burn-Rate-Alarm und ein gewöhnlicher „Website ist down“-Alarm etwa im selben Moment aus. Ihren Wert zeigen Burn Rates bei Teilausfällen: 3 % fehlgeschlagene Anfragen über Stunden, die die Website nie ganz lahmlegen, aber das Monatsbudget unbemerkt bis Mittwoch aufzehren.
Eine Error-Budget-Policy schreiben
Ein Budget ohne Policy ist nur eine Zahl auf einem Dashboard. Die Policy legt im Voraus fest, was das Team bei welchem Verbrauch tut. Stimmen Sie sie gemeinsam mit Produkt und Entwicklung ab und halten Sie sie dort fest, wo beide sie finden. Google veröffentlicht eine Beispiel-Policy für Error Budgets, die sich zu lesen lohnt, bevor Sie Ihre eigene schreiben.
Eine einfache Policy als Ausgangspunkt
Budget übrig: Ganz normal ausliefern. Geplante riskante Arbeiten finden statt.
Vor der Mitte des Zeitfensters zur Hälfte verbraucht: Die On-Call-Leitung prüft die bisherigen Vorfälle und benennt die größte Ursache.
Budget aufgebraucht: Bis sich das Zeitfenster erholt hat, werden nur Bugfixes und Zuverlässigkeitsarbeit ausgeliefert. Riskante Migrationen warten.
Ein einzelner Vorfall hat mehr als ein Fünftel des Budgets verbraucht: Er bekommt ein schriftliches Postmortem mit mindestens einer Maßnahme.
Ausnahmen entscheiden namentlich benannte Personen, etwa die Leitung der Entwicklung und die Leitung des Produktteams gemeinsam, und sie werden schriftlich festgehalten.
Die Schwellenwerte sind Beispiele, keine Regeln. Wählen Sie solche, an die sich Ihr Team tatsächlich hält. Eine Policy, die beim ersten Ernstfall ignoriert wird, ist schlimmer als gar keine, weil sie allen beibringt, dass das SLO keine Rolle spielt.
Häufige Fehler
Das SLO gleich dem SLA setzen. Dann ist das Budget genau in dem Moment aufgebraucht, in dem Sie Kunden Service-Gutschriften schulden. Setzen Sie das SLO strenger als das SLA, damit der interne Alarm zuerst anschlägt. SLA vs. SLO vs. SLI erklärt, wie die drei zusammenhängen.
Ein zu kurzes Zeitfenster. Ein Wochenbudget wird zurückgesetzt, bevor eine schlechte Woche etwas bewirken kann. Dreißig Tage, rollierend oder pro Kalendermonat, sind die übliche Wahl.
Vergessen, wie das Zeitfenster zurückgesetzt wird. Ein Kalendermonat beginnt am 1. von vorn, sodass eine schlechte letzte Woche nach wenigen Tagen vergessen ist. Ein rollierendes 30-Tage-Fenster erinnert sich einen Monat lang daran – das ist strenger und fairer.
Nur auf die Gesamtsumme schauen. Ein Ausfall von 40 Minuten und vierzig Ausfälle von je einer Minute verbrauchen dasselbe Budget, aber Letztere stören die Arbeit der Nutzer jeden Tag. Verfolgen Sie die Zahl der Vorfälle und die MTTR neben dem Budget.
Nur von innen messen. Serverlogs können keine Anfragen erfassen, die nie angekommen sind. Ein abgelaufenes Zertifikat oder ein fehlerhafter DNS-Eintrag verbraucht Budget, das nur ein externer Check sieht.
Ein zeitbasiertes Error Budget mit Uptimecheck verfolgen
Uptimecheck liefert die Zahlen, die ein zeitbasiertes Budget braucht. Das Uptime-Monitoring prüft bis zu jede Minute von Stockholm, London und New York aus und bestätigt jeden fehlgeschlagenen Check von einem zweiten Standort, damit eine einzelne kurze Störung kein Budget verbraucht. Wartungsfenster und pausierte Zeit zählen nicht gegen die Uptime.
Berichte zeigen Uptime, Ausfallzeit und Vorfälle pro Monitor für diesen Monat, den letzten Monat oder die letzten 7, 30 oder 90 Tage, gemessen an einem SLA-Ziel von 99 %, 99,5 %, 99,9 %, 99,95 % oder 99,99 %, mit CSV-Download. Das verbleibende Budget ist die erlaubte Ausfallzeit minus die Ausfallzeit im Bericht. Siehe Berichte mit SLA-Ziel erstellen.
Vorfälle bewahren die Belege und eine Zeitleiste aller Checks, Alarme und Notizen auf – genau das, was ein Postmortem braucht. Siehe Incident-Management.
Wartungsfenster halten geplante Arbeiten aus den Zahlen heraus. Siehe Wartungsfenster planen.
Um das verbrauchte Budget in Geld auszudrücken, probieren Sie den Ausfallkosten-Rechner. Was jeder Zielwert erlaubt, lesen Sie in Was 99,9 % Uptime bedeuten.
Wissen Sie, wie viel Budget Ihnen bleibt, bevor der Monat vorbei ist. Testen Sie Uptimecheck 14 Tage kostenlos, ohne Kreditkarte.