Upravit

Sdílet prostřednictvím

Zotavení po havárii pro platformu Azure Data Platform – Nasazení tohoto scénáře

Azure Synapse Analytics
Azure Machine Learning
Azure Cosmos DB
Azure Data Lake
Azure Event Hubs

Požadované aktivity zákazníků

Před incidentem

Pro služby Azure

  • Seznamte se se službou Azure Service Health na webu Azure Portal. Tato stránka bude během incidentu fungovat jako "one-stop shop".
  • Zvažte použití upozornění služby Service Health, která je možné nakonfigurovat tak, aby automaticky vytvářela oznámení, když dojde k incidentům Azure.

Pro Power BI

  • Seznamte se se službou Service Health v Centrum pro správu Microsoftu 365. Tato stránka bude během incidentu fungovat jako "one-stop shop".
  • Zvažte použití Správa Microsoftu 365 mobilní aplikace k získání automatických oznámení o upozorněních na incidenty služby.

Během incidentu

Pro služby Azure

  • Azure Service Health na portálu pro správu Azure poskytne nejnovější aktualizace.
    • Pokud při přístupu ke službě Service Health dojde k problémům, přejděte na stránku Stavu Azure.
    • Pokud někdy dojde k problémům s přístupem na stránku Stav, přejděte na @AzureSupport X (dříve Twitter).
  • Pokud dopad nebo problémy neodpovídají incidentu (nebo po zmírnění rizika přetrvávají), obraťte se na podporu a vytvořte lístek podpory služby.

Pro Power BI

  • Stránka Service Health v rámci svého Centrum pro správu Microsoftu 365 poskytne nejnovější aktualizace.
    • Pokud při přístupu ke službě Service Health dochází k problémům, přejděte na stránku stavu Microsoftu 365.
    • Pokud dopad nebo problémy neodpovídají incidentu (nebo pokud problémy po zmírnění rizika potrvají), měli byste vytvořit lístek podpory služby.

Po obnovení Microsoftu

Podrobnosti najdete v následujících částech.

Po incidentu

Pro služby Azure

Pro Power BI

Čekání na proces Microsoftu

Proces Čekání na Microsoft jednoduše čeká, až Microsoft obnoví všechny komponenty a služby v ovlivněné primární oblasti. Po obnovení ověřte vazbu datové platformy na sdílenou podnikovou nebo jinou službu, datum datové sady a pak proveďte procesy přenesení systému do aktuálního data.

Po dokončení tohoto procesu je možné dokončit ověření odborníka na danou problematiku technického a obchodního subjektu, což umožňuje schválení účastníků pro obnovení služby.

Opětovné nasazení při havárii

Pro strategii opětovného nasazení na havárii je možné popsat následující postup procesu vysoké úrovně.

  1. Obnovení podnikových sdílených služeb a zdrojových systémů společnosti Contoso

    Diagram znázorňující obnovení sdílených služeb a zdrojových systémů společnosti Contoso

    • Tento krok je předpokladem pro obnovení datové platformy.
    • Tento krok by dokončily různé skupiny provozní podpory společnosti Contoso zodpovědné za podnikové sdílené služby a operační zdrojové systémy.

  2. Obnovení služeb Azure Služby Azure odkazuje na aplikace a služby, které poskytují nabídku Cloudu Azure, jsou k dispozici v sekundární oblasti pro nasazení.

    Diagram znázorňující obnovení služeb Azure

    Služby Azure odkazují na aplikace a služby, které nabízejí cloud Azure, jsou k dispozici v sekundární oblasti pro nasazení.

    • Tento krok je předpokladem pro obnovení datové platformy.
    • Tento krok dokončí partneři Microsoftu a další platformy jako služby (PaaS) nebo software jako služba (SaaS).

  3. Obnovení základu datové platformy

    Diagram znázorňující obnovení základních systémů datové platformy

    • Tento krok je vstupním bodem pro aktivity obnovení platformy.
    • Pro strategii opětovného nasazení by se každá požadovaná komponenta nebo služba pořila a nasadila do sekundární oblasti.
    • Tento proces by měl zahrnovat také aktivity, jako je vazba ke sdíleným službám organizace, zajištění připojení k přístupu/ověřování a ověření, že snižování zátěže protokolu funguje, a zároveň zajistit připojení k nadřazeným i podřízeným procesům.
    • Data nebo zpracování by se měly potvrdit. Například ověření časového razítka obnovené platformy.
      • Pokud existují otázky týkající se integrity dat, je možné rozhodnutí vrátit se v čase, než spustíte nové zpracování, aby platforma byla aktuální.
    • Uspořádání priorit procesů (na základě obchodního dopadu) pomůže při orchestraci obnovení.
    • Tento krok by měl být uzavřen technickým ověřením, pokud podnikoví uživatelé přímo nepracují se službami. Pokud existuje přímý přístup, bude potřeba provést krok ověření firmy.
    • Po dokončení ověření proběhne předání jednotlivým týmům řešení, aby zahájily vlastní proces zotavení po havárii (DR).
      • Tato předání by měla obsahovat potvrzení aktuálního časového razítka dat a procesů.
      • Pokud se budou spouštět základní procesy podnikových dat, měli byste o tom vědět jednotlivá řešení – například příchozí nebo odchozí toky.

  4. Obnovení jednotlivých řešení hostovaných platformou

    Diagram znázorňující obnovení jednotlivých systémů platformy

    • Každé individuální řešení by mělo mít vlastní runbook zotavení po havárii. Runbooky by měly alespoň obsahovat nominované obchodní účastníky, kteří budou testovat a potvrdit, že bylo obnovení služby dokončeno.
    • V závislosti na kolizích nebo prioritách prostředků můžou být klíčová řešení nebo úlohy upřednostňovány před ostatními – základní podnikové procesy například v ad hoc cvičeních.
    • Po dokončení ověřovacích kroků dojde k předání podřízeným řešením, aby se spustil proces zotavení po havárii.

  5. Předání podřízeným, závislým systémům

    Diagram znázorňující závislé systémy

    • Po obnovení závislých služeb se dokončí proces obnovení zotavení po havárii E2E.

    Poznámka:

    I když je teoreticky možné proces zotavení po havárii E2E zcela automatizovat, je nepravděpodobné, že by se riziko události vs. náklady na aktivity SDLC potřebné k pokrytí procesu E2E.

  6. Náhradní do primární oblasti je proces přesunu služby datové platformy a jejích dat zpět do primární oblasti, jakmile je pro BAU k dispozici.

