Röviden azért idézzük fel a számunkra fontosabb történéseket, aminek apropóján rászántam magam, hogy még az idén folytassam a blogot.

A mai napon éjjel 2 óra előtt valamivel a T-Mobile szolgáltatásainak egy része gyakorlatilag gajra ment, és a szolgáltató szerint ezt kb. délután 5 óra tájékára sikerült teljesen elhárítani.

Nézzük meg a történteket IT Szolgáltatás menedzsment szemüveggel, amolyan gyors MIR (Major Incident Review = Súlyos Incidens vizsgálat) vagy Post Mortem jelleggel.
Természetesen belső információkhoz nem férünk hozzá, nem helyettesíthetjük a belső vizsgálatot, de azért pár dolog meglehetősen jól látszik, nagy valószínűséggel le fogunk tudni következtetéseket vonni. Az elemzést már csak azért is jogos megtenni, mert ismereteim szerint a T-Mobile-nál állítólag komoly ITIL folyamatrendszer van (ennek a mélységét személyesen nem ismerem, de több velük kapcsolatban álló szakmai társasággal dolgozva úgy informáltak, hogy legalábbis ez az elvárás).

A kiesés (ITIL szakszóval Incidens) okozója minden valószínűség szerint egy változás (ITIL terminológia: Change) - erre több minden utal. A T-Com sajtóközleménye is ezt állítja, és a kiesés kezdetének ideje is ezt erősíti: az éjjel 2 óra előtti időpont beleesik egy tipikus 7/24 üzemmódban működő rendszer preferált javítási ablakába. Sőt az Index cikkének kommentjeiben állítólagos bennfentesek is ezt állítják. Ezt tehát innentől fogadjuk el, és boncolgassunk innen tovább.

Két irányba indulhatunk: elemezhetjük azt, milyen (esetleges) hiányosságokat lehet feltárni a már bekövetkezett hiba kezeléséből, illetve mehetünk visszafelé: elemezhetjük azt, hogy mik vezethettek egyáltalán a hiba bekövetkeztéhez. Emellett megnézhetjük a várható következményeket is.

Induljunk el először előre.

A hiba bekövetkezte után

ITIL alapokon ilyenkor normál esetben beindul az Incidens kezelés folyamata. Itt aztán rögtön elágazások következnek, és több elemzési lehetőségünk van. Amennyiben (és erről nincs adat) külön van Major Incident kezelési folyamat, be kellett (volna) indulnia a megoldással párhuzamosan egy kommunikációt, a nagy mennyiségű hibabejelentést kezelő folyamatnak. Ennek része a nagyközönség tájékoztatása (ezzel kapcsolatban van egy korántsem teljes elemzés itt), valamint a belső tájékoztatás (különféle jelekből ítélve ezzel már voltak problémák). Emellett a Service Desk nyilván a saját automatikus reakcióját elindította: a különféle információkból tudni lehet, hogy egy általános "tudunk a problémáról, folyamatban van a javítás" típusú hangbemondás fogadta az összes betelefonálót. Ez standard módszer, amellyel a betelefonálók többségénél el lehet kerülni, hogy az ügyintézők idejét rabolja (hiszen úgysem tudnának sok mást mondani).

Emellett egy Major Incident esetében elindul egy Probléma Menedzsment folyamat is - tehát miközben az Incidens Menedzsment legfontosabb célja, hogy a hibát elhárítsa, a Probléma Menedzsment a hiba okára fókuszál. Ez láthatóan megtörtént: ebben a pillanatban a PM feladata nem az, hogy a hiba okát elhárítsa, hanem az, hogy azt ismerve kerülő megoldást tudjon szolgáltatni. Ennek megtörténtét onnan lehet tudni, hogy az ügyfélszolgálattól pár próbálkozó egy idő után szert tett egy kódra, amit a mobil telefonba a hívószám elé beütve működött nekik a szolgáltatás. Ez arra utal, hogy a mérnökök azonosították a hiba forrását, ami minden bizonnyal megkerülhető, ha a mobiltelefon kéri a hálózatot egy másfajta működésre. A kód persze nem önmagában utal a Probléma Menedzsment meglétére, hanem a tény, hogy ez a kód eljutott a Service Desk-hez, ahol tudták, hogy a jelenlegi hibánál alkalmazható. Ez pedig mindenképpen piros pont.

Az Incidens Menedzsment vonal azonban még nincs befejezve: a hiba elhárítására (ha a hibát egy változtatás okozta) a leggyorsabb módszer általában az, ha haladéktalanul és gondolkodás nélkül visszaállítják az eredeti állapotot. Erre technikailag sok lehetőség van általában - ha erre előre felkészültek. Vizsgáljuk meg egy kicsit közelebbről a konkrét esetet, hogy kiderüljön, itt ez lehetséges-e.

