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.

Tudjuk, hogy sokatokat frusztrál a napok óta tartó BIS/BES szolgáltatáskimaradás, ami az e-mail szolgáltatások mellett érinti szinte az összes fontosabb üzenetküldő platformot a RIM-nél. A hiba okairól egyelőre keveset tudunk, de annyi bizonyos, hogy a RIM szakemberei gőzerővel dolgoznak a javításon. 

Egy ehhez hasonló, több millió ügyfelet érintő szolgáltatás helyreállítása csöppet sem egyszerű feladat, ráadásul információink szerint a hibát több tényező együttesen okozta, ami az ilyen leállásoknál mondhatni szokványos, mégis borzasztó nehéz felkészülni rá.

A RIM eddig eléggé hadilábon állt a tájékoztatással, nemrég azonban az angol weboldalra felkerült egy információs aloldal, ahol szépen kronológiai sorrendben követhető, mi történt, illetve innen tudhatjuk meg mi is (hiszen ugyanazok a szerverek szolgálnak ki minket is, mint az angolokat), mikor állt helyre véglegesen a szolgáltatás.

Mondjuk túl sok konkrétum itt sem derül ki, de legalább a RIM minden update-ben bocsánatért esedezik. Tudom, hogy nem sokra mentek vele, de adjatok még kis időt nekik.

Azzal biztosan nem mondok újdonságot, hogy megint áll vagy nagyon akadozik az összes BlackBerry szolgáltatás, gyakorlatilag hasznavehetetlenek a telefonok alapvető funkciói, mint a push email, chatek, böngészés, stb. Sajnos azt sem tudni, mi okozza ezt, de amennyit az IT-ról tudok (magas labda), az alapján ez szinte bizonyosan valami elcseszett szoftverfrissítéről lehet szó, mást nem tudok elképzelni egy ilyen kiterjedtségű és tartós hiba okaként.

A RIM az alábbi üzeneteket küldi szét céges ügyfelei operátorainak:

Service Impact: Subscribers may experience delays in sending or receiving messages, roaming in another location, or using other services such as Internet browsing or instant messaging. Subscribers may also be unable to create new accounts, integrate third-party email accounts, or use BlackBerry subscriber web sites. Devices may not receive new service books. BlackBerry-enabled devices that request a new PIN may not receive a PIN. BlackBerry Enterprise Servers may be unable to connect to the BlackBerry Infrastructure. Wireless service providers and device resellers may experience delays in using BlackBerry administration web sites, creating subscriber accounts, or provisioning services for subscribers.

Magyarul: lerohadt az egész kupleráj.

Azon kívül, hogy a dolog bosszantó, sokat nem tudunk tenni. A RIM bebizonyította felhasználók millióinak, hogy a BlackBerryjük nagyon fontos, de azt hiszem, kicsit sok lesz a leckéből.

Egy ilyen fiaskó sosem jöhet jókor, de a RIM számára talán a legrosszabbkor. A cég és vezetőinek általános elemzői/pénzpiaci megítélése már eddig is kihívásokkal küzködött, finoman szólva, ez a leállás pedig csak további olaj a tűzre. Részvényesek egy csoportja ismét kezdeményezte, hogy váltsák le a cég vezetőit vagy keressenek vevőt a vállalatra, hogy a cég értéke növekedjen. Ebből a szempontból a RIM vezetősége nagyon támadható pozícióban van, hiszen a cég értéke idén eddig nagyjából a 60%-át vesztette el, és a jelek szerint a tőzsdei befektetők nem igazán hisznek a feltámadásban, egyelőre. Egy ilyen kiesés pedig közvetlen üzleti károkat okoz, amely tovább rontja a jövőbeli kilátásokat, így a cégvezetés pozícióit.

Ne lepődjünk hát meg, ha esetleg fejcserékről kapunk híreket.

süti beállítások módosítása