Entwickeln eines Notfallwiederherstellungsplans für Bereitstellungen mit mehreren Regionen

Als Cloud Solution Architekt spielen Sie eine entscheidende Rolle dabei, sicherzustellen, dass die Wiederherstellung von großflächigen Ausfällen absichtlich geplant, entworfen und als Disaster-Recovery-Plan (DR-Plan) dokumentiert wird. Im Falle eines Ausfalls beeinflusst die Qualität dieses Plans, ob es sich bei dem Ereignis um einen vorübergehenden Rückschlag handelt oder zu einer Reputations- und Finanzkrise wird.

Der Plan sollte auf Strategien basieren, die von den Geschäftsprioritäten geleitet und von messbaren Zielen gesteuert werden. Dieser Artikel führt Sie durch den Prozess der Entwicklung eines praktischen DR-Plans, beginnend mit den grundlegenden Praktiken der Wiederherstellung von Diensten zu einer Denkweisenverschiebung, die geschäftskontinuität unter Druck schützt.

Dieser Artikel konzentriert sich auf das Erreichen der Geschäftskontinuität durch technische Gegenmaßnahmen und Prozesse. Bevor Sie beginnen, überprüfen Sie die wichtigsten Strategien, und wählen Sie die Strategien aus, die für Ihr Unternehmen sinnvoll sind. Ausführliche Informationen finden Sie unter RE:09 Architekturstrategien für die Notfallwiederherstellung .

Ein DR-Plan sollte auf den Kernprinzipien der Vorfallverwaltung basieren, die als Voraussetzung für eine effektive DR-Planung dient. Anleitungen zur Entwicklung eines Vorfallverwaltungsplans finden Sie unter Entwickeln einer Vorfallverwaltungspraxis zur Wiederherstellung von Störungen.

Terminologie

Bevor Sie mit der Entwicklung Ihres Plans beginnen, machen Sie sich mit diesen Schlüsselbegriffen vertraut.

Begriff	Definition
Aktiv-Aktiv (Hot Standby)	Zwei oder mehr Umgebungen sind voll funktionsfähig und bedienen gleichzeitig Live-Verkehr in mehreren Regionen. Sollte eine Umgebung ausfallen, setzen andere die Lastbewältigung fort, ohne oder mit nahezu keinen Unterbrechungen.
Aktiv-passiv (kalter Standbymodus)	Die nicht laufende Umgebung, die bei Aktivierung die Bereitstellung und Datenwiederherstellung erfordert. Niedrigste Kosten, längste Wiederherstellungszeit.
Aktiv-passiv (Warmstandby)	Teilweise bereitgestellte Umgebung mit minimalen Diensten, die bei Fehlern schnell skaliert werden können.
Geschäftskontinuität	Strategien zur Sicherstellung, dass kritische Vorgänge während und nach Unterbrechungen fortgesetzt werden, die DR, Personal, Kommunikation und Prozesse umfassen.
Notfallwiederherstellungsplan (DR)	Detaillierte, ausführbare Verfahren zum Wiederherstellen bestimmter Systeme, einschließlich schrittweiser Aktionen, Rollen, Zuständigkeiten, Failoversequenzen und Kommunikationsworkflows.
Notfallwiederherstellungsstrategie (DR)	Hochrangiger Ansatz zur Definition von Zielen, Prinzipien und einer Wiederherstellungsstrategie für die Reaktion auf katastrophale Fehler in allen Workloads.
DR-Aktivierung	Formale Entscheidung zur Einleitung von Notfallwiederherstellungsverfahren, die in der Regel eine Geschäftsleitungsautorisierung erfordern.
Failback	Prozess der Rückgabe von Workloads an die ursprüngliche primäre Umgebung nach der Vorfallauflösung.
Failover	Prozess der Verschiebung von Workloads von der primären in die Standbyumgebung während eines Notfalls.
Ziel des Wiederherstellungspunkts (RPO)	Die Menge des Datenverlusts, der vor großen Verlusten toleriert werden kann. Das RPO bestimmt, wie oft wichtige Daten gesichert werden sollen.
Ziel der Wiederherstellungszeit (RTO)	Zeitaufwand für die Wiederherstellung wesentlicher Zugriffe, Daten und Funktionen nach einem technologiebezogenen Notfall.

Was ist die Notfallwiederherstellung?

Notfallwiederherstellung (DR) ist ein strategischer und methodischer Ansatz zum Wiederherstellen von Systemen oder kritischen Teilen davon, nachdem ein schwerwiegendes Fehlerereignis aufgetreten ist.

In Cloudumgebungen sind temporäre Fehler normal. Diese kurzen Unterbrechungen, die häufig als Blips oder vorübergehende Fehler bezeichnet werden, können dazu führen, dass isolierte Komponenten nicht verfügbar sind oder unerwartete Leistungseinbußen auftreten. Sie werden in der Regel durch Plattformresilienzfeatures und integrierte Selbstheilungsmechanismen ohne menschliche Intervention aufgelöst.

Katastrophen sind jedoch eine andere Ereignisklasse. Sie sind umfassend, wirken sich auf mehrere Systeme oder Dienste gleichzeitig aus und können das System zum Stillstand bringen. Diese Ereignisse erfordern externe Interventionen und spezielle Rollen, die durch einen gut definierten DR-Plan geleitet werden können, der aktiviert werden kann, wenn die integrierte Selbstheilungsresilienz des Systems nicht ausreicht. Einige Beispiele sind:

• Vollständige regionale Ausfälle

• Verlust des Zugriffs auf die Steuerungsebene oder der Fähigkeit zur Dienstverwaltung

• Beschädigte Produktionsumgebungen aufgrund bösartiger Aktivitäten oder kritischer Fehlkonfigurationen

• Schwerwiegende Infrastrukturfehler, die sich auf mehrere Systemebenen auswirken

• Naturkatastrophen oder geopolitische Ereignisse, die zu einer unverfügbarkeit des erweiterten Dienstes führen

Unbeaufsichtigte Blips können in voll angelegte Katastrophen eskalieren. Während erweiterte Überwachungs- und Gesundheitsmodellierung dazu beitragen kann, diese Probleme frühzeitig zu erkennen und zu beheben, liegt dieses Thema außerhalb des Umfangs dieses Artikels. Weitere Informationen finden Sie unter Gesundheitsmodellierung.

