Was ist ein SLO? Definition, Error Budget und Burn Rate

Was ist ein SLO? Ein Service Level Objective ist ein Zielwert dafür, wie zuverlässig ein bestimmtes, für Nutzer sichtbares Verhalten über ein festes Zeitfenster sein muss. „99.9% der Checkout-Anfragen sind in unter 800 ms erfolgreich, über 30 Tage“ ist ein SLO. „Die Seite soll schnell sein“ ist ein Wunsch. Entscheidend ist weniger die Zahl als das, was sie steuert: Das SLO bestimmt, wann Sie weiter ausliefern und wann Sie anhalten.

Es ist 03:12 Uhr. PagerDuty meldet, dass die Checkout-Latenz „erhöht“ ist. Sie öffnen das Dashboard und sehen eine p99-Linie, die seit vierzig Minuten nach oben wandert. Niemand kann Ihnen sagen, ob das ein Problem ist, denn niemand hat je aufgeschrieben, wie viel Latenz zu viel ist. Die Diskussion, die jetzt im Call folgt, mit einem Auge auf Slack, ist der Preis dafür, dass es kein SLO gibt.

SLI, SLO, SLA: drei Begriffe, drei Verantwortliche

Man verwendet diese Begriffe gern synonym. Sie bedeuten aber nicht dasselbe, und genau diese Verwechslung führt dazu, dass Teams einen Vertrag unterschreiben, den sie nicht einhalten können.

• SLI (Service Level Indicator) ist die Messung. Ein Verhältnis aus guten und gültigen Ereignissen: Anfragen, die mit 2xx in unter 800 ms antworten, geteilt durch alle Anfragen, die so antworten sollten.

• SLO (Service Level Objective) ist das Ziel für dieses Verhältnis über ein Zeitfenster. 99.9% über 30 Tage.

• SLA (Service Level Agreement) ist der Vertrag mit einem Kunden, mit Geld dahinter, falls er verfehlt wird. Er ist immer lockerer als das SLO. Wenn Ihr SLA 99.9% sagt und Ihr SLO ebenfalls 99.9%, bleibt Ihnen kein Spielraum, ein Problem zu bemerken, bevor Sie Gutschriften schulden.

Das Kapitel zu Service Level Objectives im Google-SRE-Buch zieht dieselbe Linie: Das SLO ist ein internes Ziel, das enger ist als alles, was Sie extern zusagen. Ingenieure verantworten SLI und SLO. Produkt und Recht verantworten das SLA.

Verzichten Sie auf den Reflex, für jede Metrik, die Sie ohnehin sammeln, ein viertes Wort zu erfinden. CPU, Speicher und Queue-Tiefe sind nützlich zum Debuggen. Sie sind keine SLIs, denn kein Kunde erlebt sie direkt.

Wie ein guter SLI in der Praxis aussieht

Ein guter SLI ist ein Verhältnis, wird so nah wie möglich am Nutzer gemessen und hat eine klare Definition von „gut“.

Bei einem anfragegetriebenen Dienst sind zwei SLIs der Standard: Verfügbarkeit (Antworten ohne 5xx über alle gültigen Anfragen) und Latenz (Anfragen unter einem Schwellenwert über alle gültigen Anfragen). Nehmen Sie einen Schwellenwert, keinen Durchschnitt. Ein Durchschnitt verdeckt das Ende der Verteilung, und genau dort kommen die Support-Tickets her.

Messen Sie am Load Balancer oder am Edge, nicht im Dienst selbst. Ein Dienst, der beim Start abstürzt, meldet eine perfekte Fehlerquote für die Anfragen, die er nie erhalten hat. Server-seitige Metriken sind für diesen Ausfall blind, der Nutzer erlebt ihn als Störung.

Benennen Sie die Ausnahmen ausdrücklich. Health Checks, synthetische Probes aus dem eigenen Monitoring und 4xx-Antworten wegen fehlerhafter Client-Eingaben sollten meist nicht gegen Sie zählen. Schreiben Sie diese Ausnahmen neben das SLO. Wenn in einer Incident-Review über die Zahl gestritten wird, soll es um die Definition gehen und nicht darum, was das Dashboard gerade zeigt.

Die Rechnung, die vor der Wahl der Neunen niemand anstellt

Jede zusätzliche Neun verkleinert die erlaubte Ausfallzeit um den Faktor zehn. Diese Tabelle sollten Sie im Dokument haben.

