SLI, SLO und Error Budgets

SLI, SLO und Error Budgets

0:00 Jetzt kommt das Modul, in dem Observability auf Geschäftsentscheidungen trifft. Bisher haben wir gemessen, dargestellt und alarmiert. Jetzt geht es um die Frage, wie zuverlässig ein Dienst eigentlich sein soll — und die hat keine technische Antwort. Eines vorweg, weil es die häufigste Fehlvorstellung ist: Hundert Prozent ist kein Ziel, sondern ein Verzicht auf jede Veränderung.

0:22 Wer nie ausfallen darf, darf auch nie etwas ändern. Die Kunst besteht darin, den richtigen Abstand zu hundert Prozent zu finden — und ihn messbar zu machen.

SLI, SLO und Error Budgets

0:32 Drei Kapitel. Zuerst die Indikatoren: Wie macht man Zuverlässigkeit aus Nutzersicht messbar? Dann die Ziele und das Error Budget, das sich daraus ableitet — inklusive der Burn Rate und der Alarmierungsmethode, die dazu gehört. Und drittens die unbequeme Frage, was eigentlich passiert, wenn das Budget aufgebraucht ist. In der Übung definieren Sie ein Ziel für Pfandwerk und überwachen es.

Zuverlässigkeit messbar machen

0:56 Fangen wir mit den Begriffen an. Drei Abkürzungen, die im Alltag oft durcheinandergehen, und ein Prinzip, das dahintersteht: Gemessen wird aus Nutzersicht, nicht aus Serversicht. Das klingt selbstverständlich und ist es in der Praxis überhaupt nicht — die meisten Verfügbarkeitszahlen, die in Berichten stehen, messen den Prozess und nicht den Vorgang.

1:16 Ein Service Level Indicator misst das Verhalten eines Dienstes aus Nutzersicht. Ein Service Level Objective legt den Zielwert dafür fest. Und ein Service Level Agreement ist die vertragliche Zusage samt Folgen — das ist die Ebene, auf der Juristen mitreden. Der Indikator ist dabei fast immer ein Anteil: gute Ereignisse geteilt durch alle Ereignisse.

1:37 Diese Form ist unspektakulär und außerordentlich tragfähig, denn sie funktioniert für Erfolgsquoten genauso wie für Latenz — man muss nur definieren, was gut heißt. Drei Indikatoren, und die Spalten zeigen genau, worauf es ankommt: Was ist gut, und was ist die Gesamtmenge? Bei der Rücknahme: abgeschlossene Vorgänge geteilt durch alle Versuche.

1:58 Bei der Latenz: Auszahlungen unter zwei Sekunden geteilt durch alle Auszahlungen. Beachten Sie, dass auch die Latenz als Anteil formuliert ist — nicht als Durchschnitt. Das ist die direkte Anwendung von Modul vierzehn. Die Fußzeile nennt die zweite Bauform: Zeitbasierte Indikatoren zählen gute Zeitfenster statt einzelner Ereignisse; das ist bei Diensten ohne klare Anfragen sinnvoll.

2:22 Vier Punkte, die alle in dieselbe Richtung zielen. Ein laufender Prozess ist keine erfolgreiche Rücknahme — das ist der Unterschied zwischen Verfügbarkeit und Zuverlässigkeit, den wir in Modul eins eingeführt haben. Die Latenz zählt dort, wo der Mensch am Automaten wartet, nicht im Rechenzentrum. Fachliche Ablehnungen gehören nicht zu den schlechten Ereignissen — die Entscheidung aus Modul sechs zahlt hier ihre Dividende.

2:46 Und der vierte Punkt ist Handwerk: Was gut und was gesamt ist, muss vor der ersten Messung feststehen. Der erste Punkt ist der Klassiker: Die Verfügbarkeit wird am Serverprozess gemessen. Dann haben Sie 99,99 Prozent auf dem Papier und unzufriedene Nutzer. Der zweite ist die Ablehnung als Fehler, die Ihre Quote grundlos drückt.

3:07 Der dritte ist ein Datenproblem — die Definition von gut ändert sich, und alte Werte werden unvergleichbar; deshalb gehört sie schriftlich und versioniert festgelegt. Und der vierte ist eine Architekturfrage: Der Indikator misst einen Dienst, während der Nutzer drei durchläuft. Der Nutzer erlebt die Kette, nicht das Glied.