V závislosti na povaze zdrojových systémů a různých datových procesů může být náhradní datová platforma provedena nezávisle na ostatních částech datového ekosystému.

Zákazníkům doporučujeme zkontrolovat závislosti své vlastní datové platformy (upstreamové i podřízené), aby mohli provést příslušné rozhodnutí. V následující části se předpokládá nezávislé obnovení datové platformy.

  • Jakmile budou všechny požadované komponenty a služby dostupné v primární oblasti, zákazníci dokončí orientační test pro ověření obnovení Microsoftu.
  • Byla by ověřena konfigurace komponenty nebo služby. Rozdíly by se vyřešily opětovným nasazením ze správy zdrojového kódu.
  • Systémové datum v primární oblasti by bylo vytvořeno napříč stavovými komponentami. Rozdíl mezi vytvořeným datem a datem a časovým razítkem v sekundární oblasti by měl být vyřešen opětovným zadáním nebo přehráním procesů příjmu dat z tohoto bodu.
  • S schválením obchodních i technických zúčastněných stran by se vybralo záložní okno. V ideálním případě by k tomu mělo dojít během lull v systémové aktivitě a zpracování.
  • Během náhradní lokality by se primární oblast před přepnutím systému do synchronizace se sekundární oblastí převedla.
  • Po uplynutí období paralelního spuštění by sekundární oblast byla ze systému převezměna do režimu offline.
  • Komponenty v sekundární oblasti by se buď v závislosti na vybrané strategii zotavení po havárii vynechaly, nebo byly odstraněny zpět.

Teplý náhradní proces

Pro strategii "Teplé náhradní" je tok procesu vysoké úrovně úzce sladěn s tokem "Opětovné nasazení při havárii", hlavní rozdíl je v tom, že komponenty už byly v sekundární oblasti pořizovány. Tato strategie eliminuje riziko kolize prostředků od jiných organizací, které chtějí dokončit vlastní zotavení po havárii v dané oblasti.

Horký náhradní proces

Strategie "Hot Spare" znamená, že služby platformy, včetně systémů PaaS a infrastruktury jako služby (IaaS), budou i nadále zachovány i přes událost havárie, protože sekundární systémy běží společně s primárními systémy. Stejně jako u strategie "Teplá náhradní" tato strategie eliminuje riziko kolize prostředků od jiných organizací, které chtějí dokončit vlastní zotavení po havárii v této oblasti.

Zákazníci hot Spare budou monitorovat obnovení komponent a služeb Microsoftu v primární oblasti. Po dokončení by zákazníci ověřili primární systémy oblastí a dokončili náhradní řešení do primární oblasti. Tento proces by se podobal procesu převzetí služeb při selhání zotavení po havárii, tedy kontrole dostupného základu kódu a dat a opětovnému nasazení podle potřeby.

Poznámka:

Zde by se měla provést zvláštní poznámka, která zajistí, aby byla všechna systémová metadata konzistentní mezi těmito dvěma oblastmi.

  • Po dokončení náhradní lokality na primární server je možné aktualizovat nástroje pro vyrovnávání zatížení systému, aby se primární oblast vrátila do topologie systému. Pokud je k dispozici, dá se přístup k kanárskému vydání použít k postupnému přepnutí primární oblasti pro systém.

