Bearbeiten

Freigeben über

Notfallwiederherstellung für Azure-Datenplattform: Bereitstellen des Szenarios

Azure Synapse Analytics
Azure Machine Learning
Azure Cosmos DB
Azure Data Lake
Azure Event Hubs

Kundenaktivitäten erforderlich

Vor dem Vorfall

Für Azure-Dienste

  • Machen Sie sich mit Azure Service Health im Azure-Portal vertraut. Diese Seite fungiert während eines Vorfalls als "One-Stop-Shop".
  • Erwägen Sie die Verwendung von Dienststatuswarnungen, die so konfiguriert werden können, dass automatisch Benachrichtigungen generiert werden, wenn Azure-Vorfälle auftreten.

Für Power BI

  • Machen Sie sich mit Service Health im Microsoft 365 Admin Center vertraut. Diese Seite fungiert während eines Vorfalls als "One-Stop-Shop".
  • Erwägen Sie die Verwendung der mobilen Microsoft 365 Admin-App , um automatische Benachrichtigungen über Dienstvorfälle zu erhalten.

Während des Vorfalls

Für Azure-Dienste

  • Azure Service Health im Azure-Verwaltungsportal stellt die neuesten Updates bereit.
    • Wenn Probleme beim Zugriff auf den Dienststatus auftreten, lesen Sie die Azure-Statusseite.
    • Wenn es jemals Probleme beim Zugriff auf die Statusseite gibt, wechseln Sie zu @AzureSupport X (vormals Twitter).
  • Wenn Die Auswirkungen/Probleme nicht mit dem Vorfall übereinstimmen (oder nach der Entschärfung beibehalten werden), wenden Sie sich an den Support , um ein Servicesupportticket auszuheben.

Für Power BI

  • Auf der Seite Dienststatus im Microsoft 365 Admin Center werden die neuesten Updates bereitgestellt
    • Wenn Probleme beim Zugriff auf Service Health auftreten, beachten Sie die Informationen auf der Seite zum Microsoft 365-Status.
    • Wenn die Auswirkungen/Probleme nicht zum Vorfall passen (oder nach der Entschärfung weiter bestehen), sollten Sie ein Supportticket öffnen.

Nach der Wiederherstellung durch Microsoft

Weitere Informationen finden Sie in den folgenden Abschnitten.

Nach einem Vorfall

Für Azure Services

Für Power BI

Prozess „Warten auf Microsoft“

Der Prozess „Warten auf Microsoft“ bedeutet einfach, dass gewartet wird, bis Microsoft alle Komponenten und Services in der betroffenen primären Region wiederhergestellt hat. Überprüfen Sie nach der Wiederherstellung die Bindung der Datenplattform an gemeinsam genutzte Unternehmensdienste oder andere Dienste sowie das Datum des Datasets. Führen Sie anschließend die erforderlichen Prozesse aus, um das System auf den aktuellen Stand zu bringen.

Sobald dieser Vorgang abgeschlossen ist, kann eine Validierung durch technische und geschäftliche Fachleute (SME) durchgeführt werden, um die Dienstwiederherstellung durch die Projektbeteiligten zu bestätigen.

Neubereitstellung bei einem Notfall