• 99% über 30 Tage: 1% Error Budget, 7.2 Stunden erlaubter vollständiger Ausfall.

• 99.9%: 0.1% Budget, 43.2 Minuten.

• 99.95%: 0.05% Budget, 21.6 Minuten.

• 99.99%: 0.01% Budget, 4.32 Minuten.

Lesen Sie die letzte Zeile noch einmal. Bei 99.99% hat ein einziges fehlerhaftes Deployment, das fünf Minuten braucht, bis es entdeckt und zurückgerollt ist, den Monat bereits gesprengt. Menschen können auf eine Page nicht reagieren, den Laptop aufklappen und in unter vier Minuten zurückrollen. Dieses Ziel ist also nur mit Automatisierung erreichbar, mit einem automatischen Gate, das den Rollout stoppt, bevor das Budget aufgebraucht ist.

Wählen Sie deshalb die Zahl, die der Dienst tatsächlich braucht. Die meisten internen APIs fühlen sich bei 99.9% wohl. Ein Zahlungspfad kann mehr rechtfertigen. Ein nächtlicher Batch-Job kann mit 99% leben. Wer 99.99% wählt, weil die Zahl seriös klingt, meldet das Team für eine Bereitschaftsrotation an, die es nicht besetzen kann.

Das Error Budget ist der Kern, nicht das SLO

Ein SLO von 99.9% bedeutet, dass Sie in 0.1% der Zeit scheitern dürfen. Diese 0.1% sind Ihr Error Budget, und es ist die nützlichste Idee der ganzen Disziplin.

Das Budget verwandelt einen Streit in eine Zahl. Das Produkt will die riskante Migration ausliefern, der SRE sagt, sie sei riskant. Ohne Budget steht Meinung gegen Meinung, und die Seniorität gewinnt. Mit Budget lautet die Frage: Wie viel ist noch übrig, und wie viel verbraucht diese Änderung vermutlich?

Zwei Regeln machen das funktionsfähig.

1. Budget übrig: ausliefern. Sie dürfen Risiko eingehen, also tun Sie es. Ein Team, das sein Budget nie ausschöpft, investiert zu viel in Zuverlässigkeit, die die Nutzer gar nicht verlangt haben.

2. Budget aufgebraucht: einfrieren. Feature-Arbeit pausiert, bis Reliability-Arbeit den SLI wieder über das Ziel bringt. Das funktioniert nur, wenn die Führung dem schon vor dem ersten Incident zugestimmt hat, nicht erst während des Incidents.

Wenn die zweite Regel nicht vorab vereinbart ist, haben Sie kein SLO. Sie haben ein Dashboard mit einer grünen und einer roten Zone.

Alarmierung auf Burn Rate statt auf den SLI selbst

Hier scheitern die meisten ersten Versuche. Jemand setzt einen Alarm, der auslöst, wenn die Verfügbarkeit unter 99.9% fällt. Der Alarm feuert, nachdem der Schaden passiert ist, oder er flackert bei jeder Schwankung, oft beides.

Das bessere Signal ist die Burn Rate: wie schnell Sie das Budget verbrauchen, verglichen mit dem Tempo, das es genau am Ende des Fensters aufbrauchen würde. Eine Burn Rate von 1 bedeutet, dass Sie den Monat mit null Budget abschließen. Eine Burn Rate von 14.4 bedeutet, dass Sie das Budget eines ganzen Monats in etwa zwei Tagen verbrennen.

Der Abschnitt zur Alarmierung auf SLOs im Google-SRE-Workbook empfiehlt, ein langes und ein kurzes Fenster zu kombinieren, damit der Alarm sowohl signifikant ist als auch noch andauert. Für ein 30-Tage-SLO sind zwei Pages ein guter Startpunkt:

• Burn Rate 14.4 über 1 Stunde, bestätigt über 5 Minuten: verbraucht 2% des monatlichen Budgets. Jemand wird geweckt.

• Burn Rate 6 über 6 Stunden, bestätigt über 30 Minuten: verbraucht 5% des monatlichen Budgets. Jemand wird geweckt.

Die Rechnung ist schlicht. Ein 30-Tage-Fenster hat 720 Stunden. Wer eine Stunde mit dem 14.4-Fachen brennt, verbraucht 14.4 / 720 = 2% des Budgets. Das kurze Fenster verhindert, dass der Alarm noch eine Stunde nach dem Ende des Problems feuert.