Struktura plánu zotavení po havárii

Efektivní plán zotavení po havárii představuje podrobný průvodce obnovením služeb, který může provést technický prostředek Azure. Následující seznam uvádí navrženou strukturu MVP pro plán zotavení po havárii.

  • Požadavky na proces
    • Podrobnosti specifické pro proces zotavení po havárii zákazníka, jako je správná autorizace potřebná ke spuštění zotavení po havárii, a podle potřeby proveďte klíčová rozhodnutí o obnovení (včetně definice hotového), reference k lístkům DR podpory služeb a podrobnosti o war room.
    • Potvrzení prostředku, včetně zálohy vedoucího zotavení po havárii a exekutoru Všechny prostředky by měly být zdokumentované pomocí primárních a sekundárních kontaktů, cest eskalace a opuštění kalendářů. V kritických situacích zotavení po havárii může být potřeba zvážit systémy seznamu.
    • Podrobnosti o přenosném počítači, napájecích balíčcích nebo záložním napájení, síťovém připojení a mobilním telefonu pro exekutor zotavení po havárii, zálohování zotavení po havárii a případné eskalační body.
    • Postup, který se má provést, pokud některý z požadavků na proces není splněn.
  • Výpis kontaktů
    • Vedení zotavení po havárii a skupiny podpory
    • Obchodní msp, kteří dokončí testovací/kontrolní cyklus technického obnovení.
    • Ovlivnění vlastníci firmy, včetně schvalovatelů obnovení služeb.
    • Ovlivnění technickí vlastníci, včetně schvalovatelů technických obnovení.
    • Podpora malých a středních podniků napříč všemi ovlivněnými oblastmi, včetně klíčových řešení hostovaných platformou
    • Ovlivněné podřízené systémy – provozní podpora.
    • Upstreamové zdrojové systémy – provozní podpora.
    • Kontakty sdílených služeb organizace. Například podpora přístupu a ověřování, monitorování zabezpečení a podpora brány
    • Externí nebo externí dodavatelé, včetně kontaktů podpory pro poskytovatele cloudu.
  • Návrh architektury
    • Popište podrobnosti o scénáři ukončení (E2E) a připojte veškerou přidruženou dokumentaci podpory.
  • Závislosti
    • Vypíše všechny vztahy a závislosti součástí.
  • Požadavky na zotavení po havárii
    • Potvrzení, že nadřazené zdrojové systémy jsou podle potřeby k dispozici.
    • Prostředkům exekutoru zotavení po havárii byl udělen zvýšený přístup napříč zásobníkem.
    • Služby Azure jsou k dispozici podle potřeby.
    • Postup, který se má provést, pokud některé z předpokladů nebyly splněny.
  • Technické obnovení – podrobné pokyny
    • Pořadí spuštění
    • Popis kroku
    • Požadavky na krok
    • Podrobné kroky procesu pro každou samostatnou akci, včetně adres URL
    • Ověřovací pokyny, včetně požadovaných důkazů.
    • Očekávaná doba dokončení každého kroku, včetně nepředvídaných událostí.
    • Proces, který se má provést, pokud se krok nezdaří.
    • Body eskalace v případě selhání nebo podpory malých a středních podniků.
  • Technické obnovení – požadavky po
    • Ověřte aktuální časové razítko data systému napříč klíčovými komponentami.
    • Potvrďte adresy URL systému zotavení po havárii a IP adresy.
    • Připravte se na proces kontroly obchodních účastníků, včetně potvrzení přístupu k systémům a obchodních msp, které dokončí ověření a schválení.
  • Kontrola a schválení obchodních účastníků
    • Kontaktní údaje obchodního zdroje
    • Kroky obchodního ověření podle výše uvedeného technického obnovení.
    • Záznam důkazů vyžadovaný od schvalovatele firmy, který odhlasuje obnovení.
  • Požadavky po obnovení
    • Předání provozní podpoře ke spouštění datových procesů, aby byl systém aktuální.
    • Předání podřízených procesůach
    • Potvrďte dokončení procesu obnovení s potenciálním zákazníkem zotavení po havárii – potvrďte záznam důkazů a dokončený runbook.
    • Upozorněte bezpečnostní týmy, že je možné z týmu zotavení po havárii odebrat zvýšená oprávnění přístupu.