A hiba leírásából kiderül, hogy a hiba az egész országban jelentkezett. Emellett az is látszik a visszajelzésekből, hogy nem egyszerre állt helyre a szolgáltatás az egyes országrészekben. Ez utóbbiból arra lehet következtetni, hogy a hiba több rendszerelemet érintett - az előbbiből pedig azt, hogy jó eséllyel egy azonos típusú frissítés (vagy beállítás) azonos (vagy nagyon hasonló) központi eszközökre történő automatikus szétterjesztése okozta a hibát. Fogadjuk most el, hogy ez történt (ha nem, akkor lehetnek hibásak az ebből levont következtetéseink). 

Ha a hiba egy valamilyen frissítés terjesztése következtében történt, akkor a leggyorsabb helyreállítás az lenne, ha ebben a pillanatban "rollback"-elni lehetne a frissítést: azaz szétterjeszteni az ezt megelőző szoftvert / beállítást. A helyreállítás menetéből (azaz, hogy nem egyszerre történt az összes központban - tehát jó eséllyel manuálisan, hosszú idő alatt történt ) az következik, hogy nem ez történt. Ennek oka két dolog lehet: 1.) maga a terjesztés nem lehetséges vagy 2.) nincs mit terjeszteni, nincs meg az előző állapot.

Az 1.) okot jó eséllyel kizárhatjuk: hogy a terjesztő rendszer romlott volna el, az kevéssé valószínű (két, többnyire független rendszer egyszeri elromlása kevésbé valószínű, bár nem kizárt, sőt a terjesztő rendszer hibájából történt rossz kód telepítése éppen ilyen következménnyel járna - de azért ez nagyon furcsa eset lenne). Ennek az esetnek a variánsa lenne, ha a hiba következtében a vezérelt rendszerek leestek volna a központról - de ez a történtek hasonlóan furcsa együttállása lenne.

Ha azonban a (valószínűbb) 2.) variáns állt elő, az komolyabb folyamatbeli hiányosságot jelez: az ITIL kiadás kezelési folyamata ugyanis azt javasolja, hogy minden, éles rendszerben üzemelő kiadásról (hardver+szoftver) legyen egy mesterpéldány - egyebek mellett éppen annak érdekébe, hogy az ilyen típusú helyreállítás lehetséges legyen. A mulasztás természetesen sokrétű lehet. Elképzelhető, hogy egyáltalán nincsen kiadás kezelés (nagyon sok, ITIL-t használó vállalat megáll a változáskezelésnél). Az is elképzelhető, hogy a kiadás definíciójakor nem tértek ki azokra a részletekre, amelyek különbsége a mostani leállást okozta - ez (technikai részletről lévén szó) elég gyakran előfordul, ez esetben azonban ez, alapvető rendszerről lévén szó, komoly hiányosság. Az is lehetséges, hogy a kiadás csak részlegesen használható: például költségtakarékossági okokból a kiadás megvan ugyan, de nem terjeszthető szét ugyanazon módszerrel, amivel a frissítés (mondjuk, mert konfigurációs különbségek vannak). 

(Frissítés: a kommentek és ez alapján a cikk alapján valószínűleg egy harmadik eset történt: a hiba következményeképp plusz komplikáció állt elő - az összes mobil készüléknek újra be kellett jelentkeznie a hálózatba, így a hiba kijavítása után túlterhelési problémák jelentkeztek, amin csak fokozatos ráengedéssel lehetett úrrá lenni. Ez viszont a kapacitás menedzsment megfelelő készültségének kérdését veti fel.)

A kiváltó okok

Abból indultunk ki tehát, hogy változás bevezetése következtében keletkezett a hiba. Ebben tulajdonképpen semmi meglepő nincsen, az informatikai rendszerekben bekövetkezett hibák kb. 80%-át valamilyen változás bekövetkezte okozza.

Az azonban nem mindegy, hogy milyen hibákat, s hogyan készülünk fel erre. Mivel az ITIL folyamatokon belül a Változás Menedzsment az elsődleges folyamat, amelynek célja a változások bevezetésével kapcsolatos rizikók kezelése, s amelytől a változások kiesésmentes bevezetését várjuk, ezért az egész esetben a legkeményebben a változáskezelési folyamatot kell felülvizsgálni. Nyugodtan kijelenthetjük, hogy egy komolyabb cégnél az egyik legfontosabb elvárás a változás menedzsmenttel kapcsolatban az, hogy az ilyen eseményeket megelőzze.

Abba az eset kapcsán nem látunk bele, hogy pontosan mi történt előzményként a T-Mobile-nál a változáskezelés során, az pedig felettébb meglepő lenne, ha éppen egy ilyen fontos rendszer változáskezelése ne lenne szabályozva.

