Was ist ein SLO? Zuverlässigkeitsziele im Engineering

Was ist ein SLO? Ein Service Level Objective (SLO) ist ein internes Zuverlässigkeitsziel, das Ihr Team sich selbst setzt. Es ist kein Vertrag mit Kunden und auch keine Rohmessung aus Ihrem Observability-Stack. Ein SLO beantwortet eine zentrale Frage: Wie zuverlässig muss dieser Service sein, und wie messen wir das?

Ein vollständiges SLO sieht so aus: 99,9 % aller HTTP-Requests an /api/checkout liefern einen erfolgreichen Status und werden innerhalb von 300 ms abgeschlossen, gemessen über ein rollendes 30-Tage-Fenster. Drei Komponenten: die Messung, das Ziel und das Fenster. Alle drei Komponenten sind entscheidend.

SLI, SLO, SLA: Drei Abkürzungen mit unterschiedlichen Bedeutungen

Diese drei Begriffe tauchen ständig zusammen auf. Teams verwenden sie oft synonym. Sie beschreiben jedoch unterschiedliche Dinge.

Ein SLI (Service Level Indicator) ist die Rohmessung, die Ihr Monitoring-System erzeugt. Fehlerquote als Prozentanteil aller Requests. P99-Latenz in Millisekunden. Prozentsatz erfolgreicher Datenbankschreibzugriffe. Das SLI ist die Zahl, die aus Datadog, Grafana oder dem genutzten Stack kommt. Es zeigt Ihnen, was passiert ist.

Ein SLO (Service Level Objective) ist das Ziel, das Sie basierend auf dem SLI definieren. Es beantwortet: Welcher Bereich aus allen möglichen Werten des SLI zählt als akzeptabel? Wenn Ihr SLI die Fehlerquote ist und Ihr SLO lautet "Fehlerquote unter 0,1 % für 99 % der Fünf-Minuten-Fenster", dann haben Sie einen Bestanden/Nicht-Bestanden-Test, nicht nur eine Zahl auf einem Dashboard.

Ein SLA (Service Level Agreement) ist die externe Version derselben Logik mit vertraglichen Konsequenzen. Ihr SLA könnte vorsehen: "99,5 % Verfügbarkeit oder wir gewähren 20 % Dienstguthrift." Ihr SLO sollte über dieser Schwelle liegen, damit Ihr Team Degradationen merkt, bevor ein SLA-Verstoß zu einem Gespräch mit Kunden wird.

Die Lücke zwischen SLO und SLA ist kein Polster für Fahrlässigkeit. Sie ist ein bewusst eingeplanter Sicherheitsabstand, der "wir steuern auf einen Verstoß zu" in "wir haben Zeit, das jetzt zu beheben" umwandelt.

Ein weiterer wichtiger Unterschied: SLIs werden kontinuierlich gemessen, aber SLOs werden über ein Fenster bewertet. Dieselbe Fehlerquote gemessen über sieben Tage versus 30 Tage erzeugt sehr unterschiedliche Bestanden/Nicht-Bestanden-Ergebnisse. Eine einzelne schlechte Stunde wiegt in einem Sieben-Tage-Fenster schwer. In einem 30-Tage-Fenster ist sie ungefähr ein Prozent des Zeitraums. Die Wahl des richtigen Fensters ist genauso wichtig wie die Wahl des richtigen Ziels.

Warum "Wie zuverlässig?" nicht die vollständige Frage ist

Bevor Sie sich auf eine Zahl einigen, müssen Sie verstehen, was Benutzer erleben, wenn der Service abbaut. "Wir brauchen fünf Neunen" ist eine Absichtserklärung, keine Messung. Eine Checkout-API mit 99,999 % Verfügbarkeit bedeutet ungefähr 26 Sekunden Fehlerzeit pro Monat. Für einen Service, der zehn Transaktionen pro Sekunde verarbeitet, ist das möglicherweise akzeptabel. Für einen Service, der in Echtzeit Finanzliquidationen abwickelt, möglicherweise nicht.

Das richtige SLO hängt von zwei Faktoren ab: von der Auswirkung einer Degradation auf Benutzer und von den Betriebskosten, um ein strengeres Ziel zu halten.

Wenn Ihr Service in den letzten 90 Tagen 99,3 % Verfügbarkeit hatte, dann ist ein SLO von 99,9 % am Anfang aspirativ, nicht kalibriert. Der praktische Ansatz: Ziehen Sie die SLI-Daten der letzten 90 Tage heran, legen Sie das SLO etwas strenger als die aktuelle Leistung fest, und überprüfen Sie vierteljährlich. Ein SLO von 99,5 % mit einer echten Error-Budget-Richtlinie schlägt ein SLO von 99,9 %, das jedes Mal ignoriert wird, wenn es verletzt wird.

