Empfehlungen zum Entwerfen einer Strategie für die Notfallwiederherstellung

  • Artikel

Gilt für die folgende Prüfliste für die Zuverlässigkeit von Azure Well-Architected Framework:

RE:09 Implementieren Sie strukturierte, getestete und dokumentierte BcDR-Pläne (Business Continuity and Disaster Recovery), die an den Wiederherstellungszielen ausgerichtet sind. Pläne müssen alle Komponenten und das System als Ganzes abdecken.

In diesem Leitfaden werden Empfehlungen zum Entwerfen einer zuverlässigen Notfallwiederherstellungsstrategie für eine Workload beschrieben. Um interne Servicelevelziele (Service Level Objectives, SLOs) oder sogar eine Vereinbarung zum Servicelevel (SERVICE Level Agreement, SLA) zu erreichen, die Sie für Ihre Kunden garantiert haben, benötigen Sie eine robuste und zuverlässige Notfallwiederherstellungsstrategie. Fehler und andere wichtige Probleme werden erwartet. Ihre Vorbereitungen für die Behandlung dieser Vorfälle bestimmen, wie sehr Ihre Kunden Ihrem Unternehmen vertrauen können, um zuverlässig für sie zu liefern. Eine Notfallwiederherstellungsstrategie ist das Rückgrat der Vorbereitung auf größere Incidents.

Definitionen

Begriff Definition
Failover Die automatisierte und/oder manuelle Verlagerung des Datenverkehrs von Produktionsworkloads aus einer nicht verfügbaren Region in eine nicht betroffene geografische Region.
Failback Die automatisierte und/oder manuelle Verschiebung des Produktionsworkloaddatenverkehrs von einer Failoverregion zurück in die primäre Region.

Wichtige Entwurfsstrategien

In diesem Leitfaden wird davon ausgegangen, dass Sie im Rahmen Ihrer Zuverlässigkeitsplanung bereits die folgenden Aufgaben ausgeführt haben:

Eine zuverlässige Notfallwiederherstellungsstrategie baut auf der Grundlage einer zuverlässigen Workloadarchitektur auf. Achten Sie auf zuverlässigkeit in jeder Phase der Erstellung Ihrer Workload, um sicherzustellen, dass die erforderlichen Teile für eine optimierte Wiederherstellung vorhanden sind, bevor Sie mit dem Entwerfen Ihrer Notfallwiederherstellungsstrategie beginnen. Diese Grundlage stellt sicher, dass die Zuverlässigkeitsziele Ihrer Workload, z. B. Recovery Time Objective (RTO) und Recovery Point Objective (RPO), realistisch und erreichbar sind.

Verwalten eines Notfallwiederherstellungsplans

Der Eckpfeiler einer zuverlässigen Notfallstrategie für eine Workload ist der DrW-Plan. Ihr Plan sollte ein lebendiges Dokument sein, das regelmäßig überprüft und aktualisiert wird, wenn sich Ihre Umgebung weiterentwickelt. Stellen Sie den Plan regelmäßig (z. B. alle sechs Monate) den entsprechenden Teams vor (Betriebsbetrieb, Technologieführer und Geschäftsbeteiligte). Speichern Sie sie in einem hochverfügbaren, sicheren Datenspeicher wie OneDrive for Business.

