Das On-Call-Runbook: Engineering-Praktiken, die Incidents überstehbar machen
Die meisten On-Call-Rotationen scheitern leise, monatelang, bevor sie laut scheitern. Jemand wird um 3 Uhr nachts wegen eines Alerts ohne Kontext gepiept, verbringt vierzig Minuten damit herauszufinden, was der Alert überhaupt bedeutet, und behebt das Problem am Ende eher durch Glück als durch Prozess. Niemand schreibt auf, was passiert ist. Die nächste Person im Dienst trifft drei Wochen später auf denselben Alert und fängt wieder bei null an. Ein funktionierendes On-Call-Runbook ist das, was diesen Kreislauf durchbricht, und für ein Team von drei bis fünfzehn Engineers muss es dafür nicht kompliziert sein.
Dieser Beitrag behandelt, was eine On-Call-Rotation tatsächlich überstehbar macht: das Runbook-Format, das Engineers auch halb im Schlaf nutzen können, Alert-Design, das auf echten Nutzer-Impact statt auf Infrastruktur-Rauschen reagiert, eine Eskalationspolitik, die nicht vom Gedächtnis einer einzelnen Person abhängt, ein Review-Prozess, der das System verbessert ohne die Schuld bei der Person zu suchen, die den Pager hatte, und eine Vergütung, die die Rotation nachhaltig hält statt Leute still auszubrennen.
Warum die meiste On-Call-Dokumentation nicht genutzt wird
Teams neigen dazu, On-Call-Dokumentation einmal zu schreiben, während einer ruhigen Phase, und sie danach nie wieder anzufassen. Das Ergebnis liest sich wie eine Wiki-Seite, geschrieben für jemanden mit unbegrenzter Zeit: vollständige Architekturdiagramme, historischer Kontext, Links zu fünf weiteren Dokumenten. Nichts davon hilft einer Person, die um 3 Uhr nachts wach ist und wissen muss, ob es sicher ist, einen Service neu zu starten.
Ein Runbook verdient seinen Namen nur, wenn es den Kontakt mit einem müden Engineer unter Druck übersteht. Das bedeutet, es muss eine Frage schnell beantworten: Was mache ich jetzt gerade. Alles andere, das Warum und der Hintergrund, gehört woanders hin, nicht auf die Seite, die jemand während eines Alerts öffnet.
Was ein Runbook braucht, um um 3 Uhr nachts wirklich zu funktionieren
Ein nützlicher Runbook-Eintrag ist kurz, spezifisch für einen Alert oder einen Fehlermodus, und als Abfolge von Schritten geschrieben statt als Beschreibung des Systems. Er sagt, was der Alert in einfacher Sprache bedeutet, was zuerst zu prüfen ist, die genauen Befehle oder Dashboard-Links dafür, wie eine sichere Sofortmaßnahme aussieht, und wann man aufhören sollte, es allein zu versuchen, und eskalieren muss.
Halte jeden Eintrag auf einer Seite oder weniger. Wenn ein Runbook-Eintrag ein Inhaltsverzeichnis braucht, hat er aufgehört, ein Runbook zu sein, und ist zu einem Handbuch geworden. Speichere Einträge direkt beim Service, den sie betreffen, damit sie unter Druck leicht zu finden sind, und versioniere sie genauso wie Code, damit ein veraltetes Runbook niemanden auf eine Konfigurationsdatei verweist, die vor sechs Monaten verschoben wurde.
Ein nützlicher Test: Gib den Runbook-Eintrag einem Engineer, der den Service noch nie angefasst hat, und schau, ob er ihm folgen kann, ohne eine Frage zu stellen. Wenn nicht, braucht der Eintrag noch eine Runde. Genau hier zahlt sich ein Code-Quality-Review gleich doppelt aus: derselbe Durchgang, der unklare Fehlerbehandlung im Code aufdeckt, bringt meist auch die Stellen ans Licht, an denen niemand erklären konnte, was ein Ausfall für einen On-Call-Engineer tatsächlich bedeutet.
Alert-Design: Alarmieren bei dem, was der Nutzer spürt
Die größte einzelne Quelle für Alert-Müdigkeit ist, auf Infrastruktur-Metriken statt auf nutzersichtbare Symptome zu alarmieren. CPU bei 85 Prozent kann völlig in Ordnung sein. Eine zehn Minuten lang steigende Queue-Tiefe kann nichts bedeuten. Keines von beidem sollte allein jemanden aufwecken.
Alarmiere bei den Dingen, die ein Nutzer tatsächlich bemerken würde: Fehlerraten über einem Schwellenwert auf einem echten Endpunkt, Request-Latenz, die eine Grenze überschritten hat, ab der Leute die Seite verlassen, ein Hintergrundjob, der komplett aufgehört hat zu verarbeiten, statt nur langsamer zu sein. Infrastruktur-Metriken zählen weiterhin, aber sie gehören auf Dashboards für die Untersuchung tagsüber, nicht in die On-Call-Rotation.
Eine gute Gewohnheit ist, für jeden Alert in der Rotation zu fragen: "Wenn ich das dreißig Minuten ignoriere, würde ein Kunde es merken?" Wenn die ehrliche Antwort Nein lautet, gehört dieser Alert nicht in die On-Call-Rotation. Er gehört stattdessen in eine Ticket-Queue oder ein tägliches Digest. Teams, die diesen Filter konsequent anwenden, senken ihr Alert-Volumen meist innerhalb eines Monats um die Hälfte oder mehr, was oft die größte einzelne Verbesserung für die Nachhaltigkeit der Rotation ist, die ihnen zur Verfügung steht.
Eskalationspolitik, die nicht das ganze System in einen Kopf packt
Ein häufiger Fehlermodus in kleinen Teams ist eine informelle Eskalationspolitik, die darauf hinausläuft, "die Person anzurufen, die es gebaut hat". Das funktioniert, bis diese Person im Flugzeug sitzt, im Urlaub ist oder das Unternehmen verlassen hat, und dann wird das System über Nacht unwartbar.
Eine funktionierende Eskalationspolitik hat mindestens zwei benannte Stufen: einen primären On-Call-Engineer und einen sekundären, der automatisch alarmiert wird, wenn der primäre nicht innerhalb eines festgelegten Zeitfensters reagiert, typischerweise fünf bis zehn Minuten. Für Teams über etwa acht Engineers lohnt sich eine dritte Stufe, die einen Engineering-Lead oder Manager für Incidents benennt, die Service-Grenzen überschreiten. Die Policy sollte im Paging-Tool selbst konfiguriert sein, in PagerDuty oder OpsGenie, statt nur im Gedächtnis einer Person oder einem Slack-Pin zu leben, den während eines echten Incidents niemand liest.
Auch die Rotationslänge spielt eine Rolle. Eine einwöchige primäre Rotation mit einer gleich langen sekundären Rotation, versetzt, sodass dieselbe Person nie gleichzeitig primär und sekundär ist, ist für kleine Teams ein vernünftiger Standard. Kürzere Rotationen reduzieren die Belastung pro Person, erhöhen aber das Umschalten zwischen Kontexten; längere Rotationen bewirken das Gegenteil. Es gibt keine universell richtige Antwort, nur einen Trade-off, den man offen im Team besprechen sollte statt einfach hineinzurutschen.
Blamefreie Reviews, die das System tatsächlich verändern
Der Sinn eines Incident-Reviews ist herauszufinden, was das System, nicht die Person, anders hätte machen können. Ein Review, das seine Zeit damit verbringt festzustellen, wer den Fehler gemacht hat, bringt Engineers bei, Probleme zu verstecken statt sie sichtbar zu machen, was spätere Incidents garantiert schlimmer macht.
Ein nützliches Review deckt eine schlichte Timeline dessen ab, was passiert ist, was der reagierende Engineer zu jedem Zeitpunkt wusste und wann er es wusste, was die Diagnose langsamer gemacht hat als nötig, und welche konkrete Runbook- oder Alerting-Änderung den Incident verkürzt hätte. Genau der letzte Teil wird von Teams am häufigsten übersprungen. Ein Review, das mit "wir werden nächstes Mal vorsichtiger sein" endet, hat eigentlich nichts überprüft. Ein Review, das mit einem konkreten Pull Request endet, der einen Runbook-Eintrag aktualisiert oder einen Alert-Schwellenwert verschärft, hat es.
Halte das Review kurz. Dreißig Minuten reichen meist für alles, was kein mehrtägiger Ausfall ist. Schreib die Zusammenfassung irgendwo auf, wo der nächste On-Call-Engineer sie tatsächlich sieht, idealerweise direkt vom Runbook-Eintrag des ausgelösten Alerts verlinkt.
On-Call nachhaltig machen, ohne Leute auszubrennen
Die Nachhaltigkeit der Rotation ist teils eine Vergütungsfrage und teils eine Umfangsfrage. Auf der Vergütungsseite ist es bei Unternehmen üblich, die erfahrene Engineers über Jahre in der Rotation halten statt sie nach sechs Monaten aussteigen zu sehen, eine separate Pauschale für die Zeit im Bereitschaftsdienst zu zahlen, getrennt von der Bezahlung für die tatsächliche Reaktion auf einen Incident. Die genaue Höhe variiert je nach Markt und Unternehmensgröße, aber das Prinzip gilt unabhängig vom Budget: Zeit mit dem Pager ist etwas wert, auch in einer ruhigen Woche.
Auf der Umfangsseite ist der größte Hebel das oben schon behandelte Alert-Volumen. Eine Rotation, die dreimal im Monat alarmiert, ist bei fast jedem Vergütungsniveau nachhaltig. Eine Rotation, die dreimal in der Woche alarmiert, brennt Leute aus, egal was sie dafür bezahlt bekommen. Wenn ein Review der Technologiestrategie auf Service- oder Team-Ebene immer wieder dieselbe Klasse von Incident zutage fördert, ist das meist ein Zeichen, dass die zugrunde liegende Architektur geändert werden muss, nicht der On-Call-Prozess.
Eine minimale Runbook-Vorlage zum sofortigen Start
Ein funktionaler Runbook-Eintrag für einen einzelnen Alert braucht sechs Dinge: den Alert-Namen und was er in einfacher Sprache bedeutet, die ersten drei Dinge, die zu prüfen sind, die Dashboard- oder Log-Abfrage dafür, einen sicheren ersten Mitigationsschritt, die Bedingung, unter der eskaliert werden soll statt allein weiterzumachen, und einen Link zum letzten Incident-Review, bei dem dieser Alert ausgelöst hat, falls es einen gibt. Teams, die gerade erst mit diesem Prozess anfangen, müssen nicht am ersten Tag Runbooks für jeden Alert schreiben. Fange mit den fünf Alerts an, die im letzten Quartal am häufigsten ausgelöst haben. Diese fünf Einträge decken die Mehrheit der echten Pages ab, und das Format verbessert sich mit jedem Incident, der es auf die Probe stellt.
Diesen Prozess von Grund auf neben einem größeren System aufzubauen, oder eine Codebase zu übernehmen, in der niemand irgendetwas davon aufgeschrieben hat, ist genau die Art von Lücke, die ein fokussiertes Engagement in Custom Software Development schnell schließen kann, indem die Runbook-Arbeit mit den Alerting- und Observability-Änderungen kombiniert wird, die Runbooks erst wertvoll machen.
Wenn dein Team Engineers alarmiert, ohne dass ein klares Runbook hinter dem Alert steht, oder deine Eskalationspolitik immer noch davon abhängt zu wissen, wen man persönlich anrufen muss, melde dich unter hello@wolf-tech.io. Wolf-Tech hilft kleinen Engineering-Teams dabei, On-Call-Prozesse aufzubauen, die um 3 Uhr nachts standhalten, nicht nur auf dem Whiteboard. Mehr unter wolf-tech.io.