Das ultimative Ziel von DR ist es, die Geschäftskontinuität innerhalb definierter quantitativer Metriken aufrechtzuerhalten. Stellen Sie sich den Plan als koordinierte Anstrengungen vor, die vordefinierte Verfahren, klare Kommunikationsprotokolle und Entscheidungsfindung auf Geschäftsleitungsebene erfordern.

Auswählen der Kritischen Stufe

Nicht alle Workloads (oder Teile davon) benötigen einen heroischen Wiederherstellungsplan. Die Wiederherstellung sollte ihre Kritikalität widerspiegeln.

Von Bedeutung

Kritischität ist eine Geschäftsentscheidung, und es liegt in Ihrer Verantwortung, diese Entscheidung zu leiten. Es hängt davon ab, was Ihre Arbeitsauslastung tut, wer davon abhängt und was passiert, wenn sie heruntergeht. Azure entscheidet nicht darüber, was unternehmenskritisch ist, diese Entscheidung treffen Sie. Wenn ein Ausfall Ihren Umsatz beeinträchtigen, das Vertrauen der Kunden beschädigen oder Sie aus rechtlichen Vorgaben herausfallen lassen würde, dann ist dies ein kritisches System. Treffen Sie diese Entscheidung und behalten Sie sie im Hinterkopf beim Entwerfen.

Überentwickeln von Dienstleistungen mit geringer Wirkung verschwendet Ressourcen; untervorbereitete hochwirksame Dienstleistungen bergen schwerwiegende Folgen. Der Schlüssel ist die richtige Größenanpassung Ihrer Wiederherstellungsstrategie basierend auf den geschäftlichen Auswirkungen. Verwenden Sie die folgenden Klassifizierungsstufen als Ausgangspunkt, um die Kritischität zu bewerten und Ihre Investitionen für die Notfallwiederherstellung entsprechend auszurichten.

Eine gängige Methode zur Quantifizierung von Ebenen ist die Verwendung von Dienstebenenzielen (SLOs), die häufig als "fünf neune" (99,999%), "vier neun" (99,99%) ausgedrückt werden usw. Diese Perzentile repräsentieren allgemein die erwartete Verfügbarkeitsebene für eine bestimmte Arbeitslast.

Die wichtigsten Metriken in der DR-Strategie sind Recovery Time Objective (RTO) und Recovery Point Objective (RPO), beide als Zeiteinheiten quantifiziert. RTO definiert, wie schnell ein System nach einer Unterbrechung wiederhergestellt werden muss. Sie stellt die Toleranz der Organisation für Ausfallzeiten dar. RPO definiert, wie viel Datenverlust akzeptabel ist und gibt an, wie häufig Daten gesichert werden müssen.

In diesem Artikel wird davon ausgegangen, dass Ihre SLOs und Wiederherstellungsmetriken bereits definiert wurden und nicht behandelt werden, wie sie berechnet werden. Wenn Sie Anleitungen zum Einrichten aussagekräftiger SLOs benötigen, lesen Sie die Zuverlässigkeitsmetriken.

Stufe 0: Missionskritisch

Die unternehmenskritische Ebene umfasst ganze Workloads oder bestimmte Komponenten, bei denen Ausfallzeiten keine Option sind und Kosteneinsparungen sekundär für die Kontinuität sind. Diese Systeme sind von grundlegender Bedeutung für die Organisation, die direkte Steuerung des Umsatzes, die Sicherung des Kundenvertrauens oder die Auswirkungen auf das Leben. Zu den gängigen Beispielen gehören Finanzplattformen, Gesundheitssysteme und Sicherheitsinfrastrukturen.

Diese Stufe erfordert SLOs über 99,99%, wobei RTO in Sekunden gemessen wird und RPO annähernd null ist. Um diese Anforderungen zu erfüllen, ist eine aktiv-aktiv, mehrregionale Bereitstellung in der Regel erforderlich, sodass eine sofortige Wiederherstellung ohne Unterbrechung für Benutzer möglich ist.

Wenn unternehmenskritische Systeme fehlschlagen, sind die Folgen unmittelbar und signifikant: Verlorene Einnahmen, Reputationsschäden oder regulatorische Gefährdungen.

Stufe 1: Unternehmenskritisch

Geschäftskritische Systeme sind für den täglichen Betrieb und die Kundenerfahrung unerlässlich, aber im Gegensatz zu unternehmenskritischen Systemen können sie kurze Unterbrechungszeiten tolerieren, solange die Wiederherstellung schnell ist und Datenverlust minimal ist. Diese Systeme werden häufig durch Umsatzanreize gesteuert, z. B. E-Commerce-Plattformen, kundenorientierte Anwendungen und Partnerportale.

Sie benötigen für gewöhnlich etwa 99,95 % SLOs, wobei RTO und RPO in Minuten gemessen werden. Eine Mischung aus aktive-aktive- oder Warm-Standby-Konfigurationen wird häufig verwendet, um die Ausfallsicherheit mit den Kosten auszubalancieren.

Während kurze Ausfälle überlebensfähig sein können, wirkt sich eine erweiterte Ausfallzeit in dieser Stufe direkt auf Einnahmen, Benutzerzufriedenheit und Marken glaubwürdigkeit aus. Vorhersagbarkeit und Geschwindigkeit der Wiederherstellung sind von entscheidender Bedeutung.

Stufe 2: Geschäftsbetrieb

Geschäftsbetriebssysteme unterstützen interne Teams und Prozesse. Sie sind zwar nicht direkt kundenseitig ausgerichtet, aber sie sind für Produktivität und Betriebskontinuität unerlässlich. Typische Beispiele sind Berichterstellungsplattformen, interne Dashboards und Verwaltungstools.

Diese Systeme richten sich in der Regel auf SLOs von 99,9 % aus, wobei RTO und RPO dabei in Stunden gemessen werden. Eine aktiv-passive Strategie mit warmen/kalten Bereitstellungen ist üblich, bei der sekundäre Umgebungen inaktiv bleiben, bis sie benötigt werden, und es wird mehr auf Kosteneffizienz als auf schnelle Wiederherstellung geachtet.

