Érthető okokból nagy figyelmet kapott British Airways informatikai rendszere által okozott üzemzavar május 27-én. 75.000 ezer utasnak okoztak fennakadást az életükben, a becsült kár értéke 50 milliárd forint felett van, és nem biztos, hogy ez marad a végösszeg.
Kép: Daniel Leal-Olivas/AFP/Getty Images
Az eset súlyához képest ugyanakkor keveset lehet tudni arról, hogy pontosan mi is történt. Itt most arra teszünk kísérletet, hogy a rendelkezésre álló információk alapján összefoglaljuk az esetet, és rávilágítsunk az ügy néhány tanulságára.
Hiszen máshol hasonló eset nem fordulhat elő, ugye?
A valódi kérdések
Azt mondják, ha meg tudod fogalmazni a problémát, akkor a válasz fele már meg is van.
Egy olyan komolyságú informatikai leállásban, mint a BA ügye is volt, nem könnyű a jó kérdésekre rátalálni. Dolgoznak az érzelmek, megjelennek az üzleti érdekek, és korlátosan hozzáférhetők az információk.
Könnyű ilyenkor a "Ki a felelős?" vagy "Miért és hogyan történhetet egyáltalán ilyen?" típusú kérdésekben elveszni, miközben az érintetteknél már működik a CYA mechanizmus.
A jó gyakorlat ilyenkor az, hogy először pontos információkat (és nem spekulációkat) kell időrendbe szedve összeállítani, és olyan kérdésekre válaszolni, hogy:
- Mi történt, mely rendszerek és hol voltak érintettek?
- Mi az ami nem (!) történt, mi a tévedés, rémhír és terelés?
- Pontosan mikor és hol történtek az események?
- Mely részletek azok, amelyeket nem értünk?
- Mely rendszerek működtek a probléma alatt?
Ha vannak teljeskörű, minden érintett által elfogadott adatok és összeállt az események időrendje, akkor lehet a tanulságokon és következményeken gondolkodni.
Események időrendben
Nézzük akkor, mit tudunk arról, hogy mi történt.
Péntek este vagy éjjel, pontosabban nem ismert céllal és kezdési időponttal a BA egy alvállalkozója karbantartást kezdett a BA londoni adatközpontjában, feltehetőleg a szombati incidenst megelőző napon elkezdve a munkát. A karbantartás az egyik aktív adatközpont áramellátó rendszerét érintette.
Az elérhető információk szerint a BA londoni informatikai rendszerei két aktív adatközpontból működnek, illetve van egy harmadik, tartalék helyszín is. Két adatközpont egymással aktív-aktív kapcsolatban volt, vagyis mindkét helységben volt élesben üzemelő informatikai rendszer, míg a harmadik adatközpontban csak passzív rendszerek voltak.
A karbantartási tevékenység irányulhatott az áramellátást végző eszközök karbantartására, de nem kizárható egy összetettebb üzletfolytonossági teszt sem. Erre utal még péntek estéről néhány olyan jelzés, hogy 7-8 órás késéssel érkeznek meg azok a regisztrációs e-mailek, amelyek 1-2 percen belül szoktak.
Szombaton 9:30-kor összetett áramellátási probléma lépett fel az egyik aktív adatközpontban.
- Nem ismert okokból megszakadt az adatközpont áramellátása, ugyanakkor áramellátási problémák a környéken nem voltak, az okok az adatközponton belül, és valószínűleg a karbantartáshoz kapcsolódóan keresendők.
- Az áramkimaradás 15 percig tartott, és a szünetmentes áramforrás nem az elvárható módon reagált. A tartalék áramforrásra történő kontrollált átkapcsolás helyett túlfeszültség alá került az adatközpont. Vagy emberi pánikreakció rontotta tovább a helyzetet, vagy rosszul volt az UPS és az áramellátást menedzselő informatikai rendszer beállítva.
- Pár perccel később áramellátás visszakapcsolása tervezetlenül és előkészítetlenül történt, ezzel további súlyos károkat okozva az informatikai szolgáltatásokban.
Egy megfelelően beállított szünetmentes áramforrás (UPS) áramszünet esetén néhány percig saját akkumulátorokról látja el az adatközpontot, amíg a generátorok elindulnak és stabilizálódik az általuk fejlesztett áram. Jellemzően ezek a tartalék generátorok által feljesztett áram is átfolyik az UPS-en, ami kisimítja és leszabályozza a generátorokból jövő, gyakran változó feszültséget és frekvenciát.
Szombat (május 27.) délelőttjén, de pontosan nem ismert időponttól kezdve, az informatikai rendszerek leállása már érintette a BA ügyfélszolgálati vonalait és honlapját, a check-in és a légiközlekedés szervezésére szolgáló rendszereket, a BA e-mail rendszerét.
Rosszul működött az informatikai szolgáltatások átállása másik adatközpontra (failover), sőt az egyik adatközpontban kialakult hiba átterjedt a másik aktív adatközpontra.
- Az áramellátásban történt hibák miatt inkonzisztens rendszerállapotok és hibás adatok keletkeztek az áramellátási problémával sújtott adatközpontban
- Az automatikus átállási (failover) mechanizmusok miatt inkonzisztens rendszerállapotok és adatok jelentek meg a másik aktív adatközpontban is, használhatatlanná téve számos onnan működő, végig normális áramellátásal futó rendszert.
- Innentől kezdve reménytelen volt a helyzet: a két aktív adatközpont számos rendszere nem működött, ezek kontrollált újraindítása és az adatkonzisztencia helyreállítása, a harmadik tartalék adatközpont beüzemelése és az adatok mentésekből való visszaállítása hosszú órákba került. Egy idő után a kerülő megoldások és az informatika nélküli működés lehetőségei kimerültek vagy bedugultak.
A légitársaság szombaton 14:30-kor bejelentette, hogy a Heathrowl és Gatwick repülőterekről induló járatok indulását 18:00-ig felfüggesztik.
18:30-kor a BA vezetője az első twitter videóüzenetében elmondja, hogy áramellátási problémák okozták a leállást, és hogy szombaton egész nap nem indítanak járatokat Heathrow-ról és Gatwick-ről.
Vasárnapra az IT rendszerek már működtek, de a felborult menetrend csak napokkal később állt helyre.
Tanulságok menedzsment szempontból
Négy általánosan érvényes témakört szeretnénk tanulságként kiemelni és minden informatikával dolgozó vezetőnek megfontolásra ajánlani.
1. Tervezett változások ellenőrzése
Semmi információ nem utal arra, hogy valami váratlan technikai vagy természeti hatás okozta volna a kiesést. Sőt tervezett karbantartás volt pénteken. Az eddigi információk alapján feltételezzük, hogy ezt a karbantartást nem jól tervezték meg, és/vagy nem jól hajtották végre a BA-nál.
De vajon azon kedves olvasó, aki felelős informatikai szolgáltatásokért, ismeri-e, hogy mikor végeztek utoljára az ő felelősségi körébe tartozó szolgáltatáson vagy adatközpontban hasonló karbantartást? Ha igen, milyen mélységben ismeri és ellenőrizte annak tervezett lépéseit, lefutását, a felmerült problémákat? Van-e a tervezett változtatások ellenőrzésére és felelős vezető általi jóváhagyásra bejáratott folyamat és kialakult szokás a vállalatban?
Sok kellemetlenséget lehet elkerülni, hogyha a fenti kérdésekre nem csak alibi válaszok vannak.
2. Válságkommunikáció
Még egy olyan nagy és veszélyes üzemnek is, mint a világ egyik legnagyobb légitársasága, ahol rutinszerűen fel vannak arra készülve, hogy széles körben ismertté váló, váratlan helyzetekben tudjanak kommunikálni, komoly és hosszan tartó problémát okozott az ügyfelek, a média és a munkatársak tájékoztatása. Biztos hogy van a BA-nál war-room, voltak már nehéz helyzetben, és mégsem működött a válságkommunikáció.
Az okok elemzése nem képezi e blog tárgyát, de arra szeretnénk itt is felhívni a figyelmet, hogy az informatikai problémák okozta válságkommunikációra is fel lehet készülni és érdemes azt gyakorolni.
Van-e war-room, működnek-e a riasztások és ügyeleti rendszer, elérhető-e szombat hajnalban szolgáltatók támogató mérnöke, időben felismeri-e a vállalat a vészhelyzetet? A LinkedIn-en található egy ellenőrzési listánk, amely segíti az informatikáért felelős vezetők felkészülését krízishelyzetekre.
3. Folyamat, gyakorlás és teszt
Bonyolult szervezetekben kulcsfontosságú a bejáratott szolgáltatási folyamatok léte, azok minősége, ellenőrzése és fejlesztése.
A tűzoltók sem akkor kezdik kitalálni, hogy mit kell csinálni, amikor megérkeztek az égő ház elé. Az informatikai üzemeltetésben is rendszeresen gyakorolni kell, évente 1-4 audit nem elég, így biztosítva a vészhelyzeti folyamatok bejáratottságát.
Számos praktikus lehetőség létezik arra, hogy a folyamat kisebb részeit gyakoroljuk vagy gyakoroltassuk.
Figyelemre méltó egy új iparági kezdeményezés, amely ajánlásokat és standardokat fogalmaz meg az informatikai problémák okozta kiesések hatásainak minimalizálására, Zero Outage Industry Standards néven.
4. Használjuk tanulságként
Nem bizonyultak igaznak azok a hírek, hogy a kiesést az okozta, hogy a BA fél évvel korábban külső szolgáltatóhoz szervezte ki az IT szolgáltatások jelentős részt. A kiesést nem a szolgáltató (TCS) okozta, a szakembereik a szolgáltatások újraindításában vettek részt, éjjel-nappal. Továbbra sincsenek külső támadásra, hackerekre utaló információk sem.
A BA esete jól mutatja, hogy nagyon könnyű hibák sorozatán keresztül eljutni oda, hogy órákig tartó informatikai kiesés és milliós károk keletkeznek. Véleményünk szerint az eset tanulságait felhasználva mindenhol újra gondolható az adatközpontok üzembiztonsága és a szolgáltatások robusztossága. A BA esete kiváló lehetőséget ad arra, hogy megvizsgáljuk és frissítsük a saját vészhelyzeti terveinket és helyreállítási előírásokat.
Tegyük fel azt a kérdést, hogy reagáltunk volna, mi történt volna a vállalatunknál, ha az egyik adatközpontban hirtelen megszűnik az áramellátás, gond van az UPS-sel és a failover mechanizmusok révén propagálódik az inkonzisztens állapot?
Készüljünk fel
Nem technikai hiba történt, nem külső hatások érték a BA-t, és biztos, hogy nem csak egy ember hibázott. Biztos vagyok benne, ahogy a BA mind a fenti négy pontban komoly hiányosságokat fog megállapítani és változtatásokat fog végrehajtani.
Tanuljunk belőle, mielőtt címlapon lesz a cég. Hasonló eseteket időnként nem lehet elkerülni, de hatásukat minimalizálni lehet. Készüljünk fel a kezelésükre, és ehhez segítünk az ITMA Hungary-ban az informatikával dolgozó vezetők számára szervezett informatikai továbbképzéseken és tanfolyamokon.
Információk
- A New York Times első riportja
- Első tanulságok a New York Times szerint
- A Guardian összefoglalója
- Információk a BA adatközpontokról és az eset részleteiről
- Jó és rossz kérdések IT probléma feltáráshoz
- Vezetők informatikai vészhelyzetben és utána
- Zero Outage Industry Standards
