Doporučení pro návrh strategie zotavení po havárii

  • Článek

Platí pro toto doporučení kontrolního seznamu spolehlivosti azure Well-Architected Framework:

RE:09 Implementujte strukturované, otestované a zdokumentované plány provozní kontinuity a zotavení po havárii (BCDR), které jsou v souladu s cíli obnovení. Plány musí zahrnovat všechny komponenty a systém jako celek.

Tato příručka popisuje doporučení pro návrh spolehlivé strategie zotavení po havárii pro úlohu. Abyste splnili interní cíle úrovně služeb (SLO) nebo dokonce smlouvu o úrovni služeb (SLA), kterou jste svým zákazníkům garantovali, musíte mít robustní a spolehlivou strategii zotavení po havárii. Očekává se selhání a další závažné problémy. Vaše přípravy na řešení těchto incidentů určují, do jaké míry můžou vaši zákazníci důvěřovat vaší firmě, aby je spolehlivě doručili. Strategie zotavení po havárii je páteří přípravy na závažné incidenty.

Definice

Období Definice
Převzetí služeb při selhání Automatizované nebo ruční přesouvání provozu produkčních úloh z nedostupné oblasti do geografické oblasti, na které to nemá vliv.
Navrácení služeb po obnovení Automatizované nebo ruční přesouvání provozu produkčních úloh z oblasti převzetí služeb při selhání zpět do primární oblasti.

Klíčové strategie návrhu

V tomto průvodci se předpokládá, že jste již provedli následující úlohy v rámci plánování spolehlivosti:

Strategie spolehlivého zotavení po havárii staví na základech spolehlivé architektury úloh. Vyřešte spolehlivost v každé fázi vytváření úloh, abyste měli jistotu, že před zahájením návrhu strategie zotavení po havárii budou potřebné součásti pro optimalizované obnovení. Tento základ zajišťuje, že cíle spolehlivosti vašich úloh, jako je cíl doby obnovení (RTO) a cíl bodu obnovení (RPO), budou realistické a dosažitelné.

Údržba plánu zotavení po havárii

Základním kamenem spolehlivé strategie zotavení po havárii pro úlohu je plán zotavení po havárii. Váš plán by měl být živým dokumentem, který se s vývojem prostředí pravidelně kontroluje a aktualizuje. Pravidelně prezentujte plán příslušným týmům (provoznímu, technologickému vedení a obchodním zúčastněným stranám) (například každých šest měsíců). Uložte ho do vysoce dostupného zabezpečeného úložiště dat, jako je OneDrive pro firmy.

