SLOs in der Praxis: Von Error Budgets zu Release Gates

Die meisten Teams, die SLOs einführen, kommen bis zu einem Dashboard mit einer Prozentzahl. Die Zahl ist meistens grün, gelegentlich rot und ändert nichts an der Arbeitsweise des Teams. SLOs zahlen sich in der Praxis erst aus, wenn das Error Budget Entscheidungen steuert: welche Alerts jemanden wecken, wann Zuverlässigkeitsarbeit Vorrang vor Features hat und ob ein Release heute rausgeht.

Dieser Beitrag geht den ganzen Weg, von der Auswahl eines SLI bis zur Anbindung des Error Budgets an Ihre Delivery-Pipeline, mit Konfigurationsbeispielen, die Sie für Ihre Umgebung anpassen können.

Schritt 1: SLIs wählen, die das Nutzererlebnis abbilden

Ein Service Level Indicator (SLI) misst einen Aspekt der Servicequalität. Die robusteste Form ist ein Verhältnis: gute Events geteilt durch gültige Events. Diese Form funktioniert für Verfügbarkeit, Latenz und Korrektheit gleichermaßen und lässt sich direkt in ein Error Budget übersetzen.

SLI-Typ	Gutes Event	Gültiges Event
Verfügbarkeit	Request ohne Serverfehler (5xx) beantwortet	Alle Requests außer Health Checks
Latenz	Request in unter 400 ms abgeschlossen	Alle erfolgreichen Requests
Aktualität	Daten innerhalb der letzten 10 Minuten aktualisiert	Alle Lesezugriffe auf den Datensatz
Korrektheit	Ergebnis eines Jobs hat die Validierung bestanden	Alle abgeschlossenen Jobs

Messen Sie so nah am Nutzer, wie es praktikabel ist. Ein SLI am Load Balancer oder Ingress erfasst auch Fehler, die eine service-interne Metrik übersieht, etwa abgebrochene Verbindungen oder einen abgestürzten Pod. Für User Journeys wie Checkout oder Login definieren Sie das SLI am Einstiegs-Span der Journey, nicht an jedem internen Service.

Schließen Sie aus, was Nutzer nicht erleben: Health Checks, synthetische Prüfungen (sofern sie nicht selbst das SLI sind) und Requests, die wegen Client-Fehlern abgelehnt wurden. Ein 4xx aufgrund einer ungültigen Anfrage ist kein Zuverlässigkeitsproblem. Ein 429 durch Ihr eigenes Rate Limiting kann dagegen durchaus eines sein.

Schritt 2: Ziele und Zeitfenster bewusst festlegen

Das Ziel definiert, wie viel Unzuverlässigkeit Sie akzeptieren. Es sollte sich daran orientieren, was Nutzer tolerieren und was der Service historisch erreicht hat, nicht an runden Zahlen. Starten Sie leicht unterhalb der aktuellen Leistung, damit das SLO erreichbar ist, und verschärfen Sie es, sobald Sie die Dynamik des Budgets verstehen.

Verwenden Sie ein rollierendes Zeitfenster, typischerweise 28 oder 30 Tage. Kalendermonate setzen das Budget am Monatsersten zurück und verleiten dazu, gegen Monatsende riskante Releases mit dem übrigen Budget auszuliefern.

Das Error Budget ist schlicht eins minus Ziel. Ein Verfügbarkeits-SLO von 99,9 % über 30 Tage erlaubt, dass 0,1 % der Requests fehlschlagen. Bei einem Service mit 10 Millionen Requests in diesem Zeitraum sind das 10.000 fehlgeschlagene Requests. In Zeit ausgedrückt entsprechen 0,1 % von 30 Tagen 43,2 Minuten vollständigem Ausfall. Mit 99,95 % halbieren sich beide Werte. Jede zusätzliche Neun sollte deshalb eine bewusste Investition sein.

SLOs als Code bleiben reviewbar und portabel. Die OpenSLO-Spezifikation ist dafür ein herstellerneutrales Format:

apiVersion: openslo/v1
kind: SLO
metadata:
  name: checkout-availability
  displayName: Checkout availability
spec:
  service: checkout
  budgetingMethod: Occurrences
  timeWindow:
    - duration: 30d
      isRolling: true
  objectives:
    - displayName: 99.9% of checkout requests succeed
      target: 0.999
  indicator:
    metadata:
      name: checkout-good-requests
    spec:
      ratioMetric:
        counter: true
        good:
          metricSource:
            type: Obseria
            spec:
              query: 'fetch spans | filter service.name == "checkout" and span.kind == "server" and http.status_code < 500 | summarize count()'
        total:
          metricSource:
            type: Obseria
            spec:
              query: 'fetch spans | filter service.name == "checkout" and span.kind == "server" | summarize count()'

Schritt 3: Das Error Budget laufend messen

Der aktuelle Zustand eines SLO lässt sich auf zwei Zahlen reduzieren: das SLI über das Zeitfenster und den Anteil des verbleibenden Budgets. In OQL lassen sich beide direkt aus Spans berechnen:

fetch spans, from: now() - 30d
| filter service.name == "checkout" and span.kind == "server"
| summarize total = count(), bad = count_if(http.status_code >= 500)
| fields_add sli = 1 - bad / total,
             budget_remaining = 1 - (bad / total) / 0.001

Ein budget_remaining von 0,4 bedeutet, dass 60 % der erlaubten Fehler verbraucht und 40 % übrig sind. Negative Werte bedeuten, dass das SLO im aktuellen Zeitfenster verletzt ist. Diese Zahl pro Service auf einem Team-Dashboard ist weit handlungsrelevanter als eine rohe Fehlerrate, weil sie bereits enthält, wie viel Fehler akzeptabel sind.