Für eine "Redeploy on Disaster"-Strategie kann der folgende allgemeine Prozessfluss beschrieben werden.

  1. Wiederherstellen von gemeinsamen Unternehmensdiensten und Quellsystemen von Contoso

    Abbildung: Wiederherstellung der gemeinsam genutzten Dienste und Quellsysteme von Contoso

    • Dieser Schritt ist eine Voraussetzung für die Wiederherstellung der Datenplattform.
    • Dieser Schritt würde durch die verschiedenen operativen Supportgruppen von Contoso abgeschlossen, die für die gemeinsamen Unternehmensdienste und betriebsbereiten Quellsysteme verantwortlich sind.

  2. Wiederherstellung der Azure-Dienste: Der Begriff „Azure-Dienste“ bezieht sich auf die Anwendungen und Dienste, aus denen sich das Azure-Cloudangebot zusammensetzt und die in der sekundären Region für die Bereitstellung zur Verfügung stehen.

    Abbildung: Wiederherstellung der Azure-Dienste

    Der Begriff „Azure-Dienste“ bezieht sich auf die Anwendungen und Dienste, aus denen sich das Azure-Cloudangebot zusammensetzt und die in der sekundären Region für die Bereitstellung zur Verfügung stehen.

    • Dieser Schritt ist eine Voraussetzung für die Wiederherstellung der Datenplattform.
    • Dieser Schritt würde von Microsoft und anderen Plattform as a Service (PaaS)/Software as a Service (SaaS)-Partnern abgeschlossen.

  3. Wiederherstellung der grundlegenden Systeme der Datenplattform

    Abbildung: Wiederherstellung der grundlegenden Systeme der Datenplattform

    • Dieser Schritt ist der Einstiegspunkt für die Plattformwiederherstellungsaktivitäten.
    • Für die Strategie für die Erneute Bereitstellung werden alle erforderlichen Komponenten/Dienste in der sekundären Region bereitgestellt und bereitgestellt.
    • Dieser Prozess sollte auch Aktivitäten wie die Bindung an die gemeinsam genutzten Unternehmensdienste umfassen, die Konnektivität für den Zugriff/die Authentifizierung sicherstellen und überprüfen, ob das Abmelden funktioniert, und gleichzeitig die Konnektivität mit upstream- und downstream-Prozessen sicherstellen.
    • Daten und Verarbeitung müssen überprüft werden. Beispiel: Überprüfung des Zeitstempels der wiederhergestellten Plattform.
      • Wenn Es Fragen zur Datenintegrität gibt, könnte die Entscheidung getroffen werden, einen Rollback weiter in der Zeit durchzuführen, bevor die neue Verarbeitung ausgeführt wird, um die Plattform auf dem neuesten Stand zu bringen.
    • Die Prioritätsreihenfolge für Prozesse (basierend auf geschäftlichen Auswirkungen) hilft bei der Orchestrierung der Wiederherstellung.
    • Dieser Schritt sollte durch eine technische Überprüfung ergänzt werden, sofern die Geschäftsbenutzer nicht direkt mit den Diensten interagieren. Wenn es direkten Zugriff gibt, muss ein Schritt für die Überprüfung eines Unternehmens erfolgen.
    • Nach Abschluss der Überprüfung erfolgt eine Übergabe an die einzelnen Lösungsteams, um ihren eigenen Notfallwiederherstellungsprozess (DR) zu starten.
      • Diese Übergabe sollte die Bestätigung des aktuellen Zeitstempels der Daten und Prozesse umfassen.
      • Wenn kernige Enterprise-Datenprozesse ausgeführt werden, sollten die einzelnen Lösungen darauf aufmerksam gemacht werden – z. B. eingehende/ausgehende Abläufe.

  4. Wiederherstellung der einzelnen Lösungen, die von der Plattform gehostet werden

    Abbildung: Wiederherstellung der einzelnen Plattformsysteme

    • Für jede Lösung sollte ein eigenes Runbook für die Notfallwiederherstellung vorhanden sein. Die Runbooks sollten zumindest die nominierten Geschäftsbeteiligten enthalten, die testen und bestätigen, dass die Dienstwiederherstellung abgeschlossen wurde.
    • Je nach Ressourcenkonflikt oder Priorität können wichtige Lösungen/Workloads gegenüber anderen priorisiert werden – z. B. zentrale Enterprise-Prozesse über Ad-hoc-Labore.
    • Nachdem die Validierungsschritte abgeschlossen wurden, erfolgt eine Übergabe an die nachgelagerten Lösungen, um ihren DR-Wiederherstellungsprozess zu starten.

  5. Übergabe an nachgelagerte, abhängige Systeme

    Abbildung: abhängige Systeme

    • Sobald die abhängigen Dienste wiederhergestellt wurden, ist der E2E DR-Wiederherstellungsvorgang abgeschlossen.

    Hinweis

    Obwohl es theoretisch möglich ist, einen E2E DR-Prozess vollständig zu automatisieren, ist es unwahrscheinlich, dass das Risiko des Ereignisses im Vergleich zu den Kosten der SDLC-Aktivitäten, die für die Deckung des E2E-Prozesses erforderlich sind, unwahrscheinlich ist.

  6. Fallback auf primäre Region: Ein Fallback ist der Prozess, bei dem der Datenplattformdienst und die zugehörigen Daten in die primäre Region zurückverlagert werden, sobald diese wieder für den normalen Geschäftsbetrieb zur Verfügung stehen.

