Share via

Doporučení pro návrh strategie zmírnění selhání nasazení

  • Článek

Platí pro toto doporučení kontrolního seznamu pro efektivitu provozu azure Well-Architected Framework:

OE:12 Implementujte strategii zmírnění selhání nasazení, která řeší neočekávané problémy s rychlým obnovením v polovině zavádění. Zkombinujte několik přístupů, jako je vrácení zpět, zakázání funkcí nebo použití nativních funkcí modelu nasazení.

Tato příručka popisuje doporučení pro návrh standardizované strategie pro efektivní zpracování selhání nasazení. Stejně jako u jiných problémů s úlohami jsou selhání nasazení nevyhnutelnou součástí životního cyklu úloh. Díky tomuto myšlení můžete být proaktivní díky dobře navržené a záměrné strategii pro řešení selhání nasazení. Tato strategie umožňuje týmu úloh efektivně zmírnit selhání s co nejmenším dopadem na koncové 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ýrazně ovlivnit soudržnost týmu a organizace, důvěru zákazníků a finance.

Klíčové strategie návrhu

Občas, navzdory vyspělosti vašich postupů vývoje, dochází k problémům s nasazením. Použití postupů bezpečného nasazení a provozování robustního dodavatelského řetězce úloh vám může pomoct minimalizovat frekvenci neúspěšných nasazení. Musíte ale také navrhnout standardizovanou strategii pro zpracování neúspěšných nasazení, když k nim dojde.

Pokud jako standardní postup používáte model postupného nasazení expozice:

  • Máte správný základ pro minimalizaci dopadů na zákazníky nebo interní uživatele, když nasazení selže.
  • Problémy můžete efektivně zmírnit.

Strategie zmírnění selhání nasazení se skládá z pěti širokých fází:

  1. Detekce: Pokud chcete reagovat na neúspěšné nasazení, musíte nejprve zjistit selhání. Detekce může mít různé podoby, jako jsou neúspěšné orientační testy, problémy nahlášené uživatelem nebo výstrahy, které generuje vaše monitorovací platforma.

  2. Rozhodnutí: Musíte se rozhodnout, jaká je nejlepší strategie pro zmírnění rizik pro konkrétní typ selhání.

  3. Zmírnění rizik: Provedete identifikovanou akci pro zmírnění rizik. Zmírnění rizik může mít podobu náhradního řešení, vrácení zpět, vrácení vpřed nebo použití konfigurace modulu runtime k obejití funkce, která by urážel.

  4. Komunikace: Zúčastněné strany a koncoví uživatelé, kterých se to týká, musí být při zjišťování problému a jejich řešení informovány o stavu, jak to vyžaduje váš plán reakce na tísňové situace.

  5. Postmortem: Bezúhonné postmortems poskytují pracovnímu týmu příležitosti k identifikaci oblastí pro zlepšení a vytváření plánů pro uplatnění učení.

Následující části obsahují podrobná doporučení pro tyto fáze. V těchto částech se předpokládá, že po nasazení změn do jedné nebo více skupin uživatelů nebo systémů, ale před aktualizací všech skupin v plánu uvedení zjistíte problém.

Detekce

Pokud chcete rychle identifikovat problémy s nasazeními, potřebujete robustní postupy testování a pozorovatelnosti , které souvisejí s nasazeními. Pokud chcete rychle detekovat anomálie, můžete monitorování úloh a upozorňování doplnit provedením následujících kroků:

  • Použijte nástroj pro správu výkonu aplikace.
  • Povolte protokolování prostřednictvím instrumentace.

Testování kouře a další testování kvality by mělo probíhat v každé fázi uvedení. Úspěšné testy v jedné skupině nasazení by neměly ovlivnit rozhodování o testování v následných skupinách.

Můžete implementovat telemetrii, která koreluje problémy uživatelů s fází nasazení. Pak můžete rychle zjistit, ke které skupině uvedení je konkrétní uživatel přidružený. Tento přístup je zvlášť důležitý pro progresivní nasazení expozice, protože v libovolném bodě nasazení může běžet více konfigurací napříč vaší uživatelskou základnou.

