Ein Runbook ist eine dokumentierte Anleitung, die Engineers in der Rufbereitschaft oder einem Automatisierungssystem zeigt, wie ein bestimmtes Betriebsproblem diagnostiziert und behoben oder eine Routineaufgabe wie ein Failover ausgeführt wird. Gute Runbooks sind direkt mit Alerts verknüpft, enthalten überprüfbare Schritte mit erwarteten Ergebnissen und werden schrittweise automatisiert.
Was ist ein Runbook?
Ein Runbook ist eine schriftliche, wiederholbare Anleitung für eine bekannte Situation: eine volllaufende Festplatte, eine sich stauende Queue, ein bald ablaufendes Zertifikat, ein Datenbank-Failover. Es hält das Wissen der Engineers fest, die einen Service gebaut haben und betreiben. So kann jede Person in der Rufbereitschaft auch um drei Uhr nachts schnell und einheitlich handeln, ohne das System unter Druck erst verstehen zu müssen.
Runbooks verkürzen die Zeit bis zur Eindämmung, einen wesentlichen Treiber der MTTR, und verteilen Betriebswissen im Team. Sie machen außerdem Toil sichtbar: Jedes Runbook, das häufig und Schritt für Schritt identisch ausgeführt wird, ist ein Kandidat für Automatisierung.
Runbook vs. Playbook
Die Begriffe werden oft synonym verwendet, viele Organisationen unterscheiden sie aber:
| Aspekt | Runbook | Playbook |
|---|---|---|
| Umfang | Eine konkrete technische Aufgabe oder ein Fehlerbild | Ein übergreifender Reaktionsprozess, etwa bei einem Major Incident oder Sicherheitsvorfall |
| Inhalt | Konkrete Befehle, Abfragen, Prüfungen und erwartete Ergebnisse | Rollen, Kommunikation, Eskalationswege und Entscheidungspunkte |
| Typischer Auslöser | Ein bestimmter Alert | Ein Schweregrad oder Incident-Typ |
Ein Playbook verweist häufig auf mehrere Runbooks: Das Major-Incident-Playbook legt fest, wer Incident Commander ist, das Datenbank-Runbook erklärt, wie ein Replikat zum Primary befördert wird.
Was ein gutes Runbook enthält
- Titel und Auslöser: welcher Alert oder welches Symptom adressiert wird.
- Auswirkung und Dringlichkeit: was Nutzer erleben und wie schnell gehandelt werden muss.
- Diagnose: Links zu den passenden Dashboards und Abfragen sowie wie sich die Hypothese bestätigen lässt.
- Schritte zur Eindämmung: nummerierte, kopierbare Aktionen, jeweils mit erwartetem Ergebnis und Prüfung.
- Rollback: wie sich jeder Schritt rückgängig machen lässt, falls er die Lage verschlechtert.
- Eskalation: wann Sie abbrechen und wen Sie hinzuziehen, inklusive Service-Verantwortlichen und Anbietern.
- Metadaten: verantwortliche Person, Datum der letzten Prüfung und Links zu zugehörigen Postmortems.
Beispiel-Runbook
Ein Runbook zur Veranschaulichung für einen Alert zur Verbindungssättigung in PostgreSQL:
Alert: orders-db Verbindungen > 90 % von max_connections seit 5 Min.
Auswirkung: Checkout-Requests laufen in Timeouts, sobald das Limit erreicht ist
1. Bestätigen: Dashboard "orders-db" öffnen; aktive vs. inaktive
Verbindungen prüfen und welche Services sie halten.
2. Lang laufende Sessions finden:
SELECT pid, state, now() - xact_start AS age, query
FROM pg_stat_activity ORDER BY age DESC LIMIT 20;
3. Hält ein Service die meisten "idle in transaction"-Sessions,
seine Pods einzeln neu starten und die Verbindungszahl beobachten.
Erwartet: Wert sinkt binnen 2 Minuten unter 70 %.
4. Hat ein aktuelles Deployment Pool-Einstellungen geändert: Rollback.
5. An das Datenbank-Team eskalieren, wenn die Sättigung nach
15 Minuten anhält oder der Replikations-Lag 30 s übersteigt.Jeder Schritt sagt, worauf Sie schauen, was Sie tun und wie „gut“ aussieht. Die Schwellenwerte sind Beispiele; verwenden Sie die Werte, die zu Ihrem System passen.
Von der Dokumentation zur Automatisierung
Runbook-Automatisierung macht die sicheren, deterministischen Teile einer Anleitung zu Code, der auf Abruf oder als Reaktion auf einen Alert läuft: Diagnosedaten sammeln, ein Deployment skalieren, Zugangsdaten rotieren, einen hängenden Consumer neu starten. Bewährt hat sich ein schrittweises Vorgehen:
- Manuell: schriftliche Schritte, denen ein Mensch folgt.
- Assistiert: Skripte sammeln Kontext und schlagen den nächsten Schritt vor, ein Mensch gibt frei.
- Automatisiert: Der Workflow läuft in gut verstandenen Fällen selbstständig, mit Leitplanken, Ratenbegrenzung und Audit-Trail.
Halten Sie Entscheidungspunkte explizit. Automatisierung, die Services blind neu startet, kann ein echtes Problem verdecken oder verstärken, etwa wenn alle Pods gleichzeitig neu starten. Kombinieren Sie automatische Behebung mit Health Checks, die prüfen, ob die Maßnahme gewirkt hat.
Best Practices und typische Fehler
- Verknüpfen Sie jeden Alert, der jemanden weckt, mit einem Runbook. Ein Alert ohne Runbook ist ein Kandidat zum Löschen und eine Quelle von Alarmmüdigkeit.
- Legen Sie Runbooks neben dem Code oder in einem durchsuchbaren Wiki mit Versionshistorie ab und überarbeiten Sie sie nach jedem Incident, in dem sie genutzt wurden.
- Testen Sie Runbooks in Game Days; Schritte, die nur auf dem Laptop des Autors funktionieren, versagen genau dann, wenn es darauf ankommt.
- Vermeiden Sie vage Anweisungen wie „Logs prüfen“. Nennen Sie Abfrage, Feld und erwarteten Wert.
- Lassen Sie Runbooks nicht veralten: Falsche Hostnamen oder Befehle sind schlimmer als gar keine, weil sie Zeit und Vertrauen kosten.
Wie Obseria unterstützt
In Obseria können Alerts einen Runbook-Link und die relevanten Dashboards mitführen, sodass Einsatzkräfte sofort im richtigen Kontext landen. Mit Obseria Automation setzen Sie die deterministischen Schritte eines Runbooks als Workflows as Code um, ausgelöst durch Alerts oder auf Abruf, wobei jede Aktion für das Postmortem protokolliert wird.
