Ein SLO (Service Level Objective) ist ein Zielwert dafür, wie zuverlässig ein Service sein soll, gemessen über einen Service Level Indicator (SLI) in einem Zeitfenster, zum Beispiel: 99,9 % der Checkout-Requests sind innerhalb von 300 ms erfolgreich, gemessen über 30 Tage. Die Differenz zu 100 % ist das Error Budget.
Das Wichtigste in Kürze
- Ein SLI ist eine Messgröße (gute Events geteilt durch gültige Events), ein SLO das Ziel dafür über ein Zeitfenster, ein SLA ein Vertrag mit Konsequenzen.
- Das Error Budget beträgt 1 minus SLO. Bei 99,9 % über 30 Tage sind das 43,2 Minuten Totalausfall oder 0,1 % der Requests.
- Alarmieren Sie auf die Burn Rate des Error Budgets mit mehreren Zeitfenstern statt auf starre Schwellwerte. Das reduziert Rauschen und erkennt schnelle wie langsame Verschlechterungen.
- Gute SLOs sind wenige, nutzerzentriert, einem Team zugeordnet und an eine Error-Budget-Policy gekoppelt.
Was ist ein SLO?
Ein Service Level Objective (SLO) ist ein explizites, messbares Zuverlässigkeitsziel für einen Service. Es besteht aus drei Bausteinen: einem Service Level Indicator (SLI), der einen Aspekt der Nutzererfahrung misst, einem Zielwert wie 99,9 % und einem Zeitfenster wie den letzten 30 Tagen. Ein vollständiges SLO lässt sich als Satz formulieren: „99,9 % der HTTP-Requests an die Checkout-API werden erfolgreich in unter 300 ms beantwortet, gemessen über ein rollierendes 28-Tage-Fenster.“
Bekannt wurde das Konzept durch das Site-Reliability-Engineering-Buch von Google. Dort ist ein SLI als sorgfältig definierte quantitative Messung eines Aspekts des Service-Levels beschrieben und ein SLO als Zielwert oder Zielbereich für diesen per SLI gemessenen Service-Level. Ein SLO beschreibt also nicht Perfektion. Es legt fest, wie viel Unzuverlässigkeit Nutzer tolerieren, damit Teams bewusst zwischen Feature-Entwicklung und Stabilität abwägen können.
SLI, SLO und SLA im Vergleich
Die drei Begriffe werden oft verwechselt. Sie hängen zusammen, richten sich aber an unterschiedliche Zielgruppen.
| Begriff | Bedeutung | Beispiel | Zielgruppe |
|---|---|---|---|
| SLI (Indicator) | Eine Messgröße, meist ein Verhältnis guter zu gültigen Events | Anteil der Requests mit Status unter 500 und Latenz unter 300 ms | Engineers, SREs |
| SLO (Objective) | Internes Ziel für den SLI über ein Zeitfenster | SLI von mindestens 99,9 % über 30 Tage | Engineering- und Produktteams |
| SLA (Agreement) | Vertrag mit Kunden, mit Vertragsstrafen bei Verfehlung | 99,5 % Verfügbarkeit pro Monat, sonst Gutschriften | Kunden, Rechtsabteilung, Vertrieb |
Faustregel: Das SLO sollte strenger sein als das SLA. Wenn Ihr SLA 99,5 % zusagt, warnt ein internes SLO von 99,9 % Sie früh genug, bevor vertragliche Konsequenzen drohen.
Gute SLIs auswählen
Die nützlichsten SLIs sind Verhältniswerte: SLI = gute Events / gültige Events × 100 %. Diese Form passt auf fast jeden Service und macht das Error Budget leicht verständlich. Typische SLI-Arten je Service-Kategorie:
- Request-basierte Services (APIs, Web-Frontends): Verfügbarkeit (Anteil fehlerfreier Antworten) und Latenz (Anteil der Requests unter einem Schwellwert).
- Datenpipelines und Batch-Jobs: Aktualität (Anteil der Daten, die innerhalb von N Minuten aktualisiert werden), Korrektheit und Abdeckung.
- Storage-Systeme: Dauerhaftigkeit sowie Lese- und Schreiblatenz.
- User Journeys: Abschlussrate eines mehrstufigen Ablaufs wie Login oder Checkout, gemessen per Real User Monitoring oder synthetischen Checks.
Messen Sie so nah am Nutzer wie praktikabel. Ein Load Balancer sieht abgebrochene Verbindungen, die die Anwendung nie loggt, und Real User Monitoring sieht clientseitige Fehler, die kein Server bemerkt. Setzen Sie bei der Latenz auf perzentilbasierte Schwellwerte („99 % der Requests unter 300 ms“) statt auf Durchschnittswerte, denn Mittelwerte verstecken genau den Long Tail, den Nutzer spüren. Legen Sie klar fest, was ein gültiges Event ist: Health Checks, synthetische Probes und durch Clientfehler verursachte 4xx-Antworten werden meist ausgeschlossen.
Error Budget berechnen
Das Error Budget ist die Menge an Unzuverlässigkeit, die ein SLO erlaubt: Error Budget = 1 − SLO. Bei einem SLO von 99,9 % beträgt es 0,1 %. Es lässt sich auf zwei Arten ausdrücken.
Zeitbasiertes Error Budget
Multiplizieren Sie das Zeitfenster mit dem Error Budget. 30 Tage haben 43.200 Minuten:
| SLO | Error Budget | Erlaubte Ausfallzeit pro 30 Tage | Pro Jahr |
|---|---|---|---|
| 99 % | 1 % | 7 h 12 min | 3,65 Tage |
| 99,5 % | 0,5 % | 3 h 36 min | 1,83 Tage |
| 99,9 % | 0,1 % | 43,2 min | 8,76 h |
| 99,95 % | 0,05 % | 21,6 min | 4,38 h |
| 99,99 % | 0,01 % | 4,32 min | 52,6 min |
Request-basiertes Error Budget
Für request-basierte Services ist ein eventbasiertes Budget genauer. Verarbeitet die Checkout-API 20 Millionen Requests in 30 Tagen bei einem SLO von 99,9 %, beträgt das Budget 20.000.000 × 0,001 = 20.000 fehlerhafte oder zu langsame Requests. Sind an Tag 10 bereits 8.000 davon verbraucht, haben Sie 40 % des Budgets in einem Drittel des Fensters aufgebraucht, also etwas schneller als linear.
Jede zusätzliche „Neun“ verkleinert das Budget um den Faktor zehn und erhöht Kosten und Aufwand meist deutlich. Bedenken Sie außerdem, dass sich Zuverlässigkeit multipliziert: Ein Service, der synchron von drei Komponenten mit je 99,9 % abhängt, kommt ohne Redundanz oder Graceful Degradation auf höchstens etwa 99,7 %.
Alerting auf die Burn Rate
Die Burn Rate beschreibt, wie schnell Sie das Error Budget relativ zum Zeitfenster verbrauchen: Burn Rate = beobachtete Fehlerrate / (1 − SLO). Bei einer Burn Rate von 1 ist das Budget genau am Ende des Fensters aufgebraucht. Eine Burn Rate von 14,4 bei einem 30-Tage-SLO von 99,9 % entspricht einer Fehlerrate von 1,44 % und würde das komplette Monatsbudget in etwa 50 Stunden aufzehren.
Das Google SRE Workbook empfiehlt Multi-Window-Multi-Burn-Rate-Alerts statt statischer Schwellwerte:
- Page, wenn 2 % des Budgets in 1 Stunde verbraucht sind (Burn Rate 14,4), bestätigt durch ein kurzes 5-Minuten-Fenster.
- Page, wenn 5 % des Budgets in 6 Stunden verbraucht sind (Burn Rate 6), bestätigt durch ein 30-Minuten-Fenster.
- Ticket, wenn 10 % des Budgets in 3 Tagen verbraucht sind (Burn Rate 1), bestätigt durch ein 6-Stunden-Fenster.
Das lange Fenster stellt sicher, dass das Problem relevant ist, das kurze, dass es noch andauert. So wird der Alarm nach der Behebung schnell zurückgesetzt. Kurze Ausreißer wecken niemanden, anhaltende Verschlechterungen dagegen zuverlässig.
Error-Budget-Policy und Governance
Ein SLO ohne Konsequenzen ist nur ein Dashboard. Eine Error-Budget-Policy ist eine schriftliche Vereinbarung zwischen Engineering, Produkt und Betrieb darüber, was bei welchem Budgetstand passiert. Ein typisches Beispiel:
- Budget gesund: Features in normalem Tempo ausliefern, Chaos-Experimente und riskante Migrationen durchführen.
- Budget unter 25 %: zusätzliche Reviews für riskante Änderungen, bekannte Zuverlässigkeitsprobleme priorisieren.
- Budget aufgebraucht: nicht kritische Releases einfrieren, bis sich der SLI erholt, und Kapazität für Postmortem-Maßnahmen reservieren.
Die Policy macht aus Diskussionen über Zuverlässigkeit datenbasierte Entscheidungen. Sie schützt Teams auch vor Überinvestition: Bleibt am Ende jedes Fensters der Großteil des Budgets übrig, ist das SLO vielleicht zu locker oder Sie können schneller ausliefern.
Beispiel: eine vollständige SLO-Spezifikation
Wenn Sie SLOs strukturiert und versioniert ablegen, lassen sie sich wie Code reviewen. Eine minimale Spezifikation für einen Checkout-Service könnte so aussehen:
service: checkout
owner: team-payments
slo:
name: checkout-availability-latency
sli:
good: spans where status != error and duration < 300ms
valid: spans where http.route == "/api/checkout" and not synthetic
objective: 99.9
window: 30d rolling
alerting:
page: burn_rate >= 14.4 over 1h and 5m
page: burn_rate >= 6 over 6h and 30m
ticket: burn_rate >= 1 over 3d and 6hHier sind Latenz und Verfügbarkeit in einem einzigen SLI kombiniert: Ein Request, der nach vier Sekunden erfolgreich zurückkommt, ist aus Nutzersicht nicht „gut“. Manche Teams bevorzugen getrennte SLOs, häufig mit zwei Latenz-Schwellwerten (etwa 90 % unter 100 ms und 99 % unter 500 ms), um sowohl die typische Erfahrung als auch den Long Tail abzubilden. Wichtig ist in beiden Fällen, dass die Definition von „gut“ und „gültig“ eindeutig dokumentiert ist und von allen Beteiligten gleich verstanden wird.
Best Practices und typische Fehler
- Mit wenigen SLOs starten. Zwei bis vier pro kritischer User Journey genügen. Dutzende SLOs verwässern die Aufmerksamkeit.
- Zielwerte aus Historie und Nutzererwartung ableiten. Analysieren Sie die SLI-Daten der letzten 90 Tage und wählen Sie einen Wert, dessen Unterschreitung Nutzer tatsächlich bemerken würden.
- Nicht 100 % anstreben. Nutzer merken keinen Unterschied zwischen 99,999 % und 100 %, weil ihr eigenes Netz und ihre Geräte weniger zuverlässig sind. Die Kosten dagegen explodieren.
- Keine Durchschnittswerte oder Ressourcenmetriken als SLI. 90 % CPU ist kein Nutzerproblem, fehlgeschlagene Bestellungen schon.
- Rollierende Fenster für das operative Alerting, Kalenderfenster für das Reporting an Stakeholder.
- Jedem SLO einen Owner zuweisen und die Zielwerte quartalsweise überprüfen, wenn sich Traffic, Architektur und Erwartungen ändern.
- Geplante Wartung sorgfältig behandeln oder besser so gestalten, dass sie gar kein Budget verbraucht.
Wie Obseria bei SLOs unterstützt
SLOs sind in jedem Obseria-Tarif enthalten. Sie definieren SLIs auf jedem Signal, das Obseria erfasst, also OpenTelemetry-Spans, Metriken, Logs, Real-User-Monitoring-Events und Ergebnisse synthetischer Checks, entweder in der Oberfläche oder per OQL-Query wie fetch spans | filter service == "checkout" | summarize good = countIf(status != "error" and duration < 300ms), total = count(). Obseria verfolgt den Verbrauch des Error Budgets, wertet Multi-Window-Burn-Rate-Alerts aus und verknüpft jeden Budgetverbrauch mit den Traces, Deployments und Topologie-Änderungen, die ihn verursacht haben. So kann Obseria Intelligence eine Root-Cause-Analyse mit nachvollziehbarer Beweiskette starten, sobald das Budget in Gefahr ist.