Rekommendationer för att utforma en strategi för haveriberedskap

  • Artikel

Gäller för den här rekommendationen om checklista för tillförlitlighet i Azure Well-Architected Framework:

RE:09 Implementera strukturerade, testade och dokumenterade BCDR-planer (affärskontinuitet och haveriberedskap) som överensstämmer med återställningsmålen. Planer måste omfatta alla komponenter och systemet som helhet.

Den här guiden beskriver rekommendationer för att utforma en tillförlitlig strategi för haveriberedskap för en arbetsbelastning. För att uppfylla interna servicenivåmål (SLO) eller till och med ett serviceavtal (SLA) som du har garanterat för dina kunder måste du ha en robust och tillförlitlig strategi för haveriberedskap. Fel och andra större problem förväntas. Dina förberedelser för att hantera dessa incidenter avgör hur mycket dina kunder kan lita på att ditt företag levererar på ett tillförlitligt sätt åt dem. En strategi för haveriberedskap är ryggraden i förberedelserna för större incidenter.

Definitioner

Period Definition
Redundans Automatisk och/eller manuell växling av produktionsarbetsbelastningstrafik från en otillgänglig region till en opåverkad geografisk region.
Återställning efter fel Automatisk och/eller manuell växling av produktionsarbetsbelastningstrafik från en redundansregion tillbaka till den primära regionen.

Viktiga designstrategier

Den här guiden förutsätter att du redan har utfört följande uppgifter som en del av tillförlitlighetsplaneringen:

En tillförlitlig haveriberedskapsstrategi bygger på en tillförlitlig arbetsbelastningsarkitektur. Hantera tillförlitligheten i varje steg när du skapar din arbetsbelastning för att säkerställa att nödvändiga delar för optimerad återställning finns på plats innan du börjar utforma din DR-strategi. Den här grunden säkerställer att arbetsbelastningens tillförlitlighetsmål, till exempel mål för återställningstid (RTO) och mål för återställningspunkter (RPO), är realistiska och kan uppnås.

Underhålla en haveriberedskapsplan

Hörnstenen i en tillförlitlig DR-strategi för en arbetsbelastning är DR-planen. Din plan bör vara ett levande dokument som regelbundet granskas och uppdateras i takt med att din miljö utvecklas. Presentera planen för lämpliga team (drift, teknikledarskap och affärsintressenter) regelbundet (till exempel var sjätte månad). Lagra den i ett säkert datalager med hög tillgänglighet, till exempel OneDrive för företag.