Hier ist die erste Regel als Prometheus-Alert, unter der Annahme, dass Sie eine Fehlerquote pro Fenster aufzeichnen:

groups:
  - name: checkout-slo-burn
    rules:
      - alert: CheckoutErrorBudgetFastBurn
        expr: |
          job:checkout_error_ratio:rate1h > (14.4 * 0.001)
          and
          job:checkout_error_ratio:rate5m > (14.4 * 0.001)
        labels:
          severity: page
        annotations:
          summary: "Checkout verbraucht pro Stunde 2% seines 30-Tage-Error-Budgets"

Die 0.001 ist die erlaubte Fehlerquote für ein 99.9%-SLO. Ändern Sie das Ziel, dann verschiebt sich diese Konstante mit. Halten Sie sie an einer einzigen Stelle, sonst laufen Alarm und SLO auseinander, ohne dass es jemand bemerkt.

Langsamere Verbrennungen brauchen keine Page. Eine dauerhafte Burn Rate von 1 über drei Tage gehört in ein Ticket für den nächsten Arbeitsmorgen. Wer das Team nachts wegen eines langsamen Lecks weckt, bringt Bereitschaftsteams bei, den Pager zu ignorieren.

Den SLI berechnen, ohne eine zweite Plattform zu kaufen

Für den Anfang brauchen Sie kein eigenes SLO-Produkt. Sie brauchen einen Zähler für gute Ereignisse, einen Zähler für alle Ereignisse und einen Ort, an dem beide 30 Tage lang gespeichert werden.

Liegen Ihre Metriken bereits auf einer gehosteten Plattform, ist das SLO-Feature meist eine dünne Schicht über Daten, für die Sie ohnehin bezahlen.

Datadog bietet SLOs nativ an, inklusive Burn-Rate-Alarmen, und ist der einfache Weg, wenn Traces und Metriken dort bereits liegen. Der Haken ist die Rechnung: Custom Metrics und hochkardinale Tags vervielfachen sich schnell. Prüfen Sie also den Preis der SLI-Zeitreihen, bevor Sie sich festlegen.

Wenn Sie Prometheus betreiben, deckt Grafana dasselbe Terrain über Recording Rules und seine SLO-Werkzeuge ab, allerdings mit mehr Einrichtungsaufwand und mehr eigener Zeit.

Der ehrliche Vergleich lautet: Zeit bis zum ersten brauchbaren Alarm gegen Kosten im großen Maßstab. Datadog gewinnt beim ersten Punkt, Grafana mit Prometheus meist beim zweiten. Entscheiden Sie anhand dessen, woran es Ihrem Team gerade fehlt.

Das SLO mit dem Rollout verbinden, der Teil, den die meisten auslassen

Ein SLO, das nur einen Bericht erzeugt, wird nur halb genutzt. Der Schritt, der das Verhalten tatsächlich ändert, ist die Anbindung des Budgets an den Deployment-Pfad, damit der Rollout sich selbst anhält.

Ein progressiver Rollout mit SLO-Gate funktioniert so: Sie liefern zuerst an 1% des Traffics hinter einem Flag aus. Sie beobachten den SLI dieser Kohorte gegen die Baseline. Überschreitet die Burn Rate der Canary-Kohorte den Schwellenwert, rollen Sie automatisch zurück. Hält sie, gehen Sie auf 5%, dann auf 25%, dann auf 100%.

Das ist etwas anderes als ein Dashboard, das jemand um 03:12 Uhr im Blick behalten soll. Um 03:12 Uhr wollen Sie nicht denken. Sie wollen einen Knopf oder, besser, überhaupt keinen Knopf.

Hier zahlen sich Feature Flags aus, denn ein Flag macht aus einem Rollback eine Konfigurationsänderung, die Sekunden dauert, statt eines Redeployments, das zehn Minuten braucht.

LaunchDarkly und ähnliche Plattformen liefern Ihnen das prozentuale Rollout und den Kill Switch. Was die meisten Ihnen überlassen, ist die Entscheidung: Welcher SLI wird gelesen, welcher Schwellenwert gilt als schlecht, und wer darf überstimmen? Genau diese Lücke soll ein automatischer Pilot mit Auto-Rollback auf Basis des SLO schließen. Diesen Ansatz verfolgen wir bei upstreamapi. LaunchDarkly gewinnt bei SDK-Breite und Enterprise-Kontrollen, und das sagen wir auch.