Ausfälle in dieser Stufe wirken sich möglicherweise nicht sofort auf Kunden aus, aber längere Unterbrechungen können das Geschäft verlangsamen. Die rechtzeitige Wiederherstellung ist wichtig, auch wenn sie nicht unmittelbar ist.

Ebene 3: Administrative Verwaltung

Administrative Systeme sind nicht kritische Workloads, die Hintergrundvorgänge unterstützen oder Anwendungsfälle mit geringer Dringlichkeit unterstützen. Dazu gehören in der Regel Archivierungsplattformen, Sandkastenumgebungen, Schulungsportale oder Batchverarbeitungstools, bei denen die Verfügbarkeit nicht zeitempfindlich ist.

Mit SLOs unter 99,9 % tolerieren diese Systeme längere Wiederherstellungsfenster, wobei der RTO von Stunden bis zu Tagen reicht und der RPO in Stunden gemessen wird. Der kostengünstigste Ansatz hier ist in der Regel Sicherung und Wiederherstellung, wodurch die laufenden Infrastrukturkosten minimiert werden und gleichzeitig die Wiederherstellbarkeit erhalten bleibt.

Während Verzögerungen auf dieser Ebene im Allgemeinen akzeptabel sind, muss die Datenintegrität weiterhin geschützt werden. Diese Systeme könnten das Geschäft möglicherweise nicht sofort zum Stillstand bringen, wenn sie ausfallen, aber ihr vollständiger Verlust könnte im Laufe der Zeit dennoch Risiken für die Einhaltung von Vorschriften oder Wissenslücken verursachen.

Klassifizieren Sie Ihre Arbeitslast

Bevor Sie Ihre DR-Strategie starten, klassifizieren Sie Ihre Workloads basierend auf tatsächlichen Geschäftlichen Auswirkungen und Wiederherstellungsanforderungen.

Beginnen Sie, indem Sie jeden Benutzerfluss in Ihrer Workload auflisten. Dokumentieren Sie, was sie tut, wer davon abhängt, und was passiert, wenn es heruntergeht. Unterschiedliche Abläufe innerhalb derselben Workload erfordern möglicherweise unterschiedliche Notfallwiederherstellungsstrategien basierend auf ihren individuellen Geschäftlichen Auswirkungen und kritischer Bedeutung.

Arbeiten Sie mit Ihren Geschäftsbeteiligten zusammen, um ihre Zustimmung zu diesen Klassifizierungen zu erhalten. Bestätigen Sie die RTO- und RPO-Ziele basierend auf echten geschäftlichen Folgen, nicht nur technischen Meinungen. Ihr Engagement setzt die Grundlage und Ihre DR-Strategie baut darauf auf. Ohne Ausrichtung auf das Geschäftsrisiko fehlt einer technischen Reaktion die Richtung.

Überprüfen Sie diese Klassifizierungen regelmäßig. Aktualisieren Sie ihren DR-Plan entsprechend, wenn sich die geschäftlichen Anforderungen weiterentwickeln.

Achten Sie auf diese Reibungspunkte

Hier sind einige wichtige Reibungspunkte, bei denen Sie vorsichtig sein sollten, andernfalls kann die DR-Planung zu einer kostspieligen Übung ohne die richtigen Ergebnisse werden.

• Missübereinstimmung zwischen Erwartungen und Budget. Legen Sie die Erwartungen richtig fest, damit die Projektbeteiligten nicht erwarten, dass sie Hot-Standby-Leistung in einem Cold-Standby-Budget erhalten. Die Lücke zwischen RTO/RPO-Zusagen und Budgets kann zu Risiko und Enttäuschung führen.

• Abhängigkeiten für gemeinsame Dienste können Ihre Kette unterbrechen. Ihr DR-Plan ist nur so effektiv wie seine schwächste Komponente. Wenn Ihre Workloads von freigegebenen oder Drittanbieterressourcen abhängig sind, die keine ordnungsgemäßen Failoverstrategien aufweisen, kann dies während eines Notfalls Sicherheitsrisiken schaffen.

• Dr-Aktivierungskriterien müssen kristallklar sein. Jeder, der in der Verantwortungsliste aufgeführt ist, muss sich über die Kriterien im Klaren sein. Ohne dies kann es zögern, die Wiederherstellung zu initiieren, was unnötige Verzögerungen verursachen kann.

• Failback ist genauso wichtig wie Failover. Während sich viele darauf konzentrieren, failover als unidirektionale Übernahme zu behandeln, ist failback manchmal eine praktikable Option. Das Zurückgeben von Vorgängen an den primären Standort erfordert jedoch häufig mehr Komplexität. Stellen Sie sicher, dass Sie Failbackprozeduren planen und testen. Eine gute Richtlinie ist das Automatisieren des Failovers beim Verwalten von Failbacks über einen kontrollierten Prozess.

Optimieren Sie die Wiederherstellungskosten

Die Kosten der Notfallwiederherstellung skalieren mit der Kritikalität der Workload.

• Stufe 0 (Mission Critical) kommt mit den höchsten Kosten, und das wird erwartet. Aktive Bereitstellungen und redundante Infrastruktur erhöhen Ihre Ausgaben im Austausch erheblich für nahezu null Ausfallzeiten. Bei der Kostenoptimierung sind Ihre besten Optionen Standardpraktiken wie reservierte Instanzen oder Azure-Hybridvorteil, falls zutreffend.

  Bemühen Sie sich um Einfachheit in Ihrem Design. Über-Ingenieurwesen, das über gut definierte Anforderungen hinausgeht, ist der Bereich, in dem sich versteckte Kosten leise anhäufen. Denken Sie daran, dass grundlegende Praktiken wie Infrastruktur als Code, automatisierte Bereitstellungen und Tests vorab technische Anstrengungen unternehmen. Auch wenn dieser Aufwand mit der Bereitstellung neuer Features konkurrieren könnte, ist die Beeinträchtigung der Investitionen in starke Operationen einfach keine Option.

• Stufe 1 (Business Critical) bietet ein Gleichgewicht, in der Regel unter Verwendung warmer Standby-Umgebungen, die Kosten reduzieren.

  Senken Sie die Grundkapazität im warmen Standby, indem Sie Rechenressourcen in der sekundären Region in einem reduzierten Maß bereitstellen und die automatische Skalierung nur bei Bedarf erhöhen. Dieser Ansatz vermeidet die Zahlung für die volle Kapazität 24/7.

  Die Verwendung eines manuell ausgelösten Failoverprozesses mit einem koordinierten Runbook zur Reduzierung der Komplexität und fortlaufender Betriebskosten im Vergleich zu einem vollständig automatisierten Failover. Regelmäßige Failovertests helfen bei der Identifizierung von Ineffizienzen,

