Vorlagen für Business-Continuity- und Disaster-Recovery-Tests

Erfahren Sie, wie man einen Business-Continuity-Test durchführt, und auf was man dabei achten sollte.

Pläne für Business Continuity (BC) und Disaster Recovery (DR) sind ohne vorherige Tests ziemlich nutzlos. Glücklicherweise gibt es dafür eine ganze Reihe von Tests – von sehr einfach bis hochkomplex. Welche Tests auch immer Sie nutzen: Der entscheidende Schlüssel zum Erfolg eines Business-Continuity-Tests ist es, den Test als Teil des Business-Continuity/Disaster-Recovery-Management-Prozesses zu integrieren.

Grundsätzlich sind Tests für viele Unternehmen eine große Herausforderung. Sie erfordern Management-Unterstützung, Zeit für die Vorbereitung und Durchführung, eine solide Finanzierung, die sorgfältige Planung sowie einen strukturierten Prozess von Pre-Tests über den eigentlichen Test bis zur Testauswertung.

Um Ihnen zu zeigen, wie man solche Tests entwickelt und ausführt, hat SearchDisasterRecovery.com eine englische Vorlage und einen Leitfaden für Business-Continuity-Tests erstellt. In dieser Anleitung erfahren Sie, wie man einen Business-Continuity-Test durchführt, wer dabei mitmachen sollte und wie man eine erfolgreiche BC/DR-Test-Strategie aufbaut.

Einführung in Business-Continuity-Tests

In Business-Continuity-Tests werden drei grundlegende Testarten verwendet: Die Planbewertung, die sogenannten Tabletop-Tests sowie Simulationstests. Betrachten wir jeden genauer:

  • Bei der Planbewertung diskutieren die Besitzer eines Business Continuity/Disaster-Recovery-Plans und die Teams den BC/DR-Plan. Sie suchen den Plan im Detail nach fehlende Elementen und Inkonsistenzen ab.
  • Im Tabletop-Test gehen die Teilnehmer in einem Raum Schritt-für-Schritt alle geplanten Aktivitäten durch. Tabletop-Übungen können sehr effektiv zeigen, ob Teammitglieder ihre Aufgaben im Notfall kennen. In diesen Tests können Dokumentationsfehler, fehlende Informationen und Unstimmigkeiten über Business-Continuity-Management (BCM)-Pläne festgestellt werden.
  • Um zu prüfen, ob BCM-Verfahren und -Ressourcen in realistischeren Situationen funktionieren, sollte ein Simulationstest durchgeführt werden. Er nutzt etablierte Business-Continuity-Ressourcen, wie zum Beispiel Recovery-Orte, Backup-Systeme und andere spezialisierte IT-Services. Teams können auch an alternative Standorte geschickt werden, um Technologien und Business-Funktionen dort neu zu starten. Zudem können Simulationstests auch Personalprobleme aufdecken – beispielsweise kann Personal für bestimmte Aufgaben fehlen. Im Endeffekt ist eine Simulation ein „Full-Scale-Test”, der in der Realität keinerlei negative Auswirkungen hat. Die Verwendung von Szenarien in Simulationen wird dabei dringend empfohlen.

So nutzen Sie unser Template für Business Continuity Tests

Unsere Vorlage unterstützt Sie bei der Vorbereitung und Ausführung eines Business-Continuity-Tests. Das Template gibt Ihnen ein Test-Framework zur Hand, ohne ein spezifisches Planformat vorauszusetzen. Alle Phasen eines Tests – Pre-Test-Planung, Testdurchführung, Post-Test-Auswertung und Abschlussbericht – werden von der Vorlage unterstützt. Die Durchführung des eigentlichen Tests einschließlich Teststruktur, Szenarien, Skripts und Zusatzaktivitäten (zum Beispiel Audio-und Videoprogramme) liegt ganz in Ihrem Ermessen.

Wenn Sie unsere Vorlage nutzen, sollten Sie allen vorgegebenen Schritten folgen: Pre-Test-Planung, Durchführung des Tests, Auswahl und Schulung der Testteilnehmer, Durchführung von Post-Test-Befragungen und die Vorbereitung von abschließenden, zusammenfassenden Berichten.

Die wichtigsten Begriffe zum Business-Continuity-Test

Im Folgenden erklären wir die wichtigsten Begriffe zum Business-Continuity-Test, die in der Vorlage verwendet werden:

Begriff

Definition

Design Team

Das Design-Team entwickelt den Test von Anfang bis Ende. Die Mitglieder des Teams sollten das gesamte Unternehmen sehr gut kennen. Sie sollten auch detaillierte Kenntnisse in ihrem eigenen Bereich und über ihre Abteilung haben. Das Team umfasst in der Regel drei bis sieben Mitglieder, wenn nötig auch mehr. Das Design-Team ist:

  • Kreativ
  • Unter Druck funktional
  • Fähig, Zeitpläne einzuhalten
  • Detail-orientiert
  • Bereit, mit Herausforderungen umzugehen
  • Bereit, sensible Informationen für sich zu behalten
  • Nicht Testteilnehmer