Hier die Form des Gates in TypeScript. Die Entscheidungslogik ist der Teil, den Sie selbst schreiben sollten, egal welches Flag-System Sie nutzen:

type Cohort = { good: number; total: number };

const SLO_TARGET = 0.999;
const BUDGET = 1 - SLO_TARGET; // 0.001
const PAGE_BURN_RATE = 14.4;

function burnRate(c: Cohort): number {
  if (c.total === 0) return 0;
  const errorRatio = 1 - c.good / c.total;
  return errorRatio / BUDGET;
}

export function rolloutDecision(canary: Cohort): "advance" | "hold" | "revert" {
  if (canary.total < 500) return "hold"; // nicht genug Traffic für ein Urteil
  return burnRate(canary) > PAGE_BURN_RATE ? "revert" : "advance";
}

Achten Sie auf den Zweig hold. Ein Canary auf 1% eines ruhigen Dienstes sieht in zehn Minuten vielleicht vierzig Anfragen, und ein Fehler bei vierzig Anfragen ist eine Fehlerquote von 2.5%. Ohne Mindeststichprobe löst das Gate auf Rauschen hin aus, und Ihr Team lernt, ihm nicht zu trauen.

Fehler, die wir bei Teams mit 80 Ingenieuren immer wieder sehen

Dieselben wenigen Fehler tauchen in vielen Teams auf, und fast keiner davon ist technisch.

Zu viele SLOs. Zwanzig Ziele pro Dienst bedeuten, dass sich niemand an eines davon erinnert. Zwei oder drei pro Nutzerreise reichen.

SLOs, denen niemand zugestimmt hat. Ein Ingenieur schreibt sie allein an einem Wochenende. Das Produkt hat sie nie gesehen, also bricht die Budgetregel zusammen, sobald sie bei einem Launch Nein sagt.

SLOs auf dem aktuellen Niveau. Läuft der Dienst heute bei 99.97% und setzen Sie das Ziel auf 99.97%, bleibt kein Budget, und ein Verfehlen ist garantiert. Setzen Sie das Ziel dort an, wo Nutzer anfangen, unzufrieden zu werden. Das liegt fast immer tiefer.

Das SLO als dauerhaft behandeln. Prüfen Sie die Zahl jedes Quartal. Verbrauchen Sie das Budget nie, sollten Sie das Ziel verschärfen oder schneller ausliefern. Reißen Sie es jeden Monat, beheben Sie entweder das System oder geben zu, dass das Ziel eine Fantasie war.

Zählen, was leicht zu messen ist, statt was die Nutzer spüren. Eine 200-Antwort mit leerem Warenkorb ist in Ihren Logs ein Erfolg und für den Kunden ein Fehler. Definieren Sie „gut“ aus Sicht der Nutzer.

Wer diese Woche den ersten schreiben sollte

Sie brauchen dafür kein Programm. Wählen Sie die eine Nutzerreise, bei deren Ausfall der CEO jemanden anrufen würde. Definieren Sie dafür einen Verfügbarkeits-SLI und einen Latenz-SLI. Setzen Sie das Ziel im ersten Quartal auf 99.9%, schreiben Sie die Einfrierregel in zwei Sätzen auf und lassen Sie das Produkt schriftlich mit „einverstanden“ antworten.

Danach fügen Sie einen Burn-Rate-Alarm hinzu und einen Ort, an dem das ganze Team das verbleibende Budget sieht.

Wenn Sie vor einer vollwertigen Plattform einen schlanken Startpunkt wollen, übernimmt Better Stack Uptime-Monitoring und Incident-Paging mit deutlich weniger Einrichtung. Die Budget-Rechnung erledigt es Ihnen allerdings nicht gratis.

Die erste Version wird falsch sein. Das ist in Ordnung. Entscheidend ist, dass die nächste Incident-Review von einer Zahl ausgeht, die Sie vorher aufgeschrieben haben, und nicht von einem Gefühl.

Wie sieht Ihr 03:12 Uhr jetzt aus?

Denken Sie an den letzten Incident in Ihrem Team. Gab es eine Zahl, die festlegte, ob er wichtig war? Wenn die ehrliche Antwort nein lautet, ist das Ihr erstes SLO, und das Post-Mortem hat Ihnen bereits verraten, was Sie messen sollten.