Doporučení pro provádění analýzy režimu selhání
Platí pro toto doporučení kontrolního seznamu pro spolehlivost architektury Azure Well-Architected Framework:
| RE:03 | Pomocí analýzy režimu selhání (FMA) identifikujte a upřednostněte potenciální selhání v komponentách řešení. Proveďte FMA, abyste mohli vyhodnotit riziko a účinek jednotlivých režimů selhání. Určete, jak úloha reaguje a obnovuje. |
|---|
Tato příručka popisuje osvědčené postupy pro provádění analýzy režimu selhání (FMA) pro vaši úlohu. FMA je postup identifikace potenciálních bodů selhání ve vaší úloze a souvisejících toků a akcí pro plánování zmírnění rizik odpovídajícím způsobem. V každém kroku toku identifikujete poloměr výbuchu více typů selhání, který vám pomůže navrhnout novou úlohu nebo refaktorovat stávající úlohu, aby se minimalizoval rozsáhlý dopad selhání.
Klíčovým principem FMA je to, že k selhání dochází bez ohledu na to, kolik vrstev odolnosti použijete. Složitější prostředí jsou vystavena více typům selhání. Vzhledem k této realitě vám FMA umožňuje navrhnout úlohu tak, aby vydržela většinu typů selhání a v případě selhání se řádně zotavila.
Pokud fma úplně přeskočíte nebo provedete neúplnou analýzu, vaše úloha je ohrožena neprediktovaným chováním a potenciálními výpadky způsobenými neoptimálním návrhem.
Definice
| Pojem | definice |
|---|---|
| Režim selhání | Typ problému, který může způsobit snížení nebo závažný dopad jedné nebo více komponent úloh na nedostupný bod. |
| Zmírnění | Aktivity, které jste identifikovali k řešení problémů, buď proaktivně, nebo reaktivně. |
| Detection | Vaše infrastruktura, data a procesy monitorování a upozorňování aplikací a postupy. |
Klíčové strategie návrhu
Projděte si a implementujte doporučení pro identifikaci toků. Předpokládá se, že jste identifikovali a určili priority toků uživatelů a systémů na základě závažnosti.
Data, která jste shromáždili, a artefakty, které jste vytvořili ve své práci, poskytují konkrétní popis vašich datových cest zahrnutých v rámci toků. Pokud chcete být úspěšní v práci FMA, přesnost a důkladnost artefaktů je důležitá.
Po určení kritických toků můžete naplánovat jejich požadované komponenty. V dalším kroku postupujte podle jednotlivých kroků a identifikujte závislosti, včetně služeb třetích stran a potenciálních bodů selhání, a naplánujte strategie pro zmírnění rizik.
Rozložte úlohu.
Při přechodu z ideace na návrh je potřeba identifikovat typy komponent, které jsou potřeba pro podporu vaší úlohy. Vaše úloha určuje potřebné součásti, pro které je nutné naplánovat. Obvykle je potřeba naplánovat řízení příchozího přenosu dat, sítě, výpočetní prostředky, data, úložiště, podpůrné služby (jako je ověřování, zasílání zpráv a správa tajných kódů nebo klíčů) a řízení výchozího přenosu dat. V této fázi návrhové práce možná neznáte konkrétní technologie, které nasadíte, takže návrh může vypadat jako v následujícím příkladu.
Po vytvoření počátečního návrhu architektury můžete překrytím toků identifikovat samostatné komponenty, které se v těchto tocích používají, a vytvořit seznamy nebo diagramy pracovních postupů, které popisují toky a jejich komponenty. Pokud chcete porozumět závažnosti komponent, použijte definice závažnosti, které jste přiřadili tokům. Vezměte v úvahu účinek selhání komponenty na toky.
Identifikace závislostí
Identifikujte závislosti úloh pro provedení analýzy jediného bodu selhání. Rozložení toků úloh a překrytí poskytuje přehled o závislostech, které jsou interní a externí pro danou úlohu.
Interní závislosti jsou komponenty v oboru úloh, které jsou potřeba pro fungování úlohy. Mezi typické interní závislosti patří rozhraní API nebo řešení pro správu tajných kódů nebo klíčů, jako je Azure Key Vault. Pro tyto závislosti zachyťte data o spolehlivosti, jako jsou smlouvy SLA dostupnosti a limity škálování. Externí závislosti jsou povinné komponenty mimo rozsah úlohy, jako je jiná aplikace nebo služba třetích stran. Mezi typické externí závislosti patří řešení ověřování, jako je ID Microsoft Entra a cloudová řešení připojení, jako je Azure ExpressRoute.
Identifikujte a zdokumentujte závislosti v úloze a zahrňte je do artefaktů dokumentace toku.
Vyhodnocení bodů selhání
V kritických tocích úloh zvažte jednotlivé komponenty a určete, jak může být tato komponenta a její závislosti ovlivněna režimem selhání. Mějte na paměti, že při plánování odolnosti a obnovení je potřeba zvážit mnoho režimů selhání. Na libovolnou komponentu může mít vliv více než jeden režim selhání v daném okamžiku. Mezi tyto režimy selhání patří:
Regionální výpadek. Celá oblast Azure není k dispozici.
Výpadek zóny dostupnosti Zóna dostupnosti Azure není k dispozici.
Výpadek služby. Jedna nebo více služeb Azure není k dispozici.
Distribuovaný útok na dostupnost služby (DDoS) nebo jiný škodlivý útok.
Chybná konfigurace aplikace nebo komponenty
Chyba operátoru
Výpadek plánované údržby.
Přetížení součásti.
Analýza by měla být vždy v kontextu toku, který se pokoušíte analyzovat, takže nezapomeňte zdokumentovat vliv na uživatele a očekávaný výsledek tohoto toku. Pokud máte například aplikaci pro elektronické obchodování a analyzujete tok zákazníka, může mít vliv konkrétního režimu selhání na jednu nebo více komponent, že všichni zákazníci nemůžou dokončit rezervaci.
Zvažte pravděpodobnost každého typu režimu selhání. Některé jsou velmi nepravděpodobné, jako jsou výpadky více zón nebo více oblastí a přidání plánování omezení rizik nad rámec redundance není dobrým využitím prostředků a času.
Zmírnění
Strategie zmírnění rizik spadají do dvou širokých kategorií: budování větší odolnosti a navrhování pro snížení výkonu.
Budování větší odolnosti zahrnuje přidání redundance do komponent, jako je infrastruktura, data a sítě, a zajištění, že návrh aplikace dodržuje osvědčené postupy pro odolnost, například rozdělení monolitických aplikací do izolovaných aplikací a mikroslužeb. Další informace najdete v tématu Doporučení pro redundanci a doporučení pro sebezáchování.
Pokud chcete navrhnout snížení výkonu, identifikujte potenciální body selhání, které můžou zakázat jednu nebo více součástí toku, ale tento tok úplně nezakážte. Abyste zachovali funkčnost kompletního toku, budete možná muset převést jeden nebo více kroků na jiné součásti nebo přijmout, že neúspěšná komponenta spouští funkci, takže funkce už není dostupná v uživatelském prostředí. Pokud se chcete vrátit k příkladu aplikace elektronického obchodování, může neúspěšná komponenta, jako je mikroslužba, způsobit nedostupnost modulu doporučení, ale zákazníci stále můžou hledat produkty a dokončit svou transakci.
Potřebujete také naplánovat zmírnění závislostí. Silné závislosti hrají důležitou roli ve funkci a dostupnosti aplikace. Pokud chybí nebo dochází k selhání, může to mít významný vliv. Absence slabých závislostí může mít vliv pouze na konkrétní funkce a nemá vliv na celkovou dostupnost. Tento rozdíl odráží náklady na zachování vztahu vysoké dostupnosti mezi službou a jejími závislostmi. Klasifikujte závislosti jako silné nebo slabé, abyste mohli určit, které komponenty jsou pro aplikaci nezbytné.
Pokud má aplikace silné závislosti, bez kterých nemůže fungovat, měly by cíle dostupnosti a obnovení těchto závislostí odpovídat cílům samotné aplikace. Minimalizujte závislosti, abyste dosáhli kontroly nad spolehlivostí aplikací. Další informace najdete v tématu Minimalizace koordinace mezi aplikačními službami za účelem dosažení škálovatelnosti.
Pokud je životní cyklus aplikace úzce spojen s životním cyklem jeho závislostí, může být provozní flexibilita aplikace omezená, zejména pro nové verze.
Detection
Detekce selhání je nezbytná, abyste měli jistotu, že jste v analýze správně identifikovali body selhání a správně naplánovali strategie zmírnění rizik. Detekce v tomto kontextu znamená monitorování infrastruktury, dat a aplikací a upozorňování v případě, že dojde k problémům. Automatizujte detekci co nejvíce a zabudujte redundanci do vašich provozních procesů, abyste zajistili, že se výstrahy vždy zachytí a odpoví dostatečně rychle, aby splňovaly vaše obchodní požadavky. Další informace najdete v tématu Doporučení pro monitorování.
Výsledek
Pro výsledek analýzy vytvořte sadu dokumentů, které efektivně komunikují vaše zjištění, rozhodnutí, která jste udělali v porovnání s komponentami toku a zmírněním rizik, a dopad selhání na vaši úlohu.
V analýze upřednostněte režimy selhání a strategie zmírnění rizik, které jste identifikovali na základě závažnosti a pravděpodobnosti. Pomocí této stanovení priorit se můžete zaměřit na dokumentaci na ty režimy selhání, které jsou běžné a dostatečně závažné, aby bylo možné věnovat čas, úsilí a prostředky na navrhování strategií pro zmírnění rizik. Můžou se například vyskytovat některé režimy selhání, které jsou ve výskytu nebo detekci velmi vzácné. Návrh strategií pro zmírnění rizik, které jsou kolem nich, nestojí za náklady.
Informace o výchozím bodu dokumentace najdete v následující ukázkové tabulce .
Během úvodního cvičení FMA budou dokumenty, které vytvoříte, převážně teoreticky plánování. Dokumenty FMA by se měly pravidelně kontrolovat a aktualizovat, aby se zajistilo, že budou aktuální s vašimi úlohami. Chaos testování a zkušenosti z reálného světa vám pomůžou v průběhu času upřesnit analýzy.
Usnadnění azure
K detekci problémů ve vaší úloze použijte Azure Monitor a Log Analytics . Další přehled o problémech souvisejících s vaší infrastrukturou, aplikacemi a databázemi získáte pomocí nástrojů, jako jsou Application Insights, Container Insights, Network Insights, VM Insights a SQL Insights.
Azure Chaos Studio je spravovaná služba, která využívá přípravu chaosu, která vám pomůže měřit, pochopit a zlepšit odolnost cloudových aplikací a služeb.
Informace o použití principů FMA u běžných služeb Azure najdete v tématu Analýza režimu selhání pro aplikace Azure.
Příklad
Následující tabulka ukazuje příklad FMA pro web elektronického obchodování, který je hostovaný na instancích služby Aplikace Azure Service s databázemi Azure SQL a je před frontou azure Front Door.
Tok uživatele: Interakce s přihlášením uživatele, vyhledáváním produktů a nákupním košíkem
| Komponenta | Riziko | Pravděpodobnost | účinek/ zmírnění rizik / poznámka | Výpadek |
|---|---|---|---|---|
| Microsoft Entra ID | Výpadek služby | Nízká | Úplný výpadek úloh Závisí na Microsoftu na nápravě. | Úplný |
| Microsoft Entra ID | Chybná konfigurace | Střední | Uživatelé se nemůžou přihlásit. Žádný podřízený účinek. Helpdesk hlásí problém s konfigurací týmu identit. | Nic |
| Azure Front Door | Výpadek služby | Nízká | Úplný výpadek externích uživatelů Závisí na Microsoftu na nápravě. | Pouze externí |
| Azure Front Door | Regionální výpadek | Velmi nízká | Minimální účinek. Azure Front Door je globální služba, takže směrování globálního provozu směruje provoz prostřednictvím neprojevených oblastí Azure. | Nic |
| Azure Front Door | Chybná konfigurace | Střední | Během nasazování by se měly zachytit chybné konfigurace. Pokud k těmto změnám dojde během aktualizace konfigurace, musí správci vrátit změny zpět. Aktualizace konfigurace způsobí krátký externí výpadek. | Pouze externí |
| Azure Front Door | Útok DDoS | Střední | Potenciál přerušení. Microsoft spravuje ochranu před útoky DDoS (L3 a L4) a Azure Web Application Firewall blokuje většinu hrozeb. Potenciální riziko dopadu útoků L7. | Potenciál částečného výpadku |
| Azure SQL | Výpadek služby | Nízká | Úplný výpadek úloh Závisí na Microsoftu na nápravě. | Úplný |
| Azure SQL | Regionální výpadek | Velmi nízká | Skupina automatického převzetí služeb při selhání převezme služby při selhání do sekundární oblasti. Potenciální výpadek během převzetí služeb při selhání Cíle doby obnovení (RTO) a cíle bodů obnovení (RPO), které se mají určit během testování spolehlivosti. | Potenciální plný |
| Azure SQL | Výpadek zóny dostupnosti | Nízká | Žádný vliv | Nic |
| Azure SQL | Škodlivý útok (injektáž) | Střední | Minimální riziko. Všechny instance Azure SQL jsou virtuální sítě vázané prostřednictvím privátních koncových bodů a skupin zabezpečení sítě (NSG) přidávají další ochranu uvnitř virtuální sítě. | Potenciální nízké riziko |
| App Service | Výpadek služby | Nízká | Úplný výpadek úloh Závisí na Microsoftu na nápravě. | Úplný |
| App Service | Regionální výpadek | Velmi nízká | Minimální účinek. Latence pro uživatele v ovlivněných oblastech Azure Front Door automaticky směruje provoz do neprojevených oblastí. | Nic |
| App Service | Výpadek zóny dostupnosti | Nízká | Žádný vliv Služby App Services byly nasazeny jako zónově redundantní. Bez redundance zón existuje potenciál pro efekt. | Nic |
| App Service | Útok DDoS | Střední | Minimální účinek. Příchozí provoz je chráněný službou Azure Front Door a službou Azure Web Application Firewall. | Nic |
Související odkazy
Kontrolní seznam pro spolehlivost
Projděte si kompletní sadu doporučení.