Recovery orchestrieren: Runbooks, Trockenläufe und Freigabetore

Automatisierung macht auch den falschen Schritt zuverlässig, schnell und über alle Systeme gleichzeitig. Dieses Modul zieht die Grenze dort, wo sie tragfähig ist — bei der Umkehrbarkeit — und zeigt, warum ein grüner Trockenlauf ausgerechnet bei Wiederanläufen wenig beweist: Module ohne Prüfmodus melden nichts und tun nichts, und Aufgaben, die auf Ergebnissen vorheriger Schritte beruhen, werden gar nicht simuliert. Dazu die Frage, die kaum jemand stellt: Was tun, wenn die Automatisierung selbst Teil des Schadens ist?

Lehrtext · 11 Abschnitte · zuletzt geprüft: 2026-09-04

Automatisierung verschiebt den Fehler, sie beseitigt ihn nicht

Der Grund, eine Wiederherstellung zu automatisieren, ist gut und lässt sich in einem Satz sagen: Menschen unter Zeitdruck vergessen Schritte, vertauschen Reihenfolgen und tippen Pfade falsch. Ein Ablauf, der jedes Mal gleich läuft, ist dem überlegen — und er ist schneller, was direkt auf die zugesagte Wiederanlaufzeit einzahlt.

Der Preis steht daneben und wird selten ausgesprochen: Dieselbe Automatisierung macht auch den falschen Schritt zuverlässig, schnell und über alle Systeme gleichzeitig. Ein Mensch, der den falschen Zeitpunkt zurückholt, merkt es beim dritten Server. Ein Ablauf, der den falschen Zeitpunkt zurückholt, ist beim dritten Server längst fertig.

Die Frage, die dieses Modul beantwortetNicht „automatisieren oder nicht“ — die Antwort darauf ist fast immer ja. Sondern: Welcher Schritt darf ohne Rückfrage laufen, welcher braucht eine Entscheidung, und woran erkennt man den Unterschied? Dazu kommt eine zweite Frage, die noch seltener gestellt wird: Was passiert, wenn die Automatisierung selbst nicht verfügbar ist?

Die Trennlinie verläuft bei der Umkehrbarkeit

Es gibt eine brauchbare, einfache Regel, und sie hält erstaunlich weit: Umkehrbares darf automatisch laufen, Unumkehrbares braucht ein Tor. Nicht die Wichtigkeit entscheidet und nicht die Komplexität, sondern die Frage, ob ein Fehler danach noch korrigierbar ist.

Freigabetor — Ein Halt im Ablauf, an dem ein Mensch eine benannte Entscheidung trifft, bevor es weitergeht. Es ist kein Bestätigungsdialog: Ein Tor nennt die Information, auf deren Grundlage entschieden wird, und die Person, die entscheiden darf.

Darf automatisch laufen: Zielsystem bereitstellen, Bestand in ein leeres Verzeichnis holen, Prüfsummen vergleichen, Dienste in einer Testumgebung starten, Berichte erzeugen.
Braucht ein Tor: Überschreibende Wiederherstellung, Umschaltung des produktiven Namens, Freigabe ausgehender Verbindungen, Löschen alter Stände, Rückkehr in den Normalbetrieb.
Der Grenzfall: Alles, was Dritte erreicht — Nachrichten verschicken, Schnittstellen aufrufen, in fremden Systemen buchen. Technisch oft umkehrbar, praktisch nicht.

Die dritte Zeile ist die, an der Entwürfe scheitern. Ein wiederhergestellter Dienst nimmt die Arbeit dort auf, wo er aufgehört hat: Er verschickt die Rechnungen aus der Warteschlange von vor drei Tagen, ruft Schnittstellen erneut auf und bucht ein zweites Mal. Rein technisch ließe sich das rückgängig machen; beim Empfänger nicht.

Wie ein Tor nicht aussehen darfEin Freigabetor mitten in einem Ablauf, der um vier Uhr morgens ohne Zuschauer läuft, ist kein Tor, sondern ein Stillstand. Wer Tore setzt, muss zugleich festlegen, wer sie öffnet und wie diese Person erreicht wird — sonst verlagert das Tor die Wiederanlaufzeit in die Erreichbarkeit einer einzelnen Person. Die brauchbare Form nennt eine Rolle statt eines Namens, eine Vertretung und einen Weg, der ohne die eigenen Systeme funktioniert.

