Übersicht
Diese Reihe enthält ein anschauliches Beispiel dafür, wie eine Organisation eine Strategie für die Notfallwiederherstellung für eine Azure-Datenplattform eines Unternehmens entwerfen kann.
- Diese Artikelreihe ergänzt die Leitfäden für das Cloud Adoption Framework von Microsoft, für das Well-Architected Framework und für Verwaltungsfunktionen für Geschäftskontinuität von Azure
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.
Zwar treten gelegentlich punktuell Fehler im Azure-Dienst auf, jedoch ist zu beachten, dass Microsoft-Rechenzentren und Azure-Dienste über mehrere integrierte Redundanzebenen verfügen. Normalerweise ist der Umfang von Fehlern begrenzt, und in der Regel ist die Wiederherstellung innerhalb weniger Stunden abgeschlossen. Rückblickend ist es viel wahrscheinlicher, dass bei einem wichtigen Dienst wie der Identitätsverwaltung ein Dienstproblem auftritt, als dass eine gesamte Azure-Region offline geht.
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 mittelgroße Organisation mit einer definierten Funktion zur operativen Unterstützung, die einer Information Technology Infrastructure Library (ITIL)-basierten Dienstverwaltungsmethodik folgt
- nicht cloudnativ, da die wichtigsten unternehmensweiten, gemeinsam genutzten Dienste wie Zugangs- und Authentifizierungsmanagement und Incidentmanagement lokal bleiben
- unterwegs auf dem Weg der Cloudmigration zu Azure, ermöglicht durch Automatisierung
- Die Azure-Datenplattform hat die folgenden Entwürfe innerhalb des Azure-Mandanten des Kunden implementiert
- Unternehmenszielzone: Bereitstellung der Plattformbasis, einschließlich Netzwerk, Überwachung, Sicherheit usw.
- Azure Analytics-Plattform: Bereitstellen der Datenkomponenten, die die verschiedenen vom Dienst bereitgestellten Lösungen und Datenprodukte unterstützen
- Dieser Vorgang wird von einer technischen Azure-Ressource anstatt von einem speziellen Azure-Fachexperten (SME) ausgeführt. Die Ressource(n) sollte(n) daher über den folgenden Wissens-/Qualifikationsgrad verfügen
- Azure-Grundlagen: fundierte Kenntnisse von Azure, seinen Kerndiensten und Datenkomponenten
- Fundierte Kenntnisse von Azure DevOps. Fähig, in der Quellcodeverwaltung zu navigieren und Pipelinebereitstellungen auszuführen.
- Dieser Vorgang beschreibt den Failovervorgang von der primären zur sekundären Region
Nicht betreffende Organisationen
Die folgenden Punkte werden in dieser Artikelreihe nicht behandelt:
- Der Fallbackvorgang von der sekundären Region zurück zur primären Region
- Alle Nicht-Azure-Anwendungen, -Komponenten oder -Systeme – dazu gehören unter anderem lokale, andere Cloud-Anbieter, Webdienste von Drittanbietern usw.
- Wiederherstellung von Upstreamdiensten, z. B. lokalen Netzwerken, Gateways, gemeinsam genutzten, unternehmensweiten Diensten usw., die für diesen Prozess erforderlich sind
- Wiederherstellung von nachgelagerten Diensten, z. B. lokale Betriebssysteme, Berichtssysteme von Drittanbietern, Datenmodellierungs- oder Data Science-Anwendungen usw., die auf diesen Prozess angewiesen sind, um ihre eigenen Dienste wiederherzustellen
- Datenverlustszenarien, einschließlich der Wiederherstellung nach Ransomware- oder ähnlichen Datensicherheitsvorfällen
- Datensicherungsstrategien und Datenwiederherstellungspläne
- Festlegen der Grundursache eines Notfallwiederherstellungsereignisses
- Für Azure-Dienst-/Komponentenvorfälle veröffentlicht Microsoft eine „Analyse der Grundursache“ auf der Webseite „Status – Verlauf“
Wichtige Annahmen
Die wichtigsten Annahmen für dieses praktische DR-Beispiel sind:
- Die Organisation folgt einer ITIL-basierten Dienstverwaltungsmethodik zur operativen Unterstützung der Azure-Datenplattform
- Die Organisation verfügt über einen vorhandenen DR-Prozess als Teil ihres Framework zur Dienstwiederherstellung für IT-Ressourcen.
- „Infrastructure-as-Code“ (Infrastructure-as-Code (IaC)) wurde verwendet, um die durch einen Automatisierungsdienst wie Azure DevOps oder Ähnliches aktivierte Azure-Datenplattform bereitzustellen.
- Für jede von der Azure-Datenplattform gehostete Lösung wurde eine Bewertung der geschäftlichen Auswirkungen oder ähnliches durchgeführt, die klare Serviceanforderungen für Recovery Point Objective (RPO), Recovery Time Objective (RTO) und MTO enthält.
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.