Sdílet prostřednictvím

Doporučení pro provádění analýzy režimu selhání

  • Článek

Platí pro toto doporučení kontrolního seznamu spolehlivosti pro Well-Architected Power Platform:

RE:03 Použijte analýzu režimu selhání (FMA) k identifikaci a stanovení priority potenciálních selhání součástí vašeho řešení. Proveďte FMA, která vám pomůže posoudit riziko a účinek každého režimu selhání. Určete, jak bude úloha reagovat a jak se obnoví.

Tato příručka popisuje nejlepší 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í opatření k řešení podle toho. V každém kroku toku identifikujete rozsah škod různých typů selhání, což vám pomůže navrhnout nové úlohu nebo refaktorovat stávající úlohu, abyste minimalizovali široký vliv selhání.

Klíčovým principem FMA je, ž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 poruch. Vzhledem k této realitě vám FMA umožňuje navrhnout vaši úlohu tak, aby odolala většině typů selhání a aby se v případě selhání plynule obnovila.

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

Pojem 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 úlohy do té míry, že nebudou dostupné.
Zmírnění Činnosti, které jste určili k řešení problémů buď proaktivně, nebo reaktivně.
Detekce Procesy a postupy pro monitorování a upozorňování vašich dat a aplikací.

Klíčové strategie návrhu

V kontextu FMA je pochopení předpokladů zásadní. Začněte revizí a implementací doporučení pro identifikaci toků a upřednostněte je na základě kritičnosti. Vaše datové artefakty hrají klíčovou roli při popisu datových cest v rámci těchto toků. Když se ponoříte do přístupu FMA, zaměřte se na plánování komponent pro kritické toky, identifikaci závislostí (interních i externích) a navrhování strategií řešení.

Předpoklady

Zkontrolujte a implementujte doporučení pro identifikaci a hodnocení toků. Předpokládá se, že jste identifikovali a upřednostnili uživatelské a systémové toky na základě kritičnosti.

Data, která jste shromáždili, a artefakty, které jste vytvořili ve své práci, vám poskytnou konkrétní popis vašich datových cest zahrnutých v průběhu toků. Abyste byli úspěšní ve své práci FMA, je kritická přesnost a důkladnost vašich artefaktů.

Přístup FMA

Poté, co určíte kritické toky, můžete naplánovat jejich požadované součásti. Dále postupujte podle jednotlivých toků krok za krokem, abyste identifikovali závislosti, včetně služeb třetích stran a potenciálních bodů selhání, a naplánujte své strategie řešení.

Rozložte úlohu

Když přejdete od nápadu k návrhu, musíte identifikovat typy komponent, které jsou vyžadovány pro podporu úlohu. Vaše úloha určuje nezbytné součásti, které musíte naplánovat.

Po vytvoření počátečního návrhu architektury můžete překrýt své toky, abyste identifikovali 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. Chcete-li porozumět kritičnosti komponent, použijte definice kritičnosti, které jste přiřadili tokům. Zvažte vliv poruchy součásti na vaše toky.

Identifikuje závislosti

Identifikujte závislosti úlohy, abyste mohli provést analýzu jednoho bodu selhání. Rozložení úlohy a překrytí toků poskytuje náhled na závislosti, které jsou interní a externí vzhledem k úloze.

Interní závislosti jsou komponenty v oboru úlohy, které jsou nutné pro fungování úlohy. Mezi typické interní závislosti patří rozhraní API nebo řešení správy tajných klíčů / klíčů, jako je Azure Key Vault. Pro tyto závislosti zachyťte data spolehlivosti, jako jsou dohody o úrovni služeb (SLA) a limity škálování. Externí závislosti jsou požadované součásti mimo rozsah úlohy, jako je jiná aplikace nebo služba třetí strany. Typické externí závislosti zahrnují autentizační řešení, např. Microsoft Entra ID a infrastruktura Power Platform.

Identifikujte a zdokumentujte závislosti v úloze a zahrňte je do artefaktů dokumentace toku.

Body selhání

