Praktikable Notfallpläne haben Seltenheitswert

Die Katastophenplanung ist eine strategische Aufgabe

22.02.1991

Völlig ausschließen läßt sich die Katastrophe im Rechenzentrum nie. Und die Hoffnung, mit einem blauen Auge davonzukommen, wird meist enttäuscht - nicht selten wird der Ernstfall im RZ zum existenzbedrohenden Ernstfall für das ganze Unternehmen. Wo der tägliche Betrieb vom Funktionieren der DV abhängt, ist die Notfallplanung eine Aufgabe des Managements. Das aber ist in der Regel erschreckend ahnungslos.

An einem Freitagabend, es war der 8. Juli 1988, brach nach einer länger anhaltenden Trockenheit ein Wolkenbruch über die Stadt herein. Innerhalb von zwei Stunden fielen 50 Zentimeter Regen je Quadratzentimeter vom Himmel.

Von einem nahegelegenen Hügel stürzte ein reißender Strom herab. Nachdem die Stahltüren krachend nachgegeben hatten, drangen mit unvorstellbarer Kraft zirka 200 Kubikmeter Wasser vermischt mit Modder und Steinen in die unteren Räume des Hauses ein. Das Wasser hob den darüberliegenden Boden um 20 Zentimeter an, zerstörte zwei weitere Stahltüren, riß die Türrahmen heraus und stürzte in das Bandarchiv sowie in den Raum, der für das Kommunikationsequipment eingerichtet worden war.

Im Rechnerraum hielten sich nur zwei einsame Operatoren auf. Sie hatten zunächst nicht bemerkt, was sich draußen ereignete. Als das Wasserwarngerät hinter der zweiten Stahltür Alarm gab, war es bereits zu spät. Die Stahltür wurde eingedrückt und kam mit einem mächtigen Wasserschwall und ein paar Modem-Racks, die sich in der schlammigen Lawine wie große Steine ausnahmen, quer durch den Rechnerraum auf die Operatoren zugeschwemmt. Das Licht verlosch, und in der Dunkelheit ergoß sich das Wasser über die Stromanlage in den hinteren Maschinenraum, zerstörte den Schaltschrank, die Zugriffssteuereinheit und gelangte schließlich in das Papierlager.

Nachdem das Wasser den gesamten Boden mit einer zwanzig Zentimeter dicken Schlammschicht bedeckt hatte, trat das Feuerlöschsystem in Aktion, versprühte Halogengas und bemühte sich, durch fleißiges Bewässern, den Wasserstand noch zu erhöhen.

Seit Beginn der Katastrophe waren 15 Minuten vergangen.

Was in den folgenden Stunden geschah, rettete die Firma vor dem Untergang. Die Operatoren klingelten ihren Chef aus den Federn. Nach seiner Ankunft besprach er das Problem mit der Feuerwehr, die letztlich nichts tun konnte, da das Wasser schon wieder abgelaufen war. Übrig geblieben war eine zwanzig Zentimeter hohe Dreckschicht in den Rechnerräumen; die Produktion war ausgestiegen und guter Rat teuer.

Systeme nach drei Tagen wieder einsatzfähig

Schließlich erwischte der Produktionschef noch in der Nacht den befreundeten Leiter einer auf derartige Zwischenfalle spezialisierten Firma. Eine Stunde später waren zwei Spezialisten zur Stelle, die das Ausmaß der Schäden feststellten und schließlich erklärten, daß etwa 14 Tage nötig wären, um die Zerstörungen zu beseitigen. Blitzschnell wurde ein Krisenstab von verschlafenen Managern zusammengetrommelt und entschieden, daß alles Menschenmögliche getan werden solle, um die Produktion so schnell wie möglich wieder auf die Beine zu bringen. Mittlerweile waren etwa 80 Minuten vergangen, seit das Wasser zum Stillstand gekommen war.

In den folgenden Stunden gab jeder der Beteiligten sein Bestes, und alle zusammen erbrachten eine großartige Leistung. Innerhalb von Stunden war ein Notstromaggregat beschafft und installiert. Währenddessen bemühte man sich, das Wasser und den Schlamm zu beseitigen. Die Räume wurden gesäubert, es wurde repariert und getestet, dann wurden die Komponenten angeschaltet. In den frühen Stunden des Samstagmorgens funktionierte bereits die Beleuchtung wieder.

Die Anwender wurden eingeladen sich den Schaden anzusehen und um Verständnis für den Produktionsausfall gebeten. Eine Pressemeldung ging an die örtlichen Medien. Am Sonntag schließlich, nachdem alles gereinigt war, konnte eine völlig übermüdete Mannschaft die CPUs anschalten, die glücklicherweise von der Überschwemmung nicht betroffen waren. Drei Tage später waren alle Systeme wieder voll einsatzfähig. Viereinhalb Tage nach der Katastrophe lief die Produktion wieder an.

Der geschilderte Fall, der sich wirklich ereignet hat, ging noch glimpflich aus. In einer anderen Branche, etwa bei einem Flugunternehmen, einer Bank oder einer Versicherung wären die Folgen für das tägliche Geschäft sicher gravierender gewesen. Ähnliches gilt bei einem Just-inTime-arbeitenden Betrieb. Ein Systemausfall in der geschilderten Dimension ist in diesen Branchen nicht nur ein Problem der Datenverarbeiter.

Bei einem Airliner beispielsweise bedeuten fünf Tage Systemausfall einen gravierenden Umsatz- und Kundenausfall und gegebenenfalls weitere Auswirkungen auf zukünftige Geschäfte. Bei Just-in-Time-Fertigern gerät das gesamte logistische System durcheinander; von den Auswirkungen sind nicht nur die Kunden betroffen, die auf pünktliche Lieferung angewiesen sind, sondern auch Materialbestände, Transportkosten etc.

Die Beispiele zeigen: Die Katastrophenvorsorge ist nicht mehr nur eine Angelegenheit der Datenverarbeiter, sondern ein strategisches Problem, das die Geschäftsleitung angeht.

Dennoch hat bis heute manch ein Top-Manager keine Ahnung davon oder er verdrängt das Problem einfach.

Kaum die Hälfte der großen Firmen und Institutionen hat auch nur einen Katastrophenplan und nur ein Viertel von diesen glaubt, daß er im Notfall auch funktioniert. Das heißt, daß nahezu drei Viertel der Unternehmen, die über einen solchen Plan verfügen, wissen, daß er im Notfall nicht durchführbar sein wird. Dies ergab eine Studie des Amdahl-Research-Instituts, London.

Es ist immer wieder erstaunlich, mit welcher Ignoranz und Lässigkeit viele Unternehmen das Problem einfach verdrängen, und dies in einer Situation, in der sie durch Distributed Processing, steigende Komplexität der Systeme und zunehmende Bedeutung der Heart-of- business-Systeme, immer anfälliger für eventuelle Katastrophen werden.

Die Absicherung des wirtschaftlichen Wohlergehens einer Firma ist eine Angelegenheit des Top-Managements; den Informationsverarbeitern kann hier nur eine Hilfsfunktion zugewiesen werden.