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

Die meisten Reliability-Dashboards sind grün, während die Nutzer auf ihren Bildschirm fluchen. 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 Zeichen: 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. Bau SLOs auf der Journey auf (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 den langsamen Rand, in dem echte Nutzer landen, also nenne p95/p99. Und miss so nah am Nutzer wie möglich - am Load Balancer, an der Edge, per Real-User-Monitoring - denn serverseitige Metriken sehen nie DNS-Fehler, CDN-Probleme oder die Anfrage, die nie ankam.

Falls Perzentile dir schwammig vorkommen: Die p95-Latenz ist die Antwortzeit, unter der 95 % der Anfragen liegen - 1 von 20 Nutzern wartet also 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 behält diesen Rand im Blick.

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

Mittelwerte verbergen Nutzer mit Fehlern genauso leicht wie langsame Nutzer. 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. Sorge immer dafür, dass du ein SLI nach Journey, Plattform und Region aufschlüsseln kannst.

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 den User Journeys, nicht deinem Organigramm und nicht einzelnen Services. Definiere eines pro Journey - Checkout, Login, Suche - und widerstehe der Versuchung, sie zu einer einzigen Zahl für die gesamte Site zusammenzufassen: Ein globales SLO bleibt grün, während der Checkout kaputt ist, weil gesunde statische Assets die Fehler übertönen, auf die es ankommt. 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 verantwortlichen 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 verantwortlichen Teams. Teams sind weitgehend voneinander unabhängig, und manche Oberflächen verkraften weit mehr Fehler als andere, also lass jedes Team sein eigenes Budget halten und ausgeben: Es erkauft Tempo, wenn Spielraum da ist, und erzwingt einen Fokus auf Zuverlässigkeit, wenn es aufgebraucht ist. Nichts davon funktioniert ohne diszipliniertes Tagging - jede Metrik, jede 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 tatsächlich 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, am ersten Tag die perfekte Zahl 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 klettert 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 an. 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: ausliefern, die riskante Migration angehen, den Lasttest in der Produktion fahren. Budget aufgebraucht: riskante Änderungen einfrieren und den nächsten Sprint in Zuverlässigkeit stecken, bis du wieder im Plus bist. Wöchentlich überprüft, verwandelt es Zuverlässigkeit von einem Gefühl in eine geteilte Entscheidung mit klarem Eigentümer.

Alarmiere auf die Journey, navigiere zur Ursache

Weil das SLO die Journey misst, ist das das Einzige, wofür sich ein Page 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; ein Grund zu pagen ist es nie. Konsistente Tags machen diesen Drilldown erst möglich - sie lassen ein Template-Dashboard auf das nächste verlinken, statt dich mit einem Haufen unverbundener Bildschirme zurückzulassen.

Page 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 (diesen Mechanismus behandle ich 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 ohnehin 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, verkommt 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 investierst zu viel 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 auf nützliche Weise 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 durchführen - das ist ein SLO, das die Wahrheit sagt. Alles andere ist ein grünes Licht über einem brennenden Gebäude.