Typische SLO-Ziele nach Service-Typ:

• Benutzergerichtete APIs (Checkout, Authentifizierung): 99,9 % Verfügbarkeit, P99-Latenz unter 500 ms

• Interne Services (Daten-Pipelines, Batch-Jobs): 99,5 % Erfolgsquote, gemessen an Job-Abschluss

• Admin-Tools: 99 % Verfügbarkeit ist oft ausreichend

• Hintergrund-Worker: SLO für Job-Abschlusszeit statt HTTP-Status

Wenn Sie auswählen, welches SLI Sie messen, verwenden Sie die vier Signale aus Googles SRE-Buch als Ausgangspunkt: Verfügbarkeit (wurde die Anfrage erfolgreich abgeschlossen?), Latenz (wie lange hat es gedauert?), Durchsatz (wie viele Requests verarbeitet das System?), und Fehlerquote (Welcher Anteil fehlgeschlagen?). Nicht jeder Service braucht alle vier. Die meisten Teams bekommen echte Aussagekraft aus Verfügbarkeit plus einer Latenz-Perzentil. Mehrere SLIs hinzufügen, bevor Sie für die ersten zwei eine zuverlässige Ausgangslage haben, ist ein verbreiteter Weg, Rauschen zu erzeugen ohne Erkenntnisse zu gewinnen.

Das Error Budget: Vom Ziel zur Betriebsentscheidung

Ein Error Budget ist das mathematische Gegenteil Ihres SLO. Wenn Ihr SLO für Verfügbarkeit 99,9 % ist, dann dürfen 0,1 % der Requests über das Messfenster hinweg fehlschlagen. Für einen Service, der eine Million Requests pro Monat empfängt, sind das 1.000 fehlgeschlagene Requests, bevor das SLO verletzt wird.

Das Error Budget macht SLOs operativ nützlich. Ohne es ist ein SLO eine Schwelle, die verletzt und dann diskutiert wird. Mit einer Error-Budget-Richtlinie wird es zu einem Entscheidungsrahmen.

Wenn das Error Budget gesund ist, sagen wir 80 % verbleibend mit zwei Wochen im Fenster verbleibend, kann das Team schnell ausliefern. Neue Features, Experimente, riskantere Deployments sind alle zulässig. Das Error Budget ist das Signal, dass Geschwindigkeit aktuell nicht der Engpass ist.

Wenn das Error Budget aufgebraucht wird, ändert das Team seine Strategie. Nicht-kritische Änderungen gehen in den Rückstand. Die Deployment-Richtlinie wird strenger. Zuverlässigkeitsfixes bekommen Priorität. Das Error Budget traf die Entscheidung, nicht ein Management-Urteilsspruch über "whether things feel stable enough".

Ein konkretes Szenario: Ein Checkout-Service hatte eine 12-Minuten-Degradation Dienstagvormittag, die 15 % des monatlichen Error Budgets verbrauchte. Ein zweiter Zwischenfall Donnerstag verbrauchte weitere 12 %. Mit 27 % im ersten Wochenmonat verbrauchtem Budget tritt die Error-Budget-Richtlinie in Kraft: keine neuen Feature-Deployments, bis ein Postmortem vorliegt und die Grundursache gepatcht ist. Diese Entscheidung ist kein Produkt-/Engineering-Verhandlungsthema. Sie ist eine Ablesung aus den Daten.

Google veröffentlichte seine Error-Budget-Richtlinie im SRE-Workbook: Ein einzelner Zwischenfall, der mehr als 20 % des Quarterly Error Budgets verbraucht, erfordert ein Postmortem. Das ist eine konkrete Richtlinie zum Anpassen.

Burn-Rate-Alerts gehen weiter. Statt zu warten, bis das Error Budget fast aufgebraucht ist, löst ein Burn-Rate-Alert aus, wenn die Konsumtionsrate andeuten würde, dass Sie das Budget vor Ablauf des Fensters ausschöpfen. Wenn Ihr Service Error Budget 14-mal schneller verbraucht als normal, erschöpfen Sie ein 30-Tage-Budget ungefähr in 50 Stunden. Ein Alert bei dieser Rate gibt dem Team zwei Tage zum Reagieren, statt einer Postmortem-Benachrichtigung nach dem Verstoß. Tools wie Datadog und Grafana unterstützen Multi-Fenster-, Multi-Burn-Rate-Alerting ab Werk. Das Einrichten braucht einen Nachmittag. Es nicht zu haben bedeutet, SLO-Verstöße nach dem Bemerken durch Kunden zu entdecken.

