In vielen Gesprächen, Beratungen, Kundenterminen und Workshops habe ich häufig das gleiche Deja vue durchlebt: erklären zu müssen, was versteht man eigentlich unter einem Notfallhandbuch.
Die häufigste Darstellung bei Kunden ist ein pures Missverständnis. Demnach ist im Notfallhandbuch beschrieben, wie man im Detail seine IT-Infrastruktur wieder zum Laufen bekommt. Das BSI sagt hierzu (Zitat):
„Das Notfallhandbuch umfasst alle Dokumente, die eine angemessene Reaktion auf Krisen und Notfälle unterstützen sollen.“
Quelle: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzSchulung/Webkurs1004/7_Notfaellebewaeltigen/4_Notfallhandbuch/Notfallhandbuch_node.html
Das IT-Notfallhandbuch (Betonung liegt auf „IT“) ist BESTANDTEIL des innerbetrieblichen Notfallmanagements. Im Notfallmanagement gilt es Präbention, Umgang sowieTraining & Erkennung von Notfallsituationen zu beschreiben und festzulegen.
Wenn ich dann Notfallhandbücher sehe, welche Kunden selber erstellt haben, sei es aus einem konkreten MUSS heraus oder aber aus Eigenanspruch, erkennt man oft das Mißverständnis. Das sind dann häufig mehrere 100 Seiten starke Abhandlungen. Dies erfüllt eher den Sachbestand des Romans; ein Notfallhandbuch sollte deutlich verschlankt sein. Wobei man die Seitenanzahl relativieren kann, ein grafischer Plan kann mitunter eine eigene Seite sein (zu viele Pläne sind jedoch auch eher suboptimal). Anmerkung: Daher ist ein Notfallhandbuch von einem externen Ersteller meist eindeutiger. Warum: dazu später ein paar Fact’s.
Nehmen wir das Thema mal ein wenig auseinander. Stellen wir uns doch einmal folgende Fragen, um uns auf die richtige Spur zu bringen.
- Was ist ein IT-Notfall?
- Wie definiere ich eigentliche eine Störung und wann führt diese zu einem Notfall?
- Was tue ich als Unternehmen, wenn eine komplette IT-Abteilung ausfällt und ein IT-Notfall Eintritt?
- Was kann ich tun, damit ich dieses Szenario möglichst vermeiden kann?
- Was ist eigentlich mein Kern-Business und was nicht?
- Habe ich eigentlich jemals irgendwo fixiert, was das Kernbusiness ausmacht und dieses dann auch im Unternehmen publiziert?
- Wie stelle ich sicher, das bei einem Notfall auch aktiv gearbeitet werden kann?
- Welches Material muss ich WANN, WEM und WO zur Verfügung stellen, damit man es auch zeitnah nutzen kann?
- Wer benötigt möglicherweise Befugnisse und Berechtigungen über seinen eigentlichen Job hinaus?
- Kann ich als Manager einem Mitarbeiter für sensible Aufgaben vorübergehend mehr Kompetenzen einräumen, weil er sich im Thema mitunter besser auskennt als ich selbst?
Dies alles sind Fragen, die klar machen können was idealerweise in einem Notfallhandbuch geregelt werden sollte: die Organisatorischen Prozesse bei Eintritt, Lösung und Beendigung einer IT-Krise zu definieren!
Alles andere (Recovery-Prozeduren, Installationsanleitung) sind eigene Themen. Sie können im Notfallhandbuch als Handlungsmaßnahme referenziert sein, sind aber nicht automatisch Teil dessen.
Eine Ausnahme bildet der Geschäftsfortführungsplan. Dieser kann separiert oder auch Teil(en) des Notfallhandbuches sein.
Ein Betriebshandbuch wiederum erklärt lediglich eine Einzelanlage in Bedienung, Wartung etc. (die IT-Infrastruktur besteht aus deutlich mehr als nur einer Anlage).
Das wichtigste am Notfallhandbuch ist die Mitarbeit und die Aktualität. Eine aktive, regelmäßige Mitarbeit und Bewertung des Notfallhandbuches sind elementar wichtig.
Warum habe ich weiter oben angemerkt, das ein externer ein Notfallhandbuch häufig besser erstellen kann. Hier im folgendem ein Beispiel.
Es tritt ein bestätigter Notfall im Unternehmen ein: der Dateiserver ist Offline, welche elementar für die und die Logistik sind. Diese beiden Geschäftsbereiche sind das Kernbusiness! Von den 2 internen Admin’s ist einer im Urlaub, der andere Langzeiterkrankt – ein benachbarter IT-Dienstleister steht bereit und ist vor Ort. Im „Notfallhandbuch“ steht geschrieben: Fileserver 1 (SRVFS01) wieder einschalten. Toll, doch….
- Finde ich den Server im Serverraum A oder B
- In welchem Rack
- Ist der überhaupt physisch (wenn nicht kommen x weitere Fragen auf mich zu)?
- Wie komme ich in den überhaupt in den Serverraum rein um den Powerknopf zu drücken?
- Das Rack ist abgeschlossen, wo ist der Schlüssel?
- Wen kann ich anrufen, wenn die Physik des Servers defekt ist (wo habe ich Wartung)?
Ergo: diese Dinge sind es, welche geregelt und dokumentiert sein müssen. Und das ist EIN Zweck des Notfallhandbuches, vieles weitere (organisatorische) gilt es zu dokumentieren. Anmerkung: wie der Server eingeschaltet wird, wie ein Backup wieder hergestellt wird regelt der Recoveryplan bzw. dessen Recovery-Prozedurbeschreibung denn der Mann der das tut ist vom Fach.
Häufig stellt man auch in den Unternehmen fest, das es keine sauberen Prozesse gibt, die das Business regeln. Diese sind dann auch häufig gar nicht oder unsauber dokumentiert. Ebenso gibt es keine klare Festlegung von Kern-, Management- & Unterstützungsprozessen (was auch ein eigenes Thema ist).
Ich hoffe, das ich in meinem Beitrag hier die eine oder andere Barriere im Kopf verständlich lösen konnte. Da ich ja meinen Hauptjob mit Docusnap mache, könnt ihr, liebe Leser, davon ausgehen das ich in Docusnap umfangreiche Implementierungen vorgenommen habe um die Erstellung und dynamische Aktualität eines Notfallhandbuches zu ermöglichen und dies für den Anwender einfach zu gestalten. Ich zeige euch gern wie ich das ganze umsetze, sprecht mich an!