• Stufe 2 (Geschäftsbetrieb) konzentriert sich auf die Optimierung der Kosten mithilfe von Cold Standby-Setups und Pay-as-you-go-Optionen wie Spotinstanzen und Verbrauchspreisen. Automatisieren Sie die Bereitstellung von PaaS-Berechnungen in der sekundären Region nur, wenn sie erforderlich sind, um die Zahlung für Leerlaufressourcen zu vermeiden. Definieren Sie klare Notfallkriterien und Failoverprozesse, um unnötige Failovers zu verhindern. Regelmäßige Tests stellen sicher, dass Wiederherstellungsziele erfüllt sind, und hebt Bereiche hervor, um die Kosten zu kürzen.

• Stufe 3 (Administrative) priorisiert Kosteneinsparungen, indem sie sich auf den Sicherungs- und Archivierungsspeicher mit längeren Wiederherstellungsfenstern verlassen. Verwenden Sie replizierte Sicherungen und Azure Backup Vaults in einer sekundären Region, um persistente Daten zu schützen, ohne die Standby-Infrastruktur auszuführen. Testen Sie regelmäßig Wiederherstellungsprozesse, um Zuverlässigkeit zu gewährleisten und gleichzeitig Ausgaben auf ein Minimum zu beschränken.

Was auch immer Ihre Stufe sein kann, verwenden Sie die richtigen Tools, um Kosten zu überprüfen. Verwenden Sie Tools wie Microsoft Cost Management und Azure Advisor, um Ausgaben auf allen Ebenen zu überwachen, zu prognostizieren und zu optimieren. Markieren Sie Ressourcen, und legen Sie Budgetschwellenwerte fest, um Die Verantwortlichkeits- und Rückbuchungsmodelle einfacher nachzuverfolgen. Informationen zu von Microsoft empfohlenen Tags finden Sie unter Kategorisieren von unternehmenskritischen Workloads.

Dokumentieren Sie Ihren DR-Plan

Ein starker Notfallwiederherstellungsplan wandelt die Strategie in entscheidende Maßnahmen um. Die Aktivierung beginnt mit einer Kombination aus automatisierten Warnungen und menschlicher Aufsicht. Observability-Tools kennzeichnen potenzielle Probleme wie Leistungsverschlechterungen und lösen Warnungen aus, damit das Operations-Team diese untersuchen kann. Sie überprüfen Dashboards für Anomalien und bewerten die Situation. Wenn das Problem breiter oder schwerer erscheint, wird es eskaliert, und es können zusätzliche Teams beteiligt sein. Nachdem genügend Nachweise vorhanden sind, deklariert der DR-Lead formal eine Katastrophe und initiiert einen strukturierten Failoverprozess, um die Systemkontinuität aufrechtzuerhalten.

Um dies zu ermöglichen, sollte jeder DR-Plan drei wesentliche Komponenten enthalten: ein klares Runbook, einen klar definierten Kommunikationsplan und einen strukturierten Eskalationspfad.

DR-Kommunikationsplan

Ein Kommunikationsplan stellt sicher, dass die richtigen Informationen die richtigen Personen zur richtigen Zeit während einer Unterbrechung erreichen. Sie unterstützt koordination, reduziert Verwirrung und hält die Beteiligten während des gesamten Wiederherstellungsprozesses auf dem Laufenden. Ihr Plan sollte diese Aspekte abdecken:

• Aktivierungskriterien und Genehmigungen. Legen Sie fest, was als DR-Ereignis qualifiziert ist. Identifizieren Sie, wer über die Berechtigung verfügt, den DR-Prozess auszulösen. Dokumentieren Sie Eskalationspfade und Entscheidungsprüfpunkte.

• Rollen und Zuständigkeiten. Definieren Sie, wer für die Kommunikation und für wen verantwortlich ist.

• Wichtige Projektbeteiligte. Identifizieren Sie wichtige interne und externe Zielgruppen, z. B. Mitarbeiter, Führung, Partner und Kunden.

• Kommunikationskanäle. Erstellen Sie primäre und Sicherungsmethoden wie E-Mail, SMS und andere. Richten Sie außerdem die Häufigkeit der Updates für diese Kanäle ein.

• Benachrichtigungen und Vorlagen. Beschreiben Sie, wann Updates gesendet und vorab genehmigte Messagingvorlagen für E-Mails, Statusseiten und Vorfallkanäle vorbereitet werden sollen.

• Eskalation und Kontinuität. Stellen Sie sicher, dass es eine strukturierte Möglichkeit gibt, Probleme zu eskalieren, wenn jemand nicht verfügbar ist oder sich die Dinge schnell ändern. Kommunikationspläne müssen sowohl interne als auch externe Projektbeteiligte mit entsprechender Detail- und Häufigkeit ansprechen und separate Kanäle verwenden. Interne Kommunikation bietet regelmäßige Aktualisierungen für Führungskräfte und Geschäftsbenutzer, die sich auf geschäftliche Auswirkungen, Zeitpläne und Ressourcenanforderungen konzentrieren. Die externe Kommunikation koordiniert mit Kunden, Partnern und Aufsichtsbehörden und umfasst den aktuellen Status und realistische Zeitrahmen für die Wiederherstellung.

DR-Runbuch

Ein starkes Runbook ersetzt abstrakte Strategien durch Struktur und ermöglicht es dem Team, unter Druck zu reagieren. Machen Sie es klar, machen Sie es praktisch, und stellen Sie sicher, dass sie funktioniert. Beginnen Sie mit einer einfachen Gliederung und bauen Sie schrittweise darauf auf. Arbeiten Sie mit Unternehmen, Sicherheit und Betrieb zusammen, um eine vollständige Abdeckung sicherzustellen.