Ziele und Budgets

3:27 Jetzt wird gerechnet — und zwar überraschend einfach. Aus einem Zielwert folgt unmittelbar, wie viele Fehler erlaubt sind. Diese Zahl heißt Error Budget, und sie verwandelt eine abstrakte Prozentangabe in etwas, mit dem man arbeiten kann: einen Kontostand. Dazu kommt die Burn Rate, die beschreibt, wie schnell dieser Kontostand abgebaut wird — und die trägt die Alarmierung.

3:50 Das Error Budget ist der Anteil an Fehlern, der innerhalb des Messfensters zulässig ist, ohne das Ziel zu verfehlen — bei 99,9 Prozent über dreißig Tage also 0,1 Prozent. Bei hunderttausend Rücknahmen im Monat sind das hundert, die scheitern dürfen. Diese Umrechnung in absolute Zahlen ist der eigentliche Trick: Plötzlich ist es keine Prozentdiskussion mehr, sondern ein Kontostand.

4:13 Und die Burn Rate beschreibt, wie schnell dieser Kontostand im Verhältnis zum Ziel abgebaut wird. Drei Zeilen, die zeigen, wie sich die Burn Rate liest. Eine Burn Rate von eins heißt: Das Budget reicht genau bis zum Ende des Messfensters — Sie sind exakt auf Kurs. Bei sechs ist es nach fünf Tagen aufgebraucht. Bei vierzehn Komma vier nach rund zwei Tagen.

4:34 Die Zahl vierzehn Komma vier sieht willkürlich aus und ist es nicht: Sie entspricht dem Verbrauch von zwei Prozent des Budgets in einer Stunde. Genau diese Größenordnungen nutzt die Alarmierungsmethode auf der nächsten Folie. Der Name ist sperrig, die Idee ist einfach. Ein schneller Verbrauch soll sofort melden, ein langsamer erst als Ticket — deshalb mehrere Burn Rates.

4:57 Und das kurze Fenster verhindert, dass ein längst beendeter Verbrauch weiter meldet — deshalb mehrere Fenster. Die empfohlenen Werte stehen im dritten Punkt: vierzehn Komma vier über eine Stunde, sechs über sechs Stunden, eins über drei Tage. Und das kurze Fenster beträgt jeweils ein Zwölftel des langen. Diese Werte sind erprobt — Sie müssen sie nicht neu erfinden.

5:20 Der erste Punkt beschreibt, was ohne diese Methode passiert: Es wird auf die reine Fehlerquote alarmiert, und jede Schwankung meldet. Der zweite ist die halbe Umsetzung — nur ein Fenster, und der Alarm bleibt stundenlang aktiv, obwohl die Störung vorbei ist. Der dritte ist die Zielsetzung, über die wir eingangs gesprochen haben: hundert Prozent, also kein Budget, also keine Steuerungsgröße.

5:43 Und der vierte ist banal und häufig — das Messfenster wird nie festgelegt, und damit ist das Budget schlicht nicht berechenbar.

SLOs im Alltag

5:51 Kommen wir zum entscheidenden Kapitel, und es ist kein technisches. Ein Service Level Objective entfaltet seinen Wert erst, wenn daraus Entscheidungen folgen. Ohne diese Folgen ist es eine weitere Zahl in einem weiteren Bericht — gut gemeint, aber wirkungslos. Deshalb geht es hier darum, was ein aufgebrauchtes Budget in Ihrer Organisation konkret auslösen soll.

6:13 Ein Service Level Objective beschreibt die angestrebte Zuverlässigkeit. Das daraus abgeleitete Error Budget schafft einen messbaren Spielraum für Fehler und lässt sich als Grundlage für Release- und Betriebsentscheidungen verwenden. Beachten Sie den letzten Halbsatz auf der Folie: nicht als Kennzahl für Berichte. Das ist der Unterschied zwischen einem lebendigen SLO und einer weiteren Ampelfarbe in der Monatsübersicht.