Měli byste být připraveni okamžitě reagovat na problémy nahlášené uživatelem. Kdykoli je to praktické, nasaďte fázi zavádění během pracovní doby, pokud máte k dispozici kompletní tým podpory. Ujistěte se, že pracovníci podpory jsou vyškoleni o tom, jak eskalovat problémy s nasazením za účelem správného směrování. Eskalace by měly být v souladu s vaším plánem reakce na nouzové situace pro úlohy.

Rozhodnutí

Rozhodnutí o vhodné strategii zmírnění rizik pro daný problém nasazení zahrnuje zvážení mnoha faktorů, mezi které patří:

  • Typ modelu progresivní expozice, který používáte. Můžete například použít modrozelený model nebo kanárový model.

    Pokud používáte modrozelený model, je návrat zpět praktičtější než vrácení zpět. Provoz můžete snadno přesunout zpět do zásobníku, ve kterém se spouští konfigurace, která se neaktualizuje. Pak můžete problém vyřešit v problematickém prostředí a zkusit nasazení ve vhodnou dobu znovu.

  • Metody, které máte k dispozici pro obejití problému. Mezi příklady patří použití příznaků funkcí, proměnných prostředí nebo jakéhokoli jiného typu vlastnosti konfigurace modulu runtime, kterou můžete zapnout a vypnout.

    Někdy můžete problém snadno obejít vypnutím příznaku funkce nebo přepnutím nastavení. V takovém případě můžete být schopni:

    • Pokračujte v zavádění.
    • Vyhněte se pádu zpět.
    • Vraťte se zpět, zatímco opravíte urážený kód.

  • Úroveň úsilí, která je nutná k implementaci opravy v kódu.

    Pokud je úroveň úsilí o opravu kódu nízká, je pro určité scénáře tou správnou volbou postupná implementace aktivní opravy.

  • Úroveň závažnosti pro ovlivněnou úlohu.

    Aby bylo možné dosáhnout nasazení s nulovými výpadky, měly by se úlohy pro důležité obchodní informace vždy nasazovat vedle sebe, například v modrozeleném modelu. V důsledku toho je vhodnější strategií zmírnění rizik pro tyto typy úloh návrat.

  • Typ infrastruktury, kterou úloha používá – proměnlivá nebo neměnná.

    Pokud je vaše úloha navržená tak, aby používala proměnlivou infrastrukturu, může mít smysl pokračovat, protože zahrnuje aktualizaci infrastruktury. Naopak vrácení zpět nebo pokles zpět může dávat smysl, když používáte neměnnou infrastrukturu.

Bez ohledu na to, kterou volbu uděláte, byste měli do rozhodovacího procesu zahrnout příslušná schválení a kodifikovat je ve svém rozhodovacím stromu.