Při vývoji plánu zotavení po havárii postupujte podle těchto doporučení:

  • Jasně definujte, co představuje havárii, a proto vyžaduje aktivaci plánu zotavení po havárii.

    • Katastrofy jsou rozsáhlé problémy. Může se jednat o regionální výpadky, výpadky služeb, jako je id Microsoft Entra nebo Azure DNS, nebo závažné škodlivé útoky, jako jsou útoky ransomwarem nebo útoky DDoS.

    • Identifikujte režimy selhání, které se nepovažují za havárie, jako je selhání jednoho prostředku, aby operátory omylem nevyvolaly eskalaci zotavení po havárii.

  • Vytvořte plán zotavení po havárii v dokumentaci k FMA. Ujistěte se, že váš plán zotavení po havárii zachycuje režimy selhání a strategie zmírnění výpadků, které jsou definované jako katastrofy. Aktualizujte plán zotavení po havárii i dokumenty FMA paralelně, aby byly přesné, když se změní prostředí nebo když testování odhalí neočekávané chování.

    • To, jestli vyvíjíte plány zotavení po havárii pro neprodukční prostředí, závisí na vašich obchodních požadavcích a dopadech na náklady. Pokud například určitým zákazníkům nabízíte prostředí pro zajištění kvality (QA) pro předběžné testování, můžete tato prostředí zahrnout do plánování zotavení po havárii.

  • Jasně definujte role a zodpovědnosti v rámci týmu úloh a porozumíte všem souvisejícím externím rolím ve vaší organizaci. Mezi role patří:

    • Strana odpovědná za prohlášení o havárii.

    • Strana odpovědná za prohlášení o uzavření incidentu.

    • Provozní role.

    • Role testování a ověřování.

    • Role interní a externí komunikace.

    • Retrospektivní role a hlavní role analýzy původní příčiny (RCA).

  • Definujte cesty eskalace, kterými se tým úloh musí řídit, aby se zajistilo, že se stav obnovení sdělí zúčastněným stranám.

  • Zachyťte postupy obnovení na úrovni komponent, obnovení na úrovni datových aktiv a procesy obnovení pro celou úlohu. Zahrňte předepsané pořadí operací, abyste zajistili, že se komponenty obnoví co nejméně. Můžete například obnovit a zkontrolovat databáze před obnovením aplikace.

    • Podrobné informace o jednotlivých postupech obnovení na úrovni komponent najdete v podrobném průvodci. Pokud je to možné, uveďte snímky obrazovky.

    • Definujte povinnosti vašeho týmu oproti zodpovědnostem poskytovatele cloudového hostingu. Microsoft například zodpovídá za obnovení PaaS (platforma jako služba), ale za dosazování dat a použití konfigurace služby zodpovídáte vy.

    • Zahrňte požadavky pro spuštění procedury. Můžete například zobrazit seznam požadovaných skriptů nebo přihlašovacích údajů, které je potřeba shromáždit.

    • Před zahájením obnovení zaznamenejte původní příčinu incidentu a proveďte zmírnění rizik. Pokud je příčinou incidentu například problém se zabezpečením, před obnovením ovlivněných systémů v prostředí převzetí služeb při selhání tento problém zmírněte.

  • V závislosti na návrhu redundance pro vaši úlohu může být potřeba provést významné kroky po převzetí služeb při selhání, než úlohu znovu zpřístupníte zákazníkům. Práce po převzetí služeb při selhání může zahrnovat aktualizace DNS, aktualizace připojovací řetězec databáze a změny směrování provozu. Zaznamenejte všechny práce po převzetí služeb při selhání v postupech obnovení.

    Poznámka

    Váš návrh redundance vám může umožnit automatické zotavení z hlavních incidentů zcela nebo částečně, proto se ujistěte, že váš plán zahrnuje procesy a postupy, které se v těchto scénářích obhosílaly. Pokud máte například plně aktivní-aktivní návrh, který zahrnuje zóny dostupnosti nebo oblasti, můžete být schopni transparentně automaticky převzít služby při selhání po výpadku zóny dostupnosti nebo oblasti a minimalizovat kroky v plánu zotavení po havárii, které je potřeba provést. Podobně, pokud jste navrhli úlohu pomocí razítek nasazení, může dojít pouze k částečnému výpadku, pokud jsou razítka nasazena zónově. V takovém případě by se váš plán zotavení po havárii měl zabývat tím, jak obnovit razítka v nedotčených zónách nebo oblastech.

  • Pokud potřebujete aplikaci znovu nasadit v prostředí převzetí služeb při selhání, využijte nástroje k co největší automatizaci procesu nasazení. Ujistěte se, že jsou vaše kanály DevOps předem nasazené a nakonfigurované v prostředích převzetí služeb při selhání, abyste mohli okamžitě zahájit nasazování aplikací. K zajištění konzistentního a efektivního procesu nasazení používejte automatizovaná kompletní nasazení s ručním schvalováním v případě potřeby. Úplná doba trvání nasazení musí odpovídat vašim cílům obnovení.

    • Pokud fáze procesu nasazení vyžaduje ruční zásah, zdokumentujte ruční kroky. Jasně definovat role a odpovědnosti.

  • Automatizujte co nejvíce procedur. Ve skriptech použijte deklarativní programování, protože umožňuje idempotenci. Pokud nemůžete použít deklarativní programování, mějte na paměti vývoj a spouštění vlastního kódu. Použijte logiku opakování a logiku jističe, abyste se vyhnuli plýtvání časem na skriptech, které jsou zablokované u nefunkční úlohy. Vzhledem k tomu, že tyto skripty spouštíte pouze v nouzových situacích, nechcete, aby nesprávně vyvinuté skripty způsobily větší poškození nebo zpomalily proces obnovení.

    Poznámka

    Automatizace představuje riziko. Vytrénované operátory musí automatizované procesy pečlivě monitorovat a zasahovat, pokud dojde k problémům. Pokud chcete minimalizovat riziko, že automatizace bude reagovat na falešně pozitivní výsledky, pečlivě se řiďte postupy zotavení po havárii. Otestujte všechny fáze plánu. Simulujte detekci, která vygeneruje výstrahy, a pak projděte celou proceduru obnovení.

    Nezapomeňte, že postup zotavení po havárii by měl ověřovat nebo informovat o aktualizacích metrik cíle obnovení. Pokud zjistíte, že vaše automatizace je náchylná k falešně pozitivním výsledkům, možná budete muset zvýšit prahové hodnoty převzetí služeb při selhání.

  • Oddělte plán navrácení služeb po obnovení od plánu zotavení po havárii, abyste se vyhnuli možným nejasnostem s postupy zotavení po havárii. Plán navrácení služeb po obnovení by se měl řídit všemi doporučeními plánu zotavení po havárii a údržby a měl by být strukturován stejným způsobem. Všechny ruční kroky potřebné pro převzetí služeb při selhání by měly být zrcadlené v plánu navrácení služeb po obnovení. Navrácení služeb po obnovení může proběhnout rychle po převzetí služeb při selhání nebo může trvat dny nebo týdny. Zvažte navrácení služeb po obnovení jako oddělené od převzetí služeb při selhání.

    • Potřeba navrácení služeb po obnovení je situační. Pokud kvůli výkonu směrujete provoz mezi oblastmi, je důležité vrátit zatížení původně v oblasti převzetí služeb při selhání po obnovení. V jiných případech můžete úlohu navrhnout tak, aby fungovala plně bez ohledu na to, ve kterém produkčním prostředí se kdykoli nachází.