Je nach Art der Quellsysteme und der verschiedenen Datenprozesse kann ein Fallback der Datenplattform unabhängig von anderen Teilen des Datenökosystems erfolgen.

Kunden wird empfohlen, die (sowohl vor- als auch nachgelagerten) Abhängigkeiten ihrer eigenen Datenplattform zu überprüfen, um die richtige Entscheidung zu treffen. Im folgenden Abschnitt wird von einer unabhängigen Wiederherstellung der Datenplattform ausgegangen.

  • Sobald alle erforderlichen Komponenten/Dienste in der primären Region verfügbar sind, würden Kunden einen Rauchtest durchführen, um die Microsoft-Wiederherstellung zu überprüfen.
  • Validierung der Komponenten-/Dienstkonfiguration. Deltas würden über eine erneute Bereitstellung aus der Quellcodeverwaltung adressiert werden.
  • Das Systemdatum in der primären Region wird über zustandsabhängige Komponenten festgelegt. Das Delta zwischen dem festgelegten Datum und dem Datums-/Zeitstempel in der sekundären Region sollte durch erneutes Ausführen oder Wiedergeben der Datenaufnahmeprozesse von diesem Punkt nach vorne behoben werden.
  • Mit Genehmigung durch die geschäftlichen und technischen Projektbeteiligten wird ein Fallbackfenster ausgewählt. Im Idealfall sollte dies während einer Lull in Systemaktivitäten und -verarbeitungen geschehen.
  • Während des Fallbacks wird die primäre Region mit der sekundären Region synchronisiert, bevor das System umgeschaltet wurde.
  • Nach einem Zeitraum einer parallelen Ausführung wird die sekundäre Region vom System offline geschaltet.
  • Die Komponenten in der sekundären Region würden je nach ausgewählter DR-Strategie entweder verworfen oder entfernt.

Warmer Ersatzprozess

Bei einer „Warm-Spare“-Strategie ist der allgemeine Prozessablauf eng an die Strategie zur Neubereitstellung bei einem Notfall angelehnt. Der Hauptunterschied besteht darin, dass die Komponenten in der sekundären Region bereits bereitgestellt wurden. Bei dieser Strategie entfällt das Risiko von Ressourcenkonflikten mit anderen Organisationen, die ihre eigene Notfallwiederherstellung in dieser Region durchführen möchten.

Hot Spare-Prozess

Bei der „Hot-Spare“-Strategie bleiben die Plattformdienste (PaaS- und Infrastructure-as-a-Service (IaaS)-Systeme eingeschlossen) auch im Katastrophenfall erhalten, da die sekundären Systeme parallel zu den primären Systemen betrieben werden. Wie bei der „Warm-Spare“-Strategie entfällt bei dieser Strategie das Risiko von Ressourcenkonflikten mit anderen Organisationen, die ihre eigene Notfallwiederherstellung in dieser Region durchführen möchten.

Kunden mit einem Hot-Spare-System überwachen die Wiederherstellung der Komponenten/Dienste in der primären Region durch Microsoft. Nach Abschluss der Wiederherstellung validieren die Kunden die Systeme der primären Region und führen ein Fallback zur primären Region durch. Dieser Prozess ähnelt dem Failoverprozess bei der Notfallwiederherstellung, d. h. die verfügbare Codebasis und die Daten werden überprüft und bei Bedarf neu bereitgestellt.

Hinweis

