Was ist nun zu tun?

Wer sich durch Dokumente und Normen gelesen hat, wird unschwer erkennen, dass eine Lösung nicht einfach so auf der Hand liegt. In den letzten Jahren haben sich jedoch aufgrund von technischen Vorgaben und finanziellen Einschränkungen verschiedene Modelle etabliert.

Mögliche Konsequenzen…

Es lässt sich unschwer feststellen, dass innerhalb des IT-Betriebs Disaster Recovery und Business Continuity sehr nahe beieinander liegen und voneinander abhängig sind. Dies wiederum führt zur Konsequenz, dass bereits die Konzeption von  normalen Bedienungen auf einen allfälligen Zwischenfall ausgelegt werden muss.

Dies wiederum hat zur Folge, dass eine mögliche Lösung auch weitere Synergien für die IT wie dezentrales Backup, redundante VPN-Terminierungen oder Auslagerung von Teilen der IT zur Folge haben kann. Dies aufgrund der Tatsache, dass unter Umständen eine Business-Continuity-Lokation umfangreicher ausgestattet ist, als das eigene Rechenzentrum. Auch die Nutzung geografisch verteilter IT-Mitarbeiter ("Remote Hands") kann sich dabei als Vorteil herausstellen.

… und Lösungsansätze

Ein möglicher Ansatz ist die konsequente Trennung von "Primary Site" und "Second Site".

Dabei wird eine Primary Site mit allen notwendigen Redundanzen versehen und eine Second Site mit den nur für den Notfall notwendigen Systemen und Anbindungen ausgerüstet. So erzwingt zum Beispiel der Ausfall einer Datenleitung nicht gleich einen kompletten Failover von einem Rechenzentrum in ein anderes. Dabei darf durchaus in Kauf genommen werden, dass in der Second Site nicht alle Dienste wie zum Beispiel das Monitoring redundant vorhanden sind. Somit sind in der Second Site keine für den normalen Betrieb aktiven Systeme vorhanden.

Natürlich sollte man mit der Second Site auch Synergien anstreben, und diese zum Beispiel für die Aufbewahrung von Backups nutzen. Was ebenfalls bei der Planung und dem Betrieb einer Second Site nicht vergessen werden darf, ist der Mehraufwand für Tests und die Dokumentation sowie Schulung weiterer und neuer Prozesse sowie der Mehraufwand für die Logistik, da zum Beispiel Ersatzteile an mehreren Orten gelagert werden müssen und längere Anfahrtswege nötig sind.

Andere Modelle sind das Auslagern von Teilen der eigenen IT. Dies kann dann attraktiv sein, wenn das eigene Rechenzentrum nur bedingt alle gestellten Anforderungen an die IT erfüllen kann. So profitiert man mit der Auslagerung unter Umständen von Zertifizierungen, Prozessen und aber auch infrastrukturellen Diensten, welche der IT im Falle einer Auslagerung eine höhere Verfügbarkeit und Sicherheit gewähren können.

Bei der Auslagerung profitiert man typischerweise von Komponenten, die beim Dienstleister bereits redundant vorhanden sind, sowie von Personal, das vom eigenen Betrieb unabhängig ist, welches in einem Desasterfall unter Umständen ebenfalls in Mitleidenschaft gezogen werden könnte. Auch besteht die Möglichkeit, in einer solchen Konstellation das eigene RZ als Notfall-RZ einzusetzen und im Falle des Ausfalls des IT-Dienstleisters aus den eigenen vier Wänden die IT-Leistung wieder zu erbringen.