Vorfallmanagement für High-Velocity-Teams
Was ist ein Fehlerbudget, und warum ist es wichtig?
Jedes Entwicklungs-, Operations- und IT-Team weiß, dass es manchmal zu Vorfällen kommt.
Selbst die größten Unternehmen mit den fähigsten Mitarbeitern und dem Ruf, eine fast 100%ige Verfügbarkeit zu gewährleisten, müssen manchmal machtlos dabei zusehen, wie ihre Systeme ausfallen. Schau dir nur Apple, Delta oder Facebook an: Sie alle haben in den letzten fünf Jahren durch Vorfälle mehrere zehn Millionen an Verlusten hinnehmen müssen.
Das bedeutet, dass Service Level Agreements (SLAs) niemals eine Verfügbarkeit von 100 % versprechen sollten. Denn dieses Versprechen kann kein Unternehmen einhalten.
Wenn dein Unternehmen aber sehr gut darin ist, Vorfälle zu vermeiden oder zu beheben, wird es seine Verfügbarkeitsziele regelmäßig überbieten. Vielleicht versprichst du eine Verfügbarkeit von 99 %, erreichst tatsächlich aber fast 99,5 %. Oder du versprichst eine Verfügbarkeit von 99,5 % und erreichst tatsächlich 99,99 % in einem normalen Monat.
In solchen Fällen empfehlen Branchenexperten, Benutzererwartungen nicht zu hoch zu stecken, indem du deine Versprechen ständig übertriffst. Stattdessen solltest du die zusätzlichen 0,99 % als Fehlerbudget betrachten. Das ist Zeit, die dein Team nutzen kann, um Risiken einzugehen.
Was ist ein Fehlerbudget?
Ein Fehlerbudget ist die maximale Zeit, die ein technisches System ausfallen darf, ohne dass dies vertragliche Konsequenzen hätte.
Ein Beispiel: Dein Service Level Agreement (SLA) besagt, dass Systeme beispielsweise 99,99 % der Zeit funktionieren müssen, bevor das Unternehmen Kunden für Ausfälle entschädigen muss. Das heißt, dein Fehlerbudget (oder die Zeit, in der deine Systeme ohne Folgen ausfallen dürfen) beträgt pro Jahr 52 Minuten und 35 Sekunden.
Wenn dein Service Level Agreement (SLA) eine Verfügbarkeit von 99,95 % verspricht, beträgt dein Fehlerbudget vier Stunden, 22 Minuten und 48 Sekunden. Und mit einem SLA, das eine Verfügbarkeit von 99,9 % zusagt, beträgt dein Fehlerbudget acht Stunden, 46 Minuten und 12 Sekunden.
Warum brauchen technische Teams Fehlerbudgets?
Auf den ersten Blick scheinen Fehlerbudgets nicht so wichtig zu sein. Sie sind nur eine weitere Metrik, die IT- und DevOps-Teams nachverfolgen müssen, um sicherzustellen, dass alles reibungslos läuft. Oder nicht?
Die Antwort lautet zum Glück "Nein". Fehlerbudgets sind nicht nur eine praktische Möglichkeit, um sicherzustellen, dass du vertragliche Versprechen einhältst. Sie bieten Entwicklerteams auch die Möglichkeit, innovativ zu sein und Risiken einzugehen.
Wir erklären es in unserem SRE-Artikel so:
"Das Entwicklerteam kann dieses Fehlerbudget beliebig "investieren". Wenn das Produkt derzeit einwandfrei und mit wenigen oder keinen Fehlern läuft, kann das Team jederzeit ein beliebiges neues Produkt auf den Markt bringen. Wenn es das Fehlerbudget jedoch ausgereizt oder überzogen hat und das definierte Service Level Agreement (SLA) gerade noch oder nicht mehr einhält, werden alle Einführungen auf Eis gelegt, bis die Anzahl der Fehler auf ein Niveau reduziert sind, das weitere Einführungen erlaubt."
Der Vorteil dieses Ansatzes: Teams werden dazu ermutigt, echte Vorfälle zu minimieren und Innovationen zu maximieren, indem sie Risiken innerhalb zulässiger Grenzen eingehen. Er schließt zudem die Lücke zwischen Entwicklerteams, deren Ziele Innovation und Agilität sind, und Operations-Teams, die sich um die Stabilität und Sicherheit kümmern. Solange die Ausfallzeiten niedrig bleiben, können Entwickler agil handeln und Änderungen vorantreiben, ohne von der Operations-Abteilung daran gehindert zu werden.
So nutzt du ein Fehlerbudget
Zuerst musst du dir deine SLAs und SLOs näher betrachten. Welche Ziele hast du bereits für die Verfügbarkeit oder für erfolgreiche Systemanfragen festgelegt? Welche Versprechen hat dein Unternehmen Kunden gegeben? Von diesen Aspekten wird dein Fehlerbudget bestimmt.
Fehlerbudgets auf Basis der Verfügbarkeit
Die meisten Teams überwachen die Verfügbarkeit monatlich. Wenn die Verfügbarkeit über dem vom SLA/SLO versprochenen Prozentsatz liegt, kann das Team neue Funktionen veröffentlichen und Risiken eingehen. Wenn sie das Ziel nicht erfüllt, werden weitere Einführungen gestoppt, bis der Zielwert wieder erreicht ist.
Um diese Methode effektiv nutzen zu können, musst du dein SLO-Ziel (normalerweise einen Prozentsatz) in reale Zahlen umwandeln, mit denen deine Entwickler arbeiten können. Du musst beispielsweise berechnen, wie viele Stunden und Minuten deine zulässigen Ausfälle von 1 %, 0,5 % oder 0,1 % eigentlich sind. Hier einige typische Zielwerte:
SLA-Ziel | Zulässige Ausfallzeit pro Jahr | Zulässige Ausfallzeit pro Monat | |
|---|---|---|---|
| 99,99 % Verfügbarkeit | Zulässige Ausfallzeit pro Jahr 52 Minuten, 35 Sekunden | Zulässige Ausfallzeit pro Monat 4 Minuten, 23 Sekunden | |
| 99,95 % Verfügbarkeit | Zulässige Ausfallzeit pro Jahr 4 Stunden, 22 Minuten, 48 Sekunden | Zulässige Ausfallzeit pro Monat 21 Minuten, 54 Sekunden | |
| 99,9 % Verfügbarkeit | Zulässige Ausfallzeit pro Jahr 8 Stunden, 45 Minuten, 57 Sekunden | Zulässige Ausfallzeit pro Monat 43 Minuten, 50 Sekunden | |
| 99,5 % Verfügbarkeit | Zulässige Ausfallzeit pro Jahr 43 Stunden, 49 Minuten, 45 Sekunden | Zulässige Ausfallzeit pro Monat 3 Stunden, 39 Minuten | |
| 99 % Verfügbarkeit | Zulässige Ausfallzeit pro Jahr 87 Stunden, 39 Minuten | Zulässige Ausfallzeit pro Monat 7 Stunden, 18 Minuten | |
Fehlerbudgets auf Basis erfolgreicher Anfragen
Die Abneigung gegenüber SLOs ist geringer als gegenüber SLAs, sie können aber genauso viele Probleme verursachen, wenn sie vage, übermäßig kompliziert oder unmöglich zu messen sind. Einfachheit und Klarheit sind unerlässlich, um SLOs zu erstellen, mit denen die Techniker im Unternehmen gut zurechtkommen. Nur die wichtigsten Metriken sollten in die SLOs aufgenommen werden. Außerdem sollten die Ziele immer in einfacher Sprache abgefasst sein, und wie bei den SLAs sollten Probleme wie Verzögerungen auf Kundenseite berücksichtigt werden.
Behalte mit Jira Service Management den Überblick über SLAs, um Anfragen basierend auf Prioritäten zu lösen, und verwende automatisierte Eskalationsregeln, um die richtigen Teammitglieder zu benachrichtigen und SLA-Verstöße zu verhindern.
Informationen zur Kommunikation bei Vorfällen mit Statuspage
In diesem Tutorial zeigen wir dir, wie du mithilfe von Vorfallvorlagen bei Ausfällen effektiv kommunizierst. Sie sind an viele Arten von Serviceunterbrechungen anpassbar.
Dieses Tutorial ansehenWarum Post-Mortem-Analysen von Vorfällen so wichtig sind
Die Post-Mortem-Analyse eines Vorfalls, auch als Post-Incident Review bekannt, ist die beste Methode, einen Vorfall aufzuarbeiten und die daraus gezogenen Lehren zu dokumentieren.
Artikel lesen