Was ein Runbook unter Stress leisten muss

Ein Runbook wird nicht von seinem Autor gelesen, sondern von einer müden Person um drei Uhr nachts, die die Umgebung weniger gut kennt und niemanden fragen kann. Alles, was dieser Situation nicht standhält, ist Dekoration.

Ein Ziel je Abschnitt, in einem Satz. Nicht was getan wird, sondern woran man erkennt, dass der Abschnitt fertig ist.
Vollständige Befehle statt Beschreibungen. „Den Bestand zurückholen“ ist eine Absicht; der ausgeschriebene Befehl mit benannten Platzhaltern ist eine Anweisung.
Die Voraussetzungen an den Anfang. Zugänge, Schlüssel, Adressen — und zwar mit dem Hinweis, wo sie liegen, nicht nur mit ihrem Namen.
Entscheidungspunkte sichtbar. Wo eine Wahl zu treffen ist, steht die Wahl im Text, nicht im Kopf des Autors.
Was tun, wenn es schiefgeht. Zu jedem unumkehrbaren Schritt der Weg zurück oder die ausdrückliche Aussage, dass es keinen gibt.

Die billigste QualitätsprüfungDieselbe wie beim Restore-Test: Jemand, der das System nicht gebaut hat, arbeitet das Runbook allein anhand des Textes ab. Jede Stelle, an der diese Person nachfragen muss, ist ein Befund — und zwar einer, der im Ernstfall unter Zeitdruck auftritt, wenn nachfragen nicht geht. Es ist die Prüfung mit dem besten Verhältnis von Aufwand zu Erkenntnis in diesem ganzen Track.

Unter Druck wird wiederholt

Idempotenz — Die Eigenschaft eines Schritts, bei mehrfacher Ausführung dasselbe Ergebnis zu erzeugen wie bei einmaliger. Ein Schritt, der einen Zustand herstellt, ist idempotent; ein Schritt, der etwas hinzufügt, ist es nicht.

Die Bedeutung für Wiederherstellungen ist praktisch und nicht theoretisch: Unter Stress wird wiederholt. Die Verbindung bricht ab, jemand ist unsicher, ob der Befehl durchlief, zwei Personen arbeiten dasselbe Runbook parallel ab. Ein Ablauf, der das nicht verträgt, erzeugt beim zweiten Durchlauf einen Schaden, den der erste nicht hatte.

Nicht idempotent: Eine Zeile an eine Konfigurationsdatei anhängen. Zweimal ausgeführt steht sie zweimal da.
Idempotent: Sicherstellen, dass eine Zeile mit bestimmtem Inhalt vorhanden ist. Zweimal ausgeführt ändert der zweite Lauf nichts.
Der Unterschied im Ergebnis: Der erste Fall erzeugt einen Zustand, den niemand entworfen hat, und der Fehler zeigt sich erst beim Start des Dienstes — also nach dem Zeitpunkt, an dem man ihn noch billig gefunden hätte.

Werkzeuge zur Konfigurationsverwaltung sind genau darauf ausgelegt und nehmen einem diese Arbeit weitgehend ab. Wo mit eigenen Skripten gearbeitet wird, ist Idempotenz dagegen eine Entwurfsentscheidung je Schritt — und die Prüfung dafür ist simpel: Das Runbook zweimal hintereinander vollständig durchlaufen lassen und die Ergebnisse vergleichen.

Der Trockenlauf lügt genau dort, wo es zählt

Ein Trockenlauf vor dem Ernstfall wirkt wie die naheliegende Absicherung: erst simulieren, dann ausführen. Die Dokumentation der verbreitetsten Werkzeuge ist an dieser Stelle bemerkenswert offen, und wer sie liest, vertraut dem grünen Trockenlauf danach weniger.