Achten Sie hier besonders darauf, dass alle Systemmetadaten zwischen den beiden Regionen konsistent sind.

  • Sobald das Fallback auf die primäre Region abgeschlossen ist, können die Lastenausgleichsmodule des Systems aktualisiert werden, um die primäre Region wieder in die Systemtopologie aufzunehmen. Sofern verfügbar, kann ein Canary-Release-Ansatz genutzt werden, um die primäre Region stufenweise für das System zu aktivieren.

Aufbau des Notfallwiederherstellungsplans

Ein effizienter DR-Plan enthält eine Schrittanleitung für die Dienstwiederherstellung, die von einem Mitglied des technischen Azure-Teams ausgeführt werden kann. Deshalb wird im Folgenden eine MVP-Struktur für einen Notfallwiederherstellungsplan vorgeschlagen.

  • Prozessanforderungen
    • Alle prozessspezifischen Details des Kunden-DR, z. B. die richtige Autorisierung, die für den Start von DR erforderlich ist, und wichtige Entscheidungen zur Wiederherstellung nach Bedarf treffen (einschließlich "Definition der erledigten" Serviceunterstützung), Support-DR-Ticketingreferenz und War room Details.
    • Bestätigung der verantwortlichen Personen, einschließlich Leitung der Notfallwiederherstellung (DR) und einer Stellvertretung für die ausführenden Mitarbeiter. Alle Beteiligten sollten mit primären und sekundären Kontakten, Eskalationspfaden und Urlaubskalendern dokumentiert werden. In kritischen DR-Situationen müssen Listensysteme möglicherweise berücksichtigt werden.
    • Laptop, Power Packs oder Backup-Strom, Netzwerkkonnektivität und Mobiltelefondetails für den DR-Executor, die DR-Sicherung und alle Eskalationspunkte.
    • Der Prozess, der befolgt werden soll, wenn einer der Prozessanforderungen nicht erfüllt ist.
  • Kontaktauflistung
    • DR-Führungs- und Supportgruppen.
    • Geschäfts-KMU, die den Test-/Prüfzyklus für die technische Erholung abschließen werden.
    • Betroffene Geschäftsbesitzer, einschließlich der Genehmigende der Dienstwiederherstellung.
    • Betroffene technische Eigentümer, einschließlich der Genehmigende für die technische Wiederherstellung.
    • KMU-Unterstützung in allen betroffenen Bereichen, einschließlich der wichtigsten Lösungen, die von der Plattform gehostet werden.
    • Betroffene nachgelagerte Systeme – Betriebsunterstützung.
    • Upstream-Quellsysteme – betriebstechnische Unterstützung.
    • Kontaktinformationen für gemeinsam genutzte Unternehmensdienste Beispiel: Zugriffs- und Authentifizierungsunterstützung, Sicherheitsüberwachung und Gatewayunterstützung
    • Alle externen oder Drittanbieter, einschließlich Supportkontakte für Cloudanbieter.
  • Architekturdesign
    • Beschreiben Sie das Detail des End-End-Szenarios (E2E), und fügen Sie alle zugehörigen Supportdokumentationen an.
  • Abhängigkeiten
    • Listet alle Beziehungen und Abhängigkeiten der Komponenten auf.
  • DR-Voraussetzungen
    • Bestätigung, dass upstream-Quellsysteme nach Bedarf verfügbar sind.
    • Erhöhten Zugriff über den Stapel hinweg wurde den DR-Executorressourcen gewährt.
    • Azure-Dienste sind nach Bedarf verfügbar.
    • Der Prozess, der befolgt werden soll, wenn eine der Voraussetzungen nicht erfüllt wurde.
  • Technische Wiederherstellung – Schrittweise Anleitungen
    • Reihenfolge ausführen.
    • Schrittbeschreibung.
    • Schrittvoraussetzungen.
    • Detaillierte Prozessschritte für jede einzelne Aktion, einschließlich URLs.
    • Validierungsanweisungen, einschließlich der erforderlichen Nachweise.
    • Es wird erwartet, dass jeder Schritt abgeschlossen ist, einschließlich Der unterlassene Zeit.
    • Der Prozess, der befolgt werden soll, wenn der Schritt fehlschlägt.
    • Die Eskalationspunkte bei Ausfall oder KMU-Unterstützung.
  • Technische Wiederherstellung - Postvoraussetzungen
    • Bestätigen Sie den aktuellen Datums-Zeitstempel des Systems über wichtige Komponenten hinweg.
    • Bestätigen Sie die DR-System-URLs & IPs.
    • Bereiten Sie sich auf den Überprüfungsprozess der Geschäftsbeteiligten vor, einschließlich der Bestätigung des Systemzugriffs und der Geschäfts-KMU, die die Validierung und Genehmigung abschließen.
  • Überprüfung und Genehmigung von Geschäftsbeteiligten
    • Kontaktdetails der Geschäftsressource.
    • Die Schritte zur Geschäftlichen Validierung gemäß der oben beschriebenen technischen Wiederherstellung.
    • Der Nachweispfad, der vom Genehmigende des Unternehmens erforderlich ist, um die Wiederherstellung abzuzeichnen.
  • Wiederherstellung nach Voraussetzungen
    • Übergeben Sie die Übergabe an die operative Unterstützung, um die Datenprozesse auszuführen, um das System auf dem neuesten Stand zu bringen.
    • Übergeben Sie die nachgeschalteten Prozesse und Lösungen – die Datums- und Verbindungsdetails des DR-Systems bestätigen.
    • Bestätigen Sie den Wiederherstellungsvorgang vollständig mit dem DR-Lead – bestätigen Sie den Nachweispfad und das abgeschlossene Runbook.
    • Benachrichtigen Sie Sicherheitsteams, dass erhöhte Zugriffsrechte aus dem DR-Team entfernt werden können.