Legen Sie Ihr erstes SLO fest, ohne die Zahl falsch zu bekommen

Der häufigste Fehler ist, mit dem Ziel zu beginnen, bevor die Messung etabliert ist.

Schritt 1: Definieren Sie das SLI. "Verfügbarkeit" ist kein SLI. "HTTP-Requests, die einen Nicht-Fehler-Status zurückgeben (2xx/3xx), geteilt durch alle HTTP-Requests" ist ein SLI. Die Messung muss aus der Telemetrie hervorgehen, die Sie bereits haben. Ein Versprechen, etwas "bald" zu instrumentieren bedeutet, dass das SLO keine Datenquelle hat.

Schritt 2: Ziehen Sie historische Daten heran. Schauen Sie sich die letzten 60 bis 90 Tage an. Wie sieht das SLI wirklich aus? Was waren die zwei oder drei schlechtesten Tage? Das zeigt Ihnen, welches Ziel heute erreichbar ist und wie viel Spielraum Sie vor dem ersten Verstoß haben.

Schritt 3: Legen Sie das Messfenster fest. Rollende 30-Tage-Fenster sind am häufigsten und geben Ihnen responsive, immer aktuelle Daten. Kalendermonat-Fenster erzeugen Klippeneffekte an Monatsgrenzen. Sieben-Tage-Rollenfenster sind empfindlicher, können aber zu häufig für Teams auslösen, die noch ihre Zuverlässigkompetenz aufbauen.

Schritt 4: Schreiben Sie die Error-Budget-Richtlinie auf, bevor Sie sie brauchen. Bei welcher Error-Budget-Verbrauchsrate pausiert das Team nicht-kritische Änderungen? Bei welcher Verbrauchsrate eskaliert die On-Call? Dokumentieren Sie dies, bevor der Zwischenfall, nicht während.

Schritt 5: Beginnen Sie mit einem Service. SLOs für 15 Services auf einmal definieren erzeugt 15 Dashboards, das niemand liest. Beginnen Sie mit dem sichtbarsten Service für den Benutzer, führen Sie ein Quartal aus, passen Sie an, dann erweitern Sie.

Messfenster-Optionen und ihre Kompromisse:

• 7-Tage-Rollen: schnelle Rückmeldung, empfindlicher für kurze Vorfälle, kann Alert-Überflutung erzeugen

• 30-Tage-Rollen: am häufigsten, balanciert Signal und Rauschen

• 90-Tage-Rollen: nützlich für seltene, aber kritische Operationen wie Batch-Jobs

Ein durchgearbeitetes Beispiel: Für eine E-Commerce-API könnten Sie Ihr erstes SLO als "95 % der Requests an /checkout werden erfolgreich abgeschlossen und geben innerhalb von 500 ms zurück, gemessen über ein rollendes 28-Tage-Fenster" setzen. Das gibt Ihnen ein konkretes SLI (Erfolgsquote kombiniert mit Latenz), ein spezifisches Ziel (95 %), und ein definiertes Fenster (28 Tage). Von dort aus berechnen Sie das Error Budget: 5 % aller Requests dürfen fehlschlagen oder langsam sein. Wenn Sie 200.000 Requests pro Tag empfangen, ist Ihr monatliches Error Budget ungefähr 280.000 fehlgeschlagene Requests, bevor das SLO verletzt wird.

Wo SLO-Monitoring mit Codebase-Arbeit verbunden ist

Ein Error Budget, das schneller als erwartet aufgebraucht wird, ist ein Codebase-Problem öfter als ein Infrastruktur-Problem. Latenz-Spitzen gehen auf N+1-Queries zurück, die beim Code-Review nicht bemerkt wurden. Verfügbarkeit-Abfälle zurück zu einem Null-Pointer-Exception in einem Code-Pfad, der nur unter einer bestimmten Lastkombination auslöst. Das SLO entdeckt die Symptome. Die Codebase enthält die Ursache.

Hier wird die Zeit zwischen "Alert wird ausgelöst" und "Grundursache identifiziert" zur praktischen Begrenzung. Wenn der Checkout-Service 30 % seines Error Budgets in drei Tagen aufbraucht und der On-Call-Techniker eine 150.000-Zeilen-Monorepo durchsuchen muss, um die Retry-Logik zu finden, die sich unter Last unterschiedlich verhält, tut das SLO seine Aufgabe. Die Tooling für Ursachen-Analyse tut es nicht.