• Dokumentfailover- und Failbackprozeduren. Schreiben Sie schrittweise technische Anweisungen zum Initiieren des Failovers. Verweisen Sie auf Tools und Skripts, die mit Links oder Verweisen ausgeführt werden sollen. Legen Sie Kriterien für das Initiieren von Failbacks und für koordinierte Umschaltvorgänge fest.

  Entwickeln Sie einen schrittweisen Prozess für die Failoverausführung:

  Maßnahme	Besitzer	Kriterien
  1. Erkennen eines Vorfalls	Überwachung/Betrieb	Der Vorfall wird durch Warnungen oder Benutzerberichte ausgelöst.
  2. Schweregrad bewerten	Vorfall-Manager	Verwenden Sie die Tabelle "Vorfallklassifizierung", um den Schweregrad zu ermitteln.
  3. Deklarieren des Ausfalls (falls erforderlich)	Leitender Operations-/BCDR-Verantwortlicher	Deklarieren Sie den Ausfall nur für Vorfälle mit hohem und kritischem Schweregrad.
  4. Benachrichtigen der Beteiligten	Kommunikationsleiter	Folgen Sie dem etablierten Kommunikationsplan für Benachrichtigungen.
  5. Runbook-Ausführung starten	Betriebsteam	Initiieren Sie die Ausführung des DR-Runbook, einschließlich automatisierter Runbooks und manueller Schritte.
  6. Vorbereiten der sekundären Infrastruktur	Betriebsteam	Bereitstellung, Skalierung und Überprüfung der Infrastrukturkonfiguration in der sekundären Umgebung.
  7. Sicherstellen der Datenintegrität	Betriebsteam	Stellen Sie Bei Bedarf Daten aus Sicherungen wieder her, und überprüfen Sie die Datenintegrität und Einhaltung von RPO.
  8. Wiederherstellen von Anwendungen	Ops/QA Team	Stellen Sie bei Bedarf Anwendungen auf einer sekundären Umgebung bereit und aktivieren Sie sie. Überprüfen des richtigen Vorgangs und aller Abhängigkeiten
  9. Verkehrsüberschneidung	Betriebsteam	Wechseln des Benutzers zu sekundärer Umgebung. Aktualisieren von DNS-Einträgen bei Bedarf
  10. Vorfall schließen und dokumentieren	Vorfall-Manager	Ein Post-Mortem durchführen und Ereignisdaten aktualisieren.

  Erstellen Sie auf ähnliche Weise einen Failback-Entscheidungs- und Ausführungsprozess (primäre Region verfügbar):

  Maßnahme	Besitzer	Kriterien/Entscheidungspunkt
  Überwachung der Gesundheit der primären Region	Betriebs-/Cloud-Team	Stellen Sie sicher, dass die primäre Region alle Gesundheitschecks besteht und voll funktionsfähig ist. Verwenden Sie automatisierte Überwachungstools und manuelle Überprüfungen, um die Bereitschaft zu bestätigen.
  2. Bewertung der geschäftlichen Auswirkungen	Anwendungsbesitzer/Geschäftskontinuität	Bestätigen Sie die Geschäftsbereitschaft für failback, einschließlich Fenstern mit geringem Datenverkehr und erforderliche Genehmigungen. Koordinieren Sie die Projektbeteiligten, um sicherzustellen, dass die Zeitplanung an die Geschäftlichen Anforderungen angepasst wird.
  3. Überprüfen der Datensynchronisierung	Datenbank/Infrastrukturteam	Stellen Sie sicher, dass Daten in der sekundären Region mit den primären und den RPO/RTO-Anforderungen synchronisiert werden. Verwenden Sie Replikationsstatusdashboards, um die Datenkonsistenz zu überprüfen.
  4. Kommunizieren des Failback-Plans	Vorfall-Manager	Benachrichtigen Sie die Projektbeteiligten über den geplanten Failback, einschließlich Zeitachse und potenzieller Auswirkungen. Verwenden Sie E-Mail-, Teams- oder Vorfallverwaltungstools für die Kommunikation.
  5. Vorbereiten der primären Region	Infra/Cloud Team	Überprüfen Sie, ob Infrastruktur-, Sicherheits- und Anwendungskomponenten in der primären Region bereit sind. Führen Sie Checklisten vor dem Failback aus, um die vollständige Einsatzbereitschaft sicherzustellen.
  6. Failback initiieren	Betriebs-/Cloud-Team	Fahren Sie nur mit genehmigter Änderungsanforderung fort, und wenn alle Kriterien erfüllt sind. Beginnen Sie mit der Umleitung von Datenverkehr und Workloads an die primäre Region.
  7. Fortschritt des Failbacks überwachen	Betriebs-/Cloud-Team	Überwachen Sie während des Übergangsvorgangs auf Fehler, Latenz oder Datenverlust. Verwenden Sie Dashboards und Warnsysteme, um den Fortschritt nachzuverfolgen.
  8. Überprüfen der Anwendungsfunktionalität	Anwendungsbesitzer/QA	Vergewissern Sie sich, dass Anwendungen und Dienste in der primären Region voll funktionsfähig sind. Führen Sie Rauchtests und Regressionstests aus, um die Funktionalität zu überprüfen.
  9. Abschließen und Schließen eines Vorfalls	Vorfall-Manager	Stellen Sie sicher, dass alle Systeme stabil sind, die Beteiligten informiert sind und die Dokumentation aktualisiert wird. Vollständige Post-Mortem-Analyse und Erfassung der gelernten Lektionen.

• Erstellen Sie Integritätsüberprüfungen und Bereitschaftsprüfungen. Definieren Sie, wie Sie die Dienstfunktionalität nach dem Failover überprüfen. Schließen Sie Überprüfungen auf Anwendungsebene, Infrastruktur und Datenintegrität ein.

• Post-Wiederherstellungs- und Überprüfungsplanung Maßnahmen zum Bereinigen temporärer Umgebungen. Dokumentieren Sie ggf. die Datensöhnung. Planen Sie die Ursachenanalyse und die DR-Nachbesprechung.

Tipp

Behandeln Sie Ihr DR-Runbook wie Produktionscode: Versionieren Sie es und machen Sie es zugänglich. Verwenden Sie Versionssteuerungstools wie Git oder ein versionsiertes Wiki, um Updates nachzuverfolgen und die Genauigkeit im Laufe der Zeit sicherzustellen. Ebenso wichtig ist es, sicherzustellen, dass das Runbook immer erreichbar ist, auch während eines Ausfalls. Speichern Sie sie in mehreren Formaten, einschließlich offline oder druckbarer Versionen, sodass Teams darauf zugreifen können, wenn es am wichtigsten ist.

