Aanbevelingen voor het ontwerpen van een strategie voor herstel na noodgevallen

  • Artikel

Van toepassing op deze aanbeveling voor de betrouwbaarheidschecklist van Azure Well-Architected Framework:

RE:09 Implementeer gestructureerde, geteste en gedocumenteerde bcdr-plannen (bedrijfscontinuïteit en herstel na noodgevallen) die zijn afgestemd op 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 beschikken over een robuuste en betrouwbare strategie voor herstel na noodgevallen. Fouten en andere belangrijke problemen worden verwacht. Uw voorbereidingen om met deze incidenten om te gaan, bepalen hoeveel uw klanten erop kunnen vertrouwen dat uw bedrijf betrouwbaar voor hen levert. Een strategie voor herstel na noodgevallen is de ruggengraat van de voorbereiding op grote incidenten.

Definities

Termijn Definitie
Failover De geautomatiseerde en/of handmatige verplaatsing van verkeer van productieworkloads van een niet-beschikbare regio naar een niet-beïnvloede geografische regio.
Failback Het geautomatiseerd en/of handmatig verplaatsen van verkeer van productieworkloads van een failoverregio 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 (DR) bouwt voort op de basis van een betrouwbare workloadarchitectuur. Ga in op 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 RTO (Recovery Time Objective) en Recovery Point Objective (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 (bijvoorbeeld om de zes maanden) aan de juiste teams (operations, technologisch leiderschap en zakelijke belanghebbenden). Sla deze op in een maximaal beschikbare, beveiligde gegevensopslag, zoals OneDrive voor Bedrijven.

Volg deze aanbevelingen om uw noodherstelplan te ontwikkelen:

  • Duidelijk definiëren wat een ramp is en daarom activering van het NOOD-plan vereist.

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

    • Identificeer foutmodi die niet als noodgeval worden beschouwd, zoals het mislukken van één resource, zodat operators hun DR-escalaties niet per ongeluk aanroepen.

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

    • Of u noodherstelplannen ontwikkelt voor niet-productieomgevingen, is afhankelijk van uw bedrijfsvereisten en kostenimpact. Als u bijvoorbeeld qa-omgevingen (quality-assurance) aanbiedt aan bepaalde klanten 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 verklaren van sluiting van incidenten.

    • Bewerkingsrollen.

    • Test- en validatierollen.

    • Interne en externe communicatierollen.

    • Hoofdrollen retrospectief en hoofdoorzaakanalyse (RCA).

  • Definieer de escalatiepaden die het workloadteam moet volgen om ervoor te zorgen dat de herstelstatus wordt gecommuniceerd aan 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.

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

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

    • Neem de vereisten op voor het uitvoeren van de procedure. Vermeld bijvoorbeeld de vereiste scripts of referenties die moeten worden verzameld.

    • Leg de hoofdoorzaak van het incident vast en voer beperking uit voordat u het herstel start. Als de oorzaak van het incident bijvoorbeeld een beveiligingsprobleem is, kunt u dat probleem oplossen voordat u de betrokken systemen in uw failoveromgeving herstelt.

  • Afhankelijk van het redundantieontwerp voor uw workload, moet u mogelijk veel werk na de failover uitvoeren voordat u de workload weer beschikbaar maakt voor uw klanten. Na de failover kunnen dns-updates, database- verbindingsreeks-updates en wijzigingen in verkeersroutering worden opgenomen. Leg al het werk na de failover vast in uw herstelprocedures.

    Notitie

    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 op transparante wijze automatisch een failover uitvoeren na een beschikbaarheidszone of regionale storing en de stappen in uw NOOD-plan minimaliseren die moeten worden uitgevoerd. En als u uw workload hebt ontworpen met behulp van implementatiestempels, kan het zijn dat u slechts een gedeeltelijke storing ondervindt als de zegels zonegebonden worden geïmplementeerd. In dit geval moet uw noodherstelplan betrekking hebben op het herstellen van stempels in niet-getroffen zones of regio's.

  • Als u uw app opnieuw wilt 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 onmiddellijk met uw app-implementaties kunt beginnen. Gebruik geautomatiseerde end-to-end-implementaties, indien nodig 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 interventie is vereist, documenteer je de handmatige stappen. Definieer rollen en verantwoordelijkheden duidelijk.

  • Automatiseer zoveel mogelijk van de procedure. Gebruik in uw scripts declaratief programmeren, omdat idempotentie hiermee is toegestaan. Als u geen declaratief programmeren kunt gebruiken, moet u rekening houden met het ontwikkelen en uitvoeren van uw aangepaste code. Gebruik logica voor opnieuw proberen en circuitonderbrekerlogica om te voorkomen dat er tijd wordt besteed aan scripts die vastzitten aan een niet-werkende taak. Omdat u deze scripts alleen in noodgevallen uitvoert, wilt u niet dat onjuist ontwikkelde scripts meer schade veroorzaken of het herstelproces vertragen.

    Notitie

    Automatisering brengt risico's met zich mee. Getrainde operators moeten de geautomatiseerde processen zorgvuldig controleren en ingrijpen als een proces problemen ondervindt. Als u het risico wilt minimaliseren dat automatisering op fout-positieven reageert, moet u uw DR-oefeningen grondig uitvoeren. Alle fasen van het plan testen. Simuleer detectie om waarschuwingen te genereren en doorloop vervolgens de volledige herstelprocedure.

    Houd er rekening mee dat uw dr-oefeningen updates van uw metrische hersteldoelgegevens moeten valideren of informeren. Als u merkt dat uw automatisering vatbaar is voor fout-positieven, moet u mogelijk de failoverdrempels verhogen.

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

    • De noodzaak om een failback uit te geven is van een situatie. Als u verkeer om prestatieredenen tussen regio's routert, is een failback van de belasting die oorspronkelijk in de regio met failover was, belangrijk. 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.

Herstelanalyses uitvoeren

Een dr-testpraktijk is net zo belangrijk als een goed ontwikkeld DR-plan. Veel branches hebben nalevingsframeworks waarvoor regelmatig een bepaald aantal DR-oefeningen moet worden uitgevoerd. Ongeacht uw branche, zijn regelmatige DR-oefeningen essentieel voor uw succes.

Volg deze aanbevelingen voor geslaagde DR-oefeningen:

  • Voer ten minste één dr-herstelanalyse voor productie per jaar uit. Tafelboormachines (droogloop) of niet-productieboormachines helpen ervoor te zorgen dat de betrokken partijen bekend zijn met hun rollen en verantwoordelijkheden. Deze oefeningen helpen operators ook bij het opbouwen van vertrouwdheid ('spiergeheugen') door herstelprocessen te volgen. Maar alleen productieanalyses testen echt de geldigheid van het DR-plan en de metrische RTO- en RPO-gegevens. Gebruik uw productieanalyses voor tijdherstelprocessen voor onderdelen en stromen om ervoor te zorgen dat de RTO- en RPO-doelen die voor uw workload zijn gedefinieerd, 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 waarbij deze functies betrokken zijn rekening houden met mogelijke vertragingen buiten uw controle.

  • Gebruik tafelanalyses niet alleen om vertrouwd te raken met ervaren operators, maar ook om nieuwe operators te informeren over DR-processen en -procedures. Senior operators moeten de tijd nemen om nieuwe operators hun rol te laten vervullen en moeten watch voor verbeteringsmogelijkheden. Als een nieuwe operator aarzelt of in de war is door een stap in een procedure, controleert u die procedure om ervoor te zorgen dat deze duidelijk is geschreven.

Overwegingen

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

  • Geef uw team zoveel mogelijk onderhoudstijd tijdens drills. Wanneer u onderhoudstijd plant, gebruikt u de metrische herstelgegevens die u tijdens het testen vastlegt als minimale tijd die nodig is voor toewijzingen.

  • Naarmate uw dr-oefeningen volwassener worden, leert u welke procedures u parallel kunt uitvoeren en welke u op volgorde moet uitvoeren. In het begin van uw analyseprocedures gaat u ervan uit dat elke procedure opeenvolgend moet worden uitgevoerd en dat u in elke stap extra tijd nodig hebt om onverwachte problemen af te handelen.

Azure-facilitering

Veel Azure-producten hebben ingebouwde failovermogelijkheden. Maak uzelf vertrouwd 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 reeks DR voor Azure-gegevensplatforms voor hulp bij het voorbereiden van een bedrijfsgegevensdomein voor herstel na noodgeval.

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor betrouwbaarheid