Runbooks schreiben, die um drei Uhr morgens funktionieren

Ziel

Einer Person im Bereitschaftsdienst, die den Dienst nicht kennt, ermöglichen, ihn wiederherzustellen oder sicher zu eskalieren, ohne dessen Quellcode zu lesen.

Voraussetzungen

Alerts, die den Runbook-Abschnitt nennen, auf den sie sich beziehen, sowie einen Ort für das Runbook, der auch dann erreichbar ist, wenn der Dienst ausgefallen ist (nicht innerhalb des Dienstes selbst).

Schritte

1. Überblick: Was der Dienst tut, wer von ihm abhängt, sowie die eine Seite mit seinen Dashboards, Logs und der Deployment-Historie.
2. Gesundheit: Wie sich in einer Minute entscheiden lässt, ob der Dienst läuft (aufzurufende URL, erwartete Antwort, zu betrachtende Metrik).
3. Fehlermodi: ein Abschnitt pro bekanntem Modus mit Symptom, wahrscheinlicher Ursache, Diagnosebefehlen (kopierbar, mit markierten Platzhaltern), Entschärfung und dem Punkt, an dem eskaliert werden soll.
4. Sichere Massnahmen: Neustart, Rollback auf die Fallback-Version, ein Feature-Toggle deaktivieren, hochskalieren, jeweils mit angegebenen Nebenwirkungen.
5. Gefährliche Massnahmen: Was nicht ohne eine zweite Person getan werden sollte (Schemaänderungen, Datenlöschung, Rotation von Zugangsdaten).
6. Eskalation: Wer in welcher Reihenfolge zu kontaktieren ist und was dieser Person mitzuteilen ist.
7. Das Runbook testen, indem eine Kollegin oder ein Kollege es an einem Game Day befolgt; jeden Schritt korrigieren, an dem sie oder er gestolpert ist; es von jedem Alert aus verlinken.

Erwartetes Ergebnis

Vorfälle werden von der Person im Bereitschaftsdienst behandelt, statt den Autor zu wecken; Postmortems führen zu Runbook-Aktualisierungen.

Grenzen und Prüfbasis

Runbooks beschreiben bekannte Fehler; neuartige erfordern weiterhin Verständnis. Ungetestete Runbooks sind schlimmer als keine, weil sie falsches Vertrauen erzeugen. Es wird keine Messung behauptet.