Wider die gefährliche Lücke zwischen DR-Theorie und -Praxis

Damit die IT-Notfallplanung klappt - Tipps für ein Disaster Recovery

Seite: 2/2

Firmen zum Thema

Erster Schritt: Die Kosten des Ausfalls der IT-Systeme im Fall eines Disaster-Recovery (DR, IT-Notfall) genau bestimmen:

Neben den schon genannten Umsatzausfällen sollten dabei unter anderem 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 zum Beispiel 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 Service-Ausfall 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.

Zweiter Schritt: Die technischen Möglichkeiten und Kosten der DR-Lösung bestimmen:

Zur Vorsorge für den Katastrophenfalls hat der IT- und Kommunikationsdienstleister Interoute ein Metamodell entwickelt. Es kann helfen, DR-Wissenslücken zu schließen.
Zur Vorsorge für den Katastrophenfalls hat der IT- und Kommunikationsdienstleister Interoute ein Metamodell entwickelt. Es kann helfen, DR-Wissenslücken zu schließen.
(Bild: Interoute)
Die mögliche Realisierung der Zielvorgaben für RPO und RTO hängen auch von technischen Gegebenheiten ab. Daher sollten zunächst die Abhängigkeiten zwischen geschäftskritischen Anwendungen, Betriebssystemen, Datenbanken sowie Middleware untersucht werden. Leitfragen sind hier unter anderem:

  • Können Daten auf Ebene der Storage-Systeme repliziert werden? Gibt es Schnittstellen zwischen Betriebssystem und Storage-Systemen, um DR-Maßnahmen zu automatisieren?
  • Bei vielen Open-Source-Produkten, wie MySQL, ist es nicht ohne weiteres möglich, RPO- und RTO-Vorgaben von = 0 zu realisieren. Werden kommerzielle Erweiterungen (also Firmen, die technische oder Service-Erweiterungen für Open Source Produkte anbieten) nötig, die einem ursprünglichen Einsatzziel von Open Source entgegenstehen?
  • Inwieweit kann Virtualisierung genutzt werden, um automatisierte Failover-Szenarien zu realisieren? Wie weit sind die Disaster-Recovery-Standorte voneinander entfernt? Physikalisch sind nur bestimmte Latenzen auf gewissen Distanzen zwischen Rechenzentren möglich.
  • Welche Schnittstellen bestehen zu Cloud-Diensten? Gibt es eine performante Netzwerkverbindung zu Cloud-Diensten, um Failover-Szenarien zu realisieren?

Je genauer diese Fragen beantwortet werden, desto leichter fällt das Design einer technisch guten und wirtschaftlich ausgewogenen DR-Lösung.

Der Autor:

Dr. André Triebel ist Business Solutions Consultant bei der Interoute Germany GmbH.

(ID:37650820)