DR-Eskalationsplan

Während der Notfallwiederherstellung sind Geschwindigkeit und Klarheit alles. Ein Eskalationsplan stellt sicher, dass die richtigen Personen schnell benachrichtigt werden, wenn die Dinge nicht plangerecht sind.

• Eskalationsauslöser. Definieren Sie genau, wann eskaliert werden soll, unabhängig davon, ob es sich um einen verpassten Wiederherstellungsmeilenstein, einen kritischen Systemfehler oder einen nicht reagierenden Anbieter handelt.

• Befehlskette. Legen Sie in der identifizierten Liste der Rollen und Kontakte fest, in welcher Reihenfolge Sie kontaktieren können. Das heißt, wie Probleme durch primäres, sekundäres und Sicherungspersonal eskaliert werden. Schließen Sie auch die Erwartungen an die Antwortzeit ein. Rufen Sie z. B. den DR-Manager innerhalb von 15 Minuten auf der Telefon- oder Notfallkommunikationsplattform an.

• Schweregrad des Vorfalls. Kategorisieren Sie Vorfälle nach Auswirkungen, damit kleinere Probleme das System nicht verstopfen und wichtige sofortige Beachtung von der Leitung erhalten.

Hier ist eine Beispielvorlage:

Schweregrad	Description	Examples	Auslöser der Störungserklärung	Benachrichtigung der Beteiligten
Low	Geringfügige Dienstbeeinträchtigung	Kurze Latenzspitzen	Keine formale Deklaration	Betriebsteam
Mittelstufe	Teilweise Dienstbeeinträchtigung	Einzelne Dienstfehler	Protokollierter Vorfall unter Beobachtung	Betrieb, Geschäftsleitung
High	Großer Ausfall, weit verbreitete Auswirkungen	Multi-Service-Ausfall	Formale Ausfallmitteilung	Alle Projektbeteiligten, Kunden
Kritisch	Totalverlust, geschäftskritisch	Vollständiger regionaler Azure-Fehler	Sofortige Deklaration, C-Ebene	Alle Projektbeteiligten, Exec Team

Regelmäßig testen und den Plan verbessern

Notfallwiederherstellung ist eine operative Disziplin. Ein nie getesteter DR-Plan bleibt theoretisch und unbewiesen.

• Testen Sie das Runbook in regelmäßigen Abständen, um Szenarien zu simulieren und Teamrollen zu klären.

• Planen Sie vollständige oder teilweise Failover-Übungen, um konkrete Wiederherstellungsschritte und Zeitangaben zu überprüfen. Ein geplantes Failover simuliert einen regionalen Ausfall, um reibungslose Systemübergänge zu üben. Tools wie Azure Chaos Studio werden verwendet, um ungeplante Fehler zu testen und zu sehen, wie Systeme reagieren.

• Überprüfen Sie nach jedem Test die Daten, um zu bestätigen, dass nichts verloren ging oder beschädigt wurde. Erfassen Sie alle gefundenen Lücken oder Probleme, und aktualisieren Sie ihre Architektur und Runbooks umgehend.

Wiederherstellungsstrategie für Sicherung und Wiederherstellung

Sicherungs- und Wiederherstellungsstrategien müssen Teil aller Wiederherstellungsstrategien sein.

Empfohlene Maßnahmen

Verwenden Sie dies als Grundlage für alle Ebenen. Jeder Schritt sollte ein klares Ziel und eine Möglichkeit zur Überprüfung seiner Wirksamkeit enthalten.

Aktionen	Konfiguration	Validation
Konfigurieren von Sicherungsrichtlinien und Aufbewahrung	– Konfigurieren von Sicherungszeitplänen und Aufbewahrungszeiträumen für Infrastruktur und Datenbanken, die den RPO-Anforderungen entsprechen – Verwenden von Azure Backup für VMs, Azure-Dateien und Blob Storage – Speichern von Sicherungen in sekundärer Region, z. B. mithilfe von Geo-Redundant Backup Vault, sofern verfügbar	– Testen der Ausführung von Sicherungsrichtlinien – Überprüfen des Abschlusses und der Integrität der Sicherung – Überprüfen der Durchsetzung von Aufbewahrungsrichtlinien
Implementieren von kostengünstigen Speicherebenen	- Archiv- oder Cool-Speicherstufen für selten aufgerufene Daten verwenden – Anwendung von Backup-Einstufungspolitiken, um ältere Sicherungen auf kostengünstigere Optionen zu übertragen – Konfigurieren der Komprimierung und Deduplizierung zur Minimierung der Speicherkosten	- Überprüfen von Speicherkostenoptimierungsberichten - Überprüfung der Ausführung der Einstufungsrichtlinie - Testen des Datenabrufs aus verschiedenen Speicherebenen
Prozeduren für die Dokumentwiederherstellung	– Verwalten von Runbooks mit detaillierten Wiederherstellungsschritten - Definieren von Zielumgebungen für die Wiederherstellung - Kontaktlisten für Genehmigungen und Eskalationen einschließen	- Genauigkeit der Dokumentation der Prüfung der Wiederherstellungsprozedur - Überprüfen der Währung der Kontaktinformationen - Testen von Eskalationspfaden und Genehmigungsworkflows
Überwachen von Sicherungskosten und Compliance	– Festlegen von Budgetschwellenwerten für sicherungsbezogene Ressourcen - Wenden Sie sicherungsspezifische Tags an, um die ordnungsgemäße Nachverfolgung zu ermöglichen – Konfigurieren von Aufbewahrungsrichtlinien zur Erfüllung gesetzlicher Complianceanforderungen	- Monatliches Überprüfen von Sicherungskostenberichten - Überprüfen der Effektivität des Budgetschwellenwerts – Überwachen der Einhaltung von Aufbewahrungsrichtlinien
Verwalten und Überwachen von Sicherungssystemen	- Vierteljährliche Prüfungen der Sicherungsanforderungen durchführen – Veraltete Systeme einstellen und Richtlinien anpassen - Überprüfen und Aktualisieren von RPO/RTO-Anforderungen basierend auf Geschäfts- und Technologieänderungen	- Überprüfen, ob die Prüfungsergebnisse berücksichtigt werden - Bestätigen, dass eingestellte Systeme ordnungsgemäß außer Betrieb genommen werden – Überprüfung von RPO/RTO-Anforderungsänderungen ist machbar

