Sdílet prostřednictvím

Doporučení pro řešení přechodných poruch

  • Článek

Platí pro toto doporučení Power Platform Dobře architektonizovaného kontrolního seznamu spolehlivosti:

RE: 05 Posilte odolnost své úlohy implementací zpracování chyb a přechodných poruch. Zabudujte do řešení možnosti pro řešení selhání součástí a přechodných chyb.

Tento průvodce popisuje doporučení pro řešení přechodných poruch ve vašich cloudových aplikacích. Všechny aplikace, které komunikují se vzdálenými službami a prostředky, musí být citlivé na přechodné poruchy. To platí zejména pro aplikace, které běží v cloudu, kde se kvůli povaze prostředí a připojení přes internet pravděpodobně setkáte s tímto typem závady častěji. Přechodné poruchy zahrnují okamžitou ztrátu síťového připojení ke komponentám a službám, dočasnou nedostupnost služby a časové limity, ke kterým dochází, když je služba zaneprázdněna. Tyto chyby se často opravují samy, takže pokud se akce opakuje po vhodné prodlevě, je pravděpodobné, že uspěje.

Klíčové strategie návrhu

Přechodné poruchy se mohou objevit v jakémkoli prostředí, na jakékoli platformě nebo operačním systému a v jakémkoli druhu aplikace.

Výzvy

Přechodné poruchy mohou mít významný vliv na vnímanou dostupnost aplikace, i když byla důkladně testována za všech předvídatelných okolností. Aby vaše úloha Power Platform mohla spolehlivě fungovat, musíte zajistit, aby byla schopna reagovat na následující výzvy:

  • Aplikace musí být schopna detekovat chyby, když nastanou, a určit, zda jsou poruchy pravděpodobně přechodné, dlouhodobé, nebo se jedná o selhání terminálu. Různé zdroje pravděpodobně vrátí různé reakce, když dojde k poruše, a tyto reakce se mohou také lišit v závislosti na kontextu operace. Například odpověď na chybu, když aplikace načítá data z vlastního konektoru, se může lišit od odpovědi, když aplikace spouští cloudový tok a čeká na odpověď.

  • Pokud aplikace zjistí, že porucha je pravděpodobně přechodná, musí být schopna operaci zopakovat.

  • Aplikace musí používat vhodnou strategii pro opakování. Strategie určuje, kolikrát se má aplikace pokusit opakovat, prodlevu mezi každým pokusem a akce, které se mají provést po neúspěšném pokusu. Přiměřený počet pokusů a prodlevu mezi každým z nich je často obtížné určit. Strategie se liší v závislosti na typu zdroje a na aktuálních provozních podmínkách zdroje a aplikace.

Obecné pokyny

Následující pokyny vám mohou pomoci navrhnout vhodné mechanismy zpracování přechodných poruch pro vaše aplikace.

Zjistěte, zda existuje vestavěný mechanismus opakování

Některé služby, ke kterým se připojujete, již mohou poskytovat mechanismus zpracování přechodných chyb. Zásada opakování, kterou používá, je obvykle přizpůsobena povaze a požadavkům cílové služby. Alternativně mohou rozhraní REST pro služby vracet informace, které vám mohou pomoci určit, zda je opakování vhodné a jak dlouho čekat před dalším pokusem o opakování.

Měli byste použít vestavěný mechanismus opakování, pokud je k dispozici, pokud nemáte specifické a dobře srozumitelné požadavky, které by jiné chování opakování učinily vhodnější.

Zjistěte, zda je operace vhodná pro opakování

Operace opakování provádějte pouze v případě, že jsou chyby přechodné (obvykle indikovány povahou chyby) a pokud existuje alespoň určitá pravděpodobnost, že operace bude při opakování úspěšná. Nemá smysl opakovat operace, které se pokoušejí o neplatnou operaci, jako je aktualizace řádku v Microsoft Dataverse, který neexistuje nebo ke kterému uživatel nemá oprávnění, nebo volání koncového bodu API, které neexistuje.

Opakované pokusy provádějte pouze tehdy, můžete-li určit plný účinek a pokud jsou podmínky dobře pochopeny a lze je ověřit. Pamatujte, že chyby vrácené ze zdrojů a služeb mimo vaši kontrolu se mohou časem vyvíjet a možná budete muset znovu přezkoumat logiku detekce přechodných chyb.

Při vývoji jednotlivých komponent nebo služeb, které jsou volány z vašich aplikací, se ujistěte, že vracíte chybové kódy a zprávy, které klientům pomohou určit, zda by měli opakovat neúspěšné operace. Zvažte určení, zda má klient operaci zopakovat, například vrácením hodnoty isTransient. Pokud vytváříte webovou službu, zvažte vrácení vlastních chyb, které jsou definovány ve vašich smlouvách o poskytování služeb.