Bublinové popisky

  • Doporučuje se zahrnout systémové snímky obrazovek jednotlivých kroků. Tyto snímky obrazovky vám pomůžou vyřešit závislost na systémových msp pro dokončení úkolů.
    • Aby bylo možné držet krok s rychle se vyvíjejícími cloudovými službami, měl by se plán zotavení po havárii pravidelně revidovat, testovat a spouštět prostředky s aktuálními znalostmi Azure a jejích služeb.
  • Kroky technického obnovení by měly odrážet prioritu komponenty a řešení pro organizaci. Například základní podnikové toky dat se obnoví před cvičeními pro analýzu dat ad hoc.
  • Po obnovení základních komponent nebo služby, jako je Key Vault, by se měly kroky technického obnovení řídit pořadím pracovních postupů (obvykle zleva doprava). Tato strategie zajistí, že jsou k dispozici upstreamové závislosti a komponenty je možné odpovídajícím způsobem testovat.
  • Po dokončení podrobného plánu by se měla získat celková doba pro aktivity s nepředvídaných událostí. Pokud je tento součet nad dohodnutým cílem doby obnovení (RTO), je k dispozici několik možností:
    • Automatizace vybraných procesů obnovení (pokud je to možné)
    • Hledejte příležitosti ke paralelnímu spuštění vybraných kroků obnovení (pokud je to možné). Nahlédnutí však na to, že tato strategie může vyžadovat další prostředky exekutoru zotavení po havárii.
    • Zvýšení klíčové komponenty na vyšší úrovně úrovní služeb, jako je PaaS, kde Microsoft přebírá větší odpovědnost za aktivity obnovení služeb.
    • Rozšiřte rto se zúčastněnými stranami.

Testování zotavení po havárii

Povaha nabídky cloudových služeb Azure má za následek omezení pro všechny scénáře testování zotavení po havárii. Pokyny proto představují vytvoření předplatného zotavení po havárii s komponentami datové platformy tak, jak by byly k dispozici v sekundární oblasti.

Z tohoto směrného plánu je možné runbook plánu zotavení po havárii selektivně spouštět a věnovat zvláštní pozornost službám a komponentám, které je možné nasadit a ověřit. Tento proces bude vyžadovat kurátorované testovací datové sady, která umožní potvrzení kontrol technického a obchodního ověření podle plánu.

Plán zotavení po havárii by se měl pravidelně testovat, aby se zajistilo nejen to, že je aktuální, ale také k vytvoření "svalové paměti" pro týmy provádějící aktivity převzetí služeb při selhání a obnovení.

  • Zálohy dat a konfigurace by se také měly pravidelně testovat, aby se zajistilo, že jsou vhodné pro účely podpory všech aktivit obnovení.

Klíčovou oblastí, na které se má zaměřit během testu zotavení po havárii, je zajistit, aby byly preskriptivní kroky stále správné a odhadované časování jsou stále relevantní.

  • Pokud pokyny místo kódu odrážejí obrazovky portálu – pokyny by se měly ověřit alespoň každých 12 měsíců kvůli četnosti změn v cloudu.

Zatímco aspirace je mít plně automatizovaný proces zotavení po havárii, úplná automatizace může být nepravděpodobné kvůli raritě události. Proto se doporučuje vytvořit směrný plán obnovení s infrastrukturou DSC (Desired State Configuration) jako kódem (IaC), která se používá k doručování platformy, a následně vylepšovat jako nové projekty postavené na směrném plánu.

  • Vzhledem k tomu, že se komponenty a služby rozšiřují, je potřeba vynutit NFR, což vyžaduje refaktoring kanálu produkčního nasazení, aby se zajistilo pokrytí zotavení po havárii.

Pokud časování runbooků překračuje plánovanou dobu obnovení, máte několik možností:

  • Rozšiřte rto se zúčastněnými stranami.
  • Snižte dobu potřebnou pro aktivity obnovení prostřednictvím automatizace, paralelním spouštěním úloh nebo migrací na vyšší vrstvy cloudového serveru.

Azure Chaos Studio

Azure Chaos Studio je spravovaná služba pro zlepšení odolnosti vkládáním chyb do aplikací Azure. Chaos Studio umožňuje orchestraci injektáže chyb na prostředky Azure bezpečným a řízeným způsobem pomocí experimentů. Popis typů chyb, které jsou aktuálně podporované, najdete v dokumentaci k produktu.

Aktuální iterace aplikace Chaos Studio pokrývá pouze podmnožinu komponent a služeb Azure. Dokud nebude přidáno více knihoven chyb, doporučuje se nástroj Chaos Studio pro izolované testování odolnosti místo kompletního systémového testování zotavení po havárii.

Další informace o chaos studiu najdete v dokumentaci k nástroji Azure Chaos Studio.

Azure Site Recovery

U komponent IaaS bude Azure Site Recovery chránit většinu úloh běžících na podporovaném virtuálním počítači nebo fyzickém serveru.

Existují silné pokyny pro:

Další kroky

Teď, když jste se naučili, jak scénář nasadit, si můžete přečíst souhrn řady zotavení po havárii pro datovou platformu Azure.