Jedes Latency-Budget, das ich je in einem Design-Doc aufgeschrieben habe, ist still in einer Ecke des Wikis vor sich hin gerottet. Das eine, das gehalten hat, war nicht clever — es war eine einzige p99-Zahl, angeheftet an einen einzigen Endpoint, besessen von einem einzigen Team, durchgesetzt von einem einzigen Dashboard, das niemand still löschen konnte. Dieser Post ist die Geschichte, warum dieses eine gehalten hat, als die anderen es nicht taten.

Die, die nicht gehalten haben

Jedes Team, dem ich je beigetreten bin, hatte irgendwo ein Latency-Budget. Meistens in einem Design-Doc von vor 18 Monaten, drei Besitzern ago, betitelt mit irgendwas wie Performance SLOs, v2. Es hatte typischerweise:

  • Eine Tabelle mit 40 Endpoints, jeder mit einem p50/p95/p99/p99.9-Ziel.
  • Eine “Service-Level-Objective”-Zeile pro Service.
  • Eine zusammengefasste “Product-Level-Experience”-Metrik.
  • Eine Notiz am Ende, die sagte “das sind Ziele, keine Garantien.”

Jede Zeile war vernünftig. Niemand konnte mit einer einzelnen Zahl argumentieren. Und doch war, jedes Mal wenn ich eine Query gegen die tatsächlichen Zahlen in Production ausführte, die Hälfte davon still verletzt — keine Alerts, kein Follow-up, kein Gespräch. Das Budget war dekorativ.

Der Failure-Mode ist nicht, dass die Zahlen falsch waren. Der Failure-Mode ist, dass niemand laut genug eine davon besaß. Eine Zahl, die niemandens Problem ist, ist niemandens Problem.

Die, die gehalten hat

Auf einer bestimmten Plattform — einer von diesen Event-Driven-Modernisierungen, die ich mit einem Multi-Squad-Team gemacht habe — haben wir immer wieder versucht, das Ordentliche SLO-Dokument zu schreiben. Es hat keinen Sprint überlebt. Schließlich haben wir aufgegeben und etwas gemacht, das zu klein wirkte, um zu funktionieren.

Wir haben einen Endpoint ausgewählt. Den, über den jeder eine Meinung hatte — den Join-a-Match-Flow in einem Echtzeit-Game-Backend. Wir haben eine Zahl auf das Whiteboard geschrieben: p99 < 250ms. Wir haben einen Namen daneben gestellt. Wir haben eine Dashboard-URL erstellt. Wir haben die Dashboard-URL im Slack-Kanal des Teams angeheftet und sie zum On-Call-Übergabe-Template hinzugefügt.

Das war das gesamte Budget. Eine Zahl. Ein Endpoint. Ein Besitzer. Ein Dashboard.

Es hat drei Jahre gehalten. Wir haben es verfehlt, wir haben uns erholt, wir haben es wieder verletzt, wir haben es wieder gefixt. Die Zahl hat sich bewegt (zuerst runter auf 180ms, dann zurück auf 220ms als wir ein Feature hinzugefügt haben, das den Preis wert war). Aber sie war immer auf der Agenda — weil es nur eine von ihr gab, und jeder wusste, wen er pingen sollte.

Warum die einfachere Version gewann

Vier Gründe, in der Reihenfolge, in der ich sie unterschätzt habe:

1. Kognitive Last. Vierzig Zahlen sind weniger als man für eine Maschine denkt und mehr als ein Mensch dauerhaft im Blick behalten kann. Eine Zahl klebt als Sticker auf jemandem’s Laptop. Vierzig Zahlen sind in einer Tabelle in einem Dokument in einem Ordner in einem Wiki.

2. Ownership-Klarheit. “Das Platform-Team besitzt es” ist keine Ownership. Es ist Bystander-Effekt mit einer Compliance-Schicht. “Julia besitzt p99 auf Join-a-Match” bedeutet, Julia wird gepingt. Julia fixt es entweder oder gibt es explizit weiter. Die Zahl hat ein Gesicht.

