Postupy bezpečného nasazení

Někdy vydání neodpovídá očekáváním. Přestože používáte osvědčené postupy a předáváte všechny brány kvality, občas dochází k problémům, které vedou k produkčnímu nasazení, což pro uživatele způsobuje nepředvídatelné problémy. Aby se minimalizoval a zmírňoval dopad těchto problémů, týmy DevOps se doporučuje přijmout strategii progresivní expozice , která vyrovnává vystavení dané verze s jeho ověřeným výkonem. Jak se verze prokáže v produkčním prostředí, bude dostupná pro vrstvy širších cílových skupin, dokud ji všichni nepoužívají. Týmy můžou používat postupy bezpečného nasazení, aby maximalizovaly kvalitu a rychlost vydávání verzí v produkčním prostředí.

Řízení expozice zákazníkům

Týmy DevOps můžou využívat různé postupy k řízení vystavení aktualizací zákazníkům. V minulosti bylo testování A/B oblíbenou volbou pro týmy, které chtějí zjistit, jak různé verze služby nebo uživatelského rozhraní fungují proti cílovým cílům. Testování A/B je také poměrně snadné, protože změny jsou obvykle menší a často porovnávají různé verze pouze na hraničních zařízeních služby, které jsou na straně zákazníka.

Sejf nasazení prostřednictvím okruhů

S růstem platforem je potřeba rozšířit i škálování infrastruktury a cílovou skupinu. Tím se vytvoří poptávka po modelu nasazení, který vyrovnává rizika spojená s novým nasazením s výhodami aktualizací, které slibuje. Obecně platí, že daná verze by měla být nejprve vystavena pouze malé skupině uživatelů s nejvyšší odolností vůči riziku. Pokud pak verze funguje podle očekávání, může být zpřístupněna širší skupině uživatelů. Pokud nedojde k žádným problémům, proces může pokračovat v širších skupinách uživatelů nebo okruhů, dokud všichni nebudou používat novou verzi. Díky moderním platformám průběžného doručování , jako jsou GitHub Actions a Azure Pipelines, je vytváření procesu nasazení s okruhy přístupné týmům DevOps libovolné velikosti.

Hlavní příznaky

Některé funkce je někdy potřeba nasadit jako součást vydané verze, ale ne na začátku vystavené uživatelům. V těchto případech příznaky funkcí poskytují řešení, ve kterém se funkce můžou povolit prostřednictvím změn konfigurace na základě prostředí, okruhu nebo jakéhokoli jiného konkrétního nasazení.

Výslovný souhlas uživatele

Podobně jako příznaky funkcí poskytuje výslovný souhlas uživatele způsob, jak omezit vystavení. V tomto modelu je daná funkce povolená ve vydané verzi, ale není aktivována pro uživatele, pokud ji výslovně nechce. Rozhodnutí o odolnosti proti riziku se uživatelům přesměruje, aby se mohli rozhodnout, jak rychle chtějí určité aktualizace přijmout.

Současně se používá více postupů. Například tým může mít experimentální funkci určenou pro velmi konkrétní případ použití. Vzhledem k tomu, že je rizikový, nasadí ho do prvního okruhu, aby si ho interní uživatelé vyzkoušeli. I když jsou ale funkce v kódu, bude muset někdo nastavit příznak funkce pro konkrétní nasazení v okruhu tak, aby byla funkce zpřístupněna prostřednictvím uživatelského rozhraní. I potom může příznak funkce vystavit možnost, aby se uživatel přihlásil k používání nové funkce. Nikdo, kdo není v okruhu, v daném nasazení nebo se k této funkci nepřihlásil, se nezveření. I když se jedná o poměrně přesvědčivý příklad, slouží k ilustraci flexibility a praktičnosti progresivní expozice.

Běžné problémy, se kterým týmy čelí dříve

S tím, jak se týmy pohybují k agilnějším postupům DevOps, můžou narazit na problémy konzistentní s ostatními, kteří migrovali mimo tradiční monolitické dodávky. Týmy, které se používají k nasazení jednou za několik měsíců, mají na paměti, že se zasadí do vyrovnávací paměti pro stabilizaci. Očekávají, že každé nasazení přinese zásadní posun ve své službě a že dojde k nepředvídatelným problémům.

Datové části jsou příliš velké.

Služby nasazené každých několik měsíců jsou obvykle vyplněny mnoha změnami. Tím se zvyšuje pravděpodobnost, že dojde k okamžitým problémům, a také ztěžuje řešení těchto problémů, protože existuje tolik nových věcí. Přechodem na častější dodávky se rozdíly v nasazených nasazeních zmenší, což umožňuje zaměřit se na testování a snadnější ladění.

Žádná izolace služby

Monolitické systémy se tradičně škálují vyrovnáním hardwaru, na kterém jsou nasazené. Pokud se ale s instancí něco pokazí, vede to k problémům pro všechny. Jedním jednoduchým řešením je přidat více instancí, abyste mohli vyrovnávat zatížení uživatelů. To ale může vyžadovat významné aspekty architektury, protože řada starších systémů není sestavená tak, aby byla více instancí. Navíc může být potřeba přidělit významné duplicitní prostředky pro funkce, které mohou být lépe konsolidované jinde.

Při přidání nových funkcí prozkoumejte, jestli vám architektura mikroslužeb může pomoct pracovat a škálovat díky lepší izolaci služeb.

Ruční kroky vedou k chybám

Když tým nasadí jen párkrát ročně, nemusí se automatizace dodávek zdát za investici. V důsledku toho se mnoho procesů nasazení spravuje ručně. To vyžaduje značné množství času a úsilí a je náchylné k lidské chybě. Jednoduchá automatizace nejběžnějších úloh sestavení a nasazení může trvat dlouhou cestu ke zkrácení doby ztráty a nevynucených chyb.

Týmy mohou také využívat infrastrukturu jako kód , aby měly lepší kontrolu nad prostředími nasazení. Tím se eliminuje potřeba žádostí provoznímu týmu, aby provedl ruční změny, protože se do různých prostředí nasazení zavádějí nové funkce nebo závislosti.

Nasazení můžou provádět pouze operace.

Některé organizace mají zásady, které vyžadují, aby všechna nasazení byla inicializována a spravována provozními zaměstnanci. I když v minulosti mohlo dojít k dobrým důvodům, proces Agile DevOps výrazně přináší výhody, když může vývojový tým zahájit a řídit nasazení. Moderní platformy průběžného doručování nabízejí podrobnou kontrolu nad tím, kdo může zahájit nasazení a kdo může přistupovat k protokolům stavu a dalším diagnostickým informacím a zajistit, aby správné lidi měli co nejrychleji správné informace.

Pokračujte chybná nasazení a nejde je vrátit zpět.

Někdy se nasazení pokazí a týmy ho musí vyřešit. Pokud jsou ale procesy ruční a přístup k informacím je pomalý a omezený, může být obtížné vrátit se k předchozímu funkčnímu nasazení. Naštěstí existují různé nástroje a postupy pro zmírnění rizika neúspěšných nasazení.

Základní principy

Týmy, které chtějí přijmout postupy bezpečného nasazení, by měly nastavit některé základní principy pro podporu úsilí.

Být konzistentní

Stejné nástroje, které se používají k nasazení v produkčním prostředí, by se měly používat ve vývojových a testovacích prostředích. Pokud dojde k problémům, jako jsou problémy, které často vznikají z nových verzí závislostí nebo nástrojů, měly by být zachyceny dobře předtím, než se kód blíží vydání do produkčního prostředí.

Péče o kvalitní signály

Příliš mnoho týmů spadá do společné pasti, že se opravdu nezajímá o kvalitní signály. V průběhu času mohou zjistit, že zapisují testy nebo přebírají úlohy kvality, jednoduše změní žluté upozornění na zelené schválení. Signály kvality jsou opravdu důležité, protože představují impuls projektu. Signály kvality používané ke schvalování nasazení by se měly každý den sledovat nepřetržitě.

Nasazení by měla vyžadovat nulový výpadek.

I když není důležité, aby všechny služby byly vždy dostupné, měly by týmy přistupovat ke fázím doručování a provozu DevOps s ohledem na to, že můžou a měly by nasazovat nové verze, aniž by je musely kdykoliv vypnout. Moderní infrastruktury a nástroje kanálu jsou teď dostatečně pokročilé, kde je možné, aby prakticky jakýkoli tým cílil na 100% dobu provozu.

Nasazení by se měla provést během pracovní doby.

Pokud tým pracuje s myšlením, že nasazení vyžadují nulový výpadek, nezáleží na tom, kdy se nasazení odešle. Navíc se stává výhodné nabízet nasazení během pracovní doby, zejména brzy v den a brzy v týdnu. Pokud se něco nepovede, mělo by být trasováno dostatečně brzy, aby bylo možné ovládat poloměr výbuchu. Navíc už všichni budou pracovat a budou se soustředit na opravení problémů.

Nasazení založené na okruhu

Týmy s vyspělými postupy vydávání verzí DevOps jsou v pozici, která umožňuje nasazení založené na okruhu. V tomto modelu se nejprve zavádí nové funkce zákazníkům, kteří chtějí přijmout největší riziko. Jak se nasazení osvědčilo, cílová skupina se rozšíří, aby zahrnovala více uživatelů, dokud ho všichni nepoužívají.

Příklad kruhového modelu

Typický model nasazení okruhu je navržený tak, aby co nejdříve našel problémy prostřednictvím pečlivého segmentace uživatelů a infrastruktury. Následující příklad ukazuje, jak okruhy používají hlavní tým Microsoftu.

Kruh	Účel	Uživatelé	Datové centrum
0	Vyhledá většinu chyb ovlivňujících uživatelem zavedených nasazením.	Pouze interní, vysoká tolerance vůči rizikům a chybám	USA – středozápad
0	Oblasti, které tým neprovádí rozsáhlé testování	Zákazníci, kteří používají šířku produktu	Malé datové centrum
2	Problémy související se škálováním	Veřejné účty, ideálně bezplatné, s využitím různorodé sady funkcí	Střední nebo velké datové centrum
3	Problémy s škálováním v interních účtech a mezinárodních problémech souvisejících s	Velké interní účty a evropské zákazníky	Interní datové centrum a evropské datové centrum
4	Zbývající jednotky škálování	Všichni ostatní	Všechny cíle nasazení

Povolit pečení času

Termín bake time odkazuje na dobu, po kterou může nasazení běžet před rozšířením na další okruh. Některé problémy mohou trvat hodiny nebo déle, než se začnou projevovat příznaky, takže vydání by mělo být používáno po určitou dobu, než bude považováno za připravené.

Obecně platí, že 24hodinový den by měl být dostatek času pro většinu scénářů k zveřejnění latentních chyb. Toto období by však mělo zahrnovat období využití ve špičce, které vyžaduje celý pracovní den, pro služby, které špičky během pracovní doby.

Urychlení oprav hotfix

K incidentu živého webu (LSI) dochází, když má chyba závažný dopad v produkčním prostředí. LSI vyžadují vytvoření opravy hotfix, což je mimosílová aktualizace navržená tak, aby řešila problém s vysokou prioritou.

Pokud je chyba sev 0, nejvýraznější typ chyby, může být oprava hotfix nasazena přímo do ovlivněné jednotky škálování co nejrychleji. I když je důležité, aby oprava nezhoršovala věci, chyby této závažnosti jsou považovány za tak rušivé, že je nutné je okamžitě vyřešit.

Chyby s hodnocením Sev 1 musí být nasazeny prostřednictvím okruhu 0, ale je možné je nasadit do ovlivněných jednotek škálování ihned po schválení.

Opravy hotfix pro chyby s nižší závažností musí být nasazeny prostřednictvím všech okruhů podle plánu.

Klíčové poznatky

Každý tým chce poskytovat aktualizace rychle a s nejvyšší možnou kvalitou. Díky správným postupům může být dodání produktivní a bezbolestnou součástí cyklu DevOps.

• Nasazovat často.
• Zůstaňte v průběhu sprintu zeleně.
• Používejte konzistentní nástroje pro nasazení ve vývoji, testování a produkčním prostředí.
• Použijte platformu pro průběžné doručování, která umožňuje automatizaci a autorizaci.
• Dodržujte postupy bezpečného nasazení.

Další kroky

Zjistěte, jak příznaky funkcí pomáhají řídit vystavení nových funkcí uživatelům.