Teams, die KI-gestützte Code-Suche neben ihrem Observability-Stack instrumentiert haben, berichten von deutlich kürzeren Diagnosezeiten während Vorfällen. Eine natürlichsprachige Anfrage, wo der Payment-Service 503er-Antworten erneut versucht, zeigt die relevante Funktion in Sekunden statt in den 20 Minuten, die es braucht, um über fünf Dateien und eine Confluence-Seite zu lesen. Das 43-Minuten-Error-Budget-Fenster wird für das Beheben des Problems aufgewendet, nicht zum Lesen des Codes.

Vier Wege, wie Teams SLOs falsch machen

Zu viele SLOs. Ein Team, das 12 SLOs gleichzeitig verfolgt, behandelt Alerts zwei Monate später als Hintergrund-Rauschen. Drei bis fünf SLOs, die sich auf die sichtbarsten Verhaltensweisen konzentrieren, ist eine arbeitsame Obergrenze für ein Team von 10 Ingenieuren. Wenn Sie mehr brauchen, organisieren Sie sie in Ebenen: kritische SLOs, die Error-Budget-Richtlinien auslösen, und Informations-SLOs, die nur Daten erzeugen.

Infrastruktur statt Benutzererlebnis messen. CPU-Auslastung, Speichernutzung und Disk-I/O sind nützliche Debug-Signale. Sie sind schlechte SLIs, wenn Sie nicht beweisen können, dass sie direkt mit einer benutzersichtbaren Degradation korrelieren. Messen Sie, was der Benutzer erlebt: Request-Erfolgsrate, Response-Zeit bei P95 oder P99, Zeit bis zum Rendern des ersten aussagekräftigen Teils der Daten.

SLOs ohne Betriebskosten-Analyse setzen. Um 99,99 % Verfügbarkeit zu erreichen, wird normalerweise aktive Redundanz, Multi-Region-Failover und sofortige On-Call-Reaktion rund um die Uhr benötigt. Wenn das Team das nicht nachhaltig betreiben kann, wird das SLO regelmäßig verletzt und dann ignoriert. Ein verletztes und ignoriertes SLO ist schlechter als gar kein SLO: Es trainiert das Team, Zuverlässigkeits-Alerts zu ignorieren.

Error-Budget-Daten verwenden, um Schuld zuzuweisen. Wenn die erste Reaktion auf ein verbrauchtes Error Budget darin besteht, zu identifizieren, wer die Änderung geliefert hat, die es verursachte, hört die Berichterstattung auf, ehrlich zu sein. Error Budgets sind eine Team-Ressource. Wenn das Budget niedrig wird, lautet die Frage "was beheben wir?" nicht "wer ist verantwortlich?"

Der Organisationshealthcheck: Würden Sie den aktuellen Error-Budget-Status auf einer Engineering-All-Hands-Tagung teilen, ohne dass es eine politische Diskussion auslöst? Falls nicht, braucht die Kultur rund um SLOs mehr Aufmerksamkeit als die Ziele selbst. Zuverlässigkeits-Metriken funktionieren als Entscheidungs-Tools nur, wenn das Team vertraut, dass die Meldung eines Problems kein persönliches Risiko schafft.

SLOs brauchen vierteljährliche Überprüfungen, nicht jährliche

Services verändern sich, Traffic-Muster verschieben sich, und die Kosten für die Erhaltung eines bestimmten Zuverlässigkeitsgrades verändern sich damit.

Alle 90 Tage arbeiten Sie vier Fragen durch:

1. Hat das SLO Bestand? Falls ja, war es komfortabel und deutet an, dass das Ziel verschärft werden könnte?

2. Wurde das Error Budget vollständig verbraucht? Welche Vorfälle trieben das an?

3. Hat das SLO nützliches Signal geliefert oder hat das Team die Error-Budget-Richtlinie überschritten?

4. Ist das Messfenster noch für die Art, wie der Service verwendet wird, angemessen?

Wenn das Team die Error-Budget-Richtlinie in einem Quartal mehr als zweimal überschritten hat, ist das SLO wahrscheinlich falsch kalibriert. Entweder ist das Ziel zu streng, das Fenster zu kurz, oder die Messung spiegelt nicht wider, was Benutzer wirklich erleben.

SLOs sind Kalibrierungs-Tools. Sie sind dazu bestimmt, angepasst zu werden, während sich die Zuverlässigkeit verbessert, der Traffic wächst und die Business Toleranz für Ausfallzeiten sich ändert. Ein Team, das seine SLOs vierteljährlich überprüft und anpasst, führt eine Zuverlässigkeitspraxis durch. Ein Team, das sie einmal setzt und seitdem nicht angefasst hat, hat ein Dashboard mit Zahlen, die niemandem etwas bedeuten.