Ü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 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-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 – dies umfasst lokale, andere Cloudanbieter, Webdienste von Drittanbietern usw., ohne darauf beschränkt zu sein
- Wiederherstellung von Upstreamdiensten, z. B. lokale Netzwerke, Gateways, gemeinsam genutzte Unternehmensdienste usw., die Voraussetzungen für diesen Vorgang sind
- Wiederherstellung von Downstreamdiensten, z. B. lokale Betriebssysteme, Berichterstellungssysteme von Drittanbietern, Datenmodellierung oder Data Science-Anwendungen usw., die von diesem Vorgang abhängig 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 (IaC) wurde verwendet, um die durch einen Automatisierungsdienst wie Azure DevOps oder Ähnliches aktivierte Azure-Datenplattform bereitzustellen.
- Jede von der Azure-Datenplattform gehostete Lösung hat eine Bewertung der geschäftlichen Auswirkungen oder etwas Ähnliches durchlaufen, aus der klare Dienstanforderungen für RPO, RTO und MTO resultieren.
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.