Určete vhodný počet a interval opakování

Optimalizujte počet opakování a interval podle typu případu použití. Pokud nebude počet opakování dostatečný, aplikace nebude moci operaci dokončit a pravděpodobně selže. Pokud provedete příliš mnoho opakování nebo s příliš krátkým intervalem mezi pokusy, může aplikace zadržovat prostředky po dlouhou dobu, což nepříznivě ovlivní stav aplikace.

Přizpůsobte hodnoty pro časový interval a počet pokusů opakování typu operace. Pokud je operace například součástí interakce uživatele, měl by být interval krátký a mělo by se provést pouze několik pokusů. Pomocí tohoto přístupu se můžete vyhnout tomu, aby uživatelé čekali na odpověď. Pokud je operace součástí dlouhotrvajícího nebo kritického pracovního postupu, kde je zrušení a restartování procesu drahé nebo časově náročné, je vhodné mezi jednotlivými pokusy počkat déle a opakovat to vícekrát.

Mějte na paměti, že určení vhodných intervalů mezi opakováními je nejobtížnější částí návrhu úspěšné strategie. Typické strategie používají následující typy intervalů opakování:

  • Exponenciální interval. Aplikace čeká krátkou dobu před prvním opakováním a poté exponenciálně prodlužuje dobu mezi každým dalším opakováním. Může například opakovat operaci po 3 sekundách, 12 sekundách, 30 sekundách atd.

  • Pevné intervaly. Aplikace čeká stejnou dobu mezi každým pokusem.

  • Okamžité opakování. Někdy je přechodná chyba krátká a okamžité opakování operace je vhodné, protože může být úspěšné, pokud je chyba odstraněna v době, kdy aplikace odešle další požadavek. Nikdy by však nemělo dojít k více než jednomu okamžitému pokusu o opakování. Pokud okamžité opakování selže, měli byste přejít na alternativní strategie, jako je exponenciální interval nebo záložní akce.

Obecným vodítkem je použití strategie exponenciálního intervalu pro operace na pozadí a použití strategií okamžitého opakování nebo pevných intervalů pro interaktivní operace. V obou případech byste měli zvolit zpoždění a počet opakování tak, aby maximální latence pro všechny pokusy opakování byla v rámci požadovaného požadavku na úplnou latenci.

Zvažte kombinaci všech faktorů, které přispívají k celkovému maximálnímu časovému limitu pro opakovanou operaci. Mezi tyto faktory patří doba, za kterou neúspěšné připojení vyvolá odpověď, zpoždění mezi pokusy o opakování a maximální počet opakování. Součet všech těchto časů může mít za následek dlouhé celkové provozní doby, zvláště když používáte strategii exponenciálního zpoždění, kdy interval mezi opakováními po každém selhání rychle roste. Pokud proces musí splňovat konkrétní dohodu o úrovni služeb (SLA), musí být celková doba provozu včetně všech časových limitů a zpoždění v rámci limitů definovaných v SLA.

Neimplementujte příliš agresivní strategie opakování. Jedná se o strategie, které mají příliš krátké intervaly nebo příliš časté opakování. Mohou mít nepříznivý vliv na cílový zdroj nebo službu. Tyto strategie mohou zabránit tomu, aby se prostředek nebo služba zotavila z přetíženého stavu a bude nadále blokovat nebo odmítat požadavky. Výsledkem tohoto scénáře je začarovaný kruh, kdy se zdroji nebo službě posílá stále více požadavků. V důsledku toho je jeho schopnost zotavení dále snížena.

Při výběru intervalů opakování zvažte časový limit operací, abyste se vyhnuli okamžitému spuštění následného pokusu (například pokud je časový limit podobný intervalu opakování).

Pomocí typu chyby nebo chybových kódů a zpráv vrácených službou optimalizujte počet opakování a interval mezi nimi. Například některé výjimky nebo chybové kódy (jako je kód HTTP 503, Služba není k dispozici, s hlavičkou Retry-After v odpovědi) mohou naznačovat, jak dlouho může chyba trvat, nebo že služba selhala a nebude reagovat na žádné následný pokus.

Vyhněte se antivzorů

