Ein Notfallplan ist eine Reihenfolge, keine Liste
Ein Wiederanlaufplan, der nur auflistet, was wieder laufen muss, hilft im Ernstfall wenig. Denn nichts startet gleichzeitig: Die Anwendung braucht die Datenbank, die das Netz, das den Strom. Warum die Reihenfolge und der kritische Pfad über die echte Wiederanlaufzeit entscheiden und warum eine geschätzte RTO im Ernstfall selten hält.
Die meisten Notfallpläne beantworten die Frage „Was muss wieder laufen?" ordentlich. Die Frage, an der es im Ernstfall scheitert, ist eine andere: in welcher Reihenfolge? Denn nichts startet gleichzeitig. Die Fachanwendung braucht ihre Datenbank, die Datenbank das Netz, das Netz die Stromversorgung. Ein Plan, der nur die Bausteine auflistet, aber nicht ihre Abhängigkeiten, ist im Krisenmoment eine Sammlung richtiger Einzelteile ohne Bauanleitung.
Die Wiederanlaufzeit steckt in den Abhängigkeiten
Wie lange ein Wiederanlauf wirklich dauert, hängt nicht an der Summe aller Schritte, sondern an ihrer längsten Kette. Genau das ist der kritische Pfad: die Abfolge voneinander abhängiger Teilschritte, die sich nicht parallelisieren lässt. Vieles andere kann nebenher laufen, aber diese Kette bestimmt das Minimum. Wer seine Wiederanlaufzeit ohne diesen Pfad schätzt, schätzt fast immer zu optimistisch, und merkt es erst, wenn im Ernstfall die Uhr läuft.
Ein Plan besteht selten für sich allein
Dazu kommt, dass Wiederanlaufpläne nicht isoliert stehen. Der Plan für die Fachanwendung setzt voraus, dass der Plan für die Basis-Infrastruktur schon durch ist. In der Praxis heißt das: Ein Plan wird zum Teilschritt eines anderen. Wer das nicht abbildet, plant jede Ebene für sich und übersieht, dass sich die Zeiten addieren, statt sich zu überlappen.
Wie isidaten den Wiederanlauf rechnet
Das Notfallmanagement in isidaten baut Wiederanlaufpläne aus Teilschritten mit Dauern und Abhängigkeiten, nicht als flache Liste. Pläne lassen sich als Teilschritt in andere Pläne einbinden, sodass die Basis-Infrastruktur vor der Fachanwendung steht. Daraus errechnet das Modul den kritischen Pfad und die tatsächliche Wiederanlaufzeit, und ein RTO-Konsistenz-Checker zeigt, wo diese Zeit die vorgegebene RTO reißt, bevor es die Realität tut. Geprobt wird nicht erst im Ernstfall, sondern in Tabletop-Übungen mit Inject-Timeline, und was dabei auffällt, landet als Maßnahme im System.
Mehr zeigt die Notfallmanagement-Modulseite. Woher die Abhängigkeiten zwischen Anwendung, System und physischer Grundlage kommen, führt das DCIM auf.
Fragen zu dieser Neuerung?
Sprechen Sie mit uns – wir zeigen Ihnen die Funktion gern in einer Demo.