Übersicht
Diese Reihe enthält ein illustratives Beispiel dafür, wie eine Organisation eine Notfallwiederherstellungsstrategie (DR) für eine Azure-Unternehmensdatenplattform entwerfen kann.
- Diese Artikelreihe ergänzt die Anleitungen des Microsoft Cloud Adoption Framework, des Azure Well-Architected Framework und des Business Continuity Management.
Azure bietet eine breite Palette von Resilienzoptionen, die Dienstkontinuität im Notfall gewährleisten können. Mit höheren Dienstebenen steigen jedoch häufig Komplexität und Kosten. Der Kompromiss zwischen Kosten, Resilienz und Komplexität ist für die meisten Kunden der wichtigste Entscheidungsfaktor in Bezug auf die Notfallwiederherstellung.
Während gelegentliche Fehler auf der Azure-Plattform auftreten, verfügen die Azure-Rechenzentren und Azure-Dienste von Microsoft über mehrere Ebenen von Redundanz. Jeder Fehler ist normalerweise im Umfang begrenzt und wird in der Regel innerhalb von Stunden behoben. Historisch gesehen ist es viel wahrscheinlicher, dass ein wichtiger Dienst, z. B. identitätsverwaltung, ein Dienstproblem auftritt, anstatt eine gesamte Azure-Region offline zu schalten.
Sie sollten auch berücksichtigen, dass Cyberangriffe, insbesondere Ransomware, jetzt eine handfeste Bedrohung für jedes moderne Datenökosystem darstellen und zu einem Ausfall der Datenplattform führen können. Auch wenn dies in dieser Reihe nicht behandelt wird, sollten Kunden nichtsdestoweniger im Sicherheits- und Resilienzentwurf jeder Datenplattform auf solche Angriffe zielende Kontrollen implementieren.
- Eine Microsoft-Anleitung zum Schutz vor Ransomware finden Sie in den Cloudgrundlagen von Azure.
`Scope`
Der Umfang dieser Artikelreihe umfasst Folgendes:
- Die Dienstwiederherstellung einer Azure-Datenplattform nach einem physischen Notfall für einen Beispielkunden. Dieser Beispielkunde ist:
- Eine mittlere Organisation mit einer definierten operativen Unterstützungsfunktion nach einer ITIL-basierten Methodik (Information Technology Infrastructure Library).
- Nicht cloudnativ, mit seinem Kernunternehmen, gemeinsame Dienste wie Zugriff und Authentifizierungsverwaltung und Vorfallverwaltung bleiben lokal.
- Auf dem Weg der Cloudmigration zu Azure, aktiviert durch Automatisierung.
- Die Azure-Datenplattform hat die folgenden Designs innerhalb des Azure-Mandanten des Kunden implementiert:
- Unternehmenslandungszone – Bereitstellen der Plattformbasis, einschließlich Netzwerk, Überwachung, Sicherheit usw.
- Azure Analytics-Plattform – Bereitstellen der Datenkomponenten, die die verschiedenen Lösungen und Datenprodukte unterstützen, die vom Dienst bereitgestellt werden.
- Die in diesem Artikel beschriebenen Prozesse werden von einer technischen Azure-Ressource anstelle eines spezialisierten Azure-Fachexperten (SME) ausgeführt. Daher sollten die Ressourcen über die folgenden Kenntnisse/Fähigkeiten verfügen:
- Azure Fundamentals – Arbeitswissen über Azure, seine Kerndienste und Datenkomponenten.
- Fundierte Kenntnisse von Azure DevOps. In der Lage, in der Quellcodeverwaltung zu navigieren und Pipelinebereitstellungen auszuführen.
- Diese In diesem Artikel beschriebenen Prozesse behandeln Dienstfailovervorgänge von der primären bis zur sekundären Region.
Nicht betreffende Organisationen
Die folgenden Punkte werden in dieser Artikelreihe nicht behandelt:
- Der Fallbackprozess von der sekundären Region zurück zur primären Region.
- Alle Nicht-Azure-Anwendungen, -Komponenten oder -Systeme – dies umfasst, aber nicht auf lokale, andere Cloudanbieter, Webdienste von Drittanbietern usw. beschränkt ist.
- Wiederherstellung von upstream-Diensten, z. B. lokale Netzwerke, Gateways, gemeinsame Unternehmensdienste und andere, unabhängig von Abhängigkeiten von diesen Diensten.
- Wiederherstellung von nachgelagerten Diensten, z. B. lokale Betriebssysteme, Berichterstellungssysteme von Drittanbietern, Datenmodellierung oder Data Science-Anwendungen und andere, unabhängig von abhängigkeiten von diesen Diensten.
- Datenverlustszenarien, einschließlich Wiederherstellung von Ransomware oder ähnlichen Datensicherheitsvorfällen
- Strategien zur Datensicherung und Datenwiederherstellungspläne
- Einrichten der Stammursache eines DR-Ereignisses.
- Für Azure-Service-/Komponentenvorfälle veröffentlicht Microsoft eine „Analyse der Grundursache“ auf der Webseite „Status – Verlauf“
Wichtige Annahmen
Die wichtigsten Annahmen für dieses DR-Beispiel sind:
- Die Organisation folgt einer ITIL-basierten Dienstverwaltungsmethode für die operative Unterstützung der Azure-Datenplattform.
- Die Organisation verfügt über einen vorhandenen Notfallwiederherstellungsprozess als Teil des Dienstwiederherstellungsframeworks für IT-Ressourcen.
- Die Infrastruktur als Code (IaC) wurde verwendet, um die Azure-Datenplattform bereitzustellen, die von einem Automatisierungsdienst aktiviert wird, z. B. Azure DevOps oder ähnlich.
- Jede lösung, die von der Azure-Datenplattform gehostet wird, hat eine Business Impact Assessment oder ähnliche abgeschlossen, die klare Serviceanforderungen für das Wiederherstellungspunktziel (RPO), das Wiederherstellungszeitziel (Recovery Time Objective, RTO) und die mittlere Zeit für die Wiederherstellung (MTTR) Metriken bereitstellt.
Nächste Schritte
Nachdem Sie nun allgemeine Informationen über das Szenario erhalten haben, können Sie sich mit der für den Anwendungsfall entwickelten Architektur vertraut machen.