A kiadáskezeléssel kapcsolatos fenti megjegyzéssel összevonva azonban jó esélye van annak, hogy a T-Mobile-nál nem történt meg a szolgáltatás menedzsment egy kevéssé alkalmazott, ám ilyen nagyságrendű szolgáltató esetében rendkívül fontos dolog: az informatikai szolgáltatások megfelelő belső portfóliójának megfelelő szintű feltérképezése, azon belül különösképpen az egyes támogató informatikai szolgáltatások BIA (Business Impact Analysis) alapján történő kategorizálása. Ha ugyanis ez létezne, és a szolgáltatási portfólió alapján lennének a különböző támogatási folyamatok súlyozva, az hozzásegítené a menedzsmentet ahhoz, hogy a rengeteg változás erdejéből kitűnjön ez a különösen veszélyes - így lehetőséget adna az átfogóbb tesztelésre, illetve az egyedi biztonsági intézkedések előkészítése arra az esetre (pl. a legfontosabb támogató rendszereknél központilag indítható visszaállítás (rollback)), ha valami rosszul sülne el. Ezzel tehát vagy már a hibát lehetett volna elkerülni, vagy legalábbis a helyreállítási időt töredékére csökkenteni.

Egy T-Mobile méretű vállalatnál a változáskezelés annyira sok változást fog ledarálni, hogy csak a különböző súlyú változásokra vonatkozó különböző szintű engedélyezési- és követelményrendszerrel lehet kiegyensúlyozni a nagy járulékos költséget (plusz adminisztráció) a megfelelő rizikókezeléssel.

Minden eddig megemlített folyamatbeli hiányosság végső soron vezetői felelősség: hogy pontosan milyen szintű, az természetesen nem tudható - elképzelhető, hogy a megfelelő intézkedések már folyamatban voltak, csak még nem fejlődött a rendszer a kívánt szintre. Az is lehetséges, hogy a fenti hiányosságokat (ha vannak) már felfedték, csak valaki valahol nem adott pénzt azok megvalósítására (hiszen - válság van...) - ebben az esetben megkérdezném, hogy vajon a megvalósítás elmulasztásával spórolt-e jobban a cég, vagy azzal spórolt-e volna többet, ha a mostani fiaskót elkerüli... És persze az is elképzelhető, hogy e (megint csak feltételezett) hiányosságokról nem is tudott az IT vezetés - ebben az esetben azonban éppen ez a tudáshiány róható fel nekik.

Meg kell említeni azonban - pusztán személyes tapasztalat okán -, hogy a fenti elemzés szinte kidobható az ablakon, ha azt a bizonyos "emberi tényezőt" nézzük: megfelelő biztonsági rendszerek híján (de még azzal együtt is) elképzelhető, hogy az egész leállás egyetlen, a folyamatokat / rendszereket megkerülő, megfelelő jogosultságokkal rendelkező felelőtlen, vagy képzetlen rendszergazda műve. Közvetve természetesen itt is lehet vezetőséget emlegetni: a megfelelő képzés, motiváció, vállalati kultúra esetén álmában sem jut eszébe egy alkalmazottnak, hogy megkerülje a kötelező folyamatokat, vagy ne tudjon róluk. Ez azért nagyon közvetett felelősség: szerintem ma nincsen Magyarországon olyan nagyvállalat, amelyben ez a szintű kultúra el tudott volna terjedni (ehhez sok idő szükséges még akkor is, ha jó úton jár egy cég).

Következmények

Ha csak szolgáltatás menedzsment szempontok szerint nézzük (és tegyük ezt, már így is hosszú ez az írás), akkor a leállásnak a következő következményei vannak:

1.) A szolgáltatási szerződésben (amihez kimondva-kimondatlanul SLA (Service Level Agreement) tartozik) meghatározottak szerint kártérítés (penalty/bonus/malus) járhat. A különböző cikkekben megjelentek szerint a T-Mobile 4 óránál nagyobb szolgáltatáskiesés esetén köteles kötbért fizetni. A szolgáltató saját közleményében már közölte, hogy erre az esetre szerinte ez nem vonatkozik - a probléma itt az, hogy nem biztos, az ügyfelek igazságérzetével megegyezően van definiálva maga a szolgáltatás. Ugyanis a 3G hálózat működött, Internetezni is lehetett, "csak" a 2G telefonok nem működtek (többnyire) és SMS-t nem lehetett (többnyire) küldeni. Nem tiszta tehát, hogy milyen mértékben működött végül is a "szolgáltatás" - azaz első körben az sem tiszta, hogy egyáltalán (jogilag) kiesett-e a szolgáltatás.

Belső szabályozás szempontjából kérdés az is, hogy létezik-e olyan belső szolgáltatásdefiníció a portfólióban (lásd valamivel feljebb), amivel az azért felelős belső részlegeket motiválni lehet - például OLA teljesítéshez kötött bónuszrendszer formájában. Ha nincs, akkor itt az idő elgondolkodni a megfelelő struktúra kialakításán.