Följ dessa rekommendationer för att utveckla din DR-plan:

  • Definiera tydligt vad som utgör en katastrof och kräver därför aktivering av haveriberedskapsplanen.

    • Katastrofer är storskaliga problem. Det kan vara regionala avbrott, avbrott i tjänster som Microsoft Entra-ID eller Azure DNS, eller allvarliga skadliga attacker som utpressningstrojanattacker eller DDoS-attacker.

    • Identifiera fellägen som inte betraktas som katastrofer, till exempel fel för en enskild resurs, så att operatörerna inte av misstag anropar sina DR-eskaleringar.

  • Skapa DR-planen i FMA-dokumentationen. Se till att dr-planen samlar in fellägen och riskreduceringsstrategier för avbrott som definieras som katastrofer. Uppdatera både din DR-plan och dina FMA-dokument parallellt så att de är korrekta när miljön ändras eller när testningen upptäcker oväntade beteenden.

    • Om du utvecklar DR-planer för icke-produktionsmiljöer beror på dina affärskrav och kostnadspåverkan. Om du till exempel erbjuder kvalitetssäkringsmiljöer (QA) till vissa kunder för förhandstestning kanske du vill inkludera dessa miljöer i din DR-planering.

  • Definiera roller och ansvarsområden i arbetsbelastningsteamet tydligt och förstå eventuella relaterade externa roller i din organisation. Rollerna bör innehålla:

    • Den part som ansvarar för att förklara en katastrof.

    • Den part som ansvarar för att förklara incidenten avslutad.

    • Driftroller.

    • Testnings- och valideringsroller.

    • Interna och externa kommunikationsroller.

    • Leadroller för retrospektiv och rotorsaksanalys (RCA).

  • Definiera de eskaleringsvägar som arbetsbelastningsteamet måste följa för att säkerställa att återställningsstatusen meddelas till intressenterna.

  • Samla in återställningsprocedurer på komponentnivå, återställning på dataegendomsnivå och arbetsbelastningsomfattande återställningsprocesser. Inkludera en föreskriven ordning för åtgärder för att säkerställa att komponenterna återställs på det minst effektfulla sättet. Du kan till exempel återställa och kontrollera databaser innan du återställer programmet.

    • Gå igenom varje återställningsprocedur på komponentnivå som en steg-för-steg-guide. Inkludera skärmbilder om det är möjligt.

    • Definiera ditt teams ansvar jämfört med molnvärdleverantörens ansvarsområden. Microsoft ansvarar till exempel för att återställa en PaaS (plattform som en tjänst), men du ansvarar för att extrahera data och tillämpa din konfiguration på tjänsten.

    • Inkludera förutsättningar för att köra proceduren. Ange till exempel de skript eller autentiseringsuppgifter som krävs för att samlas in.

    • Samla in rotorsaken till incidenten och utför åtgärder innan du påbörjar återställningen. Om orsaken till incidenten till exempel är ett säkerhetsproblem kan du åtgärda problemet innan du återställer de berörda systemen i redundansmiljön.

  • Beroende på redundansdesignen för din arbetsbelastning kan du behöva utföra betydande arbete efter redundans innan du gör arbetsbelastningen tillgänglig för dina kunder igen. Arbetet efter redundansväxlingen kan omfatta DNS-uppdateringar, databasuppdateringar anslutningssträng och trafikroutningsändringar. Samla in allt arbete efter redundansväxlingen i dina återställningsprocedurer.

    Anteckning

    Din redundansdesign kan göra att du automatiskt kan återställa från större incidenter helt eller delvis, så se till att planen innehåller processer och procedurer kring dessa scenarier. Om du till exempel har en helt aktiv-aktiv design som sträcker sig över tillgänglighetszoner eller regioner kan du transparent redundansväxla automatiskt efter en tillgänglighetszon eller ett regionalt avbrott och minimera stegen i din DR-plan som måste utföras. Om du har utformat din arbetsbelastning med hjälp av distributionsstämplar kan du dessutom drabbas av ett partiellt avbrott om stämplarna distribueras zonindelade. I det här fallet bör dr-planen omfatta hur du återställer stämplar i opåverkade zoner eller regioner.

  • Om du behöver distribuera om din app i redundansmiljön använder du verktyg för att automatisera distributionsprocessen så mycket som möjligt. Kontrollera att dina DevOps-pipelines har fördistribuerats och konfigurerats i redundansmiljöerna så att du omedelbart kan påbörja appdistributionerna. Använd automatiserade distributioner från slutpunkt till slutpunkt, med manuella godkännandegrindar där det behövs, för att säkerställa en konsekvent och effektiv distributionsprocess. Den fullständiga distributionstiden måste överensstämma med dina återställningsmål.

    • När ett steg i distributionsprocessen kräver manuella åtgärder dokumenterar du de manuella stegen. Definiera roller och ansvarsområden tydligt.

  • Automatisera så mycket av proceduren som möjligt. Använd deklarativ programmering i skripten eftersom det tillåter idempotens. När du inte kan använda deklarativ programmering bör du tänka på att utveckla och köra din anpassade kod. Använd logik för återförsök och kretsbrytare för att undvika att slösa tid på skript som har fastnat i en bruten uppgift. Eftersom du bara kör skripten i nödsituationer vill du inte att felaktigt utvecklade skript ska orsaka mer skada eller göra återställningsprocessen långsammare.

    Anteckning

    Automatisering innebär risker. Utbildade operatörer måste övervaka de automatiserade processerna noggrant och ingripa om någon process stöter på problem. För att minimera risken för att automatiseringen reagerar på falska positiva identifieringar bör du vara noggrann i dr-testerna. Testa alla faser i planen. Simulera identifiering för att generera aviseringar och gå sedan igenom hela återställningsproceduren.

    Kom ihåg att dina DR-test bör verifiera eller informera uppdateringar av dina mått för återställningsmål. Om du upptäcker att din automatisering är sårbar för falska positiva identifieringar kan du behöva öka tröskelvärdena för redundans.

  • Separera planen för återställning efter fel från dr-planen för att undvika eventuell förvirring med dr-procedurerna. Planen för återställning efter fel bör följa alla rekommendationer för utveckling och underhåll av katastrofåterställningsplanen och bör struktureras på samma sätt. Alla manuella steg som var nödvändiga för redundansväxling bör speglas i planen för återställning efter fel. Återställning efter fel kan ske snabbt efter redundansväxlingen, eller så kan det ta dagar eller veckor. Överväg återställning efter fel som separat från redundans.

    • Behovet av att växla tillbaka är situationsbaserad. Om du dirigerar trafik mellan regioner av prestandaskäl är det viktigt att du växlar tillbaka den belastning som ursprungligen var i den redansväxla regionen. I andra fall kan du ha utformat din arbetsbelastning så att den fungerar fullt ut oavsett vilken produktionsmiljö den finns i när som helst.