Ve většině případů se vyhněte implementacím, které obsahují duplicitní vrstvy kódu opakování. Vyhněte se návrhům, které obsahují kaskádové mechanismy opakování nebo které implementují opakování v každé fázi operace, která zahrnuje hierarchii požadavků, pokud na to nemáte specifické požadavky. Za těchto výjimečných okolností používejte zásady, které zabraňují nadměrnému počtu opakování a zpoždění, a ujistěte se, že rozumíte důsledkům. Řekněme například, že jedna komponenta odešle požadavek na jinou, která pak přistupuje k cílové službě. Pokud implementujete opakování s počtem tří u obou volání, existuje celkem devět pokusů opakování proti službě. Mnoho služeb a prostředků implementuje vestavěný mechanismus opakování. Měli byste prozkoumat, jak můžete deaktivovat nebo upravit tyto mechanismy, pokud potřebujete implementovat opakování na vyšší úrovni.

Nikdy neimplementujte nekonečný mechanismus opakování. Pokud tak učiníte, pravděpodobně zabráníte tomu, aby se prostředek nebo služba zotavila ze situací přetížení a způsobí to, že omezení a odmítnutí připojení budou pokračovat po delší dobu.

Nikdy neprovádějte okamžitý pokus více než jednou.

Při přístupu ke službám a prostředkům v Azure nepoužívejte pevný interval opakování, zvláště když máte vysoký počet pokusů o opakování. Nejlepším přístupem v tomto scénáři je strategie exponenciálního intervalu.

Otestujte svou strategii a implementaci opakování

Plně otestujte svou strategii opakování za co nejširšího souboru okolností, zejména pokud jsou aplikace i cílové prostředky nebo služby, které používá, extrémně zatíženy. Ke kontrole chování během testování můžete:

  • Vložit do služby přechodné a nepřechodné poruchy. Například posílejte neplatné požadavky nebo přidejte kód, který detekuje testovací požadavky a reaguje s různými typy chyb.

  • Vytvořit maketu prostředku nebo služby, která vrátí řadu chyb, které může vrátit skutečná služba. Pokryjte všechny typy chyb, na které je vaše strategie opakování navržena.

  • U vlastních služeb, které vytvoříte a nasadíte, vynuťte výskyt přechodných chyb dočasným vypnutím nebo přetížením služby. (Nepokoušejte se přetížit žádné sdílené prostředky nebo sdílené služby v Azure.)

  • Při testování odolnosti klientské webové aplikace vůči přechodným chybám použijte vývojářské nástroje prohlížeče nebo schopnost vašeho testovacího rámce podvrhnout nebo blokovat síťové požadavky.

  • Proveďte vysoký faktor zatížení a souběžné testy, abyste se ujistili, že mechanismus a strategie opakování fungují za těchto podmínek správně. Tyto testy také pomáhají zajistit, že opakovaný pokus nebude mít nepříznivý vliv na provoz klienta nebo nezpůsobí křížovou kontaminaci mezi požadavky.

Spravujte konfigurace zásad opakování

Zásady opakování jsou kombinací všech prvků vaší strategie opakování. Definuje mechanismus detekce, který určuje, zda je chyba pravděpodobně přechodná, typ intervalu, který se má použít (jako pevný nebo exponenciální), skutečné hodnoty intervalu a počet opakování.

Využijte vestavěné nebo výchozí strategie opakování, ale pouze tehdy, když jsou vhodné pro váš scénář. Tyto strategie jsou obvykle obecné. V některých scénářích mohou být vše, co potřebujete, ale v jiných scénářích nenabízejí celou škálu možností, které by vyhovovaly vašim konkrétním požadavkům. Chcete-li určit nejvhodnější hodnoty, musíte provést testování, abyste pochopili, jak nastavení ovlivňují vaši aplikaci.

Zaznamenávejte a sledujte přechodné a nepřechodné poruchy

Jako součást vaší strategie opakování zahrňte zpracování výjimek a další vybavení, které zaznamenává pokusy o opakování. Občasné přechodné selhání a opakování se očekávají a neindikují problém. Pravidelné a zvyšující se počty opakování jsou však často indikátorem problému, který může způsobit selhání nebo který snižuje výkon a dostupnost aplikace.

Přechodné poruchy protokolujte jako záznamy varování, a ne záznamy chyb, aby je monitorovací systémy nezjistily jako chyby aplikace, které by mohly spustit falešné výstrahy.

Zvažte uložení hodnoty do položek protokolu, která označuje, zda jsou opakování způsobena omezením ve službě, nebo jinými typy chyb, jako jsou selhání připojení, abyste je mohli během analýzy dat odlišit. Nárůst počtu chyb omezení kapacity je často indikátorem konstrukční chyby v aplikaci nebo potřeby přidat kapacitu Premium do prostředí.

Zvažte implementaci telemetrického a monitorovacího systému, který může upozorňovat, když se zvyšuje počet a četnost selhání, průměrný počet opakování nebo celková doba, která uplyne, než operace uspěje.

