Delen via

Aanbevelingen voor het ontwerpen van een strategie voor herstel na noodgevallen

Van toepassing op de aanbeveling voor betrouwbaarheid in de Azure Well-Architected Framework-checklist:

RE:09 Implementeer gestructureerde, geteste en gedocumenteerde BCDR-plannen (bedrijfscontinuïteit en herstel na noodgevallen) die overeenkomen met de hersteldoelen. Plannen moeten alle onderdelen en het systeem als geheel omvatten.

In deze handleiding worden aanbevelingen beschreven voor het ontwerpen van een betrouwbare strategie voor herstel na noodgevallen voor een workload. Als u wilt voldoen aan interne serviceniveaudoelstellingen (SLO's) of zelfs een SLA (Service Level Agreement) die u voor uw klanten hebt gegarandeerd, moet u een robuuste en betrouwbare strategie voor herstel na noodgevallen hebben. Fouten en andere belangrijke problemen worden verwacht. Uw voorbereidingen om deze incidenten af te handelen, bepalen hoeveel uw klanten uw bedrijf kunnen vertrouwen om ze betrouwbaar te leveren. Een strategie voor herstel na noodgevallen is de backbone van voorbereiding op grote incidenten.

Definities

Termijn Definitie
Overgang bij uitval De geautomatiseerde en/of handmatige verschuiving van productie-workloadverkeer van een niet-beschikbare regio naar een onbeïnvloede geografische regio.
terugval De geautomatiseerde en/of handmatige verschuiving van productiebelastingverkeer van een failoverregio terug naar de primaire regio.

Belangrijke ontwerpstrategieën

In deze handleiding wordt ervan uitgegaan dat u de volgende taken al hebt uitgevoerd als onderdeel van uw betrouwbaarheidsplanning:

Een betrouwbare strategie voor herstel na noodgevallen is gebaseerd op de basis van een betrouwbare workloadarchitectuur. Adresseer de betrouwbaarheid in elke fase van het bouwen van uw workload om ervoor te zorgen dat de benodigde onderdelen voor geoptimaliseerd herstel aanwezig zijn voordat u begint met het ontwerpen van uw DR-strategie. Deze basis zorgt ervoor dat de betrouwbaarheidsdoelen van uw workload, zoals de beoogde hersteltijd (RTO) en het beoogde herstelpunt (RPO), realistisch en haalbaar zijn.

Een plan voor herstel na noodgevallen onderhouden

De hoeksteen van een betrouwbare DR-strategie voor een workload is het DR-plan. Uw plan moet een levend document zijn dat regelmatig wordt gecontroleerd en bijgewerkt naarmate uw omgeving zich ontwikkelt. Presenteer het plan regelmatig aan de juiste teams (operations, technologieleiderschap en zakelijke belanghebbenden) (bijvoorbeeld om de zes maanden). Sla deze op in een maximaal beschikbare, beveiligde gegevensopslag, zoals OneDrive voor Bedrijven.

Volg deze aanbevelingen om uw DR-plan te ontwikkelen:

  • Definieer duidelijk wat een noodgeval is en vereist daarom activering van het DR-plan.

    • Rampen zijn grootschalige problemen. Dit kunnen regionale storingen zijn, storingen van services zoals Microsoft Entra ID of Azure DNS, of ernstige schadelijke aanvallen zoals ransomware-aanvallen of DDoS-aanvallen.

    • Identificeer faalwijzen die niet als rampen worden beschouwd, zoals het falen van een enkele hulpbron, om te voorkomen dat operators hun DR-escalaties per ongeluk activeren. Deze foutmodi kunnen worden opgelost door het probleem op te lossen, de mislukte resources opnieuw te implementeren of een back-upplan te gebruiken

  • Bouw het disaster recovery-plan op basis van uw FMA-documentatie. Zorg ervoor dat uw DR-plan de foutmodi en risicobeperkingsstrategieën vastlegt voor storingen die zijn gedefinieerd als rampen. Werk zowel uw DR-plan als uw FMA-documenten parallel bij, zodat deze nauwkeurig zijn wanneer de omgeving verandert of wanneer het testen onverwacht gedrag ontdekt.

    • Of u DR-plannen voor niet-productieomgevingen ontwikkelt, is afhankelijk van uw bedrijfsvereisten en kostenimpact. Als u bijvoorbeeld qa-omgevingen (quality-assurance) aan bepaalde klanten biedt voor prereleasetests, kunt u deze omgevingen opnemen in uw DR-planning.

  • Definieer duidelijk rollen en verantwoordelijkheden binnen het workloadteam en begrijp alle gerelateerde externe rollen binnen uw organisatie. Rollen moeten het volgende omvatten:

    • De partij die verantwoordelijk is voor het declareren van een noodgeval.

    • De partij die verantwoordelijk is voor het declareren van de sluiting van incidenten.

    • Operationele rollen.

    • Test- en validatierollen.

    • Interne en externe communicatierollen.

    • Terugblik en oorzaakanalyse (RCA) leidende rollen.

  • Definieer de escalatiepaden die het workloadteam moet volgen om ervoor te zorgen dat de herstelstatus wordt gecommuniceerd met belanghebbenden.

  • Leg herstelprocedures op onderdeelniveau vast, herstel op gegevensdomeinniveau en herstelprocessen voor de hele workload. Neem een voorgeschreven volgorde van bewerkingen op om ervoor te zorgen dat onderdelen op de minst impactvolle manier worden hersteld. U kunt bijvoorbeeld databases herstellen en controleren voordat u de toepassing herstelt.

    • Beschrijf elke herstelprocedure op onderdeelniveau als een stapsgewijze handleiding. Neem indien mogelijk schermopnamen op.

    • Definieer de verantwoordelijkheden van uw team ten opzichte van de verantwoordelijkheden van uw cloudhostingprovider. Microsoft is bijvoorbeeld verantwoordelijk voor het herstellen van een PaaS (platform als een service), maar u bent verantwoordelijk voor het reactiveren van gegevens en het toepassen van uw configuratie op de service.

    • Voeg vereisten toe voor het uitvoeren van de procedure. Vermeld bijvoorbeeld de vereiste scripts of inloggegevens die moeten worden verzameld.

    • Leg de hoofdoorzaak van het incident vast en voer risicobeperking uit voordat u herstel start. Als de oorzaak van het incident bijvoorbeeld een beveiligingsprobleem is, kunt u dit probleem oplossen voordat u de betrokken systemen in uw failover-omgeving herstelt.

  • Afhankelijk van het redundantieontwerp voor uw workload moet u mogelijk aanzienlijk werk doen na de failover voordat u de workload weer beschikbaar maakt voor uw klanten. Werk na failover kan DNS-updates, updates voor databaseverbindingsreeksen en verkeersrouteringswijzigingen omvatten. Leg al het werk na de failover vast in uw herstelprocedures.

    Opmerking

    Met uw redundantieontwerp kunt u mogelijk automatisch volledig of gedeeltelijk herstellen van grote incidenten, dus zorg ervoor dat uw plan processen en procedures voor deze scenario's bevat. Als u bijvoorbeeld een volledig actief-actief ontwerp hebt dat beschikbaarheidszones of regio's omvat, kunt u mogelijk automatisch en naadloos overschakelen na een storing in een beschikbaarheidszone of regio, en de stappen in uw herstelplan minimaliseren die moeten worden uitgevoerd. Als u uw workload hebt ontworpen met behulp van implementatiestempels, kan het zijn dat er slechts een gedeeltelijke storing optreedt als de stempels zonegebonden worden geïmplementeerd. In dit geval moet uw DR-plan betrekking hebben op het herstellen van stempels in niet-getroffen zones of regio's.

  • Als u uw app opnieuw moet implementeren in de failoveromgeving, gebruikt u hulpprogramma's om het implementatieproces zoveel mogelijk te automatiseren. Zorg ervoor dat uw DevOps-pijplijnen vooraf zijn geïmplementeerd en geconfigureerd in de failover-omgevingen, zodat u direct met uw app-implementaties kunt beginnen. Gebruik waar nodig geautomatiseerde end-to-end-implementaties met handmatige goedkeuringspoorten om een consistent en efficiënt implementatieproces te garanderen. De volledige implementatieduur moet overeenkomen met uw hersteldoelen.

    • Wanneer voor een fase van het implementatieproces handmatige tussenkomst is vereist, documenteert u de handmatige stappen. Definieer duidelijk rollen en verantwoordelijkheden.

  • Automatiseer zoveel mogelijk van de procedure. Gebruik declaratief programmeren in uw scripts omdat dit idempotentie toestaat. Als u geen declaratieve programmering kunt gebruiken, moet u rekening houden met het ontwikkelen en uitvoeren van uw aangepaste code. Gebruik opnieuw proberen logica en circuitonderbrekerlogica om tijdverspilling te voorkomen bij scripts die vastzitten aan een niet-werkende taak. Omdat u deze scripts alleen in noodgevallen uitvoert, wilt u niet dat verkeerd ontwikkelde scripts meer schade veroorzaken of uw herstelproces vertragen.

    Opmerking

    Automatisering brengt risico's met zich mee. Getrainde operators moeten de geautomatiseerde processen zorgvuldig bewaken en tussenbeide komen als een proces problemen ondervindt. Om het risico te minimaliseren dat automatisering op fout-positieven reageert, is het belangrijk om grondig te zijn bij uw DR-oefeningen. Test alle fasen van het plan. Simuleer detectie om waarschuwingen te genereren en doorloop vervolgens de hele herstelprocedure.

    Houd er rekening mee dat uw DR-oefeningen updates van uw hersteldoelstellingen moeten valideren of informeren. Als u merkt dat uw automatisering vatbaar is voor vals-positieven, moet u mogelijk de failover-drempels verhogen.

  • Scheid het failbackplan van het plan voor herstel na noodgeval om mogelijke verwarring met de DR-procedures te voorkomen. Het failbackplan moet alle aanbevelingen voor ontwikkeling en onderhoud van het DR-plan volgen en moeten op dezelfde manier worden gestructureerd. Alle handmatige stappen die nodig waren voor failover, moeten worden gespiegeld in het failbackplan. Failback kan snel plaatsvinden na een failover, of het kan dagen of weken duren. Overweeg failback als gescheiden van failover.

    • De noodzaak om terug te vallen is afhankelijk van de situatie. Als u om prestatieredenen verkeer tussen regio's doorstuurt, is het belangrijk om de belasting terug te schakelen naar de oorspronkelijke regio na een failover. In andere gevallen hebt u uw workload mogelijk zo ontworpen dat deze volledig functioneert, ongeacht in welke productieomgeving deze zich op elk gewenst moment bevindt.

Oefeningen voor noodherstel uitvoeren

Een DR-testproces is net zo belangrijk als een goed ontwikkeld DR-plan. Veel branches hebben complianceframeworks waarvoor regelmatig een bepaald aantal DR-oefeningen (disaster recovery) moet worden uitgevoerd. Ongeacht de sector waarin u actief bent, zijn regelmatige disaster recovery oefeningen van cruciaal belang voor uw succes.

Volg deze aanbevelingen voor succesvolle DR-oefeningen.

  • Voer ten minste één productie DR-oefening per jaar uit. Tabletop-drills (dry run) of niet-productieoefeningen helpen ervoor zorgen dat de betrokken partijen bekend zijn met hun rollen en verantwoordelijkheden. Met deze oefeningen kunnen operators ook vertrouwdheid ('spiergeheugen') opbouwen door herstelprocessen te volgen. Maar alleen productieoefeningen testen echt de geldigheid van het DR-plan en de RTO- en RPO-kengetallen. Gebruik uw productieanalyses voor tijdherstelprocessen voor onderdelen en stromen om ervoor te zorgen dat de RTO- en RPO-doelen die zijn gedefinieerd voor uw workload haalbaar zijn. Voor functies die buiten uw beheer vallen, zoals DNS-doorgifte, moet u ervoor zorgen dat de RTO- en RPO-doelen voor de stromen die betrekking hebben op deze functies, rekening houden met mogelijke vertragingen die buiten uw beheer vallen.

  • Gebruik tabletop-oefeningen niet alleen om bekendheid op te bouwen voor ervaren operators, maar ook om nieuwe operators op te leiden over DR-processen en -procedures. Senior operators moeten tijd in beslag nemen om nieuwe operators hun rol te laten vervullen en moeten kijken naar verbeteringsmogelijkheden. Als een nieuwe operator aarzelt of verward is door een stap in een procedure, controleert u deze procedure om ervoor te zorgen dat deze duidelijk is geschreven.

Overwegingen

  • Het uitvoeren van DR-drills in productie kan onverwachte onherstelbare fouten veroorzaken. Zorg ervoor dat u herstelprocedures test in niet-productieomgevingen tijdens uw eerste implementaties.

  • Geef uw team zo veel mogelijk onderhoudstijd tijdens drills. Wanneer u de onderhoudstijd plant, gebruikt u de hersteltijdgegevens die u tijdens het testen vastlegt als richtlijn voor de minimale tijd die nodig is.

  • Naarmate uw disaster recovery-oefeningen verbeteren, leert u welke procedures u parallel kunt uitvoeren en welke u opeenvolgend moet uitvoeren. In een vroeg stadium van uw oefeningen wordt aangenomen dat elke procedure in de juiste volgorde moet worden uitgevoerd en dat u bij elke stap extra tijd nodig hebt om onverwachte problemen aan te pakken.

Back-upplannen definiëren en onderhouden voor middelen binnen kritieke stromen

Back-up is een belangrijk onderdeel van uw algehele herstelproces. Vaak is het slechts een onderdeel van uw omgeving dat herstel nodig heeft. DR-plannen zijn meestal toepassings- of zelfs regiobreed. Onbedoeld of schadelijk verwijderen van gegevens, bestandsbeschadiging, malware en gerichte ransomware-aanvallen kunnen allemaal van invloed zijn op de beschikbaarheid van uw workload. Het hebben van solide back-up plannen voor elk deel van uw omgeving is net zo belangrijk als het hebben van een effectief rampenherstelplan, omdat een rampenherstelplan afhankelijk is van een solide back-up plan om effectief te werken. Net als uw DR-plan moeten back-upplannen ook worden overeengekomen door de juiste beheerniveaus, regelmatig bekeken voor mogelijke updates en gedocumenteerd in een maximaal beschikbare, beveiligde gegevensopslag.

  • Bepaal de juiste back-upoplossingen voor de verschillende Azure-services die deel uitmaken van de kritieke paden binnen uw workload.

  • Definieer de vereiste bewaarperioden voor elke verschillende service.

  • Begrijp dat één hulpprogramma mogelijk niet werkt voor alles. Azure Backup-hulpprogramma's kunnen betrekking hebben op veel resourcetypen, maar niet op alle.

  • Soms is de beste optie een herinzet vanuit een bepaald type hoogbeschikbare opslagplaats om bepaalde typen objecten te herstellen. (Azure DevOps, GitHub of andere)

  • Gegevensservices hebben andere vereisten dan toepassingsgerelateerde objecten.

  • Houd rekening met een opslagstrategie voor meerdere regio's voor uw back-upgegevens om herstelmogelijkheden tussen regio's te maken.

  • Voer regelmatig geplande testherstelbewerkingen van back-upgegevens uit om ervoor te zorgen dat services werken zoals verwacht.

Azure DR-facilitering

Veel Azure-producten hebben ingebouwde failovermogelijkheden. Maak kennis met deze mogelijkheden en neem ze op in herstelprocedures.

Voor IaaS-systemen (infrastructure as a service) gebruikt u Azure Site Recovery om failover en herstel te automatiseren. Raadpleeg de volgende artikelen voor algemene PaaS-producten:

Voorbeeld

Zie de DR voor Azure Data Platform-serie voor richtlijnen over het voorbereiden van een ondernemingsgegevensdomein voor disaster recovery.

Azure Backup-ondersteuning

Veel Azure-producten hebben ingebouwde back-upmogelijkheden. Maak kennis met deze mogelijkheden en neem ze op in herstelprocedures.

Voor IaaS-systemen (infrastructuur als een dienst) gebruikt u Azure Backup om back-ups van VM's en VM-gerelateerde services en sommige gegevensservices te vergemakkelijken. Raadpleeg de volgende artikelen voor algemene producten:

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor betrouwbaarheid