3. Alerting-Fit. Du kannst einen guten Alert für eine Zahl einrichten. Du kannst keinen guten Alert für vierzig korrelierte Zahlen einrichten — du feurst entweder zu viel oder zu wenig, und du wirst nicht wissen, welches, bis der Pager schon eine Volkssteuer ist. (Sieh meinen letzten Post darüber, warum das Folk-Taxieren eines Pagers deine Rotation tötet.)

4. Sozialer Beweis bei Verletzungen. Wenn die Zahl verletzt wird, erkennen die Leute die Zahl. “p99 auf Join-a-Match ist gerade auf 380 gesprungen” ist ein Satz, bei dem die Leute nicken. “Das Platform-Latency-SLO ist gelb in Quadrant 3 des Grafana-Dashboards” ist ein Satz, der sich versteckt. Du kannst dich nicht um einen Satz mobilisieren, der sich versteckt.

Die Frage, die unsere Meeting-Hygiene gefixt hat

Nachdem wir den Ein-Zahl-Ansatz adoptiert hatten, haben wir eine einzige wiederkehrende Frage in jedem Weekly behalten: “Ist die Zahl rot, gelb oder grün?”

  • Grün: Überspringen. Kein Status-Theater.
  • Gelb: Der Besitzer sagt einen Satz darüber, was er tut.
  • Rot: Wir lassen die Agenda fallen und machen einen Plan.

Das hat ungefähr 30 Minuten “Performance-Status-Updates” pro Woche durch einen 60-Sekunden-Check-in ersetzt. Es bedeutete auch, dass wir bemerkt haben, wenn die Dinge wirklich schlimm waren — innerhalb einer Woche statt innerhalb eines Quartals.

Was die eine Zahl nicht ist

  • Sie ist nicht das gesamte Bild. Es gibt Dutzende anderer Metriken, um die du dich noch sorgst. Sie leben in Dashboards, in Alerts, in Post-Mortems. Die eine Zahl ist die Wirbelsäule; alles andere ist Muskel.
  • Sie ist kein Ziel für jeden Endpoint. 90 % deiner Endpoints verdienen kein Budget. Ein Budget ist teuer zu pflegen — gib es den Endpoints, die wirklich für das Produkt wichtig sind, und vergiss die anderen, bis sie in deinen Error-Logs auftauchen.
  • Sie ist nicht statisch. Du wirst sie rauf- und runtersetzen. Beides ist in Ordnung. Ein Budget, das sich nie bewegt, ist eines, das niemand anschaut.

Wie man anfängt

Wenn du gerade überlegst, ein ordentliches Performance-SLO-Dokument zu schreiben: tu es nicht. Stattdessen, heute Abend, bevor du es vergisst:

  1. Wähle den einzigen, für den User sichtbarsten Endpoint in deinem Produkt.
  2. Pull seinen p99 für die letzten 30 Tage.
  3. Runde auf. Das ist deine Ausgangszahl.
  4. Schreib einen Namen daneben. Wahrscheinlich deinen.
  5. Hefte die Dashboard-URL im meist genutzten Kanal deines Teams an.
  6. Füge “Was ist die Zahl?” zu deinem Weekly hinzu.

Das ist Woche eins. Woche zwei bemerkst du entweder, dass die Zahl falsch ist, oder du bemerkst, dass sie gut ist. So oder so besitzt du sie jetzt. Das ist weiter als die meisten SLO-Dokumente je kommen.

Peacock-Moment

Ich sage die stille Wahrheit: Dieser Ansatz hat mich auch sehr schnell sehr gut aussehen lassen. “Mo hat unseren p99 um 63 % gesenkt” ist eine Headline, die mein Manager in einem Performance-Review laut sagen konnte. “Mo hat das SLO-Dokument gepflegt” ist es nicht. Wähle die quantifizierte Zahl, beanspruche die quantifizierte Verbesserung. Dein Manager kann kein Dokument befördern.