2.) Szintén a szolgáltatási portfólióval kapcsolatos összefüggések kezelésének kérdése, hogy számolt-e valaki azzal, hányfajta kapcsolódó (azaz nem mobiltelefon) eladott szolgáltatással rendelkezik a T-Mobile. A banki terminálok és más hasonló jellegű szolgáltatások nagy valószínűséggel járulékos kötbérrel fogják terhelni majd a T-Mobile idei eredményét. A belső függőségek beépítésén (és itt természetesen nem csak a botütések kiosztása értelmében, hanem a nyújtott IT szolgáltatások üzleti értékének felbecsülése szempontjából is fontos dologról beszélünk) túl az azokat igénybe vevők is minden bizonnyal el fognak gondolkodni azon, hogy vajon nem érdemes-e alternatív szolgáltatót is beépíteni, amely kiesés esetén igénybe vehető. Másképpen nézve: mekkora az a függőség, amely még elnézhető a redundáns kapcsolattal járó költségekkel szemben.

3.) Egy valóban IT Szolgáltatás Menedzsment alapján működő informatikánál mindenképpen vizsgálat kell induljon. Az általános hiedelemmel ellentétben egy ilyen vizsgálatnak nem az a célja, hogy "felelősöket keressen", hanem az, hogy megelőzze az ismétlődést, illetve ahol lehet, tanuljon az esetből (itt utalnék az előző blogbejegyzésre, ahol erről már volt szó). A legkevesebb egy tisztességes Post-Mortem Review, de a valószínűsíthető hiányosságok alapján szerintem a egy teljes körű Maturity Assessment,  minimum egy Változás, Konfiguráció, Kiadáskezelési, és Incidens Menedzsmentre kiterjedő átvilágítás lenne.

Ha így is lesz, azt természetesen nem kell feltétlenül nyilvánosságra hozni, hiszen a célja nem a "tömegek", hanem a vezetőség megnyugtatása, és segítség ahhoz, hogy meg tudják hozni a megfelelő intézkedéseket, s így elkerüljék az eset megismétlődését.

u.i.: Valaki az egyik kommentben megemlítette, hogy ez nem fordulhatott volna elő, ha lenne tisztességes DRP-je illetve BCP-je a T-Mobile-nak. Azt írtam erre, hogy nem értek egyet - lássuk miért:

DRP (Disaster Recovery Plan) - kifejezetten katasztrófa helyzet esetére előkészített reakcióterv. Többnyire arra van kihegyezve, hogy hogyan lehetséges alternatív helyen, esetlegesen alternatív eszközökkel újraindítani a szolgáltatást. Ez a terv jelen helyzetben semmiképpen sem alkalmazható, mivel láthatóan nem történt katasztrófa. Semmilyen olyan esemény nem volt, amely a szolgáltatást az adott helyen, adott eszközökkel akadályozta volna - egy ilyen terv végrehajtása nem segített volna a hiba elhárításában. Maximum egy alternatív eszköz, másik toronyban reprodukálta volna ugyanezt a hibát.

BCP (Business Continuity Plan) - Üzletmenet folytonossági terv, többnyire olyan esetekre készül fel és ad alternatív üzletmenetre megoldásokat, amikor a normál üzletmenet valamiért nem folytatható. Bár a jelen helyzetben vitatható, hogy egyáltalán volt-e normál üzletmenet elvesztése (szerintem nem - természetesen komoly hiba az volt, de SZVSZ egy fontos szolgáltatás ideiglenes kiesése, különösen akkor, ha annak javítása folyamatban van - még ha sok időt is vesz igénybe -, nem indokolja egy BCP-ben körvonalazott, többnyire a normál üzletmenet visszaállításakor sokba kerülő, alternatív működés bevezetését). Azt azonban végképp nem látom, hogy egy ilyen technikai hiba esetén milyen alternatív üzleti megoldások jönnének szóba! Alternatív technikai megoldások természetesen szóba jöhetnek, ezeket azonban a hibát elhárítók minden bizonnyal figyelembe is vettek (workaround) - sőt a rendszerek tervezésekor minden bizonnyal eleve redundáns megoldásokat használtak, már amennyire a költséggazdaságosság feltételei engedték. Ezeket az alternatív technikai megoldásokat azonban általában nem a BCP tartalmazza.

A félreértés alighanem onnan fakad, hogy a BCP készítéséhez ugyanazokat az alapvető technikákat alkalmazzák, mint amiket hiányoltam - név szerint pl. a BIA (Business Impact Analysis) vagy a CFIA (Component Failure Impact Analysis), ill. egyéb risk management eszközöket.