Befolgen Sie die folgenden Empfehlungen, um Ihren Notfallplan zu entwickeln:

  • Definieren Sie eindeutig, was eine Katastrophe darstellt und daher die Aktivierung des DR-Plans erfordert.

    • Katastrophen sind große Probleme. Dies können regionale Ausfälle, Ausfälle von Diensten wie Microsoft Entra-ID oder Azure DNS oder schwerwiegende böswillige Angriffe wie Ransomware-Angriffe oder DDoS-Angriffe sein.

    • Identifizieren Sie Fehlermodi, die nicht als Katastrophen betrachtet werden, z. B. der Ausfall einer einzelnen Ressource, damit Operatoren ihre Notfallwiederherstellung nicht versehentlich aufrufen.

  • Erstellen Sie den DR-Plan in Ihrer FMA-Dokumentation. Stellen Sie sicher, dass Ihr Notfallplan die Fehlermodi und Strategien zur Vermeidung von Ausfällen erfasst, die als Katastrophen definiert sind. Aktualisieren Sie sowohl Ihren DrW-Plan als auch Ihre FMA-Dokumente parallel, damit sie genau sind, wenn sich die Umgebung ändert oder wenn tests unerwartete Verhaltensweisen entdecken.

    • Ob Sie Notfallwiederherstellungspläne für Nichtproduktionsumgebungen entwickeln, hängt von Ihren Geschäftlichen Anforderungen und Kostenauswirkungen ab. Wenn Sie beispielsweise qualitätssichernde Umgebungen (QA) für bestimmte Kunden für Vorabtests anbieten, sollten Sie diese Umgebungen in Ihre Notfallplanung einbeziehen.

  • Definieren Sie klar Rollen und Verantwortlichkeiten innerhalb des Workloadteams und verstehen Sie alle zugehörigen externen Rollen innerhalb Ihres organization. Rollen sollten folgendes umfassen:

    • Die partei, die für die Deklarierung eines Notfalls verantwortlich ist.

    • Die partei, die für die Erklärung des Incident-Abschlusses verantwortlich ist.

    • Betriebsrollen.

    • Test- und Validierungsrollen.

    • Interne und externe Kommunikationsrollen.

    • Hauptrollen für retrospektive und Grundursachenanalyse (RCA).

  • Definieren Sie die Eskalationspfade, die das Workloadteam befolgen muss, um sicherzustellen, dass die Wiederherstellung status den Beteiligten mitgeteilt wird.

  • Erfassen Sie Wiederherstellungsprozeduren auf Komponentenebene, Wiederherstellung auf Datenstandsebene und workloadweite Wiederherstellungsprozesse. Fügen Sie eine vorgeschriebene Reihenfolge von Vorgängen ein, um sicherzustellen, dass Komponenten auf die geringste Auswirkung wiederhergestellt werden. Stellen Sie beispielsweise Datenbanken wieder her, und überprüfen Sie sie, bevor Sie die Anwendung wiederherstellen.

    • Beschreiben Sie die einzelnen Wiederherstellungsprozeduren auf Komponentenebene als schrittweise Anleitung. Fügen Sie nach Möglichkeit Screenshots ein.

    • Definieren Sie die Verantwortlichkeiten Ihres Teams im Vergleich zu den Verantwortlichkeiten Ihres Cloudhostinganbieters. Microsoft ist beispielsweise für die Wiederherstellung eines PaaS (Platform-as-a-a-Service) verantwortlich, aber Sie sind für das Rehydrieren von Daten und das Anwenden Ihrer Konfiguration auf den Dienst verantwortlich.

    • Schließen Sie die Voraussetzungen für die Ausführung der Prozedur ein. Listen Sie beispielsweise die erforderlichen Skripts oder Anmeldeinformationen auf, die gesammelt werden müssen.

    • Erfassen Sie die Grundursache des Incidents, und führen Sie die Entschärfung durch, bevor Sie mit der Wiederherstellung beginnen. Wenn die Ursache des Incidents beispielsweise ein Sicherheitsproblem ist, beheben Sie dieses Problem, bevor Sie die betroffenen Systeme in Ihrer Failoverumgebung wiederherstellen.

  • Je nach Redundanzentwurf für Ihre Workload müssen Sie möglicherweise erhebliche Nachfailoverarbeiten ausführen, bevor Sie die Workload Ihren Kunden wieder zur Verfügung stellen. Nach dem Failover können DNS-Updates, Datenbank-Verbindungszeichenfolge-Updates und Änderungen des Datenverkehrsroutings verwendet werden. Erfassen Sie alle Nachfailoverarbeiten in Ihren Wiederherstellungsprozeduren.

    Hinweis

    Ihr Redundanzentwurf ermöglicht es Ihnen möglicherweise, nach wichtigen Vorfällen vollständig oder teilweise automatisch wiederherzustellen. Stellen Sie daher sicher, dass Ihr Plan Prozesse und Verfahren in diesen Szenarien enthält. Wenn Sie beispielsweise über einen vollständig aktiv-aktiven Entwurf verfügen, der Verfügbarkeitszonen oder -regionen umfasst, können Sie nach einer Verfügbarkeitszone oder einem regionalen Ausfall möglicherweise ein automatisches Failover durchführen und die schritte in Ihrem Notfallplan minimieren, die ausgeführt werden müssen. Wenn Sie Ihre Workload mithilfe von Bereitstellungsstempeln entworfen haben, kann es auch nur zu einem teilweisen Ausfall kommen, wenn die Stempel zonenweise bereitgestellt werden. In diesem Fall sollte Ihr Notfallplan die Wiederherstellung von Stempeln in nicht betroffenen Zonen oder Regionen abdecken.

  • Wenn Sie Ihre App in der Failoverumgebung erneut bereitstellen müssen, verwenden Sie Tools, um den Bereitstellungsprozess so weit wie möglich zu automatisieren. Stellen Sie sicher, dass Ihre DevOps-Pipelines in den Failoverumgebungen vorab bereitgestellt und konfiguriert wurden, sodass Sie sofort mit der App-Bereitstellung beginnen können. Verwenden Sie bei Bedarf automatisierte End-to-End-Bereitstellungen mit manuellen Genehmigungsgates, um einen konsistenten und effizienten Bereitstellungsprozess sicherzustellen. Die gesamte Bereitstellungsdauer muss an Ihren Wiederherstellungszielen ausgerichtet sein.

    • Wenn eine Phase des Bereitstellungsprozesses einen manuellen Eingriff erfordert, dokumentieren Sie die manuellen Schritte. Definieren Sie Rollen und Verantwortlichkeiten klar.

  • Automatisieren Sie so viel wie möglich. Verwenden Sie in Ihren Skripts die deklarative Programmierung, da sie Idempotenz zulässt. Wenn Sie die deklarative Programmierung nicht verwenden können, sollten Sie ihren benutzerdefinierten Code entwickeln und ausführen. Verwenden Sie Wiederholungslogik und Leitungsschalterlogik, um Zeit für Skripts zu vermeiden, die bei einer fehlerhaften Aufgabe hängen bleiben. Da Sie diese Skripts nur in Notfällen ausführen, möchten Sie nicht, dass falsch entwickelte Skripts mehr Schaden verursachen oder Ihren Wiederherstellungsprozess verlangsamen.

    Hinweis

    Automatisierung birgt Risiken. Geschulte Bediener müssen die automatisierten Prozesse sorgfältig überwachen und eingreifen, wenn bei einem Prozess Probleme auftreten. Um das Risiko zu minimieren, dass die Automatisierung auf falsch positive Ergebnisse reagiert, führen Sie gründliche Übungen zur Notfallwiederherstellung durch. Testen Sie alle Phasen des Plans. Simulieren Sie die Erkennung, um Warnungen zu generieren, und durchlaufen Sie dann den gesamten Wiederherstellungsvorgang.

    Denken Sie daran, dass Ihre Notfallwiederherstellungs-Drills Updates für Ihre Wiederherstellungszielmetriken überprüfen oder informieren sollten. Wenn Sie feststellen, dass Ihre Automatisierung anfällig für falsch positive Ergebnisse ist, müssen Sie möglicherweise Ihre Failoverschwellenwerte erhöhen.

  • Trennen Sie den Failbackplan vom Notfallplan, um potenzielle Verwechslungen mit den DrW-Verfahren zu vermeiden. Der Failbackplan sollte allen Entwicklungs- und Wartungsempfehlungen des Notfallwiederherstellungsplans entsprechen und auf die gleiche Weise strukturiert sein. Alle manuellen Schritte, die für das Failover erforderlich waren, sollten im Failbackplan gespiegelt werden. Das Failback kann nach dem Failover schnell erfolgen, oder es kann Tage oder Wochen dauern. Betrachten Sie das Failback als getrennt vom Failover.

    • Die Notwendigkeit eines Failbacks ist situationslogisch. Wenn Sie Datenverkehr aus Leistungsgründen zwischen Regionen weiterleiten, ist ein Fehler beim Zurücksetzen der ursprünglichen Last in der Failoverregion wichtig. In anderen Fällen haben Sie Ihre Workload möglicherweise so konzipiert, dass sie jederzeit vollständig funktioniert, unabhängig davon, in welcher Produktionsumgebung sie sich befindet.

