Doporučení pro návrh strategie řešení selhání nasazení
Platí pro toto doporučení kontrolního seznamu provozní dokonalosti pro Power Platform Well-Architected:
| OE:11 | Implementujte strategii řešení selhání nasazení, která řeší neočekávané problémy uprostřed zavádění s rychlou obnovou. Kombinujte více přístupů, jako je vrácení zpět, deaktivace funkcí nebo použití nativních schopností vašeho vzoru nasazení. |
|---|
Tato příručka popisuje doporučení pro návrh standardizované strategie pro efektivní řešení selhání nasazení. Stejně jako jiné problémy s úlohami jsou selhání nasazení nevyhnutelnou součástí životního cyklu úloh. S tímto přístupem můžete být proaktivní tím, že budete mít dobře navrženou, záměrnou strategii pro řešení selhání nasazení. Taková strategie umožňuje vašemu týmu úloh efektivně zmírnit selhání s co nejmenším dopadem na vaše uživatele.
Absence takového plánu může vést k chaotickým a potenciálně škodlivým reakcím na problémy, což může významně ovlivnit týmovou a organizační soudržnost, důvěru zákazníků a finance.
Klíčové strategie návrhu
Navzdory vyspělosti vašich vývojových postupů se občas vyskytnou problémy s nasazením. Použití postupů bezpečného nasazení a provozování robustního dodavatelského řetězce úlohy vám může pomoci minimalizovat frekvenci neúspěšných nasazení. Musíte také navrhnout standardizovanou strategii pro zpracování neúspěšných nasazení, když k nim dojde.
Strategie řešení selhání nasazení se skládá z pěti obecných fází:
- Detekce: Chcete-li reagovat na neúspěšné nasazení, musíte nejprve selhání detekovat. Detekce může mít několik forem, jako jsou neúspěšné kouřové testy, hlášení uživatelů nebo výstrahy, které generuje vaše monitorovací platforma.
- Rozhodnutí: Musíte se rozhodnout, jaká je nejlepší strategie řešení pro konkrétní typ selhání.
- Zmírnění: Musíte provést identifikovanou akci pro zmírnění. Řešení může mít podobu převzetí, vrácení zpět nebo převrácení vpřed.
- Komunikace: Zúčastněné strany a dotčení uživatelé musí být informováni o stavu při zjišťování a řešení problému, jak to vyžaduje váš plán reakce na mimořádné události.
- Analýza po incidentu: Analýzy po incidentu bez hledání viníka poskytují pracovnímu týmu příležitosti k identifikaci oblastí pro zlepšení a vytváření plánů pro uplatnění poznatků.
Následující části obsahují podrobná doporučení k těmto fázím.
Detekce
Pokud chcete rychle identifikovat problémy s nasazeními, potřebujete robustní postupy testování a monitorování, které souvisejí s nasazeními. Pokud chcete rychle zjišťovat anomálie, můžete monitorování úloh a upozorňování doplnit pomocí nástroje pro správu výkonu aplikací a protokolování prostřednictvím instrumentace.
Orientační testování a další testování kvality by mělo probíhat v každé fázi vašeho zavádění. Úspěšné testy v jedné skupině nasazení by neměly ovlivnit rozhodnutí o testování v následujících skupinách.
Můžete implementovat telemetrii, která koreluje uživatelské problémy s fází nasazení. Potom můžete rychle zjistit, ke které skupině zavádění je konkrétní uživatel přidružen. Tento přístup je zvláště důležitý pro nasazení s progresivním vystavením, protože v kterémkoli bodě nasazení můžete mít v rámci své uživatelské základny několik konfigurací.
Měli byste být připraveni okamžitě reagovat na problémy nahlášené uživateli. Kdykoli je to praktické, nasaďte fázi zavádění během pracovní doby, kdy máte k dispozici úplný tým podpory. Ujistěte se, že pracovníci podpory jsou vyškoleni v tom, jak eskalovat problémy s nasazením pro správné směrování. Eskalace by měly být v souladu s vaším plánem reakce na nouzové situace.
Rozhodnutí
Rozhodování o vhodné strategii zmírnění rizik pro problém s nasazením zahrnuje zvážení faktorů, jako jsou:
Typ modelu progresivní expozice, který používáte. Můžete například použít modrozelený model nebo kanárkový model. Pokud použijete modrozelený model, je praktičtější provést převzetí než se vrátit zpět. Provoz můžete snadno přesunout zpět do prostředí, které spouští konfiguraci, která není aktualizována. Poté můžete problém vyřešit v problematickém prostředí a zkusit nasazení znovu ve vhodnou dobu.
Metody, které máte k dispozici, jak problém obejít. Příklady zahrnují použití příznaků funkcí, proměnných prostředí nebo jakéhokoli jiného typu vlastnosti konfigurace za běhu, kterou můžete zapínat a vypínat. Někdy můžete problém snadno obejít vypnutím příznaku funkce nebo přepnutím nastavení. V tomto případě možná budete moci:
- Pokračovat v zavádění.
- Vyhnout se převzetí.
- Vrátit se zpět, zatímco opravujete závadný kód.
Úroveň úsilí potřebná k implementaci opravy v kódu. Pokud je úroveň úsilí o opravu kódu nízká, je pro určité scénáře správnou volbou implementace opravy hotfix.
Úroveň kritičnosti pro dotčenou úlohu. Kritické úlohy by měly být vždy nasazovány vedle sebe, jako v modrozeleném modelu, aby bylo dosaženo nasazení s nulovými prostoji. V důsledku toho je u těchto typů úloh preferovanou strategií řešení převzetí.
Zmírnění
Níže jsou uvedeny některé běžné strategie řešení:
Vrácení zpět: Ve scénáři vrácení zpět vrátíte aktualizované systémy do posledního známého dobrého stavu konfigurace.
Je důležité, aby se celý tým úloh shodl na významu "posledního známého stavu". Tento výraz odkazuje na poslední stav úlohy, která byla v pořádku před zahájením nasazení, což nemusí být nutně předchozí verze aplikace.
Vrácení zpět může být složité, zejména pokud se týká změn dat. Změny schématu mohou způsobit, že návrat zpět je riskantní. Jejich bezpečná implementace může vyžadovat značné plánování. Jako obecné doporučení by měly být aktualizace schématu aditivní. Záznamy by neměly být nahrazovány novými záznamy. Místo toho by starší záznamy měly být zastarány a měly by existovat souběžně s novými záznamy, dokud nebude bezpečné odstranit zastaralé záznamy.
Převzetí: V nouzovém scénáři jsou aktualizované systémy odstraněny z produkčního směrování provozu. Veškerý provoz je směrován do prostředí, které není aktualizováno. Tato strategie s nízkým rizikem vám poskytuje způsob, jak vyřešit problémy ve vašem kódu, aniž by došlo k dalšímu narušení.
S nasazením Canary nemusí být převzetí jednoduché nebo dokonce možné, v závislosti na vaší infrastruktuře a designu aplikace. Pokud potřebujete provést škálování, abyste zvládli zatížení systémů, které nejsou aktualizovány, proveďte toto škálování, než provedete převzetí.
Obejít problematickou funkci: Pokud můžete problém obejít pomocí příznaků funkcí nebo jiného typu vlastnosti konfigurace modulu runtime, můžete se rozhodnout, že pokračování v zavedení je správnou strategií pro daný problém.
Měli byste jasně rozumět kompromisu obcházení funkce a měli byste být schopni tento kompromis sdělit zúčastněným stranám. Zúčastněné strany by měly schválit další plán. Zúčastněné strany musí určit dobu, která je tolerovatelná pro provoz ve zhoršeném stavu. Musí také zvážit toto rozhodnutí s vaším odhadem času, který je potřeba k opravě problematického kódu a jeho nasazení.
Nouzové nasazení (oprava hotfix): Pokud můžete problém vyřešit během zavedení, může být nejpraktičtější strategií zmírnění oprava hotfix.
Stejně jako jakýkoli jiný kód musí opravy hotfix projít postupy bezpečného nasazení. S opravou hotfix se však časová osa výrazně zrychlí. Ve svém prostředí musíte použít strategii propagace kódu. Musíte také zkontrolovat kód opravy hotfix na všech branách kvality. Možná však budete muset výrazně zkrátit doby simulace a možná budete muset upravit testy, abyste je urychlili. Ujistěte se, že můžete co nejdříve po nasazení spustit úplné testy aktualizovaného kódu. Automatizace testování zajištění kvality do vysoké míry pomáhá v těchto scénářích zefektivnit testování.
Komunikace
Je důležité jasně definovat komunikační povinnosti, které pomohou minimalizovat chaos během incidentů. Tyto odpovědnosti by měly stanovit, jak tým úlohy spolupracuje s týmy podpory, zúčastněnými stranami a personálem týmu reakce na mimořádné události, jako je manažer reakce na mimořádné události.
Standardizujte kadenci, kterou tým úlohy dodržuje při poskytování aktualizací stavu. Zajistěte, aby zúčastněné strany věděly o tomto standardu, aby věděly, kdy očekávat aktualizace.
Pokud tým úloh potřebuje komunikovat přímo s uživateli, ujasněte si typ informací a úroveň podrobností, které jsou vhodné pro sdílení. Sdělte týmu úlohy také jakékoli další požadavky, které se na tyto případy vztahují.
Pitva
Po všech neúspěšných nasazeních by měly bez výjimky následovat pitvy. Každé neúspěšné nasazení je příležitostí k učení. Postmortems vám můžou pomoct identifikovat slabá místa v procesech nasazení a vývoje a chybné konfigurace ve vaší infrastruktuře.
Pitvy by měly být vždy bez heldání viny, aby se lidé, kteří jsou zapojeni do incidentu, cítili bezpečně, když sdílejí své názory na to, co lze zlepšit. Lídři analýz po incidentu by měli následovat plány na implementaci zjištěných zlepšení a na přidání těchto plánů do nevyřízených úloh v sestavě.
Úvahy a obecná doporučení
Ujistěte se, že váš kanál implementace může přijímat různé verze jako parametry, abyste mohli snadno nasadit poslední známé dobré konfigurace.
Zachovejte konzistenci se správou a datovými rovinami, když se vracíte zpět nebo vpřed. Klíče, tajné klíče, data o stavu databáze a konfigurace, které jsou specifické pro zdroje a zásady, musí být v rozsahu a zohledněny. Věnujte pozornost například návrhu škálování své infrastruktury ve vašem posledním známém dobrém nasazení. Zjistěte, zda je nutné tuto konfiguraci upravit při opětovném nasazení kódu.
Dávejte přednost malým, častým změnám před občasnými a velkými změnami, aby byl rozdíl mezi vašimi novými nasazeními a posledními známými funkčními nasazeními malý.
Proveďte analýzu režimu selhání na vašich kanálech kontinuální integrace a průběžného doručování (CI/CD), abyste pomohli identifikovat problémy, které mohou zkomplikovat úsilí o zmírnění. Stejně jako u úloh jako celku je možné vaše kanály analyzovat a identifikovat oblasti, které by mohly být problematické při pokusu o daný typ zmírnění rizik.
Používejte funkci automatického vrácení zpět uvážlivě:
- Některé nástroje CI/CD jako Azure DevOps mají zabudovanou funkci automatického vrácení zpět. Zvažte použití této funkce, pokud vám poskytuje hmatatelnou hodnotu.
- Funkci automatického vrácení zpět byste měli přijmout až poté, co důkladně a pravidelně otestujete svůj kanál. Ujistěte se, že váš kanál je dostatečně vyspělý, aby mohl způsobit další problémy, pokud je spuštěno automatické vrácení zpět.
- Musíte věřit, že automatizace nasadí pouze nezbytné změny a že se spouští pouze v případě potřeby. Navrhněte své spouštěče pečlivě, aby splňovaly tyto požadavky.
Používejte funkce poskytované platformou během vrácení zpět. Například zálohy a obnovení k určitému bodu v čase můžou pomoct s úložištěm a vrácením dat zpět. Nebo pokud k hostování aplikace používáte virtuální počítače, může být užitečné obnovit prostředí do kontrolního bodu z doby bezprostředně před incidentem.
Často testujte celou svou strategii řešení selhání nasazení. Stejně jako plány reakce na mimořádné události a plány zotavení po havárii je váš plán selhání nasazení úspěšný pouze v případě, že je váš tým na něj vyškolen a pravidelně ho cvičí. Chaosinženýrství a testování vkládáním chyb mohou být efektivní techniky pro testování vaší strategie řešení nasazení.
Usnadnění díky Power Platform
Kanály v Power Platform mají za cíl demokratizovat správu životního cyklu aplikací (ALM) pro zákazníky Power Platform a Dynamics 365 tím, že do služby přináší automatizaci ALM a kontinuální integraci a průběžné doručování (CI/CD).
Microsoft Power Platform Build Tools pro Azure DevOps lze použít pro automatizaci běžných úkolů sestavení a nasazení souvisejících s aplikacemi sestavenými v Power Platform.
Nástroj GitHub Actions pro Power Platformumožňuje vývojářům vytvářet automatizované pracovní postupy životního cyklu vývoje softwaru. Pomocí GitHub Actions pro Microsoft Power Platform můžete ve svém úložišti vytvářet pracovní toky pro sestavování, testování, balení, vydávání a nasazování aplikací, provádět automatizaci nebo spravovat roboty a další vestavěné komponenty na Microsoft Power Platform.
ALM Accelerator je nástroj s otevřeným zdrojovým kódem, který se skládá ze sady aplikací, skriptů a kanálů navržených k automatizaci procesu kontinuální integrace / průběžného doručování.
Automatizace testů s Azure Pipelines
Ke konfiguraci agentů a testů použijte Sadu Power CAT Copilot Studio Kit. Spusťte jednotlivé testy pro rozhraní API Copilot Studio (Direct Line) a vyhodnoťte odpovědi agenta oproti očekávaným výsledkům.
Proměnné prostředí v řešeních ukládají klíče a hodnoty parametrů, které pak slouží jako vstup do různých dalších objektů aplikace. Oddělení parametrů od spotřebovávajících objektů umožňuje měnit hodnoty ve stejném prostředí nebo při migraci řešení do jiných prostředí.
Prostředí Power Platform poskytují funkci obnovení k bodu v čase, která vám může pomoci vrátit se zpět.
Power Platform se integruje s Application Insights, což je součást ekosystému Azure Monitor. Tuto integraci použijte k:
Příjmu telemetrie o diagnostice a výkonu zaznamenaném platformou Dataverse v Application Insights. Můžete se přihlásit k odběru a přijímat telemetrii o 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řipojte aplikace plátna k Application Insights. Tyto analýzy můžete použít k diagnostice problémů a pochopení toho, co uživatelé s vašimi aplikacemi dělají. Můžete shromažďovat informace, které vám pomohou činit lepší obchodní rozhodnutí a zlepšovat kvalitu aplikací.
Nakonfigurujte Telemetrii Power Automate, která má proudit do Application Insights, například k monitorování spouštění cloudového toku a vytváření upozornění na selhání spuštění cloudového toku.
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.
Kontrolní seznam provozní dokonalosti
Podívejte se na úplný soubor doporučení.