Szabad az anyázás

A Windows 95 szarakodásait, amely termék egyben a cég történetének talán legnagyobb és döntő piaci sikertörténete, a mai napig nem mosta le magáról a Microsoft. Hiába kurva jó oprendszer a Windows 7, és hiába fogja a Windows 8 megújítani a PC és tabletpiacot még tovább reszelt felépítésével és nagyon is újító Metro felületével, felhasználók a mai napig gúnyosan felemlegetik a kékhalálózást, és a Microsoftot a szar minőséggel kapcsolják össze.

De most nem abba akarok belemenni, hogy ez milyen károkat okoz mindenkinek, vagy hogy egy ilyen ordas bakival mennyire el lehet sikálni bármilyen céget vagy márkát -- egy életre.

Amit kicsit taglalni fogok, amolyan műkedvelő szinten, az az, hogy ami folyik, az mennyire elfogadhatatlan, és hogy a RIM magyarázata mennyire nonszensz. Technikailag, informatikailag. Nem akarok informatikai szakértőként pózolni, mert nem vagyok az, és ilyen rendszerek üzemeltetésében egyébként is viszonylag keveseknek van mélyreható tapasztalata. De azért hülyék sem vagyunk, ha megengeditek nekem ezt a többes számot.

Mi is várható el tehát egy olyan rendszertől, amely több millió felhasználót szolgál ki világszerte, non-stop, és ahol a leállásnak, de csak lassulásoknak is  komoly következményei vannak? Pontosan ez: ne legyenek leállások, lassulások.

Dehát nem létezik olyan, hogy tökéletes megbízhatóság, mondhatná a naív megfigyelő. A legdrágább német és japán kocsik is elromlanak, ahogyan a ThinkPad notebookokat is bizony kell szervizbe vinni. Ráadásul minél több elemből tevődik össze egy nagy rendszer, annál több a lehetőség a meghibásodásra, ugyebár!

Nos, ez mind igaz. Éppen ezért az olyan hatalmas méretű és egyúttal rendkívül kritikus fontosságú rendszereket, mint amilyen a RIM által üzemeltett szolgáltatás is, úgy tervezik meg, hogy feltételezik a meghibásodásokat. A tervezés alapvetése nem az, hogy nem lehet hiba sehol a rendszerben (és akkor vegyük meg mindenből a legdrágábbat, mert az talán tovább bírja), ellenkezőleg, azt kell feltételezni, hogy bármikor és bármi meghibásodhat -- és a szolgáltatásnak akkor is mennie kell tovább. Ezt hívjuk hibatűrő rendszernek. Ennek egy magasabb szintre emelt változata az úgynevezett katasztrófatűrő rendszer, amikor az infrastruktúra egy jelentős része, akár egy egész adatközpont is megsemmisülhet egy szempillantás alatt (vegyünk terror- vagy katonai támadást) -- de akkor sincs leállás. Erre léteznek a megfelelő technológiák, mint a valósidejű aktív-aktív replikáció terheléselosztással, több száz, néha több ezer kilométerre lévő adatközpontok közt. Nincs, nem lehet egyetlen eleme sem a rendszernek, legyen szó egy csavarról egy teljes adatközpontig, néha egy teljes városig, amely pótolhatatlan volna. Ezt az angol úgy mondja, no single point of failure. Ez a minimum.

Az ilyen rendszerek tervezése, üzemeltetése nem triviális feladat, rendkívüli komplexitások léphetnek fel a követelmények teljesítése érdekében. És hogyan lehetünk bizonyosak arról, hogy amit alkottunk, és amire dollár tíz- vagy százmilliókat költöttünk, az valóban hozza azokat az extrém rendelkezésre állási szinteket (pl. úgynevezett hétkilences, 99,99999% elérhetőség, vagyis évente átlagosan 3 másodperc kiesés, tíz év alatt fél perc), amely itt elvárható?

Ennek egyetlen ismert módja van: a szándékos hibagenerálás. Igen, egy bizonyos kritikussági szint felett nincs más megoldás az infrastruktúra és az üzemeltető szakemberek tesztelésére, továbbfejlesztésére, mint a profi vandálok alkalmazása. Ezeknek a magasan kvalifikált és mindenhova bejárással rendelkező informatikusoknak az a dolga, hogy utazzanak körbe a cég adatközpontjaiban, és próbáljanak leállásokat okozni. Ezt szó szerint úgy kell elképzelni, hogy a fószer bemegy a gépterembe, oda áll az egyik szerver, tároló vagy hálózati berendezés elé, és lekapcsolja, vagy csak kihúz kábeleket. Akár teljesen véletlenszerűen. A teljes rendszernek mindezt tolerálnia kell, hiszen ezek az események maguktól is bekövetkezhetnek bármikor, minél több berendezésről van szó, annál gyakrabban: igazán nagy farmokon naponta több merevlemezt, szervert vagy komponenst kell cserélni a több ezerből. Statisztika.

A RIM által eddigi magyarázat, ha ugyan elhisszük, borzalmas emberi, leginkább vezetői mulasztásról tanúskodik: nemcsak nem volt hibatűrő a rendszerük/mechanizmusaik, de megfelelően kitesztelt forgatókönyvük sincs a hatékony elhárításra. Ha ugyan elhisszük, hogy 3 nap alatt nem tudták megoldani annak a hatásait, hogy leállt egy központi hálózati eszköz. Ezek után már a berryblogosok által is emlegetett hekkertámadásra sem tudom azt mondani, hogy csak vad fantázia. Ez a szar már nagyobb, mint maga a palacsinta. Ha van tartás a RIM egyes vezetőiben, akkor bizony a hiba elhárítását követően önként beadják a felmondólevelüket, és fejet lehajtva távoznak a hátsó ajtón. Sírni senki nem fog, rajtuk kívül.