Proč upgrade není rutina – reálné katastrofy a jejich dopady
Toto pravidlo platí z jednoho prostého důvodu. I taková věc, jakým je běžná aktualizace aplikace nebo systému, může způsobit kolaps provozu, reputační škody, právní důsledky nebo masivní finanční ztráty.
U změn totiž existuje riziko, že se nová nastavení nepohodnou s těmi starými. Problémy nastaly ve vesmíru, na nebi, na zemi, na silnicích, v bankách, na burzách, v UI i back-end prostředí, na koncových zařízeních, v sítích, v kontrolních systémech, v operačních systémech, na lékařském vybavení a dokonce i v armádě. Zajímavé vysvětlení 25 zvláštních chyb najdete v tomto videu.
Tento potenciální problém se prostě nevyhýbá nikomu. Z potenciálu se ale nutně nemusí stát realita. Jen je k tomu zapotřebí, aby byli všichni ve firmě na stejné vlně, pokud jde o pochopení hodnoty validačních a preventivních kroků v procesech, které se týkají upgradů a updatů.
V tomto článku se zaměříme na několik slavných chyb spojených s upgrady a updaty systémů, které měly katastrofální následky. Ukážeme si, proč k problému došlo a co jako zákazníci můžeme dělat, abychom minimalizovali následky, když se něco poskytovateli nepovede.
Nenechme se totiž mýlit. Chyby se dít budou a velká část zodpovědnosti za zajištění business continuity naší firmy leží na našich bedrech, ne na bedrech dodavatelů a poskytovatelů služeb.
Odstrašující příklady známé i neznámé
Rogers Communications – červenec 2022
Kanadský poskytovatel telekomunikačních služeb Rogers narazil na problém při několikakrokém updatu hlavní sítě. Na 5 dní tak jejich zákazníkům vypadl internet a mobilní síť.
Následky nebyly vůbec malé, protože například nefungovaly platby kartou, lidé nemohli volat na tísňovou linku a malé firmy akumulovaly ztráty v tisících kanadských dolarů.
Vzhledem k tomu, že v Kanadě je situace podobná jako u nás, na telekomunikačním trhu funguje jen hrstka velkých poskytovatelů, hlavně pokud se bavíme o mobilních sítích.
Můžeme tedy předpokládat, že k podobnému incidentu a obdobným následkům může dojít i u nás. Jak se tedy připravit?
Získané poznatky
- I základní služba může selhat nebo zažít výpadek. Je vhodné předpokládat, že žádný systém ani žádná služba nejsou imunní vůči chybám. Proto by firmy měly mít zpracované funkční plány pro obnovu po havárii (disaster recovery plan), aby věděly, co přesně v dané situaci dělat.
- Připojení k internetu a mobilní síti by firma měla mít kryté náhradním plánem. Řešením může být záložní připojení k jinému poskytovateli nebo například SIM karty od jiného operátora.
CrowdStrike - červenec 2024
Tento problém byl nešťastný v tom, že systém Falcon slouží ke kyberochraně a používají ho především kritické systémy. Ačkoli se společnosti CrowdStrike povedlo vše vyřešit v řádu desítek minut, pro zasažené firmy to byl problém na mnohem déle.
Hlavně kvůli tomu, že každý jednotlivý Windows systém zasažený chybnou aktualizací bylo nutné spustit v nouzovém režimu a zadat klíče pro obnovu. Vše manuálně.
Získané poznatky
- Aktualizace kritického systému by měla být dobře naplánovanou aktivitou. Je nutné mít připravená opatření v případě, že bude nutné manuálně zasáhnout, pokud se aktualizace nepovede.
- Pokud je to možné, je vhodné vyzkoušet novou aktualizaci na vzorku systémů. Jakmile je ověřena její funkčnost, pak je možné přistoupit k dalším fázím.
- Ztráta funkčnosti kritického systému znamená pro firmy a organizace neschopnost fungovat. To zase znamená náklady navíc a výpadek příjmu. Pro takovou situaci je potřeba mít plán a záložní infrastrukturu, aby se minimalizovala doba výpadku.
Royal Bank of Scotland – červen 2012
Jsme zvyklí, že internetové bankovnictví funguje bez problémů. Platby odchází, platby přichází a na svém kontě vždy vidíme skutečná čísla. Jenže v Británii se vlivem rozbitého časového plánu všechno tohle sesypalo na hromadu.
Několik dní byl systém naprosto mimo provoz. Lidé a firmy neměli přístup ke svým financím, neodcházely pravidelné platby, úvěrové skóre trpělo.
Banka samotná toto nepřiznala, ale někteří odborníci vinili outsourcing IT, který nahradil tým interních techniků. Vidina 80% úspor mohla být příliš lákavá.
Ať už byla příčina jakákoli, výpadky bank se od té doby staly relativně běžnou součástí našich životů. Jak s nimi nakládat?
Získané poznatky
- Není dobré mít všechny finanční prostředky na jednom místě. Vhodné je také zvážit, jak velkou rezervu v hotovosti byste měli držet. Vypadnout totiž nemusí pouze bankovní systém, ale například platební terminály.
Polygon – červenec 2025
Ani distribuovaný krypto svět není imunní vůči chybám. Jedna z vrstev v poslední době procházela velkým upgradem. Následkem byl nesoulad v datech, který vedl k omezení funkčnosti některých aplikací.
Ačkoli Bor, Polygon blockchain, zůstal plně funkční, některé aplikace narážely na zamrzlé bloky. Uživatelé tak nevěděli, čeho se vlastně výpadek týká a samozřejmě se s tímto problémem svezla i cena tokenu.
Získané poznatky
- Je nutné si předem vykomunikovat s dodavatelem nebo poskytovatelem SLA, která zahrnuje i pravidla komunikace. Pokud tedy dojde k jakémukoli výpadku, měli byste být jako zákazníci co nejdříve informováni.
- Zvažte, zda není bezpečným krokem zajistit si různorodé poskytovatele RPC kanálu. Při výpadku polygonu nebyli všichni stejně ovlivněni.
Co si tedy odnést?
Na první pohled se může zdát, že upgrady a aktualizace přinášejí jen problémy. Že je lepší je neinstalovat. Jenže takový přístup vede zase k jiným problémům. Spíše je potřeba mít na nové verze správný pohled a připravit zdravý plán, jak k nim přistupovat tak, aby neochromily vaši firmu.
Redundance je princip, který vám může ušetřit spoustu problémů. Jedná se o záložní varianty v případě, že některý prvek vašeho provozu vypadne. Může se jednat o druhou konektivitu, multicloud, software, nebo aplikaci, prostě o cokoli, co je pro provoz vaší organizace klíčové.
Zároveň zvažte plusy a mínusy vendor lock-inu, protože závislost na jednom dodavateli vás vystavuje většímu riziku náchylnosti k výpadkům.
Když už se bavíme o dodavatelích, nejsou jediní, kteří by se měli zasadit o to, že všechno běží hladce. Jak oni, tak i vy jako zákazníci si musíte pohlídat záložní řešení pro případ, že dojde k výpadku.
A jako vždy se opět dostáváme k business continuity a disaster recovery plánům. Za každých okolností musí být vaše firma schopná fungovat alespoň v minimálním provozním režimu. To znamená, že musíte být schopní zachovat kritické aktivity provozu.
Oba tyto plány slouží k přípravě alternativ, u kterých je ale nanejvýš důležité, aby byly spravovány a pravidelně testovány.
Co byste jako IT decision-maker měli vyžadovat?
U klíčových systémů si od svého dodavatele předem vyžádejte informace ke změnám, které chystají. Tyto informace vám pomůžou co nejrychleji reagovat v případě, že nastane problém. Tento proces si s dodavatelem vykomunikujte s co největším předstihem, abyste předešli zbytečným výpadkům. Tohle všechno zakomponujte do smlouvy, aby bylo vše černé na bílém.
Jakmile už dojde na nasazování změn, postupujte ve fázích. Nejprve aplikujte změny na vzorek systému, aby případná chyba neochromila celý provoz.
Váš IT tým by také měl aktivně pracovat na udržování funkčních záložních plánů. Měli by mít dostatečný čas na kontrolu všeho, co souvisí s alternativními opatřeními.
Když už se stane, že k nějakému problému dojde, vyžadujte rozbor incidentu. Měl by obsahovat informace k příčinám, dopadům a opatřením, která jsou z incidentu vyvozena.
Ani běžný, ani jednoduchý
Jak jsme si ukázali, i aktualizace může vést ke katastrofálním následkům. Pro vás, jako pro IT decision-makera, je kritické chápat ochranná opatření proti výpadku jako dobře vybranou investici, ne náklad nebo zbytečnou byrokracii.
Nespoléhejte ani na kvalitu dodavatele, na pozitivní zkušenost se systémem nebo na velikost organizace, která za systémem stojí. Žádná firma ani organizace není vůči chybám imunní, buďte tedy plně připravený na případ, až vaše systémy spadnou nebo se objeví modrá smrt.
