In fast jedem Unternehmen gibt es dieselbe wiederkehrende Diskussion: Die einen wollen neue Funktionen, die anderen wollen erst Stabilität. Beide Seiten argumentieren mit Eindrücken. Die Methode dahinter ändert das, indem sie Zuverlässigkeit zu einer Zahl macht, über die man nicht mehr streiten muss.
Drei Begriffe, die auseinandergehalten gehören
- SLI (Service Level Indicator): die Messgröße. Zum Beispiel der Anteil erfolgreicher Anfragen an allen Anfragen, oder der Anteil der Antworten unter 300 Millisekunden.
- SLO (Service Level Objective): das interne Ziel für diesen Indikator, etwa 99,5 Prozent erfolgreiche Anfragen im Monat.
- SLA (Service Level Agreement): die vertragliche Zusage gegenüber Kunden, meist mit Vertragsstrafe. Sie liegt bewusst unter dem internen Ziel.
Der häufigste Fehler ist, SLO und SLA gleichzusetzen. Das interne Ziel muss strenger sein als die Zusage, sonst ist die erste Verfehlung sofort ein Vertragsproblem statt eine interne Warnung.
Das Fehlerbudget ist der eigentliche Hebel
Ein SLO von 99,5 Prozent bedeutet nicht nur, dass 99,5 Prozent funktionieren sollen. Es bedeutet auch, dass 0,5 Prozent ausfallen dürfen. Diese 0,5 Prozent sind das Fehlerbudget — ein Kontingent, das über den Zeitraum verbraucht wird.
Damit wird die Frage nach neuen Funktionen beantwortbar: Ist das Budget weitgehend unangetastet, kann schneller ausgeliefert und mehr riskiert werden. Ist es aufgebraucht, gehen Änderungen zurück und Stabilisierung nach vorn. Die Regel ist vorher vereinbart, nicht im Streitfall ausgehandelt.
Ein SLO ohne vereinbarte Konsequenz ist nur ein weiteres Diagramm. Der Nutzen entsteht ausschließlich dann, wenn vorher festgelegt wurde, was passiert, sobald das Fehlerbudget aufgebraucht ist — und wer diese Entscheidung nicht überstimmen darf.
Warum 100 Prozent das falsche Ziel ist
Jede zusätzliche Neun kostet überproportional. Von 99 auf 99,9 Prozent bedeutet meist Redundanz und bessere Überwachung. Von 99,9 auf 99,99 bedeutet mehrfache Standorte, automatische Umschaltung und dauerhafte Rufbereitschaft. Der Sprung kostet ein Vielfaches — und in vielen Fällen merkt der Nutzer den Unterschied nicht, weil sein eigenes Netz unzuverlässiger ist als der Dienst.
Deshalb ist die richtige Frage nicht, wie stabil ein System sein kann, sondern wie stabil es sein muss, damit der Nutzer zufrieden ist und das Geschäft nicht leidet. Alles darüber ist Geld, das an anderer Stelle mehr bewirkt.
Den richtigen Indikator wählen
Der schwierigste Teil ist nicht die Zahl, sondern die Wahl der Messgröße. Serverseitige Verfügbarkeit misst, ob die Maschine läuft — nicht, ob der Kunde arbeiten kann. Aussagekräftig sind Indikatoren, die den tatsächlichen Nutzerpfad abbilden: Konnte die Bestellung abgeschlossen werden? Wurde die Suche innerhalb einer akzeptablen Zeit beantwortet?
Sinnvoll sind wenige Indikatoren je Dienst, meist Verfügbarkeit und Latenz auf den zwei bis drei wichtigsten Abläufen. Wer für jeden Endpunkt ein Ziel definiert, erzeugt eine Tabelle, die niemand mehr liest. Wie die dazugehörige Alarmierung aufgesetzt wird, beschreibt der Beitrag zu Monitoring und Alerting.
Alarmieren auf Budgetverbrauch statt auf Einzelwerte
Klassische Schwellenwerte lösen zu oft aus. Wer bei jedem kurzen Ausschlag geweckt wird, schaltet die Alarme ab — und verpasst den echten Ausfall. Deutlich robuster ist eine Alarmierung, die auf die Geschwindigkeit des Budgetverbrauchs schaut: Ein schneller Verbrauch löst sofort aus, ein langsamer erzeugt eine Aufgabe für den nächsten Werktag.
Das dämpft nicht nur den Lärm, es priorisiert automatisch. Ein Fehler, der das Monatsbudget in einer Stunde verbrennt, ist ein anderes Ereignis als einer, der es über drei Wochen aufzehrt — auch wenn beide dieselbe Fehlerrate zeigen.
Was die Methode nicht leistet
Fehlerbudgets funktionieren gut bei Diensten mit vielen gleichartigen Anfragen. Bei seltenen, aber kritischen Vorgängen versagen sie: Wenn im Monat zwanzig Vorgänge laufen und einer scheitert, sind das fünf Prozent Fehlerrate, obwohl es ein Einzelfall ist. Für solche Abläufe ist die einzelne Nachverfolgung sinnvoller als eine Quote.
Ebenso lassen sich Datenverluste und Sicherheitsvorfälle nicht in ein Budget einrechnen. Es gibt kein zulässiges Kontingent für verlorene Kundendaten. Solche Ereignisse gehören außerhalb dieser Systematik behandelt.
Wie ein Einstieg aussieht
Realistisch ist ein kleiner Anfang: einen zentralen Ablauf auswählen, zwei Indikatoren definieren, vier Wochen ohne Ziel messen und danach das Ziel knapp unterhalb des tatsächlichen Ist-Werts festlegen. So entsteht ein Ziel, das erreichbar ist und trotzdem Druck erzeugt — statt einer Wunschzahl, die vom ersten Tag an verfehlt wird und deshalb ignoriert wird.
Danach folgt der Teil, der über den Nutzen entscheidet: die Vereinbarung, was bei aufgebrauchtem Budget tatsächlich passiert. Ohne sie bleibt auch das beste Messsystem ein Bericht, den niemand zum Anlass nimmt, etwas zu ändern.