Ein Runbook ist eine ausführbare Betriebsanleitung für einen wiederkehrenden oder riskanten technischen Vorgang. Es beschreibt nicht nur, welche Handlung vorgesehen ist, sondern auch Voraussetzungen, Reihenfolge, Prüfung, Abbruch und Rückweg.
Runbooks werden für Deployments, Wiederherstellungen, Benutzerwechsel, Störungsbehebung, Wartung und andere Eingriffe verwendet, bei denen Improvisation unnötiges Risiko erzeugt.
Erklärung und Ausführung sind nicht dasselbe
Eine Dokumentation erklärt ein System. Eine Checkliste erinnert an einzelne Punkte. Ein Runbook führt eine verantwortliche Person durch einen konkreten Ablauf. Ein Playbook kann mehrere Runbooks und Entscheidungswege für ein grösseres Szenario verbinden.
Diese Formen dürfen aufeinander verweisen, sollten ihre Rollen aber nicht vermischen. Ein allgemeiner Standard bleibt stabil, während das operative Runbook Zielsysteme, Voraussetzungen und Kontrollen des tatsächlichen Vorgangs kennt.
Was ein Runbook enthalten sollte
Ein brauchbares Runbook beantwortet mindestens:
- Welchem Zweck dient der Ablauf und was gehört nicht zu seinem Geltungsbereich?
- Wer darf ihn ausführen und welche Freigabe ist erforderlich?
- Welches Zielsystem und welcher Ausgangszustand werden erwartet?
- Welche Abhängigkeiten und Zugänge müssen verfügbar sein?
- In welcher Reihenfolge werden die Schritte ausgeführt?
- Welche Prüfungen bestätigen den Erfolg?
- Bei welchem Befund wird abgebrochen oder eskaliert?
- Wie lässt sich der vorherige Zustand wiederherstellen?
- Wer pflegt das Runbook und wann wurde es zuletzt geprüft?
Konkrete Befehle brauchen genügend Kontext, dürfen aber keine Passwörter, Tokens oder private Schlüssel enthalten. Secrets werden über den vorgesehenen Zugriffspfad bezogen, nicht in die Anleitung kopiert.
Vorher, währenddessen und danach
Vor dem Eingriff wird geprüft, ob Ziel, Ausgangszustand, Berechtigung und Rückweg noch gelten. Während der Ausführung werden Schritte in der festgelegten Reihenfolge durchgeführt und ihre Wirkung beobachtet. Danach folgt ein Readback: Der beabsichtigte Zustand muss am Ziel nachweisbar sein.
Ein erfolgreich ausgeführter Befehl ist noch kein erfolgreicher Change. Entscheidend ist die bestätigte Wirkung. Schlägt ein Schritt fehl oder bleibt sein Ergebnis unklar, wird nicht blind wiederholt. Das Runbook legt fest, an welchem überprüften Zwischenstand fortgesetzt oder zurückgerollt werden darf.
Automatisierung ersetzt das Runbook nicht
Ein Runner kann wiederholbare Schritte ausführen, Eingaben validieren und Evidenz sammeln. Das Runbook erklärt weiterhin Zweck, Verantwortungsgrenzen, Abbruchbedingungen und Rückweg. Automatisierung verkürzt die Bedienung; sie hebt die Betriebsentscheidung nicht auf.
Umgekehrt sollte ein wiederkehrender Ablauf nicht dauerhaft aus manuell kopierten Befehlen bestehen, wenn er deterministisch automatisiert und getestet werden kann. Das Runbook beschreibt dann den kontrollierten Aufruf der Automation und die Prüfung ihres Ergebnisses.
Ein Runbook ist ein lebendes Dokument
Nach einer Änderung, Übung oder Störung wird geprüft, ob Annahmen, Schritte und Kontakte noch stimmen. Ein ungetestetes Runbook kann im Notfall gefährlicher sein als eine offen benannte Wissenslücke.
Versionierung mit Git macht Änderungen nachvollziehbar. Sie zeigt jedoch nur den Dokumentstand. Ob der Ablauf mit der aktuellen Infrastruktur funktioniert, muss durch Übungen, kontrollierte Rehearsals oder einen begrenzten Einsatz bestätigt werden.
Merksatz
Ein Runbook macht einen Eingriff wiederholbar und überprüfbar. Es legt vor Beginn fest, wie Erfolg erkannt wird, wann Schluss ist und wie der Rückweg aussieht.