SLOs, die nicht lügen: messen, was Nutzer wirklich erleben

Die meisten Reliability-Dashboards sind grün, während die Nutzer ihren Bildschirm verfluchen. Das SLO sagt 99,95%, die CPU-Graphen sind ruhig — und der Checkout fällt seit zehn Minuten aus. Diese Lücke ist das Verräterische: das SLO misst das System, nicht die Person, die es benutzt. Ein SLO sagt nur dann die Wahrheit, wenn es misst, was der Nutzer tatsächlich spürt.

Miss, was der Nutzer spürt, nicht die Maschine

CPU, Speicher und Host-Uptime sind keine Nutzererfahrung. Eine Maschine kann bei 30% CPU stehen, während jede Anfrage in einen Timeout läuft; sie kann bei 95% laufen und alle perfekt bedienen. Der einzige Richter darüber, ob dein Service funktioniert, ist der Nutzer — der Indikator muss also von seiner Seite der Leitung kommen. Baue SLOs auf der Journey (war die Anfrage erfolgreich, war sie schnell genug, war die Antwort korrekt und aktuell), nie auf der darunterliegenden Infrastruktur.

Ein Service Level Indicator (SLI) ist eine solche Zahl: der Anteil guter Ereignisse an allen Ereignissen. Die meisten Services brauchen nur drei:

Verfügbarkeit — der Anteil gültiger Anfragen, die erfolgreich waren.
Latenz — der Anteil, der schneller bedient wird als eine Schwelle, die Nutzer bemerken, z. B. 95% unter 300 ms.
Qualität oder Aktualität — bei Daten und asynchroner Arbeit, wie korrekt oder wie aktuell das Ergebnis ist.

Zwei Gewohnheiten halten das ehrlich. Nutze Perzentile, keine Mittelwerte — ein gesunder Mittelwert verbirgt die langsame Schwanzspitze, in der echte Nutzer landen, also nenne p95/p99. Und miss so nah am Nutzer wie möglich — der Load Balancer, die Edge, Real-User-Monitoring — denn serverseitige Metriken sehen nie DNS-Fehler, CDN-Probleme oder die Anfrage, die nie ankam.

Falls Perzentile dir unklar sind: die p95-Latenz ist die Antwortzeit, unter der 95% der Anfragen liegen — also wartet 1 von 20 Nutzern länger — und p99 ist das langsamste 1%. Ein Mittelwert verschmilzt die schnelle Mehrheit und die wenigen Langsamen zu einer einzigen Zahl, die niemand tatsächlich erlebt; ein Perzentil hält diesen Schwanz im Blick.

Dieselben Anfragen, zwei Geschichten: der Mittelwert sitzt in der bequemen Mitte, während p95/p99 draußen im langen Schwanz leben — genau dort, wo ein Teil der echten Nutzer ist. Nenne die Perzentile und miss sie so nah am Nutzer wie möglich.

Mittelwerte verbergen kaputte Nutzer genauso leicht wie langsame. Eine Erfolgsrate von 99,5% liest sich wie nur eine Rundung von der Perfektion entfernt — aber über echten Verkehr ist dieser Bruchteil ein steter Strom von Leuten, die auf Fehler stoßen, meist gehäuft in einem Segment, das die globale Zahl nicht sehen kann. Sei immer in der Lage, ein SLI nach Journey, Plattform und Region aufzuschlüsseln.

0,5% Fehler klingt harmlos, bis du die Nutzer dahinter zählst — und merkst, dass die Fehler nicht gleichmäßig verteilt sind. Das SLI nach Segment aufzuschlüsseln, bringt den Teil des Produkts ans Licht, der tatsächlich brennt.

Ein SLO pro Journey — mit Eigentümer und getaggt