6:36 Ein Budget, das nichts auslöst, wird nicht beachtet — und dann kann man es auch weglassen. Diese Gegenüberstellung ist der Kern des Ganzen. Ist Budget vorhanden, laufen Releases weiter, das Risiko ist tragbar, Experimente sind möglich, ein Dashboard genügt. Ist es aufgebraucht, werden Änderungen zurückgestellt, Stabilisierung hat Vorrang, keine neuen Experimente, und die Entscheidung wandert auf die Leitungsebene.

7:02 Das Schöne daran: Diese Regeln werden einmal vereinbart, in Ruhe, und gelten dann automatisch. Das erspart die immer gleiche Diskussion im Störfall, wenn alle müde und gereizt sind. Vier Punkte zur Einordnung. Der Wert entsteht erst, wenn das aufgebrauchte Budget etwas verändert. Es verhandelt den Zielkonflikt zwischen Zuverlässigkeit und Tempo sachlich — und dieser Konflikt existiert ohnehin, er wird nur sonst emotional ausgetragen.

7:29 Produktverantwortliche und Betrieb sehen dieselbe Zahl, was die Diskussion erheblich verkürzt. Und der vierte Punkt ist die Warnung: Ein SLO ohne vereinbarte Folge wird beim ersten Konflikt ignoriert. Vereinbaren Sie die Folge, solange niemand unter Druck steht. Der erste Punkt ist das folgenlose SLO von eben. Der zweite ist ein Selbstbetrug, der öfter vorkommt als man denkt: Der Zielwert wird so niedrig gewählt, dass er nie verfehlt wird — dann ist die Messung nur noch Dekoration.

7:58 Der dritte ist Routine ohne Beteiligung: Das Budget wird monatlich zurückgesetzt, ohne dass jemand hinsieht. Und der vierte ist ein Vergleichbarkeitsproblem — jedes Team definiert eigene Indikatoren, und niemand kann zwei Dienste nebeneinander stellen. Auch das ist ein Fall für eine gemeinsame Vereinbarung.

Übung

8:17 In der Übung führen Sie alles zusammen: Indikator, Zielwert, Budget und ein Alarm, der auf die Verbrauchsgeschwindigkeit reagiert. Und Sie treffen die Entscheidung, die aus der Zahl erst eine Steuerungsgröße macht. Der technische Teil ist dabei in einer Viertelstunde erledigt — die Diskussion über die Folgen dauert erfahrungsgemäß länger und ist der eigentliche Ertrag.

8:39 Vier Ergebnisse: Erfolgs- und Latenzindikator mit Zielwert und Messfenster, das berechnete Error Budget, und ein Burn-Rate-Alarm mit zwei Fenstern, der bei simulierter Störung auslöst. Der Hinweis nennt das fünfte, unbequeme Ergebnis: Was geschieht bei aufgebrauchtem Budget mit dem nächsten Release? Diese Frage lässt sich technisch nicht beantworten, und genau deshalb gehört sie in die Übung.

9:02 Nehmen Sie sie mit in Ihre Organisation — sie ist der eigentliche Prüfstein dafür, ob ein SLO ernst gemeint ist. Der rote Faden geht von der Definition über die Rechnung zum Alarm. Erst gute und gesamte Ereignisse definieren — dort steckt die inhaltliche Arbeit. Dann Zielwert und Messfenster festlegen und begründen; die Begründung kommt idealerweise aus der bisherigen Messung, nicht aus dem Bauch.

9:26 Dann das Budget in absoluten Fehlern ausrechnen, weil das die Zahl ist, über die man reden kann. Dann der Alarm mit langem und kurzem Fenster. Und zuletzt die Probe mit Auslösen und Auflösen. Die Fußzeile erinnert an die Folge fürs nächste Release. Der erste Punkt ist der aus dem Bauch gewählte Zielwert — sehen Sie stattdessen nach, wie zuverlässig der Dienst in den letzten Wochen tatsächlich war, und setzen Sie das Ziel in erreichbarer Nähe.

9:53 Der zweite ist das fehlende kurze Fenster, das den Alarm nach der Störung aktiv lässt. Der dritte ist der Ablehnungsfehler, der uns seit Modul sechs begleitet und hier zum letzten Mal auftaucht. Und der vierte ist der organisatorische: Das Budget wird berechnet, aber niemand ist für seine Folgen zuständig. Benennen Sie diese Person — sonst war die Rechnung umsonst.