V kritických tocích úlohy zvažte každou komponentu a určete, jak může být tato komponenta a její závislosti ovlivněny režimem selhání. Pamatujte, že existuje mnoho způsobů selhání, které je třeba vzít v úvahu při plánování odolnosti a obnovy. Každá komponenta může být v daném okamžiku ovlivněna více než jedním režimem poruchy. Mezi tyto režimy selhání patří:

  • Regionální výpadek: Celá oblast Power Platform oblast Azure není k dispozici
  • Výpadek služby: Jedna nebo více služeb Power Platform nebo Azure nejsou dostupné
  • Distribuované odmítnutí služby (DDoS) nebo jiný útok
  • Chyba konfigurace aplikace nebo komponenty
  • Chyba operátora
  • Výpadek z důvodu plánované údržby
  • Přetížení komponenty

Zvažte pravděpodobnost každého typu režimu selhání. Některé jsou velmi nepravděpodobné, jako například výpadky ve více zónách nebo více regionech, a přidání plánování řešení nad rámec redundance není dobrým využitím zdrojů a času.

Zmírnění

Strategie řešení spadají do dvou širokých kategorií: budování větší odolnosti a navrhování pro snížený výkon.

Budování větší odolnosti znamená zajištění toho, že návrh vaší aplikace bude dodržovat osvědčené postupy pro odolnost; například rozdělení monolitických aplikací na izolované aplikace a mikroslužby a použití konfigurací odolnosti poskytované platformou, jako jsou zásady opakování. Další informace naleznete v části Doporučení pro redundanci a Doporučení pro sebezáchovu.

V návrhu na snížený výkon identifikujte potenciální body selhání, které by mohly deaktivovat jednu nebo více součástí vašeho toku, ale ne zcela deaktivovat tento tok. Chcete-li zachovat úplnou funkčnost toku, možná budete muset přesměrovat jeden nebo více kroků na jiné komponenty nebo přijmout, že komponenta, která selhala, spouští funkci, takže funkce již není v uživatelském prostředí dostupná. Abychom se vrátili k příkladu aplikace elektronického obchodu, vadná komponenta, jako je mikroslužba, může způsobit, že váš modul doporučení nebude k dispozici, ale zákazníci mohou stále vyhledávat produkty a provádět transakce.

Musíte také naplánovat řešení ohledně závislostí. Silné závislosti hrají zásadní roli ve funkci a dostupnosti aplikace. Pokud chybí nebo dochází k poruše, může to mít významný vliv. Absence slabých závislostí může ovlivnit pouze specifické funkce a neovlivnit celkovou dostupnost. Toto rozlišení odráží náklady na udržení 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 se cíle dostupnosti a obnovy těchto závislostí shodovat s cíli samotné aplikace. Pokud je životní cyklus aplikace úzce spojen s životním cyklem jejích závislostí, provozní agilita aplikace může být omezená, zejména u nových verzí.

Detekce

Detekce selhání je nezbytná k zajištění toho, že jste ve své analýze správně identifikovali body selhání a správně naplánovali své strategie zmírnění. Detekce v tomto kontextu znamená monitorování vaší infrastruktury, dat a aplikací a upozornění, když nastanou problémy. Automatizujte detekci, jak je to jen možné, a zabudujte do svých provozních procesů redundanci, abyste zajistili, že výstrahy budou vždy zachyceny a budou na ně reagovat dostatečně rychle, aby vyhovovaly vašim obchodním požadavkům. Další informace viz : Doporučení pro monitorování.

Výsledek

Pro výsledek své analýzy vytvořte sadu dokumentů, které efektivně sdělují vaše zjištění, rozhodnutí, která jste učinili ve vztahu ke komponentám toku a řešení dopadů selhání na vaši úlohu.

Ve své analýze upřednostněte režimy selhání a strategie řešení, které jste určili na základě závažnosti a pravděpodobnosti. Pomocí tohoto stanovení priorit zaměřte svou dokumentaci na ty režimy selhání, které jsou běžné a dostatečně závažné, aby vyžadovaly vynaložení času, úsilí a zdrojů na navrhování strategií řešení. Mohou například existovat některé režimy selhání, které jsou velmi vzácné ve výskytu nebo detekci. Navrhování strategií řešení kolem nich nestojí za to.

Počáteční bod dokumentace naleznete ve vzorové tabulce.

Během počátečního cvičení FMA budou dokumenty, které vytvoříte, převážně teoretické plánování. Dokumenty FMA by měly být pravidelně kontrolovány a aktualizovány, aby bylo zajištěno, že budou aktuální s ohledem na úlohu. Testování chaosu a reálné zkušenosti vám pomohou vylepšit vaše analýzy v průběhu času.