SLOs folgen User-Journeys, nicht deinem Organigramm und nicht einzelnen Services. Definiere eines pro Journey — Checkout, Login, Suche — und widerstehe der Versuchung, sie zu einer einzigen sitewide Zahl zusammenzurollen: ein globales SLO bleibt grün, während der Checkout kaputt ist, weil gesunde statische Assets die Fehler übertönen, die zählen. Und gib jeder Journey das Ziel, das sie verdient; ein Zahlungspfad und ein Empfehlungs-Widget brauchen nicht dieselbe Zuverlässigkeit.

Jede Journey bekommt ihr eigenes SLO und das Ziel, das sie wirklich braucht. Das Fehlerbudget ist das Guthaben des Eigentümer-Teams, und konsistente Tags (Service · Team · Journey) rollen jedes SLI zu dem hoch, der handeln kann.

Das Fehlerbudget — die Lücke zwischen deinem Ziel und 100% — wird dann zur Währung des Eigentümer-Teams. Teams sind weitgehend isoliert, und manche Oberflächen schlucken weit mehr Fehler als andere, also lass jedes Team sein eigenes Budget halten und ausgeben: es kauft Tempo, wenn Spielraum da ist, und erzwingt einen Fokus auf Zuverlässigkeit, wenn es weg ist. Nichts davon funktioniert ohne diszipliniertes Tagging — jede Metrik, Ressource und jeder Alert mit Service, Team und Journey beschriftet — damit jedes SLI zum richtigen Eigentümer hochrollt und ein brennendes Budget direkt auf das Team zeigt, das es beheben kann.

Setze ein Ziel, das du verteidigen kannst

Greife nicht reflexartig nach 99,99%. Jede zusätzliche Neun ist exponentiell teurer, und ein Ziel, das du nicht wirklich finanzierst, ist nur eine weitere Lüge auf dem Dashboard. Wähle die Zahl, die die Journey wirklich braucht — und halte dein internes SLO strenger als jedes SLA, das du unterschrieben hast, damit du es vor dem Kunden erfährst.

Ein SLO von 99,9% über 30 Tage erlaubt rund 43 Minuten 'schlecht' pro Monat. Genau darum geht es: es verwandelt 'sind wir zuverlässig genug?' von einem Streit in eine Rechenaufgabe.

Und versuche nicht, die perfekte Zahl am ersten Tag zu treffen — das kannst du nicht. Setz sie zu hoch, und du lebst dauerhaft außerhalb des Budgets; zu niedrig, und sie bedeutet nichts. Beginne damit, zu messen, wo du wirklich stehst, setze das Ziel knapp über die heutige Realität, und behandle es als beweglichen Boden: bei jeder wöchentlichen oder monatlichen Review schaut das SRE-Team, was es gehalten hat, und hebt, wenn der Service sich verbessert hat, die Latte um eine Stufe. Das SLO rastet Sprint für Sprint nach oben — jeder Schritt ein Niveau, das du wirklich gehalten hast, nicht eines, das du dir gewünscht hast.

Setze das Ziel knapp über das, wo du stehst, und hebe es dann bei jeder Review. Die Latte steigt, wie der Service steigt — Schritt für Schritt wirst du messbar besser, und jedes Ziel ist eines, das du wirklich gehalten hast.

Mach das Budget zur Entscheidungsregel

Ein Fehlerbudget verdient sich seinen Platz erst, wenn es Verhalten ändert, und die Regel muss vorab vereinbart sein. Budget übrig: liefere aus, mach die riskante Migration, fahr den Lasttest in der Produktion. Budget aufgebraucht: friere riskante Änderungen ein und steck den nächsten Sprint in Zuverlässigkeit, bis du wieder im Plus bist. Wöchentlich überprüft, verwandelt es Zuverlässigkeit von einem Gefühl in eine geteilte, verantwortete Entscheidung.

Alarmiere auf die Journey, navigiere zur Ursache