Omezení rizik

  • Vrácení zpět: Ve scénáři vrácení zpět vrátíte aktualizované systémy do posledního známého stavu konfigurace.

    Je důležité, aby se celý tým úloh dohodl na významu posledního známého dobra. Tento výraz odkazuje na poslední stav úlohy, která byla před zahájením nasazení v pořádku, což nemusí být nutně předchozí verze aplikace.

    Vrácení zpět může být složité, zejména v souvislosti se změnami dat. Změny schématu můžou usnadnit vrácení zpět. Jejich bezpečná implementace může vyžadovat značné plánování. Obecně se doporučuje, aby aktualizace schématu byly doplňkové. Neměly by se jednat o nahrazení změn – záznamy by se neměly nahrazovat novými záznamy. Místo toho by starší záznamy měly být zastaralé a měly by existovat společně s novými záznamy, dokud nebude možné zastaralé záznamy bezpečně odebrat.

  • Záložní: V záložním scénáři se aktualizované systémy odeberou ze směrování provozu v produkčním prostředí. Veškerý provoz se směruje do zásobníku, který se neaktualizuje. Tato strategie s nízkým rizikem poskytuje způsob, jak řešit problémy v kódu, aniž byste museli zavádět další narušení.

    V případě nasazení kanárů nemusí být návrat zpět přímočarý nebo dokonce možný v závislosti na vaší infrastruktuře a návrhu aplikace. Pokud potřebujete provést škálování, abyste zvládli zatížení systémů, které nejsou aktualizované, proveďte toto škálování před návratem zpět.

  • Obejití urážky funkce: 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ě porozumět kompromisu při obejití 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 plán go-forward schválit. Zúčastněné strany musí určit dobu, která je pro provoz v degradovaném stavu snášená. Musí také zvážit toto rozhodnutí s vaším odhadem času, který je potřebný k opravě kódu, který je urážka, a jeho nasazení.

  • Nouzové nasazení (hotová oprava): Pokud můžete problém vyřešit v polovině uvedení, nejpraktičtější strategií pro zmírnění rizik může být horká oprava.

    Stejně jako každý jiný kód musí i horké opravy projít postupy bezpečného nasazení. Ale s horkou opravou se časová osa výrazně zrychluje. Ve svých prostředích musíte použít strategii povýšení kódu. Musíte také zkontrolovat kód opravy za běhu na všech branách kvality. Možná ale budete muset výrazně zkrátit dobu pečení a možná budete muset upravit testy, aby se urychlily. 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á zajistit, aby testování bylo v těchto scénářích efektivní.

Kompromisy:

  • Možnost návratu obvykle znamená, že potřebujete dostatečnou kapacitu infrastruktury, abyste zvládli dvě verze konfigurace úloh současně. Týmy úloh také musí být schopné současně podporovat dvě verze v produkčním prostředí.
  • Možnost efektivního vrácení zpět může zahrnovat refaktoring prvků vaší úlohy. Můžete například potřebovat oddělit funkce nebo změnit datový model.

Komunikace

Je důležité mít jasně definované komunikační povinnosti, aby se minimalizoval chaos během incidentů. Tyto odpovědnosti by měly stanovit, jak tým úloh spolupracuje s týmy podpory, zúčastněnými stranami a pracovníky týmu reakce na mimořádné události, jako je manažer reakce na mimořádné události.

Standardizujte tempo, které tým úloh sleduje při poskytování aktualizací stavu. Zajistěte, aby zúčastněné strany o tomto standardu věděly, aby věděly, kdy očekávat aktualizace.

Pokud tým úloh potřebuje komunikovat přímo s koncovými uživateli, ujasněte si typ informací a úroveň podrobností, které jsou vhodné pro sdílení s uživateli. Také informujte tým úloh o všech dalších požadavcích, které se na tyto případy vztahují.

Dodatečná analýza

Posmrtná nasazení by měla bez výjimky následovat po všech neúspěšných nasazeních. Každé neúspěšné nasazení je příležitostí k učení. Následné kroky vám můžou pomoct identifikovat slabá místa v procesech nasazení a vývoje. Kromě mnoha dalších možností můžete ve své infrastruktuře také identifikovat chybné konfigurace.

Posmrtné události by vždy měly být bez obviňování, aby se jednotlivci, kteří jsou do incidentu zapojeni, cítili bezpečně, když sdílejí své názory na to, co je možné zlepšit. Vedoucí pracovníci po dokončení by měli následovat plány na implementaci zjištěných vylepšení a přidání těchto plánů do backlogu úloh.

Důležité informace a obecná doporučení

Ujistěte se, že váš kanál nasazení může jako parametry přijímat odlišné verze, abyste mohli snadno nasadit konfigurace, které jsou poslední známé.

Při posouvání zpět nebo vpřed udržujte konzistenci s rovinami správy a dat. Klíče, tajné kódy, data stavu databáze a konfigurace specifické pro prostředky a zásady musí být v oboru a musí se s nimi počítat. Věnujte například pozornost návrhu škálování infrastruktury v posledním známém funkčním nasazení. Určete, jestli je potřeba tuto konfiguraci upravit při opětovném nasazení kódu.

