Jediné kliknutí často dělí stabilní systém od katastrofy za miliony dolarů. Analýzy ukazují, že většina výpadků nevzniká vlivem vnějších útoků, ale v důsledku interních chyb při nasazování změn do prostředí, o kterém nemají týmy dostatečný přehled. Zjistěte, proč je change management nezbytnou záchrannou sítí pro ICT infrastrukturu a jak minimalizuje riziko a chybovost a dopad.
Implementace změn vyžaduje plán
V ICT ekosystému může mít i mikroskopická změna nelineární dopady. DevOps inženýři tomu říkají „deployment anxiety,“ ten moment těsně po stisknutí Enteru, kdy sledujete logy a čekáte, jestli se grafy zazelenají, nebo jestli se produkční databáze začne hroutit pod náporem chyb.
Statistiky nám bohužel nedávají příliš důvodů ke klidu. Analytici z Gartneru dlouhodobě upozorňují na fakt, že až 80 % kritických výpadků služeb není způsobeno sofistikovaným kybernetickým útokem nebo selháním hardwaru. Viníkem jsme my. Respektive naše vlastní změny, které nebyly dostatečně otestovány, zdokumentovány nebo byly nasazeny do prostředí, o kterém jsme si mylně mysleli, že ho známe. Ke zmírnění dopadů změn a hladký přechod proto firmy implementují change management.
Co to vlastně je change management?
Když mluvíme o IT change managementu (řízení změn), nejde o abstraktní filozofii. V jádru jde o standardizovaný proces, jak bezpečně a efektivně provést jakoukoliv úpravu v IT infrastruktuře, ať už jde o instalaci nového serveru, patchování OS nebo nasazení nové verze aplikace.
Zjednodušeně řečeno je to ochranná vrstva mezi vývojem a stabilním provozem. Jde o soubor pravidel a kroků, který zajišťuje, že:
- Víme, co se mění a proč.
- Chápeme, jaké to má dopady na zbytek systému.
- Máme plán B, když se něco pokazí.
- Všichni, kterých se to týká, o tom vědí.
Nejde tedy o to zakázat změny, ale o to vnést do nich řád.
Change management je zkrátka jen jednou z klíčových disciplín širšího rámce řízení IT služeb (ITSM), který se zaměřuje na systematický přístup ke správě a provozu IT služeb jako celku.
Proč automatizovat řízení změn?
Pokud při slovech change management stále vidíte partu manažerů v zasedačce, kteří jednou týdně procházejí stohy papírů a hledají důvody, proč zamítnout nasazení nové verze aplikace, možná byste měli svůj pohled aktualizovat. Model tohoto gatekeepera je v době CI/CD pipelines, kontejnerizace a mikroslužeb zapomenutý. Pokud nasazujete kód dvacetkrát denně, nemůžete čekat na týdenní schvalovací komisi.
Systém change managementu musí být schopen rozlišit:
- Standardní změnu: Automatický update virové databáze nebo restart kontejneru? To by měl řešit skript bez lidského zásahu.
- Normální změnu: Migrace databáze na nový cluster? Zde už potřebujeme plán návratu a validaci.
- Urgentní změnu: Produkce stojí a my musíme aplikovat hotfix přímo do živého systému. Právě zde vzniká největší technologický dluh, pokud se zpětně nedohledá, co přesně se změnilo.
Když se změny vymknou z ruky
Abychom pochopili, co se stane, když se proces změny odtrhne od reality infrastruktury, podívejme se na technickou pitvu pádu společnosti Knight Capital Group.
V roce 2012 tato firma nasazovala nový software pro vysokofrekvenční obchodování (HFT). Součástí updatu bylo i opětovné využití starého softwarového „flagu“ (přepínače v kódu), který dříve sloužil k testování. Technik nasadil nový kód na sedm serverů. Na osmý server ale, zřejmě kvůli chybějící automatizaci nebo lidskému selhání, zapomněl.
Sedm serverů interpretovalo signál správně. Osmý server, běžící na starém kódu, interpretoval příkaz jako „nakupuj agresivně bez limitu“. Během 45 minut vygeneroval tento jediný „zapomenutý“ server ztrátu 440 milionů dolarů.
Technicky vzato nešlo o chybu v novém kódu. Šlo o diskrepanci mezi tím, co si change management myslel, že spravuje, a tím, co běželo v ostrém provozu.
Nemůžete řídit to, co nevidíte
IT change management je slepý, pokud není pevně integrován s IT asset managementem.
Představte si reálný scénář: Chystáte se vypnout starou verzi API, kterou podle dokumentace už nikdo nepoužívá. Jenže bez mapy vztahů nevidíte, že na tom starém API visí jeden zapomenutý legacy skript v logistice. Vy nasadíte změnu, servery běží, monitoring je zelený, ale kamiony ve skladu stojí, protože se přestaly tisknout dodací listy.
Vztah mezi těmito disciplínami je proto symbiotický:
- Analýza dopadu změn: Než schválíte update knihovny OpenSSL, musíte vědět, na kterých všech serverech a v jakých aplikacích se tato knihovna nachází a co to ovlivní. Bez ITAM dat je to jen kvalifikované hádání.
- Licenční shoda: Přidání virtuálních procesorů (vCPU) pro zvýšení výkonu je technicky triviální změna na dvě kliknutí. Licenčně to ale může znamenat porušení smlouvy s Oracle nebo Microsoftem a pokutu v řádech milionů.
Data z trhu ukazují, že tento nesoulad má i čistě finanční dopady. Reporty (např. SaaS Management Index od Zylo) naznačují, že firmy plýtvají v průměru 49 % rozpočtu na software, jelikož ho nikdo nepoužívá, nebo o něm IT oddělení ani neví.
Začněte implementovat change management
Tabulky v Excelu a manuální kontrola přestávají stačit, jakmile infrastruktura překročí určitou míru komplexity. Konfigurace se mění příliš rychle a závislosti mezi systémy jsou příliš hluboké. Úspěšné organizace dnes chápou, že správa majetku a řízení změn nejsou dvě oddělené disciplíny, ale dvě strany téže mince. Ve výsledku totiž platí jednoduchá rovnice: stabilní IT není to, které se nemění. Je to to, které má o svých změnách a IT aktivech dokonalý přehled.
Zdroj obrázku: / stock.adobe.com