Orientierungs-Test

  • Führt die Teilnehmer in die Pläne und Verfahren ein
  • Führt neue Pläne ein oder revidiert die alten Pläne
  • Erfordert keine Erfahrung im Vorfeld
  • Hilft neuen Mitarbeiter oder Führungskräften, sich zurecht zu finden
  • Planungszyklus: ein Monat
  • Testzeit : 60 bis 90 Minuten

Übung

  • Test der einzelnen Notfallfunktionen
  • Berücksichtigt Antworten aus der Praxis
  • Durchführen oder Testen unter realistischen Bedingungen
  • Bezieht alle Ebenen der Antwortenden ein
  • Planungszyklus: ein Monat
  • Testzeit : 10 bis 60 Minuten
  • Beispiele: Brandschutzübung, Radio-Test,Tornado-Test, Erdbebentest

Tabletop Test

  • In der Basisversion wird versucht, Probleme in einer Gruppe per Brainstorming zu lösen
  • Der erweiterte Tabletop Test führt Nachrichten und Test-Assistenten ein, die Fragen beantworten können
  • Ermöglicht eine realistischere Erfahrung
  • Planungszyklus: zwei bis drei Monate
  • Testzeit : 90 bis 120 Minuten
  • Befragungszeit: 30 Minuten

Funktionstest

  • Bewertet die Verteilung von Ressourcen und Arbeitskraft
  • Bewertet die Kommunikation zwischen verschiedenen Gruppen
  • Bewertet die Eignung der derzeitigen Verfahren und Richtlinien
  • Die Teilnehmer führen reale Aktivitäten aus
  • Beinhaltet mehr Teilnehmer: Simulatoren, Gutachter, größere Design-Teams
  • Führt fortgeschrittene Message-Technologien und andere Medien ein
  • Testzeit : 90 Minuten bis vier Stunden
  • Planungszyklus: drei bis sechs Monate

Großversuch (Full-Scale Test)

  • Bewertet die Funktionsfähigkeit der Systeme in interaktiver Weise über einen längeren Zeitraum
  • Präsentiert komplexe und detaillierte Ereignisse in Echtzeit
  • Mobilisiert Personal, Ressourcen, Notfallteams und Ausrüstung
  • Kann teuer sein; kann sich störend auf den normalen Betrieb auswirken
  • Testzeit: zwei bis acht Stunden
  • Planungszyklus: mindestens vier Monate

Effektive Test-Strategien für Business Continuity und Disaster Recovery

Die vorgestellte Vorlage für Business-Continuity-Tests kann Ihnen helfen, Business Continuity und Disaster Recovery-Pläne zu verbessern. Aber egal, wie oft Sie Ihre BC/DR-Pläne testen – wenn die Realität zuschlägt, werden Ihre Maßnahmen wahrscheinlich anders aussehen als in den Tests.

Zu den Schlüsselstrategien für den Test gehören folgende Punkte:

  • Beginnen Sie simpel;
  • Steigern Sie den Schwierigkeitsgrad langsam;
  • Integrieren Sie Lieferanten und Verantwortliche in die Tests;
  • Machen Sie die Tests so schwer, dass es unmöglich wird, sie erfolgreich zu bestehen;
  • Führen Sie Überraschungstests durch.

Zu Beginn eines Test-Trainingsprogramms sollten Sie mit Planbewertungen und Tabletops beginnen. Dies wird den Mitarbeiter helfen, sich an den Testprozess zu gewöhnen. Wenn sie sich im Verlauf des Tests verbessern, erhöhen Sie dessen Komplexität. 

Denken Sie daran: Schlägt ein Test fehl, so ist das kein Fehler. Einen Fehlschlag können Sie immer als Erfolg interpretieren, denn es ist weit besser, Systeme und Verfahren, die ausfallen können, im Test genau zu identifizieren und den Schaden im Test zu beheben, bevor ein echtes Ereignis eintritt. Schließlich ist ein echter Test der Beginn einer überraschenden Störung. Diese Störung „testet” dann wirklich, wie gut ein Unternehmen vorbereitet ist, einen realen Störfall zu meisten.

Die primäre Motivation für die Durchführung von Tests ist es, Mängel in BC/DR-Plänen festzustellen. Erfolgreiche Tests decken im Idealfall immer Probleme auf und dokumentieren sie. Tests, die „erfolgreich” zu sein scheinen, und keine Probleme ans Tageslicht bringen, sollten Ihnen grundsätzlich suspekt sein. Schließlich geben Ihnen Tests die Gelegenheit, Probleme zu beheben, bevor ein Unglück geschieht.

Folgen Sie SearchStorage.de auch auf Facebook, Twitter und Google+!

Erfahren Sie mehr über Disaster Recovery

ComputerWeekly.de
Close