Schritt 4: Auf Burn Rate alarmieren statt auf Schwellwerte

Die Burn Rate gibt an, wie schnell das Budget relativ zum SLO-Zeitfenster verbraucht wird. Eine Burn Rate von 1 verbraucht genau das gesamte Budget in 30 Tagen. Eine Burn Rate von 14,4, die eine Stunde lang anhält, verbraucht 2 % eines 30-Tage-Budgets, denn 14,4 mal eine Stunde geteilt durch 720 Stunden ergibt 0,02.

Burn-Rate-Alerts mit mehreren Fenstern kombinieren ein langes Fenster, das belegt, dass das Problem relevant ist, mit einem kurzen Fenster, das belegt, dass es noch andauert. Ein verbreitetes Set für ein 30-Tage-SLO:

Schweregrad	Burn Rate	Langes Fenster	Kurzes Fenster	Verbrauchtes Budget
Page	14,4	1 Stunde	5 Minuten	2 %
Page	6	6 Stunden	30 Minuten	5 %
Ticket	1	3 Tage	6 Stunden	10 %

Bei einem SLO von 99,9 % entspricht eine Burn Rate von 14,4 einer Fehlerrate von 1,44 %. Der Alert feuert nur, wenn sowohl die Fehlerrate über eine Stunde als auch die über fünf Minuten diesen Wert überschreitet. Er schlägt bei echten Incidents also schnell an und löst sich zügig auf, sobald das Problem behoben ist. Dieses Set ersetzt die meisten statischen Fehlerraten-Alerts und reduziert Pages, für die kein Mensch nötig ist, erheblich.

Schritt 5: Das Error Budget zum Release Gate machen

An dieser Stelle beginnen SLOs, das Verhalten zu verändern. Ein Release Gate prüft das Error Budget, bevor ein Deployment fortgesetzt wird, und wendet eine Richtlinie an, auf die sich das Team vorab geeinigt hat:

• Mehr als 25 % Budget übrig: automatisch deployen.
• Zwischen 0 % und 25 % übrig: nur mit Freigabe durch den Service Owner deployen und Änderungen bevorzugen, die die Zuverlässigkeit verbessern.
• Budget aufgebraucht: Feature-Releases einfrieren. Bis sich das Budget erholt hat, gehen nur Fixes, Rollbacks und Zuverlässigkeitsarbeit raus.

Das Gate gehört in die Delivery-Pipeline, nicht in ein Meeting. Als Workflow in Code kann es so aussehen:

name: release-gate-checkout
trigger:
  type: deployment.requested
  filter: service == "checkout"
steps:
  - id: budget
    action: slo.evaluate
    with:
      slo: checkout-availability
  - id: decide
    action: policy.decide
    with:
      rules:
        - when: steps.budget.budget_remaining > 0.25
          result: approve
        - when: steps.budget.budget_remaining > 0
          result: require_approval
          approvers: [team:checkout-owners]
        - otherwise: reject
          message: "Error budget exhausted: only fixes and rollbacks"

Ergänzen Sie eine zweite Prüfung nach dem Deployment: Vergleichen Sie die Burn Rate in den 15 Minuten nach dem Rollout mit den 15 Minuten davor. Verbraucht die neue Version das Budget deutlich schneller, wird automatisch zurückgerollt. Zusammen fangen das Gate vor dem Deployment und die Prüfung danach beide Fälle ab: „Wir sollten gerade nicht ausliefern“ und „Dieses Release hat die Lage verschlechtert“.

Eine Error-Budget-Policy vereinbaren

Automatisierung setzt eine Richtlinie durch, sie ersetzt sie nicht. Halten Sie schriftlich fest, was bei welchem Budgetstand passiert, und lassen Sie es von Produkt- und Engineering-Leitung bestätigen. Gute Richtlinien sind kurz und konkret:

1. Wer das SLO verantwortet und überprüft, und wie oft (monatlich ist ein guter Standard).
2. Was passiert, wenn das Budget aufgebraucht ist, einschließlich der Frage, wer Ausnahmen genehmigen darf.
3. Wie Incidents durch Abhängigkeiten behandelt werden: Sie zählen gegen das Budget, erzeugen aber eine Folgeaufgabe für den Owner der Abhängigkeit.
4. Wann Ziele neu bewertet werden, etwa wenn sich Nutzererwartungen oder die Architektur ändern.

Betrachten Sie SLOs, die nie in Gefahr sind, genauso kritisch wie solche, die dauerhaft rot sind. Ein Ziel, das nie bedroht ist, ist womöglich zu locker, um Entscheidungen zu leiten. Eines, das ständig verletzt wird, nimmt niemand mehr ernst.

SLOs mit Obseria

SLOs sind in jedem Obseria-Tarif enthalten. Sie definieren sie auf jedem Signal, ob Spans, Logs, Metriken oder synthetische Checks, mit OQL als SLI-Abfrage. Burn-Rate-Alerts folgen dem oben beschriebenen Modell mit mehreren Zeitfenstern, und Obseria Automation führt Release Gates als Workflows in Code aus, ausgelöst durch Deployment-Events aus Ihrem CI/CD-System. Verbraucht ein Service Budget, startet Obseria Intelligence eine Ursachenanalyse entlang des TopoGraph und verknüpft das betroffene SLO mit der Änderung, die den Verbrauch ausgelöst hat.

Beginnen Sie mit einer User Journey, einem SLI und einem Burn-Rate-Alert. Sobald das Team dieser Zahl vertraut, ist das Release Gate nur noch ein kleiner Schritt, und genau dieser Schritt macht aus SLOs statt eines Reports ein Werkzeug für Entscheidungen.