Overzicht
Deze reeks biedt een illustratief voorbeeld van hoe een organisatie een strategie voor herstel na noodgevallen (DR) kan ontwerpen voor een Azure Enterprise Data-platform.
- Deze reeks artikelen vormt een aanvulling op de richtlijnen van de Cloud Adoption Framework van Microsoft, het Goed ontworpen framework van Azure en het beheer van bedrijfscontinuïteit
Azure biedt een breed scala aan tolerantieopties die servicecontinuïteit kunnen bieden in het geval van een noodgeval. Maar hogere serviceniveaus kunnen leiden tot complexiteit en kostenpremies. De afweging van kosten versus tolerantie versus complexiteit is de belangrijkste beslissingsfactor voor de meeste klanten met betrekking tot herstel na noodgeval.
Hoewel er af en toe puntfouten optreden in de Azure-service, moet worden opgemerkt dat Microsoft Data Centers en Azure-services meerdere lagen van redundantie hebben ingebouwd. Elke fout is normaal gesproken beperkt in bereik en wordt doorgaans binnen een paar uur hersteld. In het verleden is het veel waarschijnlijker dat een belangrijke service, zoals identiteitsbeheer, een serviceprobleem ondervindt in plaats van dat een hele Azure-regio offline gaat.
Ook moet worden erkend dat cyberaanvallen, met name ransomware, nu een tastbare bedreiging vormen voor elk modern gegevensecosysteem en kunnen leiden tot een uitval van het gegevensplatform. Hoewel dit buiten het bereik van deze reeks valt, wordt klanten geadviseerd om controles tegen dergelijke aanvallen te implementeren als onderdeel van het beveiligings- en tolerantieontwerp van een gegevensplatform.
- Microsoft-richtlijnen voor bescherming tegen ransomware zijn beschikbaar in Cloud Fundamentals van Azure
Bereik
Het bereik van deze reeks artikelen omvat:
- Het serviceherstel van een Azure-gegevensplatform na een fysiek noodgeval voor een illustratieve persona van de klant. Deze illustratieve klant is:
- een middelgrote grote organisatie met een gedefinieerde operationele ondersteuningsfunctie, volgens een op ITIL gebaseerde servicebeheermethodologie
- niet cloudeigen, met de belangrijkste onderneming, blijven gedeelde services zoals toegangs- en verificatiebeheer en incidentbeheer on-premises
- op het traject van cloudmigratie naar Azure, mogelijk gemaakt door automatisering
- Het Azure-gegevensplatform heeft de volgende ontwerpen geïmplementeerd binnen de Azure-tenancy van de klant
- Enterprise Landing Zone : biedt de platformbasis, inclusief netwerken, bewaking, beveiliging, enzovoort.
- Azure Analytics-platform : de gegevensonderdelen leveren die ondersteuning bieden voor de verschillende oplossingen en gegevensproducten die door de service worden geleverd
- Dit proces wordt uitgevoerd door een technische Azure-resource in plaats van een gespecialiseerde Azure SME. Als zodanig moeten de resource(s) het volgende niveau van kennis/vaardigheden hebben
- Basisinformatie over Azure : praktische kennis van Azure, de belangrijkste services en gegevensonderdelen
- Praktische kennis van Azure DevOps. Kan navigeren in broncodebeheer en pijplijnimplementaties uitvoeren
- In dit proces wordt het failoverproces beschreven, van de primaire naar de secundaire regio
Buiten bereik
De volgende items worden beschouwd als buiten het bereik van deze reeks artikelen:
- Het terugvalproces, van de secundaire regio terug naar de primaire regio
- Alle niet-Azure-toepassingen, -onderdelen of -systemen: dit omvat, maar is niet beperkt tot on-premises, andere cloudleveranciers, webservices van derden, enzovoort.
- Herstel van upstreamservices, zoals on-premises netwerken, gateways, gedeelde bedrijfsservices, enzovoort, die vereist zijn voor dit proces
- Herstel van downstreamservices, zoals on-premises operationele systemen, rapportagesystemen van derden, gegevensmodellering of data science-toepassingen, enzovoort, die afhankelijk zijn van dit proces om hun eigen services te herstellen
- Scenario's voor gegevensverlies, waaronder herstel na ransomware of vergelijkbare gegevensbeveiligingsincidenten
- Strategieën voor gegevensback-up en plannen voor gegevensherstel
- De hoofdoorzaak van een noodgeval vaststellen
- Voor azure-service-/onderdeelincidenten publiceert Microsoft een 'Hoofdoorzaakanalyse' op de webpagina Status – Geschiedenis
Belangrijkste veronderstellingen
De belangrijkste veronderstellingen voor dit voorbeeld van herstel na noodgeval zijn
- De organisatie volgt een op ITIL gebaseerde methodologie voor servicebeheer voor operationele ondersteuning van het Azure-gegevensplatform
- De organisatie heeft een bestaand herstelproces na noodgevallen als onderdeel van het serviceherstelframework voor IT-assets
- 'Infrastructuur als code' (IaC) is gebruikt om het Azure-gegevensplatform te implementeren dat wordt ingeschakeld door een automatiseringsservice, zoals Azure DevOps of iets dergelijks
- Elke oplossing die wordt gehost door het Azure-gegevensplatform, heeft een business impact assessment of vergelijkbaar voltooid, met duidelijke servicevereisten voor RPO, RTO en MTO
Volgende stappen
Nu u op hoog niveau meer hebt geleerd over het scenario, kunt u verdergaan met meer informatie over de architectuur die is ontworpen voor de use-case.