Durchführen von Drills zur Notfallwiederherstellung

Eine DR-Testpraxis ist genauso wichtig wie ein gut entwickelter Notfallplan. Viele Branchen verfügen über Complianceframeworks, für die eine bestimmte Anzahl von Übungen zur Notfallwiederherstellung regelmäßig ausgeführt werden muss. Unabhängig von Ihrer Branche sind regelmäßige DR-Übungen für Ihren Erfolg von entscheidender Bedeutung.

Befolgen Sie die folgenden Empfehlungen für erfolgreiche Übungen zur Notfallwiederherstellung:

  • Führen Sie pro Jahr mindestens eine Bohrmaschine für die Produktion aus. Tabletop-Drills (Dry Run) oder Nichtproduktionsübungen tragen dazu bei, dass die beteiligten Parteien mit ihren Rollen und Verantwortlichkeiten vertraut sind. Diese Drills helfen Operatoren auch beim Aufbau von Vertrautheit ("Muskelgedächtnis"), indem sie Wiederherstellungsprozesse ausführen. Aber nur Produktionsübungen testen wirklich die Gültigkeit des Notfallplans und der RTO- und RPO-Metriken. Verwenden Sie Ihre Produktionsbohrungen, um Wiederherstellungsprozesse für Komponenten und Flows zu planen, um sicherzustellen, dass die für Ihre Workload definierten RTO- und RPO-Ziele erreichbar sind. Stellen Sie bei Funktionen, die außerhalb Ihrer Kontrolle liegen, wie z. B. dns-Weitergabe, sicher, dass die RTO- und RPO-Ziele für die Flows, die diese Funktionen umfassen, für mögliche Verzögerungen verantwortlich sind, die außerhalb Ihrer Kontrolle liegen.

  • Verwenden Sie Tabletop-Drills nicht nur, um Vertrautheit für erfahrene Operatoren zu schaffen, sondern auch, um neue Operatoren über DrW-Prozesse und -Verfahren zu informieren. Senior Operatoren sollten sich Zeit nehmen, um neuen Operatoren ihre Rolle zu überlassen, und sollten nach Verbesserungsmöglichkeiten watch. Wenn ein neuer Operator durch einen Schritt in einem Verfahren zögerlich oder verwirrt ist, überprüfen Sie dieses Verfahren, um sicherzustellen, dass er eindeutig geschrieben ist.

