Wie man ein Incident-Response-Runbook schreibt (mit Vorlagen)

Die meisten Incident-Runbooks fallen in zwei Fehlermodi. Sie sind zu lang (ein dreißigseitiges Wiki, das kein On-Call-Ingenieur um 3 Uhr morgens lesen wird), oder sie sind zu vage (ein Einzeiler wie « den Logs prüfen »). Die Runbooks, die während Incidents tatsächlich verwendet werden, folgen einer strikten Struktur mit konkreten Befehlen und klaren Entscheidungspunkten. Dieser Leitfaden behandelt die Struktur, die funktioniert, mit drei Vorlagen, die Sie für Ihre häufigsten Incident-Typen kopieren können.

Was ein Runbook ist und was nicht

Ein Runbook ist eine Checkliste für einen bekannten Incident-Typ. Es ist keine Wiki-Seite über das System, kein Architektur-Diagramm, keine Postmortem-Vorlage. Der Leser ist ein On-Call-Ingenieur, der müde ist, möglicherweise halbwach, und in den nächsten zehn Minuten das Richtige tun muss.

Wenn Ihr Runbook erklärt, wie das System funktioniert, ist es zu lang. Wenn es keine spezifischen Befehle und Entscheidungspunkte nennt, ist es zu vage. Die richtige Größe für ein einzelnes Runbook ist ungefähr eine Bildschirmseite Inhalt. Wenn Sie mehr benötigen, teilen Sie es auf.

Die fünfteilige Struktur, die funktioniert

Fünf Abschnitte behandeln das, was ein On-Call-Ingenieur benötigt. Verwenden Sie diese Struktur für jedes Runbook in Ihrer Sammlung.

• Symptom: wie die Benachrichtigung aussieht. Zitieren Sie den tatsächlichen Benachrichtigungstext. Der Ingenieur sollte dies in Sekunden erkennen.
• Impact: wer betroffen ist und wie. Kundenorientiert? Intern? Nur Monitoring-Rauschen? Legt die Dringlichkeit fest.
• Diagnostics: die drei Befehle oder Links, die die Diagnose bestätigen. Nicht »Logs überprüfen«, sondern »kubectl logs -n prod web-deployment -c app«.
• Remediation: die spezifischen Befehle oder Aktionen zur Behebung. Nummeriert, idempotent, sicher zu wiederholen.
• Escalation: wer zu kontaktieren ist, wenn die Behebung nicht funktioniert. Name und Telefonnummer.

Template: Ein Runbook für Datenbankverbindungssättigung

Häufigster Produktionsvorfall. Der Datenbankverbindungspool ist voll, neue Anfragen laufen ab, Monitoring meldet Warnungen mit erhöhter Latenz.

Symptom: »p95 response time above 5 seconds on /api/health«. Impact: kundenorientierte API-Endpunkte erhalten einen Timeout. Diagnostics: Führen Sie kubectl exec in den App-Pod aus und führen Sie pg_stat_activity aus. Suchen Sie nach lange laufenden Abfragen. Remediation: Beenden Sie die längsten laufenden Abfragen mit pg_cancel_backend, skalieren Sie die Pool-Größe mit helm upgrade um 20%, starten Sie die betroffenen Pods neu. Escalation: Benachrichtigen Sie den Datenbank-Lead, wenn der Pool nach 10 Minuten immer noch gesättigt ist.

Template: Ein Runbook für SSL-Zertifikatsablauf

Vorhersehbar, vermeidbar, und trotzdem passiert es fast jedem Team irgendwann. Das Runbook ist kurz, weil die Antwort kurz ist.

• Symptom: SSL-Monitor meldet »läuft in 7 Tagen ab« oder »abgelaufen«.
• Impact: Jeder Browser zeigt eine rote Warnseite an, sobald das Zertifikat abläuft. Konversion geht auf Null.
• Diagnostics: Führen Sie `echo
• openssl s_client -servername DOMAIN -connect DOMAIN:443 2>/dev/null
• openssl x509 -noout -dates` aus, um das Ablaufdatum des aktuellen Zertifikats zu sehen.
• Remediation: Führen Sie das Erneuerungsskript manuell aus (`certbot renew --force-renewal` oder äquivalent), laden Sie dann nginx/den Load Balancer neu. Überprüfen Sie mit demselben openssl-Befehl.
• Escalation: Benachrichtigen Sie DevOps, wenn certbot fehlschlägt. Das Zertifikat muss vor dem Ablaufen manuell erneuert werden.

Template: Ein Runbook für Ausfallzeiten eines upstream-Anbieters

Wenn eine Abhängigkeit eines Drittanbieters (Stripe, Postmark, S3, ein Auth-Provider) der eigentliche Ausfall ist, besteht Ihre Aufgabe darin, ihn zu erkennen, zu kommunizieren und keine Zeit mit dem Debuggen Ihres eigenen Codes zu verschwenden.

Symptom: Die relevante Funktion funktioniert nicht, Ihre eigenen Monitore sind ansonsten grün. Diagnostics: Öffnen Sie die Status-Seite des Providers in einer neuen Registerkarte. Durchsuchen Sie die letzten Commits auf Änderungen der Integration. Remediation: Veröffentlichen Sie ein Update auf Ihrer Status-Seite, das den upstream-Vorfall bestätigt, mit einem Link zur Status-Seite des Providers. Deaktivieren Sie die Funktion hinter einer Feature-Flag, wenn die Verschlechterung schwerwiegend ist. Escalation: Nur wenn die Verschlechterung länger als eine Stunde andauert, ohne dass der upstream-Provider sie bestätigt.

Wo Sie sie aufbewahren und wie Sie sie aktuell halten

Bewahren Sie die Runbooks im selben Git-Repository wie den Anwendungscode auf. Verlinken Sie sie aus der Benachrichtigung selbst. Überprüfen Sie sie nach jedem Vorfall: Wenn das Runbook falsch war, aktualisieren Sie es jetzt, während der Vorfall noch frisch ist. Ein Runbook, das ein Jahr lang nicht aktualisiert wurde, ist wahrscheinlich nicht mehr genau. Planen Sie eine vierteljährliche Überprüfung der Runbook-Sammlung. Löschen Sie die, die nicht mehr zutreffen. Fügen Sie die neuen ein. Behandeln Sie sie wie Code.