Een plan voor herstel na noodgevallen ontwikkelen voor implementaties in meerdere regio's

Als cloudoplossingsarchitect speelt u een belangrijke rol om ervoor te zorgen dat herstel van grootschalige fouten opzettelijk is gepland, ontworpen en gedocumenteerd als noodherstelplan. In geval van storing is de kwaliteit van dat plan van invloed of de gebeurtenis een tijdelijke terugval is of een reputatie- en financiële crisis wordt.

Het plan moet worden gebaseerd op strategieën die worden geleid door bedrijfsprioriteiten en waarop meetbare doelstellingen van toepassing zijn. In dit artikel wordt u begeleid bij het ontwikkelen van een praktisch DR-plan, te beginnen met de basisprocedures voor het herstellen van services naar een mindset-verschuiving die de bedrijfscontinuïteit onder druk verdedigt.

Dit artikel richt zich op het bereiken van bedrijfscontinuïteit via technische oplossingen en processen. Voordat u begint, bekijkt u de belangrijkste strategieën en kiest u de strategieën die zinvol zijn voor uw bedrijf. Zie RE:09 Architectuurstrategieën voor herstel na noodgevallen voor meer informatie.

Een DR-plan moet worden gebouwd op basis van de kernprincipes van incidentbeheer, die dient als een vereiste voor effectieve DR-planning. Zie Een incidentbeheerpraktijk ontwikkelen om te herstellen van onderbrekingen voor hulp bij het ontwikkelen van een plan voor incidentbeheer.

Terminologie

Voordat u begint met het ontwikkelen van uw plan, raden we u aan vertrouwd te raken met een gemeenschappelijke woordenlijst. Stel deze termen vast als gedeelde taal om duidelijke communicatie en gecoördineerde besluitvorming mogelijk te maken bij het activeren van het DR-plan.

Termijn	Definition
Actief-actief (hot standby)	Twee of meer omgevingen zijn volledig operationeel en leveren live verkeer tegelijk tussen meerdere regio's. Als één omgeving mislukt, blijven anderen de belasting verwerken met nul of bijna nul onderbrekingen.
Actief-passief (koude standby)	Omgeving die niet actief is en waarvoor voorbereiding en gegevensherstel vereist zijn wanneer deze wordt geactiveerd. Laagste kosten, langste hersteltijd.
Actief-passief (warm standby)	Gedeeltelijk ingerichte omgeving met minimale services die snel omhoog kunnen worden geschaald tijdens storingen.
bedrijfscontinuïteit	Strategieën voor het garanderen van kritieke operaties tijdens en na disrupties, waaronder DR, personeel, communicatie en processen.
Noodherstelplan (DR)	Gedetailleerde, uitvoerbare procedures voor het herstellen van specifieke systemen, waaronder stapsgewijze acties, rollen, verantwoordelijkheden, failoverreeksen en communicatiewerkstromen.
Strategie voor herstel na noodgevallen (DR)	Benadering op hoog niveau om doelen, principes en herstelaanpak te definiëren voor het reageren op catastrofale storingen in workloads.
DR-activering	Formele beslissing voor het initiëren van procedures voor herstel na noodgevallen, die doorgaans een uitvoerende autorisatie vereisen.
Failback	Proces van het retourneren van workloads naar de oorspronkelijke primaire omgeving na het oplossen van incidenten.
Failover	Proces van het verschuiven van workloads van de primaire naar de standby-omgeving tijdens een ramp.
Herstelpuntdoelstelling (RPO)	Hoeveelheid gegevensverlies die kan worden getolereerd voordat er grote verliezen ontstaan. RPO bepaalt hoe vaak u een back-up moet maken van essentiële gegevens.
Hersteltijddoelstelling (RTO)	Tijd die nodig is om essentiële toegang, gegevens en functionaliteiten te herstellen na een noodgeval met betrekking tot technologie.

Wat is herstel na noodgevallen?

Herstel na noodgeval (DR) is een strategische en methodische benadering voor het herstellen van systemen of kritieke onderdelen ervan, na een grote fout.

In cloudomgevingen zijn tijdelijke fouten normaal. Deze korte onderbrekingen, ook wel blips of tijdelijke fouten genoemd, kunnen leiden tot niet-beschikbaarheid van geïsoleerde onderdelen of onverwachte dalingen in prestaties. Ze worden meestal opgelost via platformtolerantiefuncties en ingebouwde zelfherstelmechanismen zonder menselijke tussenkomst.

Rampen zijn echter een andere gebeurtenisklasse. Ze zijn breed in omvang, hebben invloed op meerdere systemen of services tegelijk en kunnen het systeem tot stilstand brengen. Deze gebeurtenissen vereisen externe interventie en gespecialiseerde rollen, geleid door een goed gedefinieerd DR-plan dat kan worden geactiveerd wanneer de ingebouwde zelfhersteltolerantie van het systeem niet voldoende is. Enkele voorbeelden zijn:

• Volledige regionale storingen

• Verlies van toegang tot controlevlak of mogelijkheden voor het beheer van diensten

• Beschadigde productieomgevingen vanwege schadelijke activiteit of kritieke onjuiste configuratie

• Ernstige infrastructuurfouten die van invloed zijn op meerdere lagen van het systeem

• Natuurrampen of geopolitieke gebeurtenissen waardoor uitgebreide service niet beschikbaar is

