Best Practices oder Ressourcen für die Entwicklung eines Notfallwiederherstellungsplans? [geschlossen]

Ich wurde beauftragt, ein Projekt zur Aktualisierung eines alten und etwas einseitigen Notfall-Wiederherstellungsplans zu leiten. Im Moment versuchen wir nur, die IT-Seite von DR zu klären. Als sie dies das letzte Mal taten, legten sie ihren Umfang fest, indem sie eine einzige Katastrophe (das überflutete Rechenzentrum) zusammenstellten und diese unter Ausschluss aller anderen Katastrophenarten planten. Ich würde gerne einen runderen Ansatz wählen. Ich weiß, dass dies ein gelöstes Problem ist, andere Organisationen haben DR-Pläne geschrieben.

Unser Plan ist es, unseren IT-DR-Plan zu übernehmen und ihn fortzusetzen und zu sagen: "Hey, das ist, was wir in einem DR-Plan für die IT wollen, passt das zu dem, was der Rest der Universität tut? Gibt es wiederhergestellte Service-Prioritäten für Sie? möchte geändert werden? " Wir haben eine ziemlich gute Idee, was der Rest des Plans ist, und wir gehen davon aus, dass dies gut angeht.

Was ich suche, ist eine Anleitung zum Umfang eines DR-Plans und zu den Fragen, über die ich nachdenken sollte. Haben Sie Lieblingsressourcen, -bücher und -schulungen, die sich auf die Entwicklung von DR-Plänen beziehen?

Eine ausgezeichnete Informationsquelle ist das Disaster Recovery Journal ( ungefähr ).

Zu den verfügbaren Community-Ressourcen gehört der aktuelle Entwurf des GAP- Dokuments (General Accepted Practices) , das einen hervorragenden Überblick über den Prozess und die zu erbringenden Leistungen bietet, die einen soliden Geschäftskontinuitätsplan und -prozess darstellen. Ebenfalls erhältlich sind einige White Papers verschiedene DR / BC Themen.

Der Prozess wirkt entmutigend, aber wenn Sie systematisch vorgehen und einen guten Überblick darüber haben, wo Sie landen möchten (wie das DRJ GAP-Dokument), können Sie sicherstellen, dass Sie die investierte Zeit optimieren und den Wert des Endprodukts maximieren.

Ich finde ihre vierteljährliche Veröffentlichung auch interessant und informativ ( abonnieren ).

Stellen Sie sicher, dass Sie einen Notfallkontaktplan haben. aka ein Rückrufplan

Es sollte wie ein Baum aussehen und zeigen, wer wen kontaktiert. Am Ende einer Zweigstelle sollte die letzte Person die erste anrufen und jeden melden, der nicht kontaktiert werden konnte.

(Dies kann über die Personalabteilung koordiniert und für jede Art von Katastrophe verwendet werden.)

Wenn wir unsere Ideen hinzufügen, können wir aus diesem Beitrag ein schönes Wiki erstellen, sobald jeder seine eigenen Ideen hinzugefügt hat. Ich verstehe, es gibt eine Menge zu folgen, aber einige von uns haben spezifische Prioritäten, wenn es um Erholung geht. Um zu beginnen, hier ist meins:

Stellen Sie sicher, dass Sie über eine Offline- / Remote-Dokumentation Ihres Netzwerks verfügen

Bei DR sind die Grundvoraussetzungen Ihre RTOs (Recovery Time Objectives) und RPOs (Recovery Point Objectives), die in etwa bedeuten: "Wie viel Zeit ist akzeptabel, um sie zurückzugewinnen, und wie viel Daten können wir uns leisten, um sie zu verlieren". In einer idealen Welt wären die Antworten "keine und keine", aber ein DR-Szenario ist ein außergewöhnlicher Umstand. Diese sollten eigentlich von Ihren Kunden gesteuert werden. Da Sie jedoch vom IT-Standpunkt aus starten, können Sie die bestmöglichen Vermutungen anstellen, sind jedoch bereit, die Einstellungen nach Bedarf nach oben oder unten anzupassen. Es ist gut, so nahe wie möglich an "none and none" heranzukommen, aber Sie müssen in der Lage sein zu erkennen, wann der Punkt mit abnehmenden Renditen eintritt.

Diese beiden Faktoren können zu verschiedenen Jahreszeiten und auf verschiedenen Systemen unterschiedlich sein.

Ich mag den runderen Ansatz; Es ist verlockend, die Ereignisse aufzulisten, die zu einem DR-Szenario führen können, diese gehören jedoch eher zu einer Risikoanalyse / Risikominderung. Bei der DR ist der Vorfall bereits eingetreten, und Einzelheiten zu den Vorfällen sind weniger relevant (mit Ausnahme der möglichen Auswirkungen auf die Verfügbarkeit von DR-Einrichtungen). Wenn Sie einen Server verlieren, müssen Sie ihn zurückholen, unabhängig davon, ob er vom Blitz getroffen, versehentlich formatiert oder was auch immer wurde. Ein Ansatz, der sich auf die Größenordnung und Ausbreitung der Katastrophe konzentriert, führt eher zu Ergebnissen.

Ein Ansatz für Kunden, die sich nur ungern engagieren, besteht darin, ihnen DR-Fragen aus nicht-IT-Sicht zu stellen. Ein Beispiel hierfür ist die Frage, was ihre Pläne sind, wenn alle ihre Akten in Flammen aufgehen. Dies kann helfen, sie stärker in die allgemeine DR-Sache einzubeziehen, und kann nützliche Informationen in Ihre eigenen Pläne einfließen lassen.