Ansible bietet mit ansible-playbook --check einen Prüfmodus, der laut Dokumentation eine Simulation ist. Der entscheidende Satz steht direkt daneben: Module, die den Prüfmodus unterstützen, melden die Änderungen, die sie vorgenommen hätten — Module, die ihn nicht unterstützen, melden nichts und tun nichts. Ein sauberer Trockenlauf kann also bedeuten, dass ein Schritt nichts ändern würde, oder dass er überhaupt nicht simuliert werden konnte. Beide Fälle sehen gleich aus.

Der zweite dokumentierte Vorbehalt trifft Recovery besondersDieselbe Seite hält fest, dass der Prüfmodus für Aufgaben, deren Bedingungen auf Ergebnissen vorangegangener Aufgaben beruhen, keine Ausgabe erzeugt. Genau so ist aber jeder Wiederanlauf gebaut: Der zweite Schritt hängt davon ab, was der erste vorgefunden hat. Der Trockenlauf prüft damit ausgerechnet den Teil nicht, der die Reihenfolge trägt — er validiert Konfigurationsabläufe gut und Wiederherstellungsabläufe schlecht.

Der Trockenlauf, der etwas kaputt macht

Szenario

Ein Wiederanlauf-Playbook wird vor der Freigabe mit --check geprüft. Der Lauf meldet keine Auffälligkeiten. Nach dem Lauf ist ein Datenträger auf dem Zielsystem neu formatiert.

Anforderungen

Die Ursache soll ohne Rückgriff auf Vermutungen bestimmt werden.
Der Prüfmodus soll für dieses Playbook künftig belastbar sein.

Schritte

Im Playbook nach der Option check_mode suchen: Sie erzwingt für eine einzelne Aufgabe das Verhalten unabhängig vom Aufruf.
Die Aufgabe mit check_mode: false finden — sie führt laut Dokumentation auch dann echte Änderungen aus, wenn das Playbook mit --check aufgerufen wird.
Prüfen, warum das gesetzt wurde: meist, weil ein späterer Schritt das Ergebnis braucht und der Trockenlauf sonst abbricht.
Die Aufgabe in zwei zerlegen — eine lesende, die auch im Prüfmodus laufen darf, und eine schreibende, die es nicht darf.
Zusätzlich --diff verwenden, damit der Prüflauf die konkreten Vorher-Nachher-Unterschiede zeigt statt nur eine Änderungsmarkierung.

Merksatz: Ein Trockenlauf ist nur so trocken wie die Aufgabe, die ihn nicht respektiert. Vor jeder Freigabe eines Wiederanlaufablaufs gehört die Suche nach ausdrücklich erzwungenen Ausnahmen — und die Erkenntnis, dass ein grüner Prüflauf keine Aussage über nicht simulierbare Schritte enthält.

Unterbrechung ist der Normalfall

Ein Wiederanlauf über mehrere Stunden wird unterbrochen — durch einen Verbindungsabbruch, einen Fehler in Schritt elf von zwanzig, eine Entscheidung, die erst getroffen werden muss. Die Frage ist nicht, ob das passiert, sondern was danach möglich ist.

Werkzeuge bieten dafür Hilfsmittel an, und auch hier lohnt der Blick ins Kleingedruckte. Ansible kennt --start-at-task="…", um bei einer benannten Aufgabe wieder einzusteigen. Die Dokumentation weist ausdrücklich darauf hin, dass das nicht für Aufgaben innerhalb dynamisch eingebundener Rollen oder Includes funktioniert — also genau für die Struktur, in der ernsthafte Abläufe organisiert sind. Für den interaktiven Fall gibt es --step, das vor jeder Aufgabe fragt.

Verlass dich nicht auf Wiedereinstiegsfunktionen. Sie haben dokumentierte Grenzen, und die treffen strukturierte Abläufe zuerst.
Mach stattdessen jeden Schritt wiederholbar. Ein idempotenter Ablauf braucht keinen Wiedereinstieg — er wird einfach noch einmal von vorn gestartet.
Schreibe den Fortschritt fest. Ein Ablauf, der nach jedem Abschnitt seinen Stand ablegt, erlaubt es einer zweiten Person, dort weiterzumachen, wo die erste aufgehört hat.
Plane die Übergabe. Ein Wiederanlauf über acht Stunden überdauert eine Schicht. Was nicht schriftlich vorliegt, geht bei der Übergabe verloren.