Onbeheerde blip's kunnen escaleren tot grootschalige rampen. Hoewel geavanceerde bewaking en statusmodellering deze problemen vroeg kunnen detecteren en verhelpen, valt dat onderwerp buiten het bereik van dit artikel. Zie Gezondheidsmodellering voor meer informatie.

Het ultieme doel van dr is om bedrijfscontinuïteit te behouden binnen gedefinieerde kwantitatieve metrische gegevens. Denk aan het plan als een gecoördineerde inspanning waarvoor vooraf gedefinieerde procedures nodig zijn, duidelijke communicatieprotocollen en besluitvorming op leidinggevend niveau.

Uw kritieke laag selecteren

Niet alle workloads (of delen hiervan) hebben een heroïsch herstelplan nodig. Herstel moet de kritieke aard weerspiegelen.

Belangrijk

Kritiek is een zakelijke beslissing en het is uw verantwoordelijkheid om die beslissing te helpen begeleiden. Het hangt af van wat uw workload doet, wie ervan afhankelijk is en wat er gebeurt als deze uitvalt. Azure bepaalt niet wat bedrijfsmissie-kritiek is, dat bepaal jij. Als een storing uw omzet bereikt, klantvertrouwen beschadigd raakt of u niet meer aan de naleving voldoet, is dat een kritiek systeem. Bezit die beslissing en ontwerp met het in gedachten.

Over-engineering van diensten met weinig impact verspilt middelen; het onvoldoende voorbereiden van diensten met grote impact loopt ernstige gevolgen. De sleutel is het juiste formaat van uw herstelstrategie op basis van bedrijfsimpact. Gebruik de volgende classificatielagen als uitgangspunt om de kritiek te beoordelen en uw investeringen voor herstel na noodgevallen op de juiste manier af te stemmen.

