Betriebskontinuitätsplan (Business Continuity Plan, BCP) - Notfallwiederherstellung von Workloads auf AWS: Wiederherstellung in der Cloud

Betriebskontinuitätsplan (Business Continuity Plan, BCP)

Ihr Notfallwiederherstellungsplan sollte eine Teilmenge des Betriebskontinuitätsplans (BCP) Ihres Unternehmens darstellen. Er sollte kein eigenständiges Dokument sein. Es hat keinen Sinn, aggressive Notfallwiederherstellungsziele für die Wiederherstellung eines Workloads zu verfolgen, wenn die Geschäftsziele dieses Workloads nicht erreicht werden können, weil sich die Katastrophe auf andere Elemente Ihres Unternehmens als Ihren Workload auswirkt. Ein Erdbeben könnte Sie beispielsweise daran hindern, Produkte zu transportieren, die Sie über Ihre eCommerce-Anwendung gekauft haben - selbst wenn Ihr Workload durch eine effektive Notfallwiederherstellung funktionsfähig bleibt, muss Ihr BCP die Transportanforderungen berücksichtigen. Ihre DR-Strategie sollte auf geschäftlichen Anforderungen, Prioritäten und dem Kontext basieren.

Analyse der geschäftlichen Auswirkungen und Risikobewertung

Eine Analyse der geschäftlichen Auswirkungen sollte die geschäftlichen Auswirkungen einer Unterbrechung Ihrer Workloads quantifizieren. Sie sollte ermitteln, welche Auswirkungen es auf interne und externe Kunden hat, wenn Sie Ihre Workloads nicht nutzen können, und wie sich dies auf Ihr Geschäft auswirkt. Die Analyse sollte Ihnen dabei helfen, zu bestimmen, wie schnell der Workload verfügbar gemacht werden muss und wie viel Datenverlust toleriert werden kann. Die Wahrscheinlichkeit einer Unterbrechung und die Kosten der Wiederherstellung sind Schlüsselfaktoren, die dabei helfen, den geschäftlichen Nutzen einer Notfallwiederherstellung für einen Workload zu ermitteln.

Die geschäftlichen Auswirkungen können zeitabhängig sein. Sie sollten dies bei Ihrer Notfallwiederherstellungsplanung berücksichtigen. Eine Unterbrechung Ihres Gehaltsabrechnungssystems kann beispielsweise kurz vor der Auszahlung der Löhne und Gehälter sehr große Auswirkungen auf das Unternehmen haben, während sie kurz nach der Auszahlung der Löhne und Gehälter nur noch geringe Auswirkungen haben kann.

Eine Risikobewertung der Art der Katastrophe und der geografischen Auswirkungen zusammen mit einem Überblick über die technische Implementierung Ihres Workloads bestimmt die Wahrscheinlichkeit einer Unterbrechung für jede Art von Katastrophe.

Für sehr kritische Workloads können Sie eine hohe Verfügbarkeit über mehrere Regionen hinweg mit kontinuierlichen Backups in Betracht ziehen, um die geschäftlichen Auswirkungen zu minimieren. Bei weniger kritischen Workloads kann es eine gute Strategie sein, überhaupt keine Notfallwiederherstellung einzurichten. Und für einige Katastrophenszenarien ist es sinnvoll, keine Strategie für die Notfallwiederherstellung zu haben, da die Wahrscheinlichkeit des Auftretens gering ist. Denken Sie daran, dass Availability Zones innerhalb einer AWS-Region bereits mit einem sinnvollen Abstand zueinander und einer sorgfältigen Planung des Standorts konzipiert sind, sodass die meisten Katastrophen nur eine Zone betreffen sollten. Daher kann eine Multi-AZ-Architektur innerhalb einer AWS-Region Ihre Anforderungen an die Risikominderung bereits erfüllen.

Die Kosten der Optionen für die Notfallwiederherstellung sollten evaluiert werden, um sicherzustellen, dass die Notfallwiederherstellungsstrategie unter Berücksichtigung der geschäftlichen Auswirkungen und des Risikos das richtige Maß an geschäftlichem Nutzen bietet.

Mit all diesen Informationen können Sie die Bedrohung, das Risiko, die Auswirkungen und die Kosten der verschiedenen Katastrophenszenarien und die damit verbundenen Wiederherstellungsoptionen dokumentieren. Anhand dieser Informationen sollten Sie Ihre Wiederherstellungsziele für jeden Ihrer Workloads festlegen.

Wiederherstellungsziele (RTO und RPO)

Bei der Erstellung einer Strategie für die Notfallwiederherstellung (DR) planen Unternehmen in der Regel das Recovery Time Objective (RTO) und das Recovery Point Objective (RPO).


        Die Abbildung zeigt die Beziehung zwischen den Wiederherstellungszielen.

Abbildung 3 - Wiederherstellungsziele

Recovery Time Objective (RTO) ist die maximal akzeptable Verzögerung zwischen der Unterbrechung des Service und der Wiederherstellung des Service. Dieses Ziel bestimmt, welches Zeitfenster als akzeptabel angesehen wird, wenn der Service nicht verfügbar ist, und wird von der Organisation festgelegt.

In diesem Text werden im Wesentlichen vier DR-Strategien erörtert: Backup und Wiederherstellung, Pilot Light, Warm Standby und Multi-Site Active/Active (siehe Optionen für die Notfallwiederherstellung in der Cloud). Im folgenden Diagramm hat das Unternehmen sein maximal zulässiges RTO sowie die Höchstgrenze der Ausgaben für seine Service-Wiederherstellungsstrategie festgelegt. Angesichts der Ziele des Unternehmens erfüllen die DR-Strategien Pilot Light oder Warm Standby sowohl die RTO- als auch die Kostenkriterien.


        Die Grafik zeigt das Recovery Time Objective als Verhältnis zwischen Kosten und Komplexität und der Dauer der Service-Unterbrechung.

Abbildung 4 - Recovery Time Objective

Recovery Point Objective (RPO) ist die maximal akzeptable Zeitspanne seit dem letzten Datenwiederherstellungspunkt. Dieses Ziel legt fest, was als akzeptabler Datenverlust zwischen dem letzten Wiederherstellungspunkt und der Unterbrechung des Service gilt, und wird vom Unternehmen definiert.

Im folgenden Diagramm hat das Unternehmen sein maximal zulässiges RPO sowie die Höchstgrenze der Ausgaben für seine Datenwiederherstellungsstrategie festgelegt. Von den vier DR-Strategien erfüllen entweder die Pilot Light oder die Warm Standby DR-Strategie beide Kriterien für RPO und Kosten.


        Die Grafik zeigt das Recovery Point Objective als Verhältnis von Kosten und Komplexität zum Datenverlust vor der Unterbrechung des Service.

Abbildung 5 - Recovery Point Objective

Anmerkung

Wenn die Kosten der Wiederherstellung höher sind als die Kosten des Ausfalls oder Verlusts, sollte die Wiederherstellungsoption nicht eingeführt werden, es sei denn, es gibt einen sekundären Grund, wie z. B. gesetzliche Anforderungen.