Provádění postupů zotavení po havárii

Postup testování zotavení po havárii je stejně důležitý jako dobře vyvinutý plán zotavení po havárii. Mnoho odvětví má architektury dodržování předpisů, které vyžadují určitý počet pravidelných cvičení zotavení po havárii. Bez ohledu na vaše odvětví jsou pravidelné postupy zotavení po havárii nejdůležitější pro váš úspěch.

Pro úspěšné zotavení po havárii postupujte podle těchto doporučení:

  • Proveďte alespoň jeden postup zotavení po havárii v produkčním prostředí za rok. Stolní (suché) cvičení nebo neprodukční cvičení pomáhají zajistit, aby zúčastněné strany byly obeznámeny se svými rolemi a odpovědnostmi. Tyto postupy také pomáhají operátorům vytvářet znalosti ("svalovou paměť") sledováním procesů zotavení. Platnost plánu zotavení po havárii a metrik RTO a RPO ale skutečně testují pouze produkční postupy. Pomocí produkčních postupů načasujte procesy obnovení komponent a toků, abyste zajistili, že cíle rtO a RPO definované pro vaši úlohu jsou dosažitelné. U funkcí, které nemáte pod kontrolou, jako je šíření DNS, se ujistěte, že cíle RTO a RPO pro toky, které tyto funkce zahrnují, zohledňují možná zpoždění mimo vaši kontrolu.

  • Používejte stolní postupy nejen k budování znaména pro ostřílé operátory, ale také k informování nových operátorů o procesech a postupech zotavení po havárii. Starší operátoři by měli nějakou dobu trvat, než nechají nové operátory plnit svou úlohu, a měli by watch příležitostí ke zlepšení. Pokud je nový operátor váhavý nebo zmatený krokem v postupu, zkontrolujte tento postup a ujistěte se, že je jasně napsaný.

Požadavky

  • Provádění postupu zotavení po havárii v produkčním prostředí může způsobit neočekávaná katastrofická selhání. Během počátečních nasazení nezapomeňte otestovat postupy obnovení v neprodukčních prostředích.

  • Poskytněte týmu během cvičení co nejvíce času na údržbu. Při plánování doby údržby použijte metriky obnovení, které zaznamenáte během testování , jako minimální čas potřebných přidělení.

  • S postupnou postupem zotavení po havárii se dozvíte, které postupy můžete spustit paralelně a které musíte spustit v posloupnosti. Na začátku postupů přechodu k podrobnostem předpokládejme, že každá procedura musí být spuštěna postupně a že potřebujete v každém kroku více času, abyste zvládli neočekávané problémy.

Usnadnění Azure

Mnoho produktů Azure má integrované funkce převzetí služeb při selhání. Seznamte se s těmito funkcemi a zahrňte je do postupů obnovení.

V případě systémů IaaS (infrastruktura jako služba) použijte Azure Site Recovery k automatizaci převzetí služeb při selhání a obnovení. Běžné produkty PaaS najdete v následujících článcích:

Příklad

Pokyny k přípravě podnikových datových aktiv pro zotavení po havárii najdete v sérii zotavení po havárii pro zotavení po havárii.

Kontrolní seznam spolehlivosti

Projděte si kompletní sadu doporučení.

Kontrolní seznam spolehlivosti