Utföra programåterställningstest

En DR-testpraxis är lika viktig som en välutvecklad DR-plan. Många branscher har efterlevnadsramverk som kräver att ett angivet antal DR-test utförs regelbundet. Oavsett din bransch är regelbundna DR-övningar av största vikt för din framgång.

Följ dessa rekommendationer för lyckade DR-övningar:

  • Utför minst ett dr-test för produktion per år. Bordsövningar (torrkörning) eller icke-produktionsövningar hjälper till att säkerställa att de berörda parterna är bekanta med sina roller och ansvarsområden. De här övningarna hjälper även operatörerna att skapa kunskap ("muskelminne") genom att följa återställningsprocesserna. Men endast produktionstest testar verkligen giltigheten för DR-planen och RTO- och RPO-måtten. Använd dina produktionstest för att tidsbestämma återställningsprocesser för komponenter och flöden för att säkerställa att rto- och RPO-målen som har definierats för din arbetsbelastning kan uppnås. För funktioner som är utom din kontroll, till exempel DNS-spridning, ser du till att RTO- och RPO-målen för de flöden som involverar dessa funktioner står för eventuella fördröjningar utanför din kontroll.

  • Använd tabletop-övningar inte bara för att skapa kunskaper för erfarna operatörer utan också för att utbilda nya operatörer om DR-processer och procedurer. Högre operatörer bör ta sig tid att låta nya operatörer utföra sin roll och bör watch för förbättringsmöjligheter. Om en ny operatör är tveksam eller förvirrad av ett steg i en procedur granskar du proceduren för att säkerställa att den är tydligt skriven.

Överväganden

  • Om du utför DR-test i produktion kan det orsaka oväntade oåterkalleliga fel. Se till att testa återställningsprocedurer i icke-produktionsmiljöer under dina första distributioner.

  • Ge ditt team så mycket underhållstid som möjligt under övningar. När du planerar för underhållstid använder du de återställningsmått som du samlar in under testningen som den minsta tid som krävs för tilldelningar.

  • När dr-detaljnivån mognar får du lära dig vilka procedurer du kan köra parallellt och vilka du måste köra i följd. Tidigt i detaljgranskningspraxis förutsätter vi att varje procedur måste köras i följd och att du behöver extra tid i varje steg för att hantera oväntade problem.

Azure-underlättande

Många Azure-produkter har inbyggda redundansfunktioner. Bekanta dig med dessa funktioner och inkludera dem i återställningsprocedurer.

För IaaS-system (infrastruktur som en tjänst) använder du Azure Site Recovery för att automatisera redundans och återställning. Se följande artiklar för vanliga PaaS-produkter:

Exempel

Se dr för Azure-dataplattformsserien för vägledning om hur du förbereder en företagsdataegendom för DR.

Checklista för tillförlitlighet

Se den fullständiga uppsättningen rekommendationer.

Checklista för tillförlitlighet