Een veelgebruikte manier om lagen te kwantificeren is door middel van serviceniveaudoelstellingen (SLO's), vaak uitgedrukt als 'vijf negens' (99,999%), 'vier negens' (99,99%), enzovoort. Deze percentielen vertegenwoordigen het beschikbaarheidsniveau dat voor een bepaalde workload wordt verwacht.

De belangrijkste metrische gegevens in dr-strategie zijn Recovery Time Objective (RTO) en Recovery Point Objective (RPO), beide gekwantificeerd als tijdseenheden. RTO bepaalt hoe snel een systeem na een onderbreking moet worden hersteld. Het vertegenwoordigt de tolerantie van de organisatie voor downtime. RPO bepaalt hoeveel gegevensverlies acceptabel is en geeft aan hoe vaak een back-up van gegevens moet worden gemaakt.

In dit artikel wordt ervan uitgegaan dat uw SLO's en herstelmetriek al zijn gedefinieerd en niet ingaat op hoe deze moeten worden berekend. Als u hulp nodig hebt bij het tot stand brengen van zinvolle SLO's, raadpleegt u metrische gegevens over betrouwbaarheid.

Laag 0: Missiekritiek

De bedrijfskritieke laag omvat volledige workloads of specifieke onderdelen waarbij downtime geen optie is en kostenbesparingen secundair zijn voor continuïteit. Deze systemen zijn van fundamenteel belang voor de organisatie, leiden rechtstreeks tot inkomsten, het beschermen van het vertrouwen van klanten of het beïnvloeden van levens. Veelvoorkomende voorbeelden zijn financiële platforms, gezondheidszorgsystemen en beveiligingsinfrastructuur.

Deze laag vereist SLO's boven 99,99%, waarbij RTO in seconden wordt gemeten en RPO nul nadert. Om aan deze vereisten te voldoen, is doorgaans een actief-actieve implementatie met meerdere regio's nodig, waardoor direct herstel mogelijk is zonder gebruikersonderbrekingen.

Wanneer bedrijfskritieke systemen mislukken, zijn de gevolgen onmiddellijk en aanzienlijk: verlies van omzet, reputatieschade of blootstelling aan regelgeving.

Laag 1: Bedrijfskritiek

Bedrijfskritieke systemen zijn essentieel voor dagelijkse bewerkingen en klantervaringen, maar in tegenstelling tot bedrijfskritieke systemen kunnen ze korte onderbrekingsperioden tolereren, zolang herstel snel is en gegevensverlies minimaal is. Deze systemen worden vaak aangestuurd door inkomstenprikkels, zoals e-commerceplatforms, klantgerichte toepassingen en partnerportals.

Ze vereisen doorgaans SLO's van ongeveer 99,95%, waarbij RTO en RPO in minuten worden gemeten. Een combinatie van actief-actief of warme stand-by implementaties wordt vaak gebruikt om veerkracht in evenwicht te brengen met kosten.

Hoewel korte uitval te overleven is, heeft uitgebreide storing in deze laag direct invloed op de omzet, de tevredenheid van de gebruiker en de geloofwaardigheid van het merk. Voorspelbaarheid en snelheid van herstel is essentieel.

Laag 2: Zakelijk operationeel

Bedrijfs-operationele systemen ondersteunen interne teams en processen. Hoewel ze niet rechtstreeks klantgericht zijn, zijn ze essentieel voor productiviteit en operationele continuïteit. Typische voorbeelden zijn rapportageplatforms, interne dashboards en beheerhulpprogramma's.

Deze systemen richten zich over het algemeen op Service Level Objectives (SLO's) rond de 99,9%, met Recovery Time Objective (RTO) en Recovery Point Objective (RPO) gemeten in uren. Een actief-passief met een warme/koude implementatiestrategie is gebruikelijk, waarbij secundaire omgevingen inactief blijven totdat ze nodig zijn, waarbij kosten worden geoptimaliseerd voor de herstelsnelheid.

Storingen in deze laag zijn mogelijk niet onmiddellijk van invloed op klanten, maar langere onderbrekingen kunnen het bedrijf vertragen. Tijdig herstel is belangrijk, zelfs als het niet direct is.

Laag 3: Beheer

Beheersystemen zijn niet-kritieke workloads die ondersteuning bieden voor achtergrondbewerkingen of gebruiksvoorbeelden met lage urgentie. Dit zijn doorgaans archiveringsplatforms, sandbox-omgevingen, trainingsportals of hulpprogramma's voor batchverwerking waarbij beschikbaarheid niet tijdgevoelig is.

Met SLO's onder de 99,9%, tolereren deze systemen langere herstelvensters, waarbij RTO varieert van uren tot dagen en RPO gemeten in uren. De meest rendabele benadering hier is doorgaans back-up en herstel, waardoor de lopende infrastructuurkosten worden geminimaliseerd terwijl de herstelbaarheid behouden blijft.

Hoewel vertragingen in deze laag over het algemeen acceptabel zijn, moet de gegevensintegriteit nog steeds worden beveiligd. Deze systemen kunnen het bedrijf mogelijk niet stoppen als ze uitvallen, maar als ze volledig verloren gaan, kunnen ze na verloop van tijd nog steeds nalevingsrisico's of kennisgaten creëren.

Uw workload classificeren

Voordat u begint met uw DR-strategie, classificeert u uw workloads op basis van de werkelijke bedrijfsimpact en herstelvereisten.

Begin met het weergeven van elke gebruikersstroom in uw workload. Documenteer wat het doet, wie ervan afhankelijk is en wat er gebeurt als het uitvalt. Voor verschillende stromen binnen dezelfde workload zijn mogelijk verschillende strategieën voor herstel na noodgevallen vereist op basis van hun individuele bedrijfsimpact en -kritiek.

Werk samen met uw zakelijke belanghebbenden om hun goedkeuring te verkrijgen voor deze classificaties. Bevestig de RTO- en RPO-doelen op basis van echte zakelijke gevolgen, niet alleen technische adviezen. Hun inzet vormt de basis en uw DR-strategie bouwt daarop voort. Zonder afstemming op bedrijfsrisico mist een technische reactie richting.

Bekijk deze classificaties regelmatig. Naarmate de bedrijfsbehoeften zich ontwikkelen, moet u uw DR-plan dienovereenkomstig bijwerken.

Let op deze wrijvingspunten

Hier zijn enkele belangrijke knelpunten waar u voorzichtig mee moet zijn, anders kan DR-planning een dure aangelegenheid worden zonder de juiste resultaten.

• Komt niet overeen tussen verwachtingen en budget. Zorg voor realistische verwachtingen, zodat belanghebbenden geen hot standby-prestaties verwachten op een cold standby-budget. De kloof tussen RTO/RPO-beloften en budgetten kan leiden tot risico en teleurstelling.

• Afhankelijkheden van gedeelde services kunnen uw keten verbreken. Uw DR-plan is slechts zo effectief als het zwakste onderdeel. Als uw workloads afhankelijk zijn van gedeelde of externe resources, die geen goede failoverstrategieën hebben, kunnen er beveiligingsproblemen ontstaan tijdens een noodgeval.

• DR-activatiecriteria moeten glashelder zijn. Iedereen die in de lijst met verantwoordelijkheden staat, moet duidelijk zijn over de criteria. Zonder dit kan er aarzeling zijn om herstel te initiëren, wat onnodige vertragingen kan veroorzaken.

• Failback is net zo belangrijk als failover. Hoewel velen zich richten op het behandelen van failover als een eenrichtingsoverschakeling, is failback soms een haalbare optie. Het retourneren van bewerkingen naar de primaire site omvat echter vaak meer complexiteit. Zorg dat u failbackprocedures inplant en test. Een goede richtlijn is het automatiseren van failover terwijl het beheer van de failback plaatsvindt via een beheerd proces.

Uw herstelkosten optimaliseren

De kosten van herstel na noodgevallen nemen toe met de kritieke aard van de werkbelasting.

• Niveau 0 (Missiekritiek) komt met de hoogste kosten en dat wordt verwacht. Actief-actieve implementaties en redundante infrastructuur verhogen uw uitgaven aanzienlijk in ruil voor bijna nul downtime. Als het gaat om kostenoptimalisatie, zijn uw beste opties standaardprocedures, zoals gereserveerde instanties of Azure Hybrid Benefit, indien van toepassing.

  Streven naar eenvoud in uw ontwerp. Over-engineering bovenop goed gedefinieerde vereisten is waar verborgen kosten stilletjes worden opgebouwd. Houd er rekening mee dat basisprocedures zoals infrastructuur als code, geautomatiseerde implementaties en testen vooraf technische inspanningen introduceren. Hoewel die inspanning kan concurreren met het leveren van nieuwe functies, is het in gevaar brengen van investeringen in sterke activiteiten gewoon geen optie.

• Niveau 1 (Bedrijfskritiek) biedt een balans, meestal gebruikmakend van warme stand-byomgevingen die de kosten verlagen.

  Lagere basislijncapaciteit in de warme stand-by door rekenresources in de secundaire regio op gedeeltelijke schaal te implementeren en automatisch schalen alleen mogelijk te maken wanneer dat nodig is. Deze aanpak voorkomt dat u betaalt voor volledige capaciteit 24/7.

  Het gebruik van handmatig geactiveerd failoverproces met een ingedeeld runbook om complexiteit en lopende operationele kosten te verminderen in vergelijking met volledig geautomatiseerde failover. Regelmatige failovertests helpen bij het identificeren van inefficiënties,

• Niveau 2 (Business Operational) is gericht op het optimaliseren van kosten door gebruik te maken van koude reserve-opstellingen en opties voor betalen per gebruik, zoals spot-instanties en verbruiksprijzen. Automatiseer het inrichten van PaaS-rekenkracht in de secundaire regio alleen wanneer dat nodig is om te voorkomen dat u betaalt voor niet-actieve resources. Definieer duidelijke noodcriteria en failoverprocessen om onnodige failovers te voorkomen. Regelmatige tests zorgen ervoor dat aan hersteldoelen wordt voldaan en gebieden worden gemarkeerd om de kosten te verlagen.

• Laag 3 (Beheer) geeft prioriteit aan kostenbesparingen door te vertrouwen op back-up- en archiveringsopslag met langere herstelvensters. Gebruik gerepliceerde back-ups en Azure Backup-kluizen in een secundaire regio om permanente gegevens te beveiligen zonder stand-byinfrastructuur te beheren. Test regelmatig herstelprocessen om betrouwbaarheid te garanderen en kosten tot een minimum te beperken.

Wat uw laag ook is, gebruik de juiste hulpmiddelen om de kosten te controleren. Gebruik hulpprogramma's zoals Microsoft Cost Management en Azure Advisor om uitgaven in alle lagen te bewaken, voorspellen en optimaliseren. Tag resources en stel budgetdrempels in om verantwoordings- en terugstortingsmodellen gemakkelijker te volgen. Zie Tagging bedrijfskritieke workloads voor meer informatie over door Microsoft aanbevolen tags.

Documenteer uw DR-plan

Een sterk plan voor herstel na noodgevallen (DR) maakt van strategie een beslissende actie. Activering begint met een combinatie van geautomatiseerde waarschuwingen en menselijk toezicht. Hulpprogramma's voor waarneembaarheid markeren mogelijke problemen, zoals prestatievertragingen en activeren waarschuwingen voor het operationele team om te onderzoeken. Ze controleren dashboards op afwijkingen en beoordelen de situatie. Als het probleem breder of ernstiger wordt weergegeven, wordt het geëscaleerd en kunnen er extra teams bij betrokken zijn. Nadat er voldoende bewijs is, declareert de dr-lead formeel een noodgeval, waardoor een gestructureerd failoverproces wordt gestart om de systeemcontinuïteit te behouden.

Om dit mogelijk te maken, moet elk DR-plan drie essentiële onderdelen bevatten: een duidelijk runbook, een goed gedefinieerd communicatieplan en een gestructureerd escalatiepad.

DR-communicatieplan

Een communicatieplan zorgt ervoor dat de juiste informatie de juiste mensen op het juiste moment bereikt tijdens een onderbreking. Het ondersteunt coördinatie, vermindert verwarring en houdt belanghebbenden op de hoogte tijdens het herstelproces. Uw plan moet betrekking hebben op deze aspecten:

• Activeringscriteria en goedkeuringen. Bepaal wat in aanmerking komt als een DR-gebeurtenis. Bepalen wie gemachtigd is om het dr-proces te activeren. Escalatiepaden en beslissingscontrolepunten documenteert.

• Rollen en verantwoordelijkheden. Definieer wie verantwoordelijk is voor de communicatie en aan wie.

• Belangrijke belanghebbenden. Identificeer belangrijke interne en externe doelgroepen, zoals werknemers, leiderschap, partners en klanten.

• Communicatiekanalen. Primaire en back-upmethoden instellen, zoals e-mail, sms en andere. Stel ook frequentie van updates voor deze kanalen in.

• Meldingen en sjablonen. Geef een overzicht van het verzenden van updates en het voorbereiden van vooraf goedgekeurde berichtsjablonen voor e-mail, statuspagina en incidentkanalen.

• Escalatie en continuïteit. Zorg ervoor dat er een gestructureerde manier is om problemen te escaleren als iemand niet beschikbaar is of dingen snel veranderen. Communicatieplannen moeten zowel interne als externe belanghebbenden met de juiste details en frequentie en het gebruik van afzonderlijke kanalen aanpakken. Interne communicatie biedt regelmatige updates voor leidinggevenden en zakelijke gebruikers, gericht op bedrijfsimpact, tijdlijnen en resourcebehoeften. Externe communicatie coördineert met klanten, partners en regelgevende instanties, en omvat de huidige status en realistische tijdsbestekpen voor herstel.

DR-draaiboek

Een sterk runbook vervangt abstracte strategieën door structuur en stelt het team in staat om onder druk te reageren. Maak het duidelijk, maak het praktisch en zorg ervoor dat het werkt. Begin met een eenvoudig overzicht en bouw geleidelijk. Werk samen met bedrijfs-, beveiligings- en operationele afdelingen om volledige dekking te garanderen.

• Documenteer procedures voor failover en failback. Schrijf stapsgewijze technische instructies voor het initiëren van failover. Referentiehulpprogramma's en scripts die moeten worden uitgevoerd met koppelingen of verwijzingen. Bepaal criteria voor het initiëren van failback en gecoördineerde cutover-stappen.

  Ontwikkel een stapsgewijs proces voor failover-uitvoering:

  Handeling	Eigenaar	Criterium
  1. Incident detecteren	Bewaking/bewerkingen	Het incident wordt geactiveerd door waarschuwingen of gebruikersrapporten.
  2. Ernst beoordelen	Incidentbeheerder	Gebruik de tabel Incidentclassificatie om het ernstniveau te bepalen.
  3. Onderbreking aangeven (indien nodig)	Senior Ops/BCDR Lead	Declareer alleen storingen voor incidenten met hoge en kritieke ernst.
  4. Belanghebbenden op de hoogte stellen	Communicatieleider	Volg het tot stand gebrachte communicatieplan voor meldingen.
  5. Runbookuitvoering starten	Operationele Team	Start de uitvoering van het DR-runbook, inclusief geautomatiseerde runbooks en handmatige stappen.
  6. Secundaire infrastructuur voorbereiden	Operationele Team	Implementeer en/of schaal de infrastructuurconfiguratie op en valideer deze in een secundaire omgeving.
  7. Gegevensintegriteit garanderen	Operationele Team	Herstel gegevens vanuit back-ups, indien nodig, en valideer gegevensintegriteit en naleving van RPO.
  8. Toepassingen herstellen	Ops/QA-team	Implementeer, indien nodig, en activeer toepassingen in de secundaire omgeving. De juiste bewerking en alle afhankelijkheden valideren
  9. Verkeersoverschakeling	Operationele Team	De gebruiker overschakelen naar een secundaire omgeving. DNS-records bijwerken indien nodig
  10. Incident en document sluiten	Incidentbeheerder	Post-mortem uitvoeren en incidentrecords bijwerken.

  Maak op dezelfde manier een failbackbeslissing en -uitvoeringsproces (beschikbare primaire regio):

  Handeling	Eigenaar	Criteria/beslissingspunt
  1. De gezondheid van de primaire regio bewaken	Bewerkingen/cloudteam	Controleer of de primaire regio alle statuscontroles doorstaat en volledig operationeel is. Gebruik geautomatiseerde bewakingshulpprogramma's en handmatige validatie om de gereedheid te bevestigen.
  2. Bedrijfsimpact beoordelen	Toepassingseigenaar/bedrijfscontinuïteit	Bevestig de gereedheid van het bedrijf voor failback, inclusief vensters met weinig verkeer en vereiste goedkeuringen. Coördineer met belanghebbenden om ervoor te zorgen dat de timing overeenkomt met de bedrijfsbehoeften.
  3. Gegevenssynchronisatie controleren	Databank/Infrastructuurteam	Zorg ervoor dat gegevens in de secundaire regio worden gesynchroniseerd met de primaire regio en voldoen aan de RPO-/RTO-vereisten. Gebruik dashboards voor replicatiestatus om gegevensconsistentie te controleren.
  4. Failback-plan communiceren	Incidentbeheerder	Informeer belanghebbenden over de geplande failback, inclusief de tijdlijn en mogelijke impact. Gebruik e-mail, Teams of hulpprogramma's voor incidentbeheer voor communicatie.
  5. Primaire regio voorbereiden	Infra/Cloud Team	Controleer of infrastructuur-, beveiligings- en toepassingsonderdelen gereed zijn in de primaire regio. Voer controlelijsten voor pre-failback uit om volledige gereedheid te garanderen.
  6. Failback starten	Bewerkingen/cloudteam	Ga alleen verder met een goedgekeurde wijzigingsaanvraag en wanneer aan alle criteria wordt voldaan. Start met het omleiden van verkeer en workloads naar de primaire regio.
  7. Voortgang van failback bewaken	Bewerkingen/cloudteam	Controleer tijdens het overgangsproces op fouten, latentie of gegevensverlies. Gebruik dashboards en waarschuwingssystemen om de voortgang bij te houden.
  8. Toepassingsfunctionaliteit valideren	Applicatie-eigenaar/QA	Controleer of toepassingen en services volledig functioneel zijn in de primaire regio. Voer smoketests en regressietests uit om de functionaliteit te valideren.
  9. Incident afronden en sluiten	Incidentbeheerder	Zorg ervoor dat alle systemen stabiel zijn, belanghebbenden worden geïnformeerd en dat de documentatie wordt bijgewerkt. Voltooi de post-mortem analyse en leg de geleerde lessen vast.

• Stel statusvalidatie en gereedheidscontroles in. Definieer hoe u de servicefunctionaliteit na een failover controleert. Neem controles op toepassingsniveau, infrastructuur en gegevensintegriteit op.

• Plan na herstel en beoordeling. Acties om tijdelijke omgevingen op te schonen. Documenteer gegevensafstemming indien van toepassing. Plan de oorzaakanalyse en DR-debriefing in.

Aanbeveling

Behandel uw DR-runbook als productiecode: versie ervan en maak het toegankelijk. Gebruik hulpprogramma's voor versiebeheer, zoals Git of een wiki met versiebeheer, om updates bij te houden en de nauwkeurigheid in de loop van de tijd te garanderen. Zorg er net zo belangrijk voor dat het runbook altijd bereikbaar is, zelfs tijdens een storing. Sla deze op in meerdere indelingen, inclusief offline- of afdrukbare versies, zodat teams er toegang toe hebben wanneer dit het belangrijkst is.

Escalatieplan voor Disaster Recovery

Tijdens herstel na noodgevallen zijn snelheid en duidelijkheid alles. Een escalatieplan zorgt ervoor dat wanneer dingen niet volgens plan gaan, de juiste mensen snel worden gewaarschuwd.

• Escalatietriggers. Geef precies aan wanneer u moet escaleren, of het nu gaat om een gemiste herstelmijlpal, een kritieke systeemfout of een niet-reagerende leverancier.

• Keten van opdracht. In de geïdentificeerde lijst met rollen en contactpersonen legt u vast in welke volgorde er moet worden gecontacteerd. Dat wil zeggen, hoe u problemen kunt escaleren via primair, secundair en backup-personeel. Neem ook de verwachtingen van de reactietijd op. Bel bijvoorbeeld de DR-manager binnen 15 minuten op het telefoon- of noodcommunicatieplatform.

• Ernstniveaus voor incidenten. Categoriseer incidenten op basis van impact, zodat kleine problemen het systeem niet verstoppen en belangrijke problemen onmiddellijk aandacht krijgen van leiderschap.

Hier volgt een voorbeeldsjabloon:

Ernstniveau	Description	Voorbeelden	Trigger voor storingsdeclaratie	Belanghebbenden op de hoogte gesteld
Low	Kleine servicedegradatie	Korte latentiepieken	Geen formele verklaring	Operationele Team
Gemiddeld	Gedeeltelijke servicevermindering	Fouten bij enkele services	Incident geregistreerd, onder observatie	Ops, zakelijke potentiële klanten
High	Grote storing, wijdverspreide impact	Fout met meerdere services	Formele storingsdeclaratie	Alle belanghebbenden, klanten
Kritisch	Totaal verlies, bedrijfskritiek	Regionale Azure-fout voltooien	Onmiddellijke declaratie, C-niveau	Alle belanghebbenden, Exec Team

Test regelmatig en verbeter het plan

Herstel na noodgevallen is een operationele discipline. Een DR-plan dat nooit is getest, blijft theoretisch en onbeproefd.

• Oefen het runbook regelmatig om scenario's te simuleren en teamrollen te verduidelijken.

• Plan volledige of gedeeltelijke failoveroefeningen om de feitelijke herstelstappen en tijden te valideren. Een geplande failover simuleert een regionale storing om soepele systeemovergangen te oefenen. Hulpprogramma's zoals Azure Chaos Studio worden gebruikt om ongeplande fouten te testen en te zien hoe systemen reageren.

• Controleer na elke test de gegevens om te bevestigen dat er niets verloren is gegaan of beschadigd is. Leg hiaten of gedetecteerde problemen vast en werk vervolgens uw architectuur en runbooks onmiddellijk bij.

Herstelstrategie voor back-up en herstel

Back-up- en herstelstrategieën moeten deel uitmaken van alle herstelstrategieën.

Voorgestelde acties

Gebruik dit als basis voor alle lagen. Elke stap moet een duidelijk doel bevatten en een manier om de effectiviteit ervan te valideren.

Acties	Configuratie	Validation
Back-upbeleid en -retentie configureren	- Back-upschema's en bewaarperioden configureren voor infrastructuur en databases die zijn afgestemd op RPO-vereisten - Azure Backup gebruiken voor VM's, Azure Files en Blob Storage - Sla back-ups op in de secundaire regio, zoals met behulp van Geo-Redundant Backup Vault, indien beschikbaar	- Uitvoering van back-upbeleid testen - Voltooiing en integriteit van back-up controleren - Valideren van de handhaving van het bewaarbeleid
Kostenefficiënte opslaglagen implementeren	- Archief- of Cool-opslaglagen gebruiken voor niet-frequent geraadpleegde gegevens - Back-up tieringbeleid toepassen om oudere back-ups over te zetten naar opties met lagere kosten - Compressie en ontdubbeling configureren om de opslagkosten te minimaliseren	- Rapporten over optimalisatie van opslagkosten controleren - De uitvoering van het gelaagdheidsbeleid controleren - Gegevens ophalen uit verschillende opslaglagen testen
Procedures voor documentherstel	- Runbooks onderhouden met gedetailleerde herstelstappen - Doelomgevingen definiëren voor herstel - Lijsten met contactpersonen opnemen voor goedkeuringen en escalaties	- Documentatienauwkeurigheid van de herstelprocedure testen - Valuta voor contactgegevens controleren - Escalatiepaden en goedkeuringswerkstromen testen
Back-upkosten en -naleving bewaken	- Budgetdrempels instellen voor back-upgerelateerde resources - Back-upspecifieke tags toepassen om de juiste tracering mogelijk te maken - Bewaarbeleid configureren om te voldoen aan vereisten voor naleving van regelgeving	- Maandelijks back-upkostenrapporten bekijken - Effectiviteit van budgetdrempel controleren - Naleving van bewaarbeleid controleren
Back-upsystemen onderhouden en controleren	- Driemaandelijkse controles uitvoeren van back-upvereisten - Verouderde systemen buiten gebruik stellen en beleid aanpassen - RPO/RTO-vereisten beoordelen en bijwerken op basis van wijzigingen in het bedrijf en de technologie	- Controleren of controleresultaten zijn geadresseerd - Controleer of buiten gebruik gestelde systemen correct zijn uit bedrijf genomen - Valideren dat wijzigingen in RPO/RTO-vereisten haalbaar zijn

Herstelstrategie voor actief-passief (koude reserve)

Actief-passieve koude stand-by-implementaties houden de rekenresources van de secundaire regio uitgeschakeld totdat deze nodig zijn. Deze benadering is ideaal voor workloads van laag 2 of laag 3, waarbij RTO's langere vertragingen kunnen verdragen, maar herstel betrouwbaar en herhaalbaar moet zijn.

De primaire regio verwerkt al het productieverkeer terwijl de secundaire regio infrastructuurgereedheid onderhoudt met minimale actieve resources, waarvoor handmatige activering is vereist tijdens noodscenario's.

Voorgestelde acties

Bouw voort op herstelstrategieën voor back-up en herstel en bespreek deze punten. Breid het zo nodig uit.

Acties	Configuratie	Validation
Primaire en secundaire regio's instellen	- Een workload op volledige schaal implementeren in de primaire regio - Kopieer netwerktopologie, beleid en configuraties van primaire bron - Zorg ervoor dat RBAC, beveiligingsbasislijnen, bewakingsagents en beleidsregels consistent zijn - Infrastructuur implementeren als code waarbij rekenresources zijn gestopt	- Gereedheid van secundaire regio-infrastructuur controleren - Beleidsconsistentie tussen regio's testen - Netwerkconnectiviteit en routering valideren
Replicatie van gegevens in meerdere regio's instellen	- Ingebouwde replicatie inschakelen voor Azure SQL Database, PostgreSQL, MySQL, Cosmos DB - GZRS of RA-GZRS inschakelen voor replicatie van gekoppelde regio's - Objectreplicatie configureren voor Blob Storage in niet-gekoppelde regio's - Lees-/schrijfniveaus voor meerdere regio's instellen met configureerbare consistentieniveaus voor Azure Cosmos DB - Controleprocessen voor replicatievertraging en gegevensconsistentievalidatieprocessen configureren	- Test de vertraging van gegevenssynchronisatie tegen RPO-doelstellingen - Metrische gegevens over replicatiestatus en latentie controleren - Gegevensconsistentie tussen regio's valideren - Gegevensintegriteit valideren tijdens failoverscenario's
Disaster Recovery-omgeving beveiligen en compliance handhaven	- Vereisten voor gegevenslocatie repliceren in alle regio's - Identiteits- en toegangspariteit tussen regio's behouden - Testen op continuïteit van audittrail tijdens en na failover	- Beveiligingsconfiguraties in verschillende regio's controleren - Tests van identiteits-failoverscenario's uitvoeren - Naleving controleren tijdens noodherstelgebeurtenissen - Controlelogboekcontinuïteit valideren
Inrichtings- en voorbereidingsbewerkingen automatiseren	- IaC-sjablonen definiëren voor een geautomatiseerde omgeving voor het inrichten van resources, indien nodig - Serviceconfiguraties, schaalparameters en afhankelijkheden opnemen - Schaaldoelen vooraf definiëren om te voldoen aan de volledige belasting wanneer deze wordt geactiveerd - Voor IaC: Bicep, Terraform, ARM-sjablonen - Automatisering van implementatie: CI/CD-pijplijnen voor beide regio's - Runbooks: Geautomatiseerde en handmatige stappen voor het aanroepen van DR-procedures	- Geautomatiseerde inrichtingsprocedures testen - Controleer of de opstarttijden van de rekenproces voldoen aan RTO-doelen - Activeringsreeksen voor serviceafhankelijkheid valideren - Consistentie van IaC-implementatie testen tussen regio's - Valideer de uitvoering en timing van het runbook
Gereedheid en gezondheid bewaken	- Waarschuwingen instellen voor metrische gegevens over replicatiestatus en latentie - Status van secundaire regio-infrastructuur bewaken - Activeringsgereedheid bijhouden voor alle onderdelen - Gezondheidscontroles voor replicatie implementeren - Waarschuwingen instellen voor autoscale-gebeurtenissen en verkeersroutering - Zorg ervoor dat de observatietools beide regio's omvatten	- Bewakings- en waarschuwingssystemen testen - Gezondheid van infrastructuur controleren - Nauwkeurigheid van gereedheidsindicatoren valideren - Waarneembaarheidsdekking valideren
De load balancer configureren met handmatige failover	- Azure Front Door of Traffic Manager met routering op basis van prioriteit - Alle productieverkeer naar de primaire regio routeren onder normale omstandigheden - Verkeeromleiding handmatig activeren bij failover	- Failoverscenario's voor verkeer testen - Configuraties voor routeringsprioriteit controleren - DNS-doorsturing en overgangstijden valideren
Handmatig failover-runbook en criteria definiëren	- Duidelijke failovertriggers en activeringscriteria instellen - Documenteer handmatige activeringsstappen, waaronder het opstarten van berekeningen en DNS-updates - Terugdraaiprocedures opnemen voor mislukte of tijdelijke activeringen	- Test de uitvoering van het failoverrunbook - Handmatige activeringsprocedures controleren - Terugdraaiprocessen en tijdsinstellingen valideren
Herstelprocessen regelmatig testen	- Periodieke hersteloefeningen plannen om de back-upintegriteit te valideren - Herstel naar testomgevingen opnemen - Log de tijd die is besteed en vergelijken met RTO-doelen	- Driemaandelijkse hersteltests uitvoeren - Controleer gegevensconsistentie na herstel - Documentprestaties ten opzichte van RTO-doelen

Herstelstrategie voor actief-passief (warm stand-by)

Actief-passieve warme stand-by-implementaties verdelen de kosten en tolerantie door een minimaal ingerichte secundaire omgeving te onderhouden die snel kan worden geschaald tijdens storingsgebeurtenissen. Deze aanpak vermindert downtime en vermijdt de volledige kosten van always-on redundantie in verschillende regio's.

De primaire regio verwerkt al het productieverkeer onder normale omstandigheden, terwijl de secundaire regio wordt uitgevoerd met minimale resources en alleen omhoog wordt geschaald wanneer dit is geactiveerd voor herstel na noodgevallen.

Voorgestelde acties

Werk voort op herstelstrategieën voor actief-passief (koude stand-by) en bespreek deze punten. Breid het zo nodig uit.

Acties	Configuratie	Validation
Secundaire regio op gedeeltelijke schaal configureren	- Minimaal levensvatbare rekenkracht implementeren in secundaire regio	- Gereedheid van secundaire regio-infrastructuur controleren
Automatisch schalen in secundaire regio inschakelen	- Regels voor het automatisch schalen configureren om de rekencapaciteit bij failover te vergroten - Passende drempelwaarden en limieten instellen voor schaalvergroting - Opstartreeksen definiëren voor afhankelijke services	- Het testen van gedrag bij schaalvergroting tijdens failoveranalyses - Beschikbaarheid van resources controleren tijdens omhoog schalen
Geautomatiseerde failoverprocedures configureren	- Automatische failover inschakelen waar ondersteund - Documenteer handmatige failoverprocedures voor andere services - Georkestreerde failover-runbooks maken met stapsgewijze processen	- Geautomatiseerde failovermechanismen testen - Handmatige failoverprocedures valideren - Controleer de timing en nauwkeurigheid van de uitvoering van het runbook
Load balancer configureren met automatische failover	- Azure Front Door of Traffic Manager waarvoor automatische failover is ingeschakeld - Statuscontroles configureren voor automatische omleiding van verkeer	- Failoverscenario's voor verkeer testen - Configuraties voor routeringsprioriteit controleren

Herstelstrategie voor actief-actieve implementaties

Actief-actieve implementaties maximaliseren de beschikbaarheid van services door meerdere workloadexemplaren uit te voeren in verschillende regio's, waarbij elk exemplaar productieverkeer actief verwerkt. Dit ontwerp elimineert downtime en maakt directe failover mogelijk, maar vereist ook nauwkeurige planning voor het beheren van consistentie, routering en kosten voor gedistribueerde systemen.

Kies een van de twee implementatiemethoden:

• Actief-actief (op capaciteit): gespiegelde implementatiemodellen of geodes in twee of meer regio's, waarbij elke regio een deel van de productiebelasting afhandelt en in staat is op te schalen om de volledige belasting tijdens regionale storingen op te vangen.

• Actief-actief (overprovisioned): gespiegelde implementatiestempels of geodes in twee of meer regio's. Elke regio is altijd op volledige schaal om onafhankelijk 100% verkeer te verwerken.

Opmerking

In actieve-actieve scenario's, wanneer er een fout optreedt, kan de gebruikerservaring onveranderd blijven als de belasting naar de resterende exemplaren verschuift. Herstel na noodgevallen is echter nog steeds nodig om het mislukte exemplaar te herstellen.

Voorgestelde acties

Bouw voort op de herstelstrategieën voor actief-passief (warm stand-by). Breid het zo nodig uit.

Acties	Configuratie	Validation
Secundaire regio configureren op volledige capaciteit	- Secundaire regio implementeren met volledige schaalcapaciteit, gelijk aan de primaire regio	- Valideren dat de secundaire regio volledige belasting direct kan ondersteunen wanneer de primaire regio uitvalt
Load balancer configureren om verkeer te verdelen over actieve exemplaren	- Azure Front Door of Traffic Manager met op latentie gebaseerde of gewogen routering - Gezondheidsprobes geconfigureerd per endpoint - Automatisch omleiden van verkeer bij foutdetectie	- Failoverscenario's testen tussen regio's - Controleer de nauwkeurigheid en reactietijd van de gezondheidstest - Verkeersroutering valideren tijdens gesimuleerde storingen
Instellen van het verdelingsgedrag	- Drempelwaarde voor documentbelasting die elke regio aan kan verwerken tijdens normaal functioneren - Verwacht prestatie- en opschaalgedrag als een gelijke regio uitvalt - Systeemgedrag definiëren onder storing in één regio, gedeeltelijke serviceonderbreking, netwerkpartitionering	- Test regionale foutscenario's onder belasting - Prestatieverminderingslimieten controleren - Verwerking van netwerkpartities testen

Volgende stappen

• STRATEGIEËN voor RE:09-architectuur voor het ontwerpen van een strategie voor herstel na noodgevallen

• RE:05 Architectuurstrategieën voor ontwerpen voor redundantie