Weil das SLO die Journey misst, ist das das Einzige, wofür ein Page sich lohnt. Der Alert feuert bei einem nutzersichtbaren Budget-Verbrauch und öffnet das Journey-Dashboard — Erfolgsrate, p95, verbleibendes Budget. Von dort navigierst du nach unten: zu den Service-Dashboards der Komponenten auf dem Pfad, dann zu den abhängigen Ressourcen — Datenbank, Cache, Queue, Upstream-API. Diese Abhängigkeiten zu sehen ist für die Diagnose unbezahlbar; es ist nie ein Grund zu pagen. Konsistente Tags sind das, was diesen Drilldown möglich macht — sie lassen ein Template-Dashboard zum nächsten verlinken, statt dich mit einem Haufen unverbundener Bildschirme zurückzulassen.

Alarmiere oben auf das nutzersichtbare SLO — das Einzige, was jemanden wecken sollte. Der Alert öffnet das Journey-Dashboard, das nach unten zu den Services und dann zu den abhängigen Ressourcen verlinkt, wo du diagnostizierst.

Das SLO ist auch der Input für dein Alerting: speise die Budget-Burn-Rate in Multi-Window-Alerts, sodass ein kurzer Aussetzer eine Fußnote und ein anhaltender Verbrauch ein Page ist (ich behandle diesen Mechanismus in 'Alerts entwerfen, die niemand ignoriert'). Die Dashboard-Kette trägt dich dann in drei Klicks vom Page zur Ursache, nicht in dreißig.

Berechne es automatisch

Nichts davon sollte von Hand gepflegt werden. Berechne SLIs aus der Telemetrie, die du schon hast — Prometheus, Datadog, Load-Balancer-Logs — als Recording Rules, und zeige ein Panel pro Journey: aktuelles SLI, Ziel, verbleibendes Budget, Burn-Rate. Wenn das Erzeugen der Zahl manuell ist, verrottet sie; wenn es automatisch ist, wird sie zu dem, was alle zuerst prüfen.

Telemetrie, die du ohnehin sammelst, speist Recording Rules, die das SLI pro Fenster berechnen, dargestellt als eine Live-Kachel pro Journey — aktuelles SLI, Ziel, verbleibendes Budget, Burn-Rate.

Unter der Haube ist das SLI eine kleine Query: zähle die Anfragen, zähle die Fehler, teile. Definiere es einmal als Recording Rule, und jedes Dashboard und jeder Alert verwendet dieselbe Zahl wieder.

# A — Anfragen ueber das Fenster
- record: checkout:requests:rate5m
  expr: sum(rate(http_requests_total{job="checkout"}[5m]))

# B — Fehler (HTTP 5xx) ueber dasselbe Fenster
- record: checkout:errors:rate5m
  expr: sum(rate(http_requests_total{job="checkout", code=~"5.."}[5m]))

# C — Fehlerprozentsatz = B / A  (der "schlechte" Anteil des SLI)
- record: checkout:error_pct5m
  expr: 100 * checkout:errors:rate5m / checkout:requests:rate5m

# A = Anfragen · B = Fehler · C = 100 * B / A  (Fehler-%)
100 * (
  sum:http.requests.errors{service:checkout}.as_count()
  / sum:http.requests.hits{service:checkout}.as_count()
)

Überprüfe und entwickle weiter

SLOs sind lebende Versprechen, keine einmalige Tabelle. Überdenke die Ziele, während sich Produkt und Nutzererwartungen ändern. Ein Budget, das du nie verbrauchst, heißt, das Ziel ist zu niedrig — oder du überinvestierst in Zuverlässigkeit, die niemand verlangt hat; ein Budget, das du jeden Monat sprengst, heißt, das Ziel ist unrealistisch oder der Service braucht echte Arbeit. Das richtige SLO liegt dort, wo es gelegentlich und nützlich wehtut.

Ein SLO, das den Nutzer misst, auf eine Zahl gesetzt, die du wirklich finanzierst, im Besitz des Teams, das es bewegen kann, und an Alerts verdrahtet, die direkt zur Ursache durchsteigen — das ist ein SLO, das die Wahrheit sagt. Alles andere ist ein grünes Licht über einem brennenden Gebäude.