Bei jedem Ausfall stellen alle dieselben vier Fragen – immer in derselben Reihenfolge. Wer sie vorher aufschreibt, ist im Störfall sofort handlungsfähig.

Einsteiger begegnen dem Runbook meist erst, wenn eine Automation nachts ausfällt und niemand weiß, wer sie neu starten darf. Ohne dieses Wissen bleibt der Fehler liegen, bis jemand das System mühsam versteht.

Ein Runbook ist eine kurze, schriftliche Anleitung für den Störfall, die neben der Automation liegt. Es sagt im Ernstfall Schritt für Schritt, was zu prüfen und zu tun ist. Es ist keine Bauanleitung, sondern eine Notfallkarte.

Die Fragen bei einem Ausfall entstehen in fester Reihenfolge: Was macht diese Automation eigentlich? Läuft sie gerade noch? Wen muss man informieren? Wer darf sie neu starten oder abschalten? Das Google SRE Book empfiehlt deshalb Playbooks, die zu jedem Alarm die ersten Handgriffe nennen – so kann auch eine Vertretung handeln. Das Runbook braucht nur Zweck, beteiligte Systeme, Fehlerzeichen, Handgriffe und Zuständigkeit.

Ein Beispiel: Ein Workflow versendet jede Nacht Rechnungen per Zeitplan. Als Besitzerin ist die Sachbearbeiterin im Buchhaltungsteam eingetragen; sie erhält die Fehlermeldungen und hält das Runbook aktuell. Zum Besitz gehören drei schriftliche Angaben: wer Meldungen bearbeitet, wer Änderungen freigibt, wer vertritt.

Das Runbook wird oft mit der Erinnerung an die Automation verwechselt, die als Dokumentation gilt. Nach Monaten fehlt dann genau das, was der Störfall verlangt. Ein Bus-Faktor von eins – wie viele Personen ausfallen dürfen, bevor Wissen verloren geht – ist ein Betriebsrisiko.

Testen Sie das Runbook nicht im Leerlauf, sondern beim nächsten Fehler: Jede unklare Stelle sofort ergänzen.

Ein Runbook ist nicht die Erinnerung an den Bau, sondern die Antwort auf den Ausfall.

📌 Zweck · Fehlerzeichen · Zuständigkeit

📚 Automatisierung von Grund auf · Tag 6 von 30
#Automatisierung #workflow #effizienz