Eingaben sind die gefährlichste Stelle

Jeder Wiederanlaufablauf bekommt Eingaben: welchen Stand, auf welches Ziel, für welchen Dienst. Diese drei Werte entscheiden über Erfolg und Schaden, sie werden unter Zeitdruck eingegeben, und sie sind fast nie geprüft.

Der Zeitpunkt: Ein Stand aus der falschen Woche sieht aus wie ein Erfolg — bis jemand die Daten anschaut. Prüfung: Zeitstempel ausgeben und bestätigen lassen, bevor geschrieben wird.
Das Ziel: Ein Pfad mit Tippfehler schreibt an die falsche Stelle; ein Pfad ohne Tippfehler schreibt womöglich über den produktiven Bestand. Prüfung: Ziel muss leer sein oder ausdrücklich als Überschreibung freigegeben.
Der Umfang: Ein zu großer Umfang holt Daten zurück, die niemand zurückhaben wollte. Prüfung: Objektzahl und Größe vor dem Schreiben anzeigen.

Die Regel dahinterEin Ablauf, der Unumkehrbares tut, zeigt vorher an, was er tun wird — mit den konkreten Werten, nicht mit den Platzhaltern. Diese Anzeige ist der eigentliche Inhalt des Freigabetors: Sie verwandelt eine Bestätigung ohne Information in eine Entscheidung mit Grundlage. Ein Tor, das nur „Fortfahren? j/n“ fragt, ist eine Verzögerung ohne Erkenntniswert und wird nach dem dritten Mal blind bestätigt.

Eine zweite Klasse von Eingaben wird noch häufiger übersehen, weil sie nicht wie eine Eingabe aussieht: die Umgebung, in der der Ablauf gerade läuft. Dasselbe Skript, versehentlich gegen die produktive statt gegen die Testumgebung gestartet, tut zuverlässig das Falsche. Die Absicherung dagegen ist keine Eingabeprüfung, sondern eine Trennung: getrennte Zugangsdaten je Umgebung, sodass der Ablauf die produktive Umgebung gar nicht erreichen kann, solange er nicht ausdrücklich dafür gestartet wurde.

Automatisierung muss ihren eigenen Beleg erzeugen

Der Nachweis aus dem vorigen Modul — Uhrzeiten je Abschnitt, Objektzahl, Größe, Ergebnis gegen Kriterien — ist Handarbeit, solange niemand ihn dem Ablauf beibringt. Wird er dem Ablauf beigebracht, entsteht er in jedem Lauf, auch im Ernstfall, auch nachts, auch wenn niemand daran denkt.

Zeitstempel je Abschnitt, damit die Wiederanlaufzeit ohne nachträgliche Rekonstruktion aus Protokollen entsteht.
Die Eingabewerte, mit denen der Lauf tatsächlich gestartet wurde — nicht die aus der Dokumentation.
Mengengerüst, also Objektzahl und Größe, für den Vergleich mit dem Vorlauf.
Die getroffenen Entscheidungen an den Freigabetoren, mit Person und Uhrzeit.

Das ist kein großer Aufwand — es sind vier Ausgaben in ein Protokoll — und es ist der Unterschied zwischen einer Übung, aus der man lernt, und einer Übung, über die man diskutiert. Im Ernstfall ist derselbe Beleg außerdem das, was die Nachbereitung überhaupt möglich macht: Nach zwölf Stunden Wiederanlauf erinnert sich niemand mehr zuverlässig an die Reihenfolge.

Der Beleg ist kein ProtokollEin ausführliches Ablaufprotokoll ist etwas anderes als ein Beleg. Das Protokoll enthält alles und ist deshalb nach einem Ernstfall über zwölf Stunden praktisch unlesbar; der Beleg enthält vier Zeilen je Abschnitt und lässt sich in fünf Minuten auswerten. Beide zu erzeugen kostet nichts, weil der Beleg aus denselben Werten entsteht — nur an eine zweite, aufgeräumte Stelle geschrieben. Wer nur das Protokoll hat, wird die Nachbereitung verschieben und dann nicht mehr machen.