Upřednostňujte malé a časté změny před občasnými a velkými změnami, aby rozdíl mezi novým a posledním známým funkčním nasazením byl malý.

Proveďte analýzu režimu selhání (FMA) u kanálů kontinuální integrace a průběžného doručování (CI/CD), abyste mohli identifikovat problémy, které můžou komplikovat zmírnění rizik. Podobně jako u úloh jako celku je možné analyzovat vaše kanály a identifikovat oblasti, které můžou být při pokusu o určitý typ zmírnění rizik problematické.

Používejte funkce automatického vrácení zpět uvážlivě:

  • Některé nástroje CI/CD, jako je Azure DevOps, mají integrovanou 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 používat až po důkladném a pravidelném testování kanálu. Pokud se aktivuje automatické vrácení zpět, ujistěte se, že je váš kanál dostatečně zralý na to, aby mohl způsobit další problémy.
  • Musíte důvěřovat tomu, že automatizace nasazuje jenom nezbytné změny a že se aktivuje jenom v případě potřeby. Navrhněte aktivační události pečlivě tak, aby splňovaly tyto požadavky.

Při vracení zpět používejte funkce poskytované platformou. Například zálohy a obnovení k určitému bodu v čase můžou pomoct se zpětným vrácením úložiště a dat. 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 bezprostředně před incidentem.

Často testujte celou strategii omezení rizik selhání nasazení. Podobně 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ý jenom v případě, že je na něm váš tým vyškolený a pravidelně ho praktikuje. Testování chaosu a testování injektáže chyb mohou být efektivními technikami pro testování strategie omezení rizik nasazení.

Kompromis: Členové podpůrného týmu musí být schopni plnit své běžné povinnosti a také podporovat nouzové situace. Možná budete muset zvýšit počet zaměstnanců, abyste zajistili, že tým podpory bude mít správné personální obsazení a bude moct plnit všechny požadované povinnosti. Důkladně otestujte nasazení při nasazení do nižších vývojových prostředí. Tento postup vám pomůže odhalit chyby a chybné konfigurace předtím, než se dostanou do produkčního prostředí.

Usnadnění Azure

  • Azure Pipelines poskytuje služby sestavení a verze pro podporu CI/CD vašich aplikací.

  • Azure Test Plans je snadno použitelné řešení správy testů založené na prohlížeči. Toto řešení nabízí možnosti potřebné pro plánované ruční testování, uživatelské akceptační testování a průzkumné testování. Azure Test Plans také nabízí způsob, jak získat zpětnou vazbu od zúčastněných stran.

  • Azure Monitor je komplexní řešení monitorování pro shromažďování, analýzu a reagování na data monitorování z cloudových a místních prostředí. Monitorování zahrnuje robustní platformu pro upozorňování. Tento systém můžete nakonfigurovat pro automatická oznámení a další akce, jako je automatické škálování a další mechanismy samoopravení.

  • Application Insights je rozšíření monitoru, které poskytuje funkce monitorování výkonu aplikací (APM).

  • Azure Logic Apps je cloudová platforma pro spouštění automatizovaných pracovních postupů, které integrují aplikace, data, služby a systémy. Logic Apps můžete použít k vytvoření nové verze aplikace při každé aktualizaci. Azure udržuje historii verzí a může vrátit zpět nebo zvýšit úroveň jakékoli předchozí verze.

  • Mnoho databázových služeb Azure poskytuje funkci obnovení k určitému bodu v čase, která vám může pomoct, když potřebujete provést návrat zpět:

  • Azure Chaos Studio Preview je spravovaná služba, která s využitím techniky chaosu pomáhá měřit, pochopit a zlepšit odolnost vašich cloudových aplikací a služeb.

Kontrolní seznam efektivity provozu

Projděte si kompletní sadu doporučení.

Kontrolní seznam efektivity provozu