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:
| RE:03 | Pomocí analýzy režimu selhání (FMA) můžete identifikovat potenciální selhání v komponentách řešení a určit jejich prioritu. Proveďte FMA, který vám pomůže vyhodnotit riziko a účinek jednotlivých režimů selhání. Určete, jak úloha reaguje a jak se zotavuje. |
|---|
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í v rámci úlohy a souvisejících toků a plánování akcí na zmírnění rizik. V každém kroku toku identifikujete poloměr výbuchu několika typů selhání, který vám pomůže navrhnout novou úlohu nebo refaktorovat stávající úlohu, aby se minimalizoval rozsáhlý účinek selhání.
Klíčovou zásadou FMA je to, že k selháním 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 odolala většině typů selhání, a v případě selhání se bezproblémově zotavila.
Pokud FMA úplně vynecháte nebo provedete neúplnou analýzu, vaše úloha je ohrožena nepředvídatelným chováním a potenciálními výpadky způsobenými neoptimálním návrhem.
Definice
| Období | Definice |
|---|---|
| Režim selhání | Typ problému, který může způsobit snížení nebo vážné ovlivnění jedné nebo více komponent úloh až do bodu nedostupnosti. |
| Omezení rizik | Aktivity, které jste identifikovali k řešení problémů, a to buď proaktivně, nebo reaktivně. |
| Detekce | Procesy a postupy monitorování infrastruktury, dat a aplikací a upozorňování. |
Klíčové strategie návrhu
Požadavky
Projděte si a implementujte doporučení pro identifikaci toků. Předpokládá se, že jste identifikovali a určili prioritu toků uživatelů a systémů na základě důležitosti.
Data, která jste shromáždili, a artefakty, které jste ve své práci vytvořili, poskytují konkrétní popis datových cest, které jsou součástí toků. K úspěšnému fungování FMA je důležitá přesnost a důkladnost artefaktů.
Přístup FMA
Jakmile určíte kritické toky, můžete naplánovat jejich požadované komponenty. Dále postupujte podle jednotlivých toků krok za krokem, identifikujte závislosti, včetně služeb třetích stran a potenciálních bodů selhání, a naplánujte strategie zmírnění rizik.
Rozložte úlohu.
Při přechodu od návrhu k návrhu je potřeba identifikovat typy komponent, které jsou potřeba pro podporu vašich úloh. Vaše úloha určuje nezbytné komponenty, pro které musíte plá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 kontrolu výchozího přenosu dat. V této fázi návrhu možná neznáte konkrétní technologie, které nasadíte, takže váš 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řekrýt toky a 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 pochopit důležitost komponent, použijte definice závažnosti, které jste přiřadili tokům. Zvažte vliv chybné funkce komponent na toky.
Identifikace závislostí
Identifikujte závislosti úloh pro provedení analýzy jednotlivých bodů selhání. Rozložení úloh a překrytí toků poskytuje přehled o závislostech, které jsou pro úlohu interní i externí.
Interní závislosti jsou komponenty v oboru úlohy, které jsou potřebné pro fungování úlohy. Mezi typické interní závislosti patří rozhraní API nebo řešení pro správu tajných kódů a klíčů, jako je Azure Key Vault. Pro tyto závislosti zachyťte data o spolehlivosti, jako jsou smlouvy SLA o dostupnosti a limity škálování. Externí závislosti jsou požadované komponenty mimo rozsah úlohy, například jiná aplikace nebo služba třetí strany. Mezi typické externí závislosti patří řešení ověřování, jako je Microsoft Entra ID, a cloudová řešení připojení, jako je Azure ExpressRoute.
Identifikujte a zdokumentujte závislosti ve vaší úloze a zahrňte je do artefaktů dokumentace k tokům.
Body selhání
V kritických tocích úloh zvažte každou komponentu 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 vzít v úvahu mnoho režimů selhání. Každá komponenta může být v daném okamžiku ovlivněna více než jedním režimem selhání. Mezi tyto režimy selhání patří:
Oblastní 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 typu Odepření služby (DDoS) nebo jiný škodlivý útok.
Chybná konfigurace aplikace nebo komponenty
Chyba operátoru.
Výpadek plánované údržby.
Přetížení komponenty.
Analýza by vždy měla být v kontextu toku, který se pokoušíte analyzovat, proto nezapomeňte zdokumentovat vliv na uživatele a očekávaný výsledek tohoto toku. Pokud máte například aplikaci elektronického obchodování a analyzujete tok zákazníka, může mít určitý režim selhání na jednu nebo více komponent dopad, že všichni zákazníci nebudou moct dokončit rezervaci.
Zvažte pravděpodobnost jednotlivých typů režimů selhání. Některé jsou velmi nepravděpodobné, například výpadky ve více zónách nebo ve více oblastech, a plánování zmírnění nad rámec redundance není vhodné využít prostředky a čas.
Omezení rizik
Strategie pro zmírnění rizik spadají do dvou obecných kategorií: budování větší odolnosti a návrh pro snížení výkonu.
Budování vyšší odolnosti zahrnuje přidání redundance do komponent, jako jsou infrastruktura, data a sítě, a zajištění, aby návrh aplikace byl v dodržování osvědčených postupů z hlediska odolnosti, například rozdělení monolitických aplikací na izolované aplikace a mikroslužby. Další informace najdete v tématech Doporučení pro redundanci a Doporučení pro zachování sebe sama.
Při návrhu s cílem dosáhnout sníženého výkonu identifikujte potenciální body selhání, které můžou zakázat jednu nebo více komponent toku, ale tento tok úplně nezakážou. Pokud chcete zachovat funkčnost kompletního toku, možná budete muset přesměrovat jeden nebo více kroků na jiné komponenty nebo přijmout, že součást, která selhala, spustí funkci, takže funkce už nebude v uživatelském prostředí dostupná. 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 vyhledat produkty a dokončit transakci.
Potřebujete také naplánovat zmírnění závislostí. Silné závislosti hrají důležitou roli ve funkcích a dostupnosti aplikace. Pokud chybí nebo u nich dochází k poruše, může to mít významný dopad. Absence slabých závislostí může mít vliv pouze na konkrétní funkce a nemusí mít vliv na celkovou dostupnost. Tento rozdíl odráží náklady na udržová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 získali kontrolu 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 jejích závislostí, může být provozní flexibilita aplikace omezená, zejména u nových verzí.
Detekce
Detekce selhání je nezbytná k tomu, abyste měli jistotu, že jste v analýze správně identifikovali body selhání a správně naplánovali strategie pro zmírnění rizik. Detekce v tomto kontextu znamená monitorování infrastruktury, dat a aplikací a upozorňování, když dojde k problémům. Co nejvíce automatizujte detekci a zabudujte do svých provozních procesů redundanci, abyste měli jistotu, že se výstrahy vždy zachytí a budou reagovat 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ě informují o vašich zjištěních, o rozhodnutích, která jste udělali v oblasti komponent toku a zmírnění rizik, a o dopadu selhání na vaši úlohu.
Při analýze určete prioritu režimů selhání a strategií zmírnění rizik, které jste identifikovali, na základě závažnosti a pravděpodobnosti. Toto stanovení priorit použijte k tomu, abyste svou dokumentaci zaměřili na ty režimy selhání, které jsou natolik závažné, že vyžadují, aby se čas, úsilí a prostředky strávily navrhováním strategií zmírnění rizik. Některé režimy selhání mohou být například velmi vzácné při výskytu nebo detekci. Navrhování strategií zmírnění rizik souvisejících s nimi se nevyplatí.
Výchozí bod dokumentace najdete v následující ukázkové tabulce .
Během počátečního cvičení FMA budou dokumenty, které vytvoříte, převážně teoretické plánování. Dokumenty FMA byste měli pravidelně kontrolovat a aktualizovat, abyste měli jistotu, že jsou aktuální s vašimi úlohami. Testování chaosu a zkušenosti z reálného světa vám pomůžou zpřesnit analýzy v průběhu času.
Usnadnění Azure
K detekci problémů ve vašich úlohách použijte Azure Monitor a Log Analytics . Pokud chcete získat další přehled o problémech souvisejících s infrastrukturou, aplikacemi a databázemi, použijte nástroje, jako jsou Application Insights, Container Insights, Network Insights, VM Insights a SQL Insights.
Azure Chaos Studio je spravovaná služba, která používá inženýrství chaosu, která vám pomůže změřit, pochopit a zlepšit odolnost cloudových aplikací a služeb.
Informace o použití principů FMA na běžné služby 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 Azure App Service instancích s Azure SQL databázemi a který je předsuděný službou Azure Front Door.
Tok uživatele: Přihlášení uživatele, vyhledávání produktů a interakce nákupního košíku
| Součást | Riziko | Pravděpodobnost | Účinek/zmírnění/poznámka | Výpadek |
|---|---|---|---|---|
| Microsoft Entra ID | Výpadek služby | Nízká | Úplný výpadek úloh. Závisí na microsoftu k nápravě. | Do bloku |
| Microsoft Entra ID | Chybná konfigurace | Střední | Uživatelé se nemůžou přihlásit. Žádný následný efekt. Helpdesk hlásí problém s konfigurací týmu identit. | Žádné |
| Azure Front Door | Výpadek služby | Nízká | Úplný výpadek pro externí uživatele. Závisí na microsoftu k nápravě. | Pouze externí |
| Azure Front Door | Výpadek oblasti | Velmi nízká | Minimální efekt. Azure Front Door je globální služba, takže globální směrování provozu směruje provoz přes oblasti Azure, které nejsou ovlivněny. | Žádné |
| Azure Front Door | Chybná konfigurace | Střední | Během nasazování by se měly zachytit chybné konfigurace. Pokud k tomu 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ální 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 účinku útoků L7. | Potenciální částečný výpadek |
| Azure SQL | Výpadek služby | Nízká | Úplný výpadek úloh. Závisí na microsoftu k nápravě. | Do bloku |
| Azure SQL | Výpadek oblasti | Velmi nízká | Převzetí služeb při selhání skupiny automatického převzetí služeb 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 | Žádné |
| Azure SQL | Škodlivý útok (injektáž) | Střední | Minimální riziko. Všechny Azure SQL instance jsou virtuální sítě vázané prostřednictvím privátních koncových bodů a skupiny 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 k nápravě. | Do bloku |
| App Service | Výpadek oblasti | Velmi nízká | Minimální efekt. Latence pro uživatele v ovlivněných oblastech Azure Front Door automaticky směruje provoz do oblastí, které nejsou ovlivněny. | Žádné |
| App Service | Výpadek zóny dostupnosti | Nízká | Žádný vliv Aplikační služby se nasadily jako zónově redundantní. Bez zónové redundance může dojít k efektu. | Žádné |
| App Service | Útok DDoS | Střední | Minimální efekt. Příchozí provoz je chráněný službou Azure Front Door a Azure Web Application Firewall. | Žádné |
Související odkazy
Kontrolní seznam spolehlivosti
Projděte si kompletní sadu doporučení.
Váš názor
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.
Odeslat a zobrazit názory pro