Sdílet prostřednictvím

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

  • Článek

Platí pro toto doporučení kontrolního seznamu provozní efektivity architektury Azure Well-Architected Framework:

OE:12 Implementujte strategii pro zmírnění selhání nasazení, která řeší neočekávané problémy se středním zavedením při rychlém obnovení. Zkombinujte několik přístupů, jako je vrácení zpět, zákaz funkcí nebo použití nativních funkcí modelu nasazení.

Tato příručka popisuje doporučení pro návrh standardizované strategie pro efektivní zvládnutí selhání nasazení. Stejně jako jiné problémy s úlohami jsou selhání nasazení nevyhnutelné součástí životního cyklu úloh. S tímto myšlením můžete být proaktivní díky dobře navržené a záměrné strategii pro řešení selhání nasazení. Taková 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 chaosům a potenciálně škodlivým reakcím na problémy, které mohou významně ovlivnit týmovou a organizační soudržnost, důvěru zákazníků a finance.

Klíčové strategie návrhu

Občas i přes vyspělost vašich postupů vývoje dochází k problémům s nasazením. Použití bezpečných postupů 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.

Při použití modelu postupného nasazení expozice jako standardního postupu:

  • Máte správný základ pro minimalizaci dopadů na zákazníky nebo interní uživatele v případě selhání nasazení.
  • Problémy můžete efektivně zmírnit.

Strategie pro 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 několik forem, jako jsou neúspěšné orientační testy, problémy nahlášené uživatelem nebo výstrahy, které vaše monitorovací platforma generuje.

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

  3. Zmírnění: Provedete identifikovanou akci zmírnění rizik. Zmírnění rizik může mít formu náhradní funkce, vrácení zpět, vrácení zpět, vrácení vpřed nebo použití konfigurace modulu runtime k obejití funkce vypnutí.

  4. Komunikace: Účastníci a ovlivnění koncoví uživatelé si musí být vědomi stavu, když zjistíte a projdete problém podle toho, jak to vyžaduje plán reakce na tísňové volání.

  5. Postmortem: Postmortems bez obviňování poskytují týmům úloh příležitosti k identifikaci oblastí pro zlepšení a vytváření plánů pro aplikování učení.

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

Mechanismy detekce selhání návrhu

K rychlé identifikaci problémů s nasazeními potřebujete robustní postupy testování a pozorovatelnosti v souvislosti s nasazeními. Pokud chcete rychle detekovat anomálie, můžete monitorování úloh a upozorňování doplnit pomocí následujících kroků:

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

Orientační testování a další testování kvality by se měly provádět v každé fázi zavádění. Úspěšné testy v jedné skupině nasazení by neměly ovlivnit rozhodování o testování v následující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 každém okamžiku nasazení může běžet více konfigurací napříč 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 úplný tým podpory. Ujistěte se, že jsou pracovníci podpory vyškoleni, jak eskalovat problémy s nasazením pro správné směrování. Eskalace by měla odpovídat plánu reakce na tísňové volání úloh.

Rozhodnutí o strategii pro zmírnění rizik

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

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

    Pokud používáte modrý-zelený model, vrácení zpět je praktičtější než vrácení zpět. Přenosy můžete snadno přesunout zpět do zásobníku, který spouští konfiguraci, která se neaktualizuje. Problém pak můžete opravit v problematickém prostředí a zkusit nasazení znovu v příslušné době.

  • 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 návratu.
    • Vraťte se zpět, když opravíte chybný kód.

  • Úroveň úsilí potřebné k implementaci opravy v kódu.

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

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

    Úlohy kritické pro chod firmy by se měly vždy nasazovat souběžným způsobem, například v modrém modelu, aby se dosáhlo nasazení s nulovými výpadky. V důsledku toho je pro tyto typy úloh vhodnější strategie zmírnění rizik.

  • 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 být v budoucnu vhodné, protože zahrnuje aktualizaci infrastruktury. Naopak vrácení zpět nebo vrácení zpět může dávat smysl, když používáte neměnnou infrastrukturu.

Bez ohledu na to, jaké volby uděláte, byste měli do rozhodovacího procesu zahrnout příslušná schválení a rozlišovat je ve vašem rozhodovacím stromu.

Implementace strategie pro zmírnění 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 dobrého stavu konfigurace.

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

    Vrácení zpět může být složité, zejména když souvisí se změnami dat. Změny schématu můžou riskovat vrácení zpět. Jejich bezpečné provádění může vyžadovat značné plánování. Obecně doporučujeme, aby aktualizace schématu byly doplňkové. Neměly by se nahrazovat změny – záznamy by neměly být nahrazeny 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 bezpečné odebrat zastaralé záznamy.

  • Náhradní: V záložním scénáři se aktualizované systémy odeberou ze směrování produkčního provozu. 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ést další přerušení.

    U kanárských nasazení nemusí být návrat 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í pro zvládnutí zatížení systémů, které se neaktualizují, proveďte toto škálování před návratem.

  • Obejít funkci přesměrování: 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 zavádění 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 tuto kompromisu sdělit zúčastněným stranám. Účastníci by měli schválit průběžný plán. Zúčastněné strany musí určit dobu, kterou lze tolerovat pro provoz v degradovaném stavu. Musí také zvážit toto určení podle vašeho odhadu času potřebného k vyřešení chybného kódu a jeho nasazení.

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

    Stejně jako u jakéhokoli jiného kódu musí opravy hot projít postupy bezpečného nasazení. S horkou opravou se ale časová osa výrazně urychlí. Ve svých prostředích potřebujete použít strategii povýšení kódu. Také je potřeba 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 po nasazení můžete spouštět úplné testy aktualizovaného kódu co nejdříve. Automatizace testování kontroly kvality do vysokého stupně pomáhá efektivně testovat v těchto scénářích.

Kompromisy:

  • Schopnost vrátit se obvykle znamená, že potřebujete dostatečnou kapacitu infrastruktury pro zpracování dvou verzí konfigurace úloh současně. Týmy úloh také musí být schopny podporovat dvě verze v produkčním prostředí současně.
  • 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.

Standardizace aktualizací stavu během incidentu

Je důležité mít jasně definované komunikační povinnosti, které pomáhají minimalizovat chaos během incidentů. Tyto povinnosti by měly stanovit, jak tým úloh spolupracuje s týmy podpory, zúčastněnými stranami a pracovníky týmu pro reakce na tísňové volání, jako je například vedoucí reakce na tísňové volání.

Standardizujte tempo, které tým úloh sleduje za poskytování aktualizací stavu. Zajistěte, aby účastníci věděli o tomto standardu, aby věděli, kdy mají očekávat aktualizace.

Pokud tým úloh potřebuje komunikovat přímo s koncovými uživateli, upřesněte typ informací a úroveň podrobností, které jsou vhodné pro sdílení s uživateli. S týmem úloh také komunikujte o dalších požadavcích, které se na tyto případy vztahují.

Provedení posmrtných incidentů

Postmortems by měly bez výjimky dodržovat všechna neúspěšná nasazení. Každé neúspěšné nasazení je příležitostí pro výuku. Postmortems vám může pomoct identifikovat slabá místa v procesech nasazení a vývoje. Kromě mnoha dalších možností můžete také identifikovat chybné konfigurace ve vaší infrastruktuře.

Postmortems by měly být vždy bez viny, aby se jednotlivci, kteří jsou zapojeni do incidentu, cítili v bezpečí, když sdílejí své perspektivy o tom, co je možné zlepšit. Vedoucí pracovníci postmortem by měli postupovat podle plánů implementace zjištěných vylepšení a přidání těchto plánů do backlogu úloh.

Zprovoznění procesů zmírnění rizik

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

Udržujte konzistenci s rovinami správy a dat při vrácení zpět nebo dopředu. Klíče, tajné kódy, data o stavu databáze a konfigurace, které jsou specifické pro prostředky a zásady, musí být v rozsahu a musí být započítány. Věnujte například pozornost návrhu škálování infrastruktury v posledním známém dobrém nasazení. Určete, jestli při opětovném nasazení kódu potřebujete tuto konfiguraci upravit.

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

Proveďte analýzu režimu selhání (FMA) v kanálech kontinuální integrace a průběžného doručování (CI/CD), které pomáhají identifikovat problémy, které můžou komplikovat zmírnění rizik. Stejně jako u celé úlohy je možné kanály analyzovat a identifikovat oblasti, které můžou být problematické při pokusu o daný typ zmírnění.

Použití automatizovaných funkcí vrácení zpět s ohledem na to:

  • Některé nástroje CI/CD, jako je Azure DevOps, mají integrované funkce automatického vrácení zpět. Tuto funkci zvažte, pokud vám poskytuje hmatatelnou hodnotu.
  • Funkci automatického vrácení zpět byste měli přijmout až po důkladném a pravidelném otestování kanálu. Ujistěte se, že váš kanál dostatečně zralý, aby mohl při aktivaci automatického vrácení zpět zavést další problémy.
  • Potřebujete důvěřovat tomu, že automatizace nasadí jenom potřebné změny a že se aktivuje jenom v případě potřeby. Navrhněte triggery pečlivě tak, aby splňovaly tyto požadavky.

Během vrácení zpět používejte funkce poskytované platformou. Zálohy a obnovení k určitému bodu v čase můžou například pomoct se zpětnými vrácením dat a úložištěm 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í na kontrolní bod, který je bezprostředně před incidentem.

Často otestujte celou strategii zmírnění rizik selhání nasazení. Stejně jako plány reakcí na tísňové volání 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 vytrénovaný a pravidelně ho praktikuje. Chaos engineering and fault injection testing can be effective techniques for testing your deployment mitigation strategy.

Kompromis: Členové týmu podpory musí být schopni plnit své běžné povinnosti a také podporovat nouzové situace. Možná budete muset zvýšit počet hlav, abyste zajistili, že je tým podpory správně obsazený a schopný provádět všechny požadované povinnosti. Důkladně otestujte nasazení při nasazování 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 vydávání, které podporují CI/CD vašich aplikací.

  • Azure Test Plans je řešení pro správu testů založené na prohlížeči, které se snadno používá. Toto řešení nabízí možnosti potřebné pro plánované ruční testování, testování přijetí uživatelů a průzkumné testování. Azure Test Plans také nabízí způsob, jak shromáždit 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 monitorování dat z cloudu 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í monitorování, 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 nebo zvýšit úroveň jakékoli předchozí verze.

  • Mnoho databázových služeb Azure poskytuje funkce obnovení k určitému bodu v čase, které vám můžou pomoct, když potřebujete vrátit zpět:

  • Azure Chaos Studio Preview je spravovaná služba, která využívá přípravu chaosu, která vám pomůže měřit, pochopit a zlepšit odolnost cloudových aplikací a služeb.

Kontrolní seznam pro efektivitu provozu

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

Kontrolní seznam pro efektivitu provozu