Wenn die Automatisierung selbst ausfällt

Der Ablauf läuft auf einem System. Dieses System steht in einer Umgebung. Wenn die Umgebung der Grund für den Wiederanlauf ist, ist die Automatisierung Teil des Schadens — und das fällt genau dann auf, wenn sie gebraucht wird.

Kurzcheck

Der Wiederanlaufablauf liegt in einem Versionsverwaltungssystem, das auf derselben Virtualisierungsplattform betrieben wird wie die wiederherzustellenden Dienste. Welche Maßnahme ist am wirksamsten?

Eine lesbare Fassung des Ablaufs außerhalb dieser Plattform vorhalten und turnusmäßig erneuern.
Das Versionsverwaltungssystem in die oberste Schutzklasse aufnehmen.
Den Ablauf zusätzlich in einer zweiten Region derselben Plattform spiegeln.

Treffer. Richtig. Sie muss nicht ausführbar sein — sie muss lesbar sein, damit die Schritte von Hand nachvollzogen werden können. Alles, was zur Wiederherstellung gebraucht wird und nur in der geschädigten Umgebung liegt, ist im Ernstfall nicht verfügbar.

Daraus folgt eine Reihenfolge, die in den Plan gehört: Die ersten Schritte eines großen Wiederanlaufs sind immer manuell, weil noch nichts steht, worauf Automatisierung aufsetzen könnte. Erst wenn eine Grundlage existiert — Netz, Verzeichnisdienst, Ausführungsumgebung — übernimmt der Ablauf. Wer das nicht so plant, plant einen Wiederanlauf, der beim ersten Schritt hängt.

Runbook-Drift

Ein Runbook beschreibt eine Umgebung zu einem Zeitpunkt. Die Umgebung ändert sich täglich, das Runbook alle paar Jahre. Nach 18 Monaten enthält es Pfade, die es nicht mehr gibt, und lässt Systeme aus, die inzwischen dazugekommen sind — und niemand merkt es, weil es zwischen zwei Ernstfällen nie gelesen wird.

Auslöser statt Turnus: Nicht „jährlich prüfen“, sondern: Jede Änderung an einem System, das im Runbook vorkommt, löst eine Prüfung des betroffenen Abschnitts aus.
Der Verweis in beide Richtungen: Im Änderungsverfahren steht die Frage „betrifft das ein Runbook?“; im Runbook steht, welche Systeme es berührt. Ohne die zweite Richtung ist die erste nicht beantwortbar.
Der Beleg: Datum der letzten Prüfung im Kopf des Dokuments. Ein Runbook ohne Datum ist von unbekanntem Alter, und unbekanntes Alter heißt im Zweifel: zu alt.

Warum der Turnus allein nicht reichtEine jährliche Prüfung findet die Abweichungen eines Jahres auf einmal — meist unter Zeitdruck kurz vor einem Termin, und sie prüft dann Text gegen Erinnerung statt gegen die Wirklichkeit. Der auslöserbasierte Weg verteilt dieselbe Arbeit auf kleine Portionen zum Zeitpunkt der Änderung, an dem jemand die Änderung noch versteht. Beides zusammen ist besser als eines allein — aber wenn nur eines geht, ist es der Auslöser.

Abgrenzung

Hier geht es um die Mechanik des Ablaufs. Wer im Ernstfall an welchem Tor entscheidet, wie eskaliert und kommuniziert wird und wie eine Lage geführt wird, steht im Modul über Disaster Response. Wie Übungen geplant und ihre Befunde geschlossen werden, im Modul über das Übungsprogramm.

NachbartracksDie Werkzeuge selbst — Rollen, Inventare, Module, Schleifen — behandelt powershell-automation und der Automatisierungsteil von cloud-infra. Hier interessiert nur, welche Eigenschaft eines Ablaufs ihn für eine Wiederherstellung tauglich oder gefährlich macht.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität4 Primärquellen · zuletzt geprüft: 2026-09-04