Überlegungen

  • Die Durchführung von DR-Drills in der Produktion kann zu unerwarteten schwerwiegenden Fehlern führen. Stellen Sie sicher, dass Sie die Wiederherstellungsprozeduren in nicht produktiven Umgebungen während Der ersten Bereitstellung testen.

  • Geben Sie Ihrem Team während der Drills so viel Wartungszeit wie möglich. Verwenden Sie bei der Planung der Wartungszeit die Wiederherstellungsmetriken, die Sie während des Tests erfassen, als erforderliche Mindestdauer für Kontingente.

  • Wenn Ihre Dr-Übungen gereift sind, erfahren Sie, welche Prozeduren Parallele ausgeführt werden können und welche Sie nacheinander ausführen müssen. Gehen Sie zu Beginn ihrer Drillmethoden davon aus, dass jede Prozedur nacheinander ausgeführt werden muss und dass Sie in jedem Schritt zusätzliche Zeit benötigen, um unerwartete Probleme zu behandeln.

Azure-Erleichterung

Viele Azure-Produkte verfügen über integrierte Failoverfunktionen. Machen Sie sich mit diesen Funktionen vertraut und beziehen Sie sie in Wiederherstellungsverfahren ein.

Verwenden Sie für IaaS-Systeme (Infrastructure-as-a-Service) Azure Site Recovery, um Failover und Wiederherstellung zu automatisieren. In den folgenden Artikeln finden Sie gängige PaaS-Produkte:

Beispiel

Anleitungen zum Vorbereiten eines Unternehmensdatenbestands für die Notfallwiederherstellung finden Sie in der Serie DR für Azure-Datenplattform .

Prüfliste für zuverlässigkeit

Weitere Informationen finden Sie im vollständigen Satz von Empfehlungen.

Prüfliste für zuverlässigkeit