Příklad

Následující tabulka ukazuje příklad FMA pro výdajovou aplikaci, která je hostována jako aplikace plátna Power Apps s backendem Microsoft Dataverse a rozhraními API hostovanými v APIM pro interakci se systémem třetí strany.

Tok uživatele: Přihlášení uživatele, odeslání žádosti o výdaje a interakce se zprávou o výdajích

Komponenta Riziko Pravděpodobnost Vliv / řešení / poznámka Výpadek
Microsoft Entra ID Výpadek služby Nízká Úplný výpadek úlohy. Náprava závisí na společnosti Microsoft. Úplný
Microsoft Entra ID Nesprávná konfigurace střední Uživatelé se nemohou přihlásit. Žádný následný efekt. Help desk hlásí problém s konfigurací týmu identity. Žádné
Power Apps Výpadek služby Nízká Úplný výpadek pro externí uživatele. Náprava závisí na společnosti Microsoft. Úplný
Power Apps Regionální výpadek Velmi nízký Úplný výpadek pro externí uživatele. Náprava závisí na společnosti Microsoft. Úplný
Power Apps Útok DDoS střední Potenciál narušení. Microsoft spravuje ochranu DDoS (L3 a L4). Možnost částečného výpadku
Dataverse Výpadek služby Nízká Úplný výpadek úlohy. Náprava závisí na společnosti Microsoft. Úplný
Dataverse Regionální výpadek Velmi nízký Automatické 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 obnovy (RTO) a cíle bodů obnovy (RPO), které mají být stanoveny během testování spolehlivosti. Potenciálně úplný
Dataverse Útok (injektáž) střední Minimální riziko. Potenciální nízké riziko
API management Výpadek služby Nízká Úplný výpadek pro externí uživatele. Náprava závisí na společnosti Microsoft. Úplný
API management Regionální výpadek Velmi nízký Úplný výpadek pro externí uživatele. Náprava závisí na společnosti Microsoft. Úplný
API management Útok DDoS střední Potenciál narušení. Microsoft spravuje ochranu DDoS (L3 a L4). Možnost částečného výpadku
Vaše řešení Power Platform Nesprávná konfigurace střední Chybné konfigurace by měly být zachyceny během nasazení. Pokud k tomu dojde během aktualizace konfigurace, musí správci vrátit změny. Aktualizace konfigurace způsobí krátký externí výpadek. Možnost úplného výpadku

Usnadnění díky Power Platform

Power Platform se integruje s Application Insights, což je součást ekosystému Azure Monitor. Tuto integraci můžete použít k:

  • Přihlášení k odběru telemetrie získané platformou Dataverse v Application Insights o diagnostice, výkonu a operacích, které aplikace provádějí na vaší databázi Dataverse a v rámci modelem řízených aplikací. Tato telemetrie poskytuje informace, které můžete použít k diagnostice a řešení problémů souvisejících s chybami a výkonem.

  • Připojení aplikace plátna do Application Insights k použití těchto analýz k diagnostice problémů, porozumění tomu, co uživatelé s vašimi aplikacemi skutečně dělají, zajištění lepších obchodních rozhodnutí a zlepšení kvality vašich aplikací.

  • Konfigurace telemetrie Power Automate, aby směřovala do Application Insights. Tuto telemetrii můžete použít ke sledování provádění cloudových toků a vytváření výstrah na selhání běhu cloudových toků.

  • Zachyťte telemetrická data z vašeho agenta Microsoft Copilot Studio pro použití v Azure Application Insights. Tuto telemetrii můžete použít k monitorování protokolovaných zpráv a událostí odesílaných do a z vašeho agent, témat, která se mají aktivovat během konverzací uživatelů, a vlastních událostí telemetrie, které se dají odesílat z vašich témat.

Prostředky Power Platform protokolují aktivity v portálu pro dodržování předpisů Microsoft Purview. Většina akcí je dostupná do 24 hodin od aktivity. Tyto informace nepoužívejte pro monitorování v reálném čase. Pro více informací o protokolování aktivit v Power Platform, viz:

Kontrolní seznam spolehlivosti

Podívejte se na úplný soubor doporučení.

Kontrolní seznam spolehlivosti