Wiederherstellungsstrategie für aktiv-passiv (kalter Standbymodus)

Aktiv-Passiv-Kalt-Standby-Bereitstellungen halten die Compute-Ressourcen der sekundären Region gestoppt, bis sie benötigt werden. Dieser Ansatz eignet sich ideal für Arbeitslasten der Ebene 2 oder Stufe 3, bei denen RTOs längere Verzögerungen tolerieren können, die Wiederherstellung muss jedoch weiterhin zuverlässig und wiederholbar sein.

Die primäre Region verarbeitet den gesamten Produktionsverkehr, während die sekundäre Region die Infrastruktur einsatzbereit hält mit minimalem Ressourcenverbrauch, was eine manuelle Aktivierung in Notfallszenarien erfordert.

Empfohlene Maßnahmen

Bauen Sie auf den Wiederherstellungsstrategien für Sicherung und Wiederherstellung auf und decken Sie diese Punkte ab. Erweitern Sie es nach Bedarf.

Aktionen	Konfiguration	Validation
Einrichten von primären und sekundären Regionen	– Einen vollständigen Workload in der primären Region bereitstellen – Kopieren Sie die Netzwerktopologie, Richtlinien und Konfigurationen von der primären – Sicherstellen, dass RBAC, Sicherheitsgrundwerte, Überwachungs-Agents und Richtlinien konsistent sind – Bereitstellung der Infrastruktur als Code mit angehaltenen Rechenressourcen	Überprüfung der Infrastrukturbereitschaft der sekundären Region - Testen der Richtlinienkonsistenz in allen Regionen – Überprüfen der Netzwerkkonnektivität und des Routings
Einrichten der regionenübergreifenden Datenreplikation	– Aktivieren der integrierten Replikation für Azure SQL-Datenbank, PostgreSQL, MySQL, Cosmos DB – Aktivieren von GZRS oder RA-GZRS für die Speicherreplikation mit gekoppelten Regionen – Konfigurieren der Objektreplikation für Blob Storage in nicht gekoppelten Regionen – Einrichten von Lese-/Schreibzugriff über mehrere Regionen mit konfigurierbaren Konsistenzstufen für Azure Cosmos DB – Konfigurieren der Überwachung der Replikationsverzögerung und der Datenkonsistenzvalidierungsprozesse	- Testen der Datensynchronisierungsverzögerung gegenüber RPO-Zielen – Überprüfen des Replikationszustands und der Latenzkennzahlen – Überprüfen der Datenkonsistenz zwischen Regionen – Überprüfen der Datenintegrität während Failoverszenarien
Sichern Sie die DR-Umgebung und erhalten Sie die Compliance aufrecht	– Replizieren der Datenhaltungsanforderungen in allen Regionen – Aufrechterhaltung der Identitäts- und Zugriffsparität zwischen Regionen Test für die Kontinuität des Audit-Trails während und nach dem Failover	– Überwachen von Sicherheitskonfigurationen in allen Regionen – Testen von Identitätsfailoverszenarien – Überprüfen der Compliance während DR-Ereignissen – Überprüfen der Überwachungsprotokollkontinuität
Automatisieren von Bereitstellungs- und Vorbereitungsvorgängen	– Definieren von IaC-Vorlagen für die automatisierte Ressourcenbereitstellungsumgebung nach Bedarf - Dienstkonfigurationen, Skalierungsparameter und Abhängigkeiten einschließen - Skalierungsziele vorab definieren, um die vollständige Last abzudecken, wenn sie aktiviert werden - Für IaC: Bicep, Terraform, ARM-Vorlagen - Bereitstellungsautomatisierung: CI/CD-Pipelines für beide Regionen - Runbooks: Automatisierte und manuelle Schritte zum Aufrufen von DR-Verfahren	– Testen automatisierter Bereitstellungsverfahren – Überprüfen der Berechnungsstartzeiten, die RTO-Ziele erfüllen Aktivierungssequenzen für Dienstabhängigkeiten validieren – Testen der IaC-Bereitstellungskonsistenz in allen Regionen – Überprüfen der Ausführung und Zeitplanung des Runbook
Überwachen der Bereitschaft und Gesundheit	– Festlegen von Warnungen für Replikationsintegritäts- und Latenzmetriken – Überwachen des Infrastrukturstatus der sekundären Region – Nachverfolgen der Aktivierungsbereitschaft für alle Komponenten Implementierung von Gesundheitsprüfungen für den Replikationsstatus. – Konfigurieren von Benachrichtigungen für Ereignisse der automatischen Skalierung und Verkehrsrouting - Sicherstellen, dass Überwachungstools beide Regionen abdecken	- Prüfüberwachungs- und Alarmsysteme Überprüfung der Infrastrukturgesundheitschecks – Überprüfen der Genauigkeit von Bereitschaftsindikatoren - Validierung der Observability-Abdeckung
Konfigurieren eines Load-Balancers mit manuellem Failover	- Azure Front Door oder Traffic Manager mit prioritätsbasiertem Routing - Den gesamten Produktionsverkehr unter normalen Bedingungen an die primäre Region weiterleiten – Manuelles Auslösen der Datenverkehrsumleitung beim Failover	– Testen von Datenverkehrsfailoverszenarien - Überprüfen der Konfigurationen für Routing-Priorität - Überprüfen der DNS-Verteilung und Umschaltzeiten
Definieren Sie das Handbuch für manuelles Failover und die Kriterien	– Einrichten eindeutiger Failovertrigger und Aktivierungskriterien – Manuelle Aktivierungsschritte dokumentieren, einschließlich Computestart- und DNS-Updates - Rollbackprozeduren für fehlgeschlagene oder temporäre Aktivierungen einschließen	- Testen der Ausführung des Failover-Runbook – Überprüfen manueller Aktivierungsverfahren – Überprüfen von Rollbackprozessen und Zeitsteuerungen
Regelmäßiges Testen von Wiederherstellungsprozessen	– Planen regelmäßiger Wiederherstellungsbohrungen zur Überprüfung der Sicherungsintegrität - Wiederherstellung in Stagingumgebungen einschließen - Zeitaufwand aufzeichnen und mit den RTO-Zielen vergleichen	- Vierteljährliche Wiederherstellungsübungen ausführen – Überprüfen der Datenkonsistenz nach der Wiederherstellung - Leistung gegenüber den RTO-Zielen dokumentieren