Schließlich ist das regelmäßige Testen Ihres Plans entscheidend für den Erfolg. Es ist nicht gut, einen schönen DR-Plan zu haben, der auf dem Papier gut aussieht, aber seine Ziele nicht erfüllt.

Eigentlich ist das "Single Incident" -Entwicklungsmodell als erster Schritt eine gute Idee. Ein Grund dafür ist, dass die Planungsübung realistischer und fokussierter wird. Planen Sie für die Flut den ganzen Weg. Nehmen Sie dann einen anderen Vorfall an (z. B. einen langfristigen Stromausfall), wenden Sie diesen Plan darauf an und beheben Sie, was kaputt geht. Nach einigen Iterationen sollte der Plan relativ robust sein.

Einige Gedanken ... - Achten Sie darauf, nicht verfügbare Personen zu berücksichtigen. Bei Hochwasser kann nicht davon ausgegangen werden, dass alle relevanten Mitarbeiter verfügbar sind. Jemand könnte im Urlaub oder verletzt sein oder mit seiner Familie zu tun haben.
- Kommunikationsprobleme und -schwächen einplanen. Haben Sie mehrere Zahlen und mehrere Modi.
- Der DR-Plan benötigt eine Befehlskette. Zu wissen, wer Entscheidungen trifft, ist entscheidend.
- Der Plan muss weit verbreitet sein, auch außerhalb des Standorts und außerhalb des Stromnetzes. Es muss während der Katastrophe zugänglich sein!

Wo ich arbeite, war ich in den letzten zwei Jahren jeweils an der Durchführung eines groß angelegten DR-Tests beteiligt. Wir haben festgestellt, dass das Testen unserer Dienste, Mitarbeiter und Prozesse in "realistischen" Situationen nützlich war. Einige Lektionen gelernt (vielleicht offensichtlich), in der Hoffnung, Sie finden sie nützlich:

• Ungetestete Dienste weisen trotz der Angaben in ihrer DR-Dokumentation in der Regel implizite, katastrophenauslösende Abhängigkeiten auf. Das Ausschütteln mit einem oder zwei realistischen Tests ist eine nützliche und messbare Ausgabe eines DR-Vorbereitungsprozesses.
• Ungetestete Leute neigen dazu zu glauben, dass ihre Systeme in Ordnung sind und sie wissen, was in einer Katastrophensituation zu tun ist. Schütteln sie oben mit einem realistischen Test oder zwei ist groß.
• Nicht getestete Prozesse brechen in tatsächlichen Notfallsituationen schnell auseinander. Insbesondere konzentrierten sich komplexe Eskalationsprozesse auf spektakuläre Weise auf die Information des oberen Managements. Leichte Prozesse, die auf die Bedürfnisse des Betriebspersonals und anderer Einsatzkräfte ausgerichtet sind, zentrale Informationsquellen über den sich ausbreitenden Notfall, die explizite Übertragung von Verantwortung und alltägliche Notfallmaßnahmen funktionieren am besten.

Ich vermute, ich gehe davon aus, dass Sie versuchen sollten, nicht alles an Ihrem DR-Planungsprozess theoretisch zu machen. Bitten Sie um die Erlaubnis, Dinge tatsächlich zu zerstören, und erhalten Sie so harte Daten über die Bereitschaft Ihres Unternehmens. Das erfordert natürlich ernsthafte Unterstützung durch das Management, aber es kann sich wunderbar darauf konzentrieren, dass das Unternehmen ein paar Tage damit verbringt, wirklich das Schlimmste zu proben.

Cian

Es gibt verschiedene Standards des British Standards Institute (BSi), die sich auf Kontinuitätsmanagement und Disaster Recovery konzentrieren.

• BS 25999-1: 2006 Business Continuity Management, Teil 1: Verhaltenskodex
• BS 25999-2: 2007 Business Continuity Management. Spezifikation
• BS 25777: 2008 Kontinuitätsmanagement für Informations- und Kommunikationstechnologie. Verhaltenskodex

Es mag naheliegend erscheinen, aber um mit der obigen Offsite-Dokumentation Schritt zu halten, stellen Sie sicher, dass Sie Offsite-Sicherungen (vorzugsweise außerhalb der Region) haben. Dies kann ein Online-Speicherdienst oder ein Ort sein, an dem Sie Bänder ablegen können.

Ich sage am liebsten außerhalb der Region, weil ich aus einem Gebiet komme, in dem es nicht alljährlich viele Naturkatastrophen gibt, aber wenn es eine gibt, handelt es sich um eine regionale Katastrophe mit Massenvernichtung (Erdbeben, Vulkane). Es ist nur gut, Ihr Backup in einem Safe bei der Bank zu haben, bis Ihre Bank unter flüssigem heißem Magma steht (/ Dr. Evil Voice).

Etwas, worüber ich gelesen habe, sind Agenturen, die sich die Kosten für die Wartung einer Hot-Site teilen, wenn die große betroffen ist. Sie verabschieden Pläne für die Wiederherstellung der für den Hot-Site-Betrieb wichtigen Aufgaben beider Unternehmen mithilfe von Virtualisierung und dergleichen und teilen dann das Personal auf der Ebene, in der sichergestellt wird, dass alle Lichter blinken. Nur ein Gedanke.

Für Bücher gibt es Disaster Recovery Planning von Jon William Toigo, jetzt in der 3. Ausgabe, mit einem Blog (+ Buch) in der 4. Ausgabe am Horizont.

Laura,

Hier ist ein Link von SQLServerPedia, der die Grundlagen von DR vermittelt.

http://sqlserverpedia.com/blog/sql-server-backup-and-restore/disaster-recovery-basics-tutorial/

Lesen Sie auch "Business Continuity"