Doporučení pro návrh strategie zotavení po havárii
Platí pro toto doporučení Power Platform Dobře architektonizovaného kontrolního seznamu spolehlivosti:
| RE: 07 | Implementujte strukturované, testované a zdokumentované plány provozní kontinuity a zotavení po havárii (BCDR), které jsou v souladu s cíli obnovy. Plány musí zahrnovat všechny komponenty a systém jako celek. |
|---|
Tato příručka popisuje doporučení pro návrh spolehlivé strategie obnovy po havárii pro úlohu. Abyste plnili interní cíle úrovně služeb (SLO) nebo dokonce smlouvu o úrovni služeb (SLA), kterou jste svým zákazníkům zaručili, musíte mít robustní a spolehlivou strategii zotavení po havárii. Selhání a další závažné problémy se dají očekávat. Vaše přípravy na řešení těchto incidentů určují, do jaké míry mohou vaši zákazníci důvěřovat vaší firmě, že jim spolehlivě dodá. Strategie zotavení po havárii je páteří přípravy na závažné incidenty.
Definice
| Pojem | definice |
|---|---|
| Převzetí služeb při selhání | Automatizované nebo manuální přesunutí provozu produkční úlohy z nedostupné oblasti do neovlivněné oblasti. |
| Navrácení služeb po obnovení | Automatizované nebo manuální přesunutí provozu produkční úlohy z oblasti převzetí služeb při selhání zpět do primární oblasti. |
Klíčové strategie návrhu
Tato příručka předpokládá, že jste v rámci plánování spolehlivosti již provedli následující úkoly:
Identifikovali kritické a nekritické toky.
Provedli analýzu režimu selhání (FMA) pro vaše toky.
Identifikovali cíle spolehlivosti.
Navrhli robustní strategii testování.
Spolehlivá architektura úlohy je základem strategie spolehlivého zotavení po havárii (DR). Zvažte spolehlivost v každé fázi vytváření úlohy, abyste se ujistili, že máte potřebné komponenty pro efektivní obnovu, než začnete plánovat strategii DR. Tento základ zajišťuje, že cíle spolehlivosti úlohy, jako je cíl doby obnovy (RTO) a cíl bodu obnovy (RPO), jsou praktické a dosažitelné.
Udržujte plán zotavení po havárii
Klíčem ke spolehlivé strategii DR pro úlohu je plán DR. Váš plán by měl být živým dokumentem, který je pravidelně revidován a aktualizován podle toho, jak se mění vaše prostředí. Pravidelně (například každých šest měsíců) sdílejte plán s příslušnými týmy (provozní, technologické vedení a obchodní partneři). Uchovávejte ho ve vysoce dostupném, zabezpečeném úložišti dat jako OneDrive.
Při vývoji plánu DR postupujte podle těchto doporučení:
Jasně definujte, co představuje havárii a vyžaduje aktivaci plánu DR.
Havárie jsou problémy velkého rozsahu. Mohou to být regionální výpadky, výpadky služeb, jako je Microsoft Entra ID nebo Azure DNS, nebo závažné škodlivé útoky, jako jsou útoky ransomwaru nebo útoky DDoS.
Zahrňte do svého plánu DR příklady režimů selhání, které nejsou považovány za havárie, jako je například nedostupnost nebo selhání jednoho zdroje, aby operátoři omylem nevyvolali eskalaci DR.
Postavte plán DR na dokumentaci FMA. Ujistěte se, že váš plán DR zachycuje režimy selhání a strategie řešení výpadků, které jsou definovány jako havárie. Pokud jsou vyžadovány aktualizace, aktualizujte svůj plán DR i dokumenty FMA současně, aby byly přesné, když se změní prostředí nebo když testování odhalí neočekávané chování.
Jasně definujte role a odpovědnosti v rámci pracovního týmu a pochopte všechny související externí role ve vaší organizaci. Pokud je havárie způsobena výpadkem externí služby, jako je Microsoft Entra ID, ujistěte se, že máte definovanou roli, která je zodpovědná za komunikaci s externí stranou a může sdílet aktualizace s týmem pro úlohu. Role by měly zahrnovat:
- Stranu odpovědná za vyhlášení havárie
- Stranu odpovědná za vyhlášení uzavření případu
- Role operací
- Role testování a ověřování
- Role interní a externí komunikace
- Retrospektivní a hlavní role analýzy kořenových příčin (RCA)
Definujte cesty eskalace, které musí tým úlohy dodržovat, aby bylo zajištěno, že stav obnovy bude sdělen zúčastněným stranám.
Uveďte předepsané pořadí, ve kterém by měly být složky úlohy obnoveny, aby měly co nejmenší dopad. Před obnovením aplikace například obnovte databáze a restartujte cloudové toky.
Podrobně popište postup obnovy každé součásti jako průvodce krok za krokem. Pokud je to možné, zahrňte snímky obrazovky a předpoklady pro spuštění postupu. Uveďte například požadované skripty nebo přihlašovací údaje, které je třeba shromáždit.
Definujte povinnosti svého týmu oproti povinnostem poskytovatele cloudového hostingu. Například Microsoft je zodpovědný za obnovení PaaS (platforma jako služba), ale vy jste zodpovědní za rehydrataci dat a použití vaší konfigurace na službu.
Než začnete s obnovou, zachyťte hlavní příčinu incidentu a proveďte řešení. Pokud je například příčinou incidentu problém se zabezpečením, vyřešte tento problém předtím, než obnovíte postižené systémy ve svém prostředí převzetí služeb při selhání.
Pokud potřebujete znovu nasadit aplikaci v prostředí převzetí služeb při selhání, použijte nástroje k co největší automatizaci procesu nasazení. Ujistěte se, že jsou vaše Azure Pipelines předem nasazené a správně nakonfigurované v prostředích s podporou převzetí služeb při selhání, abyste mohli okamžitě začít s nasazením. Používejte automatizovaná komplexní nasazení s manuálními schvalovacími bránami tam, kde je to nutné, abyste zajistili konzistentní a efektivní proces nasazení. Pokud fáze procesu nasazení vyžaduje ruční zásah, zdokumentujte ruční kroky. Jasně definujte role a odpovědnosti.
Automatizujte proces, jak jen můžete. Použijte logiku opakování, abyste se vyhnuli plýtvání časem na skriptech, které uvízly na nefunkčním úkolu. Protože tyto skripty spouštíte pouze v případě nouze, nechcete, aby nesprávně vyvinuté skripty způsobily další škody nebo zpomalily proces obnovy.
Poznámka:
Automatizace přináší rizika. Vyškolení operátoři musí pečlivě sledovat automatizované procesy a zasáhnout, pokud nějaký proces narazí na problémy. Abyste minimalizovali riziko, že automatizace zareaguje na falešné poplachy, buďte ve svých cvičeních DR důkladní. Otestujte všechny fáze plánu. Simulujte detekci pro generování výstrah a poté projděte celým postupem obnovy.
Proveďte cvičení zotavení po havárii
Praxe testování DR je nezbytná pro dobrý plán DR. Mnoho průmyslových odvětví má rámce shody, které vyžadují pravidelná cvičení DR. Bez ohledu na vaše odvětví jsou časté cvičení DR zásadní pro váš úspěch.
Pro úspěšné cvičení DR postupujte podle těchto doporučení:
Proveďte alespoň jedno produkční cvičení DR za rok. Cvičení nanečisto nebo neprodukční cvičení pomáhají zajistit, aby zúčastněné strany byly obeznámeny se svými rolemi a odpovědnostmi. Tato cvičení také pomáhají operátorům budovat znalosti tím, že dodržují procesy obnovy. Ale pouze produkční cvičení skutečně testují platnost plánu DR a metriky RTO a RPO. Pomocí produkčních cvičení načasujte procesy obnovy komponent a toků, abyste zajistili, že cíle RTO a RPO, které byly definovány pro vaši úlohu, jsou dosažitelné. Pro funkce, které jsou mimo vaši kontrolu, např. výpadky Microsoft Entra ID, zajistěte, aby cíle RTO a RPO pro toky, které zahrnují tyto funkce, zohledňovaly možná zpoždění, která jsou mimo vaši kontrolu.
Použijte cvičení nanečisto ke vzdělávání nových operátorů o procesech a postupech DR. Starší operátoři by měli věnovat čas tomu, aby nechali nové operátory vykonávat svou roli, a měli by sledovat příležitosti ke zlepšení. Pokud nový operátor váhá nebo je zmatený krokem v postupu, prostudujte si tento postup a ujistěte se, že je jasně napsaný.
Důležité informace
Provádění cvičení DR v produkci může způsobit neočekávané katastrofické poruchy. Během počátečního nasazení nezapomeňte otestovat procedury obnovy v neprodukčních prostředích.
Dejte svému týmu během cvičení co nejvíce času na údržbu. Při plánování doby údržby použijte metriky obnovy, které zachytíte během testování přidělení minimálního potřebného času.
Jak se vaše cvičení DR zdokonalují, dozvíte se, které postupy můžete provádět paralelně a které musíte provádět postupně. Na začátku cvičení předpokládejte, že každý postup musí být spuštěn v pořadí a že v každém kroku potřebujete čas navíc, abyste zvládli neočekávané problémy.
Funkce převzetí služeb při selhání
Microsoft Obchodní aplikace poskytují funkce kontinuity podnikání a obnovy po havárii (BCDR) všem produkčním prostředím v aplikacích Dynamics 365 a Power Platform software jako služba (SAAS). Zjistěte, jak Microsoft zajistí, aby vaše produkční data byla odolná během regionálních výpadků.
Kontrolní seznam spolehlivosti
Podívejte se na úplný soubor doporučení.