Wiederherstellungsstrategie für aktiv-passiv (warmer Standbymodus)

Aktiv-passive Warm-Standby-Bereitstellungen ausgleichen Kosten und Resilienz, indem eine minimal bereitgestellte sekundäre Umgebung beibehalten wird, die bei Ausfallereignissen schnell skaliert werden kann. Dieser Ansatz reduziert Ausfallzeiten und vermeidet dabei die vollständigen Kosten von Always-On-Redundanz in allen Regionen.

Die primäre Region verarbeitet unter normalen Bedingungen den gesamten Produktionsverkehr, während die sekundäre Region mit minimalen Ressourcen betrieben wird und nur bei Aktivierung für die Notfallwiederherstellung hochskaliert.

Empfohlene Maßnahmen

Entwickeln Sie die Wiederherstellungsstrategien für aktive-passive Systeme (kalten Standby) weiter und decken Sie diese Punkte ab. Erweitern Sie es nach Bedarf.

Aktionen	Konfiguration	Validation
Konfigurieren der sekundären Region im Teilmaßstab	– Bereitstellen einer minimalistischen funktionsfähigen Rechnerkapazität in der sekundären Region	Überprüfung der Infrastrukturbereitschaft der sekundären Region
Aktivieren der automatischen Skalierung in sekundärer Region	– Konfigurieren von Regeln für die automatische Skalierung zur Erhöhung der Computeressourcen nach dem Failover – Festlegen geeigneter Skalierungsschwellenwerte und Grenzwerte - Definieren von Startsequenzen für abhängige Dienste	– Testen des Skalierungsverhaltens während Failover-Tests – Überprüfen der Ressourcenverfügbarkeit während der Skalierung
Konfigurieren automatisierter Failoverprozeduren	– Automatisches Failover aktivieren, sofern verfügbar - Manuelle Failoververfahren für andere Dienste dokumentieren - Erstellen orchestrierter Failover-Runbooks mit Schritt-für-Schritt-Prozessen	- Automatisierte Failovermechanismen testen – Überprüfen manueller Failoverprozeduren – Überprüfen des Ausführungszeitpunkts und der Genauigkeit des Runbooks
Konfigurieren Sie den Load-Balancer mit automatischem Failover	- Azure Front Door oder Traffic Manager mit aktiviertem automatischen Failover – Konfiguration von Health-Checks für die automatische Traffic-Umleitung	– Testen von Datenverkehrsfailoverszenarien - Überprüfen der Konfigurationen für Routing-Priorität

Wiederherstellungsstrategie für aktive Bereitstellungen

Aktiv-Aktiv-Bereitstellungen maximieren die Dienstverfügbarkeit, indem mehrere Workload-Instanzen über verschiedene Regionen hinweg ausgeführt werden, wobei jede Instanz den Produktionsdatenverkehr aktiv verarbeitet. Dieses Design beseitigt Ausfallzeiten und ermöglicht sofortiges Failover, erfordert aber auch eine präzise Planung, um Konsistenz, Routing und Kosten über verteilte Systeme hinweg zu verwalten.

Wählen Sie einen von zwei Bereitstellungsansätzen aus:

• Aktiv aktiv (in Kapazität): Gespiegelte Bereitstellungsstempel oder Geoden in zwei oder mehr Regionen, in denen jede Region einen Anteil der Produktionslast verarbeitet und die volle Last während des regionalen Ausfalls aufnehmen kann.

• Aktiv (überprovisioniert): Gespiegelte Bereitstellungsstempel oder Geoden in zwei oder mehr Regionen. Jede Region ist jederzeit voll betriebsbereit, um unabhängig 100% des Datenverkehrs zu bewältigen.

Hinweis

Wenn ein Fehler auftritt, bleibt die Benutzererfahrung in aktiven Szenarien möglicherweise nicht betroffen, da sich die Last in die verbleibenden Instanzen verschiebt. Notfallwiederherstellungsbemühungen sind jedoch weiterhin erforderlich, um die fehlgeschlagene Instanz wiederherzustellen.

Empfohlene Maßnahmen

Bauen Sie auf die Wiederherstellungsstrategien für aktiv-passiv (Warmstandby) auf. Erweitern Sie es nach Bedarf.

Aktionen	Konfiguration	Validation
Konfigurieren der sekundären Region mit voller Kapazität	– Sekundärregion mit voller Kapazität auf dem Niveau der Primärregion bereitstellen	– Überprüfen, ob die sekundäre Region sofort die vollständige Auslastung unterstützen kann, wenn die primäre Region ausfällt
Konfigurieren des Lastenausgleichs zum Verteilen des Datenverkehrs über aktive Instanzen	- Azure Front Door oder Traffic Manager mit latenzbasiertem oder gewichteten Routing – Diagnosesonden, die pro Endpunkt konfiguriert sind - Automatische Umleitung des Datenverkehrs bei der Fehlererkennung	– Testen von Failoverszenarien in allen Regionen Überprüfung der Genauigkeit und der Antwortzeiten der Gesundheitsüberprüfung Überprüfen Sie die Verkehrslenkung während simulierter Ausfälle.
Konfigurieren des Ladeverteilungsverhaltens	– Dokumentladeschwellenwert, den jede Region während des Normalbetriebs verarbeitet – Erwartetes Leistungs- und Skalierungsverhalten, wenn Peerregion fehlschlägt – Definieren des Systemverhaltens unter Ausfall einer Region, teilweise Dienstunterbrechung, Netzwerkpartitionierung	- Testen regionaler Fehlerszenarien unter Auslastung – Überprüfen von Leistungsbeeinträchtigungsgrenzwerten - Testen der Netzwerkpartitionsbehandlung

Nächste Schritte

• RE:09 Architekturstrategien für die Entwicklung einer Notfallwiederherstellungsstrategie

• RE:05 Architekturstrategien für das Entwerfen von Redundanz