Spravujte operace, které neustále selhávají

Zvažte, jak zacházet s operacemi, které nadále selhávají při každém pokusu. Takové situace jsou nevyhnutelné.

Přestože strategie opakování definuje maximální počet opakování operace, nebrání aplikaci v opakování operace se stejným počtem opakování. Tok může spustit například odeslání formuláře ve vaší aplikaci. Strategie opakování může zjistit časový limit připojení a považovat to za přechodnou chybu. Tok zopakuje operaci zadaný počet opakování a poté to vzdá. Když se však stejný nebo nový uživatel pokusí odeslat formulář znovu, operace se zkusí znovu, i když může i nadále selhat.

Aplikace může službu pravidelně testovat, přerušovaně a s dlouhými intervaly mezi požadavky, aby zjistila, kdy bude dostupná. Vhodný interval závisí na faktorech, jako je kritičnost operace a povaha služby. Může to být něco mezi několika minutami a několika hodinami. Když je test úspěšný, aplikace může obnovit normální operace a předat požadavky nově obnovené službě.

Mezitím možná budete moci provádět některé alternativní operace založené na naději, že služba bude brzy dostupná. Může být například vhodné uložit požadavky na službu do fronty nebo úložiště dat a zkusit je později. Nebo možná budete muset uživateli vrátit zprávu, že aplikace není k dispozici.

Další důležité informace

Když se rozhodujete o hodnotách počtu opakování a intervalech opakování pro zásadu, zvažte, zda je operace se službou nebo prostředkem součástí dlouhodobé nebo vícekrokové operace. Může být obtížné nebo nákladné kompenzovat všechny ostatní provozní kroky, které již byly úspěšné, když jeden selže. V tomto případě může být přijatelný dlouhý interval a velký počet opakování, pokud tato strategie neblokuje jiné operace držením nebo zamykáním vzácných zdrojů.

Zvažte, zda by opakovaný pokus o stejnou operaci mohl způsobit nekonzistence v datech. Pokud se některé části vícekrokového procesu opakují a operace nejsou idempotentní, může dojít k nesrovnalostem. Pokud se například opakuje operace, která vkládá záznam do Microsoft Dataverse , může to způsobit nesprávné hodnoty v tabulce. Nebo pokud zopakujete operaci, která uživateli odešle upozornění, může obdržet duplicitní zprávy.

Zvažte rozsah operací, které se opakují. Například by mohlo být snazší implementovat kód pro opakování na úrovni, která zahrnuje několik operací, a v případě selhání je zkusit všechny znovu. Pokud tak učiníte, může to mít za následek problémy s idempotenci nebo zbytečné operace vrácení zpět.

Pokud zvolíte rozsah opakování, který zahrnuje několik operací, zvažte celkovou latenci všech z nich při určování intervalů opakování, při sledování uplynulých časů operace a předtím, než spustíte upozornění na selhání.

Usnadnění díky Power Platform

Následující části popisují mechanismy, které můžete použít ke správě přechodných chyb.

Power Automate

Power Automate obsahuje funkci pro opakování akce, pokud selže. Nakonfigurujte ji na úrovni jednotlivých akcí. Přečtěte si o snižování rizika a plánování řešení chyb v Power Automate projektu. Power Automate také nabízí akce pro vrácení vlastních chyb a dat do volající aplikace nebo toku.

Některé přechodné toky mohou být způsobeny limity propustnosti a požadavků. Přečtěte si o limitech automatických, naplánovaných a okamžitých toků a limitech a alokacích požadavků.

Nakonfigurujte zpracování chyb a výjimek v cloudových tocích pomocí rozsahů a nastavení běhu.

Power Apps

Aplikace plátna Power Apps poskytují možnost kontrolovat stav připojení, což jim umožňuje chovat se jinak, pokud je aplikace offline. Zjistěte, jak vyvíjet aplikace na plátně schopné offline.

Můžete také použít funkce Error, IfError, IsError a IsBlankOrError v aplikacích plátna k rozhodnutí, co dělat dál, pokud dojde k chybě.

Další informace o zpracování přechodných chyb v Power Apps:

Azure a vlastní konektory

Pokud se vaše úloha připojuje ke službám Azure, naučte se, jak zvládnout přechodné chyby pomocí rámce Azure Well-Architected.

Chcete-li spravovat reakce vlastního konektoru na chyby, postupujte podle standardů kódování.

Application Insights

Použijte integrace Application Insights k protokolování chyb v Power Automate a Power Apps:

Kontinuita podnikání a zotavení po havárii pro aplikace Dynamics 365 SaaS

Kontrolní seznam spolehlivosti

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

Kontrolní seznam spolehlivosti