Aufrufe

  • Es wird empfohlen, Systemscreenshots für jeden Schritt beizufügen. Diese Screenshots helfen dabei, die Abhängigkeit von System-KMU zu beheben, um die Aufgaben auszuführen.
    • Um mit den sich schnell entwickelnden Clouddiensten schritt zu halten, sollte der DR-Plan regelmäßig von Ressourcen mit aktuellem Wissen über Azure und seine Dienste überprüft, getestet und ausgeführt werden.
  • Die Schritte zur technischen Wiederherstellung sollten die Priorität der Komponente und der Lösung für die Organisation widerspiegeln. Beispielsweise werden kerne Unternehmensdatenflüsse vor Ad-hoc-Datenanalyselaboren wiederhergestellt.
  • Die technischen Wiederherstellungsschritte sollten die Reihenfolge der Workflows (in der Regel von links nach rechts) befolgen, sobald die Foundation-Komponenten oder der Dienst wie Key Vault wiederhergestellt wurden. Diese Strategie stellt sicher, dass upstream-Abhängigkeiten verfügbar sind und Komponenten entsprechend getestet werden können.
  • Sobald der Plan mit den Einzelschritten fertiggestellt ist, sollte die Gesamtdauer der Aktivitäten unter Berücksichtigung einer Zeitreserve ermittelt werden. Wenn die Gesamtdauer über der vereinbarten Recovery Time Objective (RTO) liegt, gibt es mehrere Möglichkeiten:
    • Automatisieren Sie ausgewählte Wiederherstellungsprozesse (sofern möglich).
    • Suchen Sie nach Möglichkeiten, ausgewählte Wiederherstellungsschritte parallel auszuführen (sofern möglich). Beachten Sie jedoch, dass diese Strategie zusätzliche Ressourcen für die DR-Ausführung erforderlich machen kann.
    • Erhöhen Sie wichtige Komponenten auf höhere Serviceebenen wie PaaS, wo Microsoft größere Verantwortung für Dienstwiederherstellungsaktivitäten übernimmt.
    • Erweitern Sie den RTO mit den Projektbeteiligten.

DR-Tests

Die Beschaffenheit des Azure Cloud-Dienstangebots führt zu Einschränkungen bei allen DR-Testszenarien. Daher wird empfohlen, für die Notfallwiederherstellung ein Abonnement mit den Komponenten der Datenplattform so einzurichten, wie sie in der sekundären Region verfügbar wären.

Ausgehend von dieser Baseline kann das Runbook für den DR-Plan selektiv ausgeführt werden, wobei ein besonderes Augenmerk auf die Dienste und Komponenten gelegt wird, die bereitgestellt und validiert werden können. Für diesen Prozess wird ein kuratiertes Testdataset benötigt, das die Bestätigung der technischen und geschäftlichen Validierungsprüfungen gemäß Plan ermöglicht.

Ein DR-Plan sollte regelmäßig getestet werden. So wird nicht nur sichergestellt, dass der Plan auf dem neuesten Stand ist, sondern auch, dass die zur Durchführung der Failover- und Wiederherstellungsaktivitäten verantwortlichen Teams sich die Verfahren einprägen können.

  • Daten- und Konfigurationssicherungen sollten ebenfalls regelmäßig getestet werden, um sicherzustellen, dass sie für die Unterstützung von Wiederherstellungsaktivitäten geeignet sind.

Bei einem DR-Test müssen Sie vor allem gewährleisten, dass die festgelegten Schritte weiterhin korrekt sind und dass die veranschlagten Zeiträume eingehalten werden.

  • Wenn die Anweisungen sich auf Anleitungen in Portalen und nicht direkt auf den Code beziehen, sollten sie angesichts der Häufigkeit von Änderungen in der Cloud mindestens alle 12 Monate validiert werden.

Auch wenn ein vollständig automatisierter DR-Prozess angestrebt wird, ist eine vollständige Automatisierung aufgrund der Seltenheit des Ereignisses eher unwahrscheinlich. Deshalb ist es empfehlenswert, mit DSC-IaC (Desired State Configuration Infrastructure-as-Code) die Basis für die Wiederherstellung der Plattform zu schaffen und diese dann zu erweitern, wenn neue Projekte auf dieser Basis erstellt und durchgeführt werden.

  • Im Laufe der Zeit, wenn Komponenten und Dienste erweitert werden, sollte mithilfe der Erzwingung einer NFR die Pipeline für die Produktionsbereitstellung so umgestaltet werden, dass sie die Notfallwiederherstellung abdeckt.

Wenn die Zeitvorgaben im Runbook Ihre RTO überschreiten, gibt es mehrere Möglichkeiten:

  • Erweitern Sie den RTO mit den Projektbeteiligten.
  • Verringern Sie die zeitaufwendige Zeit für die Wiederherstellungsaktivitäten über automatisierungsbasierte Aufgaben, die parallel oder migration zu höheren Cloudserverebenen ausgeführt werden.

Azure Chaos Studio

Azure Chaos Studio ist ein verwalteter Dienst zur Verbesserung der Resilienz durch Einschleusung von Fehlern in Ihre Azure-Anwendungen. Mit Chaos Studio können Sie auf sichere und kontrollierte Weise Experimente zur Fehlereinschleusung bei Ihren Azure-Ressourcen durchführen. Eine Beschreibung der derzeit unterstützten Fehlertypen finden Sie in der Produktdokumentation.

Die aktuelle Iteration von Chaos Studio deckt nur eine Teilmenge von Azure-Komponenten und -Diensten ab. Bis weitere Fehlerbibliotheken hinzugefügt werden, empfiehlt sich Chaos Studio eher für isolierte Resilienztests als für DR-Tests des gesamten Systems.

Weitere Informationen zu Chaos Studio finden Sie in der Dokumentation zu Azure Chaos Studio.

Azure Site Recovery

Bei IaaS-Komponenten schützt Azure Site Recovery die meisten Workloads, die auf einer unterstützten VM oder einem physischen Server ausgeführt werden.

Es stehen dringende Empfehlungen für folgende Themen zur Verfügung:

Nächste Schritte

Nachdem Sie nun wissen, wie Sie das Szenario bereitstellen, können Sie mit der Zusammenfassung der Reihe zur Notfallwiederherstellung (DR) für eine Azure-Datenplattform fortfahren.