Runbooks: Schritt-für-Schritt-Anleitungen für den Betrieb

Kurz: Kurze, geprüfte Anleitungen, die beschreiben, wie man ein bekanntes Problem erkennt und behebt oder eine Routineaufgabe ausführt.

Genauer: Ein Runbook beantwortet nachts um drei Uhr die Frage „Was mache ich jetzt?“. Statt sich auf das Gedächtnis einer einzelnen Person zu verlassen, steht der Ablauf aufgeschrieben bereit. Gute Runbooks senken die Zeit bis zur Behebung und machen Bereitschaftsdienste fairer, weil auch neue Teammitglieder helfen können.

Im Detail

Aufbau eines guten Runbooks

• Anlass: Welcher Alarm oder welches Symptom gehört dazu?
• Auswirkung: Wer ist betroffen, wie dringend?
• Diagnose: Welche Befehle oder Dashboards zeigen die Ursache?
• Maßnahmen: nummerierte, kopierbare Schritte, möglichst mit erwartetem Ergebnis.
• Rückgängig machen: Wie macht man einen Schritt rückgängig?
• Eskalation: An wen wenden, wenn es nicht klappt?
• Stand: Datum der letzten Prüfung.

Beispiel (Auszug)

Symptom: Alarm "Festplatte voll" auf web-01
1. Verbrauch anzeigen:   df -h
2. Größte Ordner:        du -sh /var/* | sort -h
3. Alte Logs löschen:    sudo journalctl --vacuum-time=7d
4. Ergebnis prüfen:      df -h   (unter 80 % erwartet)
Eskalation: Bereitschaft Infrastruktur, falls nicht unter 90 %

Pflege

Ein veraltetes Runbook ist gefährlich. Nach jedem Incident wird geprüft, ob es gestimmt hat, und es wird angepasst. Verlinke es direkt im Alarm. Noch besser ist es, wiederkehrende Schritte zu automatisieren (Skripte, „Runbook Automation“), sodass der Mensch nur noch bestätigt.

Abgrenzung

Ein Playbook beschreibt meist einen übergeordneten Ablauf (zum Beispiel Vorgehen bei einem Sicherheitsvorfall), ein Runbook konkrete technische Schritte. Die Grenze ist in der Praxis fließend.

Siehe auch: Incident-Management und Postmortems, Logging, SLA und Ticketsystem