Velký třesk nebo kanárci — jak nasprávnou strategii nasazení změn?
Jak se ale něco takového mohlo stát? Vždyť to byla pouze aktualizace softwaru? Za prvé, v IT zásadně nepoužíváme slovo pouze. Nikdy nic není pouze. Za druhé, každá změna softwaru může způsobit velké problémy. I ta nejmenší, proto si musíme dávat pozor i u zdánlivě malých změn, které přináší aktualizace. Za třetí, z nějakého důvodu tým společnosti ignoroval základní zásady pro bezpečné změny. A za čtvrté, vzhledem k funkci, kterou software of CrowdStrike má — je součástí kyberbezpečnosti — je nutné pro změny vybrat vhodnou strategii nasazení softwaru.
Na poslední dva body se podíváme více zblízka. Nejprve si řekneme něco málo k zásadám nasazování a poté si představíme strategie, které mohou s updaty a upgrady výrazně pomoct. Nejprve tedy k těm zásadám.
Strategie jsou volitelné, zásady nikoliv 🎯
Tedy pokud se bavíme o zodpovědném přístupu ke změnám. Firma se samozřejmě může rozhodnout na všechno se vykašlat a prostě novou verzi nasadit. Následky jsou ale jasné.
To, co by nikdy v repertoáru programátorů a správců firemního IT nemělo chybět, je proces testování. Zpětná vazba ohledně funkčnosti a problémů je kritická pro zachování provozu. A vzhledem k tomu, že skoro všechny firmy jsou na IT závislé, jedná se nejen o zachování provozu IT systémů, ale vlastně přeneseně i celé firmy.
Také by mělo být pomalu zakázáno dělat změny v pátek, ještě hůře v pátek odpoledne nebo večer. Když nastanou problémy o víkendu, kdo to bude řešit? Kdo to bude chtít řešit? To je výzva hlavně pro manažery, kteří možná nedokážou vždy plně odhadnout, jak nebezpečné jsou jakékoliv velké zásahy do provozu před víkendem.
A když už se bavíme o volitelných strategiích, tak jsou spíše volitelně povinné. Ne každá je vhodná pro každou aplikace nebo typ změny. Je tedy nutné dobře vyhodnotit vlastnosti aplikace, dopad na fungování firmy a také požadavky, které má splnit.
Z čeho vybírat? 🤔
Zaměříme se nyní na 5 typů strategií. Tou první bude jednorázová, která nám poslouží jako benchmark, vůči kterému budeme zbylé 4 porovnávat.
🟦 Jednorázová strategie nasazení
Jak už napovídá její přezdívka — velký třesk — jedná se o postup, při kterém je v jednu chvíli kompletně pro všechny změna provedena.
Z její definice plynou také výhody. Je rychlá, levná, jednoduchá a nevyžaduje nějaké extra opatření. To vše ale platí pouze ve chvíli, kdy nenastane problém. Pokud se problém objeví, je docela problematické vrátit se na původní stabilní verzi. Může také dojít k přetížení infrastruktury a týmu podpory. Všichni najednou totiž budou chtít vyřešit, proč něco nefunguje.
Tato strategie je vysoce riziková a jak je vidět ze situace, které čelila společnost CrowdStrike, když problém nastane, je astronomický.
🟦 Segmentová strategie nasazení
Firma také může zvolit možnost rozdělit svou uživatelskou bázi do několika předdefinovaných segmentů. Ty mohou být děleny podle potřebného kritéria. Pak dojde k tomu, že jednotlivé segmenty postupně přejdou na novou verzi.
Z toho vyplývá, že je tento přístup méně rizikový. Nejen, že je jednodušší vrátit se zpět na stabilní verzi u segmentu, kde se vyskytl problém. Je ale také možné díky zpětné vazbě dělat úpravy, které riziko ještě zmenšují. Dopad na provoz je tak minimální.
Je ale pravdou, že spravovat segmenty v různých fázích může být pro projektový tým náročné. Navíc jednotlivé segmenty nemusí přesně zrcadlit chování všech uživatelů nebo problémy, kterým budou čelit. Není to tedy stoprocentní ochrana, ale tato strategie poskytuje jednu z největších ochran pro firmu.
🟦 A-B strategie nasazení
Při tomto postupu dojde k rozdělení uživatelů na dvě rovnoměrné skupiny. Jedna zůstane u původní verze A, druhá dostane novou verzi B. Díky tomu je možné porovnat, která lépe vyhovuje cílům firmy.
Tým může díky současnému běhu obou verzí provádět testování metrik a sběr dat. Ta pak mohou posloužit k nejpřesnějšímu rozhodování. Vzhledem k tomu, že verzi B má jen jedna část, je stále jednodušší vrátit se k původní variantě A.
Takový proces je ale velmi náročný na provoz. Nejen, že běží dvě varianty najednou, ale ještě je potřeba prostředky na analýzy metrik a sebraných dat. Infrastruktura je také komplikovanější, protože je nutné směrovat členy jednotlivých skupin na správné verze. Trvá to tedy déle, ale výsledkem je rozhodnutí na základě reálných dat.
Pouze je potřeba dát si pozor, aby skupina B byla vhodně vybrána a co nejlépe reprezentovala celou uživatelskou bázi.
🟦 Kanárková strategie nasazení
Tento proces spočívá v otestování nové verze na malé skupině „pokusných králíků“. Uživatelé jsou náhodně vybráni.
Malá skupina není zvolena náhodně. Je tím zrychlena smyčka zpětné vazby, takže může dojít ke svižnému řešení problémů. Jsou tím také minimalizována rizika, protože je jednodušší vrátit zpět na původní verzi malou skupinu, než velkou či všechny uživatele.
I tak je ale potřeba zvýšit náklady na provoz, protože stále nám jedou dvě skupiny vedle sebe. Zároveň samozřejmě pečlivost vede k prodloužení času na kompletní nasazení.
Díky tomuto principu se skvěle testuje připravenost nové verze.
🟦 Fázová strategie nasazení
Jak už název napovídá, při této změně se předem uživatelé rozdělí do jednotlivých fází. Každá zahrnuje větší část než ta předchozí. Nasazení změn je tedy postupné.
Díky malým začátkům se minimalizuje riziko problémů, protože se nejprve změny zkouší na malém vzorku. Díky tomu je také zmenšena smyčka zpětné vazby a je možné dobře případné problémy a návraty řešit. Navíc má tento přístup výhodu v tom, že se také testuje i škálovatelnost.
Samozřejmě ale kvůli tomu trvá nasazení déle. Také jen nutné počítat s komplikovanější správou řešení přechodu a komunikací. Zároveň je potřeba dobře naplánovat i rozšiřování infrastruktury.
Alternativní historie 🕰️
Když se nyní podíváme na situaci s aplikací Falcon, je vidět, kde se chyby staly. Také bychom možná dokázali odhadnout, která strategie by v tomto případě tak kritického softwaru byla vhodnější volbou. Není ale potřeba plakat nad rozlitým mlékem. Spíše se z tohoto velkého fiaska poučit.
