Doporučení pro provádění analýzy režimu selhání
Týká se tohoto doporučení kontrolního seznamu spolehlivosti Frameworku Azure: Well-Architected
| RE:03 | K identifikaci potenciálních selhání ve vaší úloze použijte analýzu režimu selhání (FMA). Identifikujte závislosti a body selhání a vyvíjejte strategie pro zmírnění těchto selhání. |
|---|
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 pracovní zátěž je ohrožena nepředvídatelným chováním a potenciálními výpadky způsobenými suboptimálním návrhem.
definice
| Termín | Definice |
|---|---|
| Režim selhání | Typ problému, který může způsobit zhoršení nebo vážné ovlivnění jedné nebo více komponent úloh do té míry, že jsou nedostupné. |
| Zmírnění | Aktivity, které jste identifikovali k řešení problémů, buď proaktivně, nebo reaktivně. |
| Detekce | Vaše infrastruktura, data, a procesy a postupy monitorování a upozorňování aplikací. |
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ů. Abyste byli úspěšní ve své práci FMA, je zásadní přesnost a důkladnost ve vašich artefaktech.
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í. Rozklad vašeho pracovního zatížení a analýza toků poskytují přehled o závislostech, které jsou vnitřní i vnější vůči pracovnímu zatížení.
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 dohody o úrovni služeb (SLA) 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 ve své pracovní zátěži a zahrňte je do dokumentačních artefaktů 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 naleznete v doporučení pro nadbytečnost a v 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.
Detekce
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 naleznete 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.
Výchozí bod dokumentace najdete v následující ukázkové tabulce.
Během úvodního cvičení FMA budou dokumenty, které vytvoříte, převážně teoretické plánování. Dokumenty FMA by se měly pravidelně kontrolovat a aktualizovat, aby se zajistilo, že zůstanou up-to- datum s vaším zatížením. Testování chaosu a zkušenosti z reálného světa vám v průběhu času pomohou upřesnit analýzy.
Usnadnění služby Azure
Pomocí Azure Monitoru a Log Analyticsu můžete detekovat problémy ve vašem pracovním zatížení. Pokud chcete získat další přehled o problémech souvisejících s vaší 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á 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 e-commerce web, hostovaný v instancích služby Azure App Service s databázemi Azure SQL a zajištěný službou 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 pracovní zátěže Závisí na tom, že Microsoft zajistí nápravu. | Plný |
| Microsoft Entra ID | Chybná konfigurace | Středně | Uživatelé se nemůžou přihlásit. Žádný podřízený účinek. Zákaznická podpora hlásí problémy s konfigurací týmu pro správu identit. | Žádný |
| Azure Front Door (Azure Přední Dveře) | Výpadek služby | Nízký | Úplný výpadek externích uživatelů Závisí na Microsoftu pro nápravu. | 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 vede provoz prostřednictvím neovlivněných oblastí Azure. | Žádný |
| Azure Front Door | Špatná 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 pracovní zátěže Závisí na nápravě od Microsoftu. | Plný |
| Azure SQL | Regionální výpadek | Velmi nízká | Skupina automatického převzetí při selhání přepne na sekundární region. Možný výpadek během failoveru. Cíle doby obnovení (RTO) a cíle bodů obnovení (RPO), které se mají určit během testování spolehlivosti. | Možný plný výkon |
| Azure SQL | Výpadek zóny dostupnosti | Nízký | Žádný efekt | Žádný |
| Azure SQL | Škodlivý útok (injektáž) | Středně | Minimální riziko. Všechny instance Azure SQL jsou vázané na virtuální síť prostřednictvím privátních koncových bodů, zatímco skupiny zabezpečení sítě (NSG) poskytují dodatečnou ochranu uvnitř virtuální sítě. | Nízké riziko, potenciál částečného výpadku |
| Služba aplikace | Výpadek služby | Nízký | Úplný výpadek pracovní zátěže Jsme závislí na Microsoftu pro nápravu. | Plný |
| služba aplikace | 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 síťový provoz do nepostižených oblastí. | Žádný |
| Služba aplikací | Výpadek zóny dostupnosti | Nízký | Žádný efekt. Služby App Services byly nasazeny jako zónově redundantní. Bez redundance zón existuje potenciál pro efekt. | Žádný |
| 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. | Žádný |
Související odkazy
- analýza režimu selhání pro aplikace Azure
- odolnost a závislosti
Kontrolní seznam pro spolehlivost
Projděte si kompletní sadu doporučení.