Startseite > Datacenter & Verkabelung > IT-Notfallplan: Lücke zwischen Theorie und Praxis

Disaster-Recovery

IT-Notfallplan: Lücke zwischen Theorie und Praxis

27. Februar 2013, 12:29 Uhr | Ralf Ladner

Disaster-Recovery (DR, IT-Notfallplanung) hilft Unternehmen im Katastrophenfall dabei, geschäftskritische Daten wiederherzustellen. Ziel ist es, Ausfallzeiten, die zu Umsatzeinbußen führen, zu verringern oder ganz zu verhindern. Allerdings erweist sich die Realisierung eines schlüssigen IT-Notfallplans als Herausforderung für viele Unternehmen. Geschäftskritische Prozesse sind zwar bekannt, welche IT-Systeme damit verbunden sind, aber selten. Die bei einer Katastrophe entstehenden Kosten sind ungewiss, ebenso wie der Preis und die technischen Randbedingungen der Einführung einer DR-Lösung. Was ist zu beachten, um die Lücke zwischen Theorie und Praxis zu schließen?

Die Einführung einer Disaster-Recovery-Lösung startet in der Theorie mit einer Business-Impact-Analyse (BIA), die nach geschäftskritischen Prozessen und Anwendungen im Unternehmen fragt. In der Analyse geht es darum zu definieren, welche maximale Ausfallzeit von IT-Systemen (RTO) und welcher maximale Datenverlust (RPO) nicht geschäftskritisch sind. Auf Basis dieser Werte können garantierte Verfügbarkeiten der IT bestimmt werden. Danach soll die Realisierung folgen. In der Praxis sind das aber nicht zwei Schritte, sondern bei guter Vorarbeit auf beiden Seiten viele Abstimmungsrunden, in denen Kunde und IT-Dienstleister eine technisch und kommerziell ausgewogene Lösung gemeinsam entwickeln. Die anfangs sehr hohen RTO- und RPO-Anforderungen des Anwenders und die Kosten für die technische Umsetzung haben dann eine vertretbare Balance gefunden. Um diesen Prozess zu verkürzen, und somit wertvolle Projektzeit und -kosten einzusparen, empfiehlt Interoute das folgende, allgemein akzeptierte Vorgehen:

Erster Schritt: Die Kosten des Ausfalls der IT-Systeme im DR-Fall genau bestimmen: Neben den schon genannten Umsatzausfällen sollten dabei unter anderem auch Reputationsschäden, verringerte Produktivität und Kosten der Wiederherstellung berücksichtigt werden. Drei Beispiele, die die Lücke zwischen Theorie und Praxis belegen soll:

Welche Umsatzausfälle sind bei einem Webshop zu erwarten? Diese lassen sich anhand von Umsatzzahlen der Vergangenheit recht konkret abschätzen.
Ab wann können Service-Level-Verträge (SLAs) mit Endkunden nicht mehr eingehalten werden? Neben Reputationsschäden können hier Kosten beispielsweise durch Vertragsstrafen entstehen.
Was kostet es, wenn eine Kernanwendung wie ein ERP-System ausfällt und eine interne Abteilung mit 100 Mitarbeitern nicht arbeiten kann? Diese Kosten lassen sich nicht so einfach abschätzen.

Die Auswirkungen „klassischer“ IT-Vorfälle sind aus Erfahrungswerten bekannt und durch den Ausfall von Einzelsystemen leichter überschaubar. Diese wertvollen Informationen können dafür verwendet werden, abzuschätzen, was größere Ausfälle bewirken. Dabei sollte erfasst werden, was ein Serviceausfall für betroffene Personen, Prozesse und Kunden auf der „Zeitschiene“ bedeuten würde. Was sind die Auswirkungen von beispielsweise einer Stunde Nichterreichbarkeit einer Website, von vier Stunden Unterbrechung eines Produktionsprozesses X, oder von einem 24-stündigen Bruch eines SLA mit Endkunde Y? Die Kosten summieren sich entsprechend.