Adatvédelemről beszélve elsősorban arra gondolunk, meg kell védenünk adatainkat a rosszindulatú támadásoktól, adatlopástól, illetéktelen adatfelhasználástól... ja, igen, és az adatvesztéstől. Kisebb szervergondok, leállások a legjobb családban is előfordulnak, ilyenkor néha újra kell installálni, konfigurálni ezt-azt, esetleg egy-két kódrészlet elveszik, de semmi gond, van mentés (ugye van?), onnan helyreállítható, ami szükséges. Oké, de mi van, ha a napi üzletmenet szempontjából kulcsfontosságú rendszer sérül meg olyan szinten, hogy minden adatot a mentésből kell visszaállítani? Továbbra sem írok IT-blogot, úgyhogy az alábbiakban elsősorban üzleti és menedzsment szempontból vizsgálom meg a kérdést, egy 10 évvel ezelőtti saját tapasztalat alapján.
2002. október 25-e pénteki nap volt. Akkoriban a NetPiac Online Filmáruház tulajdonosa és vezetője voltam, az életem reggeltől-estig az internetes DVD-kereskedelemről szólt. Késő délután kaptam egy hívást a rendszergazdánktól.
Egy rendszergazda csak akkor telefonál, ha valami nagy baj van. Nagy baj volt.
A helyzet pontos megértéséhez tudni kell, hogy a NetPiac új rendszere pár hónappal korábban indult, jelentős anyagi- és energia-ráfordítás árán, miközben az árbevétel-duplázós időszakunk harmadik évében voltunk.
(Erről szóló korábbi írásom itt olvasható.) A webshop a folyamatosan növekvő igényeink szerint épített
erőművön futott, amelyben négy merevlemez szolgálta ki a rendszert,
RAID 5-be kötve. A RAID 5 lényege, hogy több (minimum három) meghajtón elosztva tartalmazza a teljes rendszert, és mivel az írási és olvasási műveletek párhuzamosan végezhetők, nagyon gyors kiszolgálást tesz lehetővé. Ez főleg olyan alkalmazásoknál fontos, mint pl. egy webshop, ahol rengeteg lekérés (adatböngészés) mellett az írási igény is jelentős, hiszen az adatbázis tartalma folyamatosan változik a regisztrációk, vásárlások és adatfeltöltés által. RAID technológiát persze nem csak a gyorsaság miatt használ az ember, hanem azért is, hogy adatait megóvja az adatvesztéstől. RAID 5 használatakor:
"egy meghajtó meghibásodása esetén az adatok sértetlenül visszaolvashatóak, a hibás meghajtó adatait a vezérlő a többi meghajtóról ki tudja számolni." (Forrás: Wikipédia) Ez négy lemezből álló RAID 5 esetén azt jelenti, hogy ha az egyik lemez kiesik, akkor az azon tárolt adatokat a rendszer elkezdi a maradék háromra menteni és ott elosztva tárolni, így a rendszergazdának van ideje egyrészt a teljes rendszerről egy friss biztonsági mentést készíteni, másrészt a kiesett lemezt pótolni.
Amikor 2002. október 25-én délután a rendszergazda felhívott, épp azt kívánta közölni, hogy
a négy lemezből kettő 20 percen belül tönkrement, és úgy tűnik, az első és második lemez kiesése közötti 20 perc nem volt elég a rendszer számára ahhoz, hogy helyreállítsa saját magát. Amire a beszélgetés során eljutottunk odáig, hogy megértsem, miről van szó és mik az esélyeink, a harmadik merevlemez is beadta a kulcsot és a teljes rendszer leállt: a NetPiac.hu eltűnt a világ szeme elől.
Ez olyan, mint amikor a kereskedőnek leég a boltja - méghozzá a szezon kellős közepén! Illetve azért van különbség: a raktárkészlet
nincs a boltban, tehát a megsemmisülés nem teljes, csak a vevőknek nincs hova
bemenni vásárolni. A füstölgő hamukupacon végigtekintve azt gondoltam: nagyon szép volt, amit eddig csináltunk, de ennyi volt, mégsem ütöttük meg a főnyereményt. (Emlékeztetőül: a NetPiac árbevételével akkor a teljes hazai e-kereskedelem 2,5%-át adta, ami 2012-es mértéken számolva
4,5 milliárdos forgalomnak felel meg.)
Aztán összeszedtem magam és egy hét alatt talpraálltunk. Nem volt kis munka, egy hétig nem aludtam, de ma már tudom, megérte. Az, hogy ez sikerült, azon túl, hogy nem adtuk fel, négy tényezőn múlott:
- A rendszerről és az adatbázisról is volt külső mentés.
- A webshop és a rendelések kiszolgálását végző számlázó, készletnyilvántartó rendszer két, fizikailag is elkülönült szerveren futott.
- A rendelésekről és online fizetésről kimenő visszajelző emailekről egy külön postafiókba is ment másolat.
- A Netpiac maroknyi csapata, a StoreWizard rendszer fejlesztői, a rendszergazdánk valamint a segítségünkre rohanó bedolgozóink mind felfogták, hogy élet-halál helyzetről van szó és maximális teljesítményt nyújtottak.
Nézzük most ezeket a tényezőket egyenként:
A mentés
Mi volt a probléma, ha volt külső mentés? Teljes külső mentést bizonyos időközönként lehet csak csinálni. Tökéletes biztonságot csak a teljes redundancia adhatna, amikor két különálló, fizikailag is egymástól távollévő szerver szolgálja ki a rendszert, ami, amellett, hogy megvéd az adatvesztés ellen, még a folyamatos kiszolgálást is biztosítja. Ám egy ilyen rendszer létrehozása és fenntartása nagyon drága még ma is, akkor meg végképp az lett volna.
A külső mentésnél az a kulcs, milyen gyakran történik. A napi, automatizált mentés már viszonylag biztonságosnak mondható, de nekünk akkor még csak heti külső mentésünk volt, mondván, egy négy
vinyóból álló RAID 5 szerver önmagában is
atombiztos. Az előző külső mentésünk bő egyhetes volt, tehát egy hét adatait kellett helyreállítani - párhuzamosan a napi működéssel -, egy olyan időszakban, amikor épp a kiadók karácsonyi katalógusainak feldolgozása zajlott; tehát az elveszett egy hétben rengeteg új termék került fel a webshopba, és az aktuális héten is folyamatosan jöttek az új termékadatok. (Mellesleg a 2002-es ősz amúgy is csúcsszezon volt új kiadványok szempontjából. Volt olyan hét, amikor 200 új DVD jelent meg, mert elindult a Warner hazai kiadója.)
Tanulságok az adatbiztonság kapcsán:
- Mindig a cégvezető felelőssége, hogy meghatározza, milyen gyakori és milyen mélységű mentés kell, illetve, hogy általában mennyit költ az adatbiztonságra. A rendszergazától nem várható, hogy maga döntse el, mik a prioritások, hiszen nem ő tudja, min múlik a bevétel és adott probléma mekkora veszteséget okoz.
- Akinek a webshop a fő bevételi forrása, annak nagyon komoly erőforrásokat kell fordítania a megvédésére. Érdemes elgondolkozni, hogy a bevételünk hány százalékát fordítjuk adatbiztonságra! (Vajon egy hipermarket bevételének hány százalékát teszik ki az ezzel analóg költségek? Például: biztonsági szolgálat éjjel-nappal, tűzvédelem, biztosítási költségek; nem beszélve azokról a beruházásokról, amik eleve ezt szolgálták már az áruház megépítésekor!)
- Egy IT-tanulság, amit azóta már több helyről hallottam: RAID 5-öt nem szabad használni! (Kissé leegyszerűsítve persze. Az informatikusoknak biztos vannak ellenérveik is, de mondom, ez nem IT-blog.)
Ma valószínűleg egyébként
felhőbe raknám a webshopomat, de nagyon-nagyon megnézném, ki a szolgáltató, milyen garanciákat vállal a szerződésben, és milyen esély van azok érvényesítésére. 500 ezer Ft alaptőkéjű felhőszolgáltatóhoz nem vinnék semmit, az biztos.
Webshop és back office
A NetPiac üzleti folyamatai egy rendszeren, de
két külön szerveren zajlottak. A
Store Wizard FrontOffice-on (FO) futott maga a webshop: itt volt a termékkatalógus, a vásárlási folyamat, a felhasználói regisztráció és kezelés, valamint az ezekhez kapcsolódó adminisztrátori felületek (ez a rendszer omlott össze 2002. október 25-én). A
BackOffice (BO) menedzselte a rendelések teljesítési folyamatait a készletkezeléstől, komissiózástól a számlázáson át a postai és futáros szállításhoz tartozó dokumentumok és címkék előállításáig, illetve a pénzügyi teljesítések könyveléséig. A FO egy szerverteremben állt a Victor Hugo utcában, a BO pedig a logisztikai központunkban, ahol a fizikai folyamatok zajlottak. A két szerver nem állt egymással folyamatos kapcsolatban, hanem
gombnyomásra lehetett őket szinkronizálni, ezt naponta legalább kétszer elvégeztük. (Szinkronizáláskor letöltődtek az új rendelések a BO-ra, a FO-ra pedig felkerültek a friss készletadatok, illetve a rendelések állapotára vonatkozó adatok, a felhasználók tájékoztatására.) Azon a bizonyos
fekete pénteken a FO összeomlása előtt nagyjából fél órával volt az utolsó szinkron, így hat darab rendelés kivételével (amik ebben a fél órában érkeztek)
minden rendelésünk összes adata megvolt, beleértve a teljes felhasználói adatbázist. Ez egyúttal azt is jelentette, hogy a helyreállítás ideje alatt az előzőleg leadott rendelések teljesítése, a beérkező új áru kezelése, komissiózása, azaz a bevételszerző tevékenység egyik legfontosabb része zavartalanul folytatódhatott tovább. A webshopot már vasárnap délutánra sikerült működésbe hozni, és mivel a BO volt a
mester adatbázis, így az első szinkronizálás alkalmával az összes felhasználói- és készlet-adat az aktuális állapotra frissült és rendeléseket is lehetett leadni. Épp csak az előző héten rögzített termékeket kellett újra felvenni, illetve a korábbi termékek adataiban történt módosításokat, javításokat ismét elvégezni - mindezt párhuzamosan a beérkező új katalógusok feldolgozásával. A munkát több segítő között szétosztva, csütörtökre helyreállítottunk minden elveszett adatot és felvettük az új termékeket is - összesen több mint 400-at.
Rengeteg e-kereskedelmi céget láttam már a
backstage felől, azaz
hátulról. A komolyabbak közül is elég soknál a rendelések kezelése, kiszolgálása, a számlázás és készletkezelés ugyanazon a rendszeren fut, ahol a publikus webfelület. Pedig ezeket a rendszereket
folyamatszervezési, terhelés-optimalizálási szempontból is célszerű szétválasztani - és ahogy történetünk mutatja: adatbiztonsági szempontból pedig akár létkérdés lehet.
Másolat az emailekről
Kedves webshop-tulajdonos! Neked megvannak másolatban azok az automatikus emailek, amiket a webshop a felhasználóknak küld a rendelések kapcsán? (Rendelés visszajelzés, fizetés visszaigazolása, rendelés státuszának változása stb.) Nem arra gondolok, hogy ezek megvannak-e
valahol a szerveren egy könyvtárban, mert az vész esetén fabatkát sem ér. A NetPiacnál minden, a felhasználónak automatikusan kimenő email titkos másolatban
egy külön erre a célra fenntartott postafiókba is elment, és a postafiók teljes tartalma megvolt. Innen tudom, hogy az utolsó rendelés-lekérdezés és a szerver összeomlása közti fél órában hat darab rendelés érkezett.
Ez olyan információ, amit semmilyen más forrásból nem lehetett volna megtudni! A levelekből persze a rendelések pontos tartalma és a megrendelő személye is kiderült, így ezeket a rendeléseket könnyedén helyre tudtuk állítani úgy, hogy egyszerűen újra rögzítettük őket. Egyébként ezek a másolatban meglévő levelek sok apróbb, hétköznapi probléma esetén is nagy segítséget tudtak nyújtani. Amikor a fejlesztés során meghoztuk azt a döntést, hogy legyen ilyen funkció, még nem tudtam, mire lesz jó, de így utólag elég jó ötletnek bizonyult.
Az emberi tényező
Az adatbiztonsági szakemberek egyik axiómája, hogy a fizikai adatvesztések túlnyomó többsége nem technológia okokra vezethető vissza, hanem emberi tényezők állnak a háttérben. Eltekintve attól, hogy egy bizonyos technológia használata (esetünkben a RAID 5) melletti döntés szintén
emberi tényező, a katasztrófát nálunk az egyik merevlemez meghibásodása, majd a RAID vezérlő hibás reakciója okozta. Ami viszont tényleg egyértelműen emberi tényező, az a csapat helytállása volt. Nem csak a NetPiac dolgozói és a rendszergazdánk, de a rendszerünket fejlesztő Erba 96 Kft. programozói is zokszó nélkül feláldozták a hétvégéjüket, hogy vasárnap ismét
kinyithasson a bolt. A rákövetkező hét során pedig a postázásban és egyéb adminisztratív munkákban már korábban is besegítő diákmunkásaink töltötték az adatbázist, éjt nappallá téve.
A posztra készülve végeztem egy kis forráskutatást a neten. Eközben bukkantam egy megdöbbentő statisztikai adatra: eszerint
a katasztrofális adatvesztésben érintett cégek 94%-a nem éli túl a sokkot, legkésőbb két éven belül tönkremegy. Nehéz megmondani, hogy a fent sorolt négy tényező közül melyik mennyire volt fontos, de egy biztos: ezek együttesen tették lehetővé, hogy mi a maradék 6%-ba tartozzunk és a történet öt év múlva egy sikeres tranzakcióval záruljon.
(A poszthoz kapcsolódik a SzEK-klub következő témája is, amelyre épp a tízéves évforduló napján kerül sor. Részletes információk itt.)