Runbooks und Betriebswissen

Dokumentation, die im Ernstfall trägt: ausführbare Schritte statt Beschreibungen, Aktualität durch Nutzung und die Grenze zwischen Runbook und Automatisierung.

Dokumentation, die um drei Uhr nachts funktioniert

Einführung · 6 Abschnitte · ~15 Min Lesezeit · Stand 2026-07-30

Betriebsfrage

Betriebswissen scheitert selten daran, dass es fehlt. Es scheitert daran, dass es zum Zeitpunkt des Bedarfs nicht auffindbar, nicht aktuell oder nicht ausführbar ist — von einer Person, die den Dienst nicht gebaut hat.

Mentales Modell

Auslöser
Prüfen
Handeln
Bestätigen
Eskalieren

Merkmale eines tragfähigen Runbooks

Ein benannter Auslöser: bei welchem Alarm oder Symptom es gilt — und wann ausdrücklich nicht.
Schritte in der Befehlsform mit erwartetem Ergebnis, nicht als Beschreibung des Systems.
Ein Abbruchpunkt: ab wann nicht weiter probiert, sondern eskaliert wird.
Ein Stand mit Datum und die Angabe, wann es zuletzt tatsächlich benutzt wurde.

Aktualität entsteht durch Nutzung

Ein Runbook, das nur bei der jährlichen Revision angefasst wird, ist bei der nächsten Störung falsch. Aktualität entsteht dort, wo das Dokument im Ernstfall verwendet und unmittelbar danach korrigiert wird — der Vorfall ist der beste Revisionsanlass.

Grenze zur Automatisierung

Automatisieren	Der Ablauf ist eindeutig, häufig und ohne Ermessensentscheidung — dann gehört er in Code, nicht in Prosa.
Runbook behalten	Der Ablauf erfordert Beurteilung, ist selten oder hat gefährliche Nebenwirkungen — dann ist die geführte Handarbeit sicherer.