Hogyan teszteljük rendszeresen a vállalati mentéseket?

Egy hétfő reggelen nem indul az ügyviteli rendszer. A szerverhiba, egy hibás frissítés vagy egy zsarolóvírus miatt a rendelési, készlet- és számlázási adatok elérhetetlenné válnak. Van mentés - mondja valaki az IT-tól. Ez megnyugtató, de önmagában nem válasz arra, hogy mikor folytatható a munka. A valódi kérdés az, hogyan teszteljük rendszeresen a vállalati mentéseket úgy, hogy egy éles hibahelyzetben valóban visszaállítható legyen az üzletmenet.

Sok szervezetnél a mentés egy háttérben futó technikai feladat. A rendszer naponta elkészíti, a tárhelyszolgáltató visszaigazolja, a zöld pipa megjelenik a monitorozó felületen. Közben senki nem ellenőrzi, hogy az adatok megnyithatók-e, összeillenek-e, és egy használható üzleti rendszer állítható-e vissza belőlük. Ez ugyanaz a különbség, mint amikor egy folyamat leírása létezik, de a csapat még sosem próbálta végig valódi körülmények között.

A mentés nem a fájlok elkészítésével válik értékessé. Akkor értékes, amikor bizonyíthatóan helyreállítható belőle a működés.

A mentési teszt valójában üzletmeneti próba

A technikai siker és az üzleti siker nem mindig ugyanaz. Lehet, hogy egy adatbázis visszaállítható, de a webshop nem kapcsolódik az aktuális készlethez. Lehet, hogy a fájlszerver tartalma megvan, de a jogosultságok hiányoznak, ezért a munkatársak nem férnek hozzá a szükséges mappákhoz. Előfordulhat az is, hogy az ERP-adatbázis és a csatolt dokumentumok eltérő időpontból származnak, ezért a rendszer formálisan elindul, de a nyitott rendelések állapota bizonytalan.

Ezért a teszt célját nem érdemes úgy megfogalmazni, hogy „sikerült-e visszatölteni a mentést”. A cél inkább ez: egy kijelölt üzleti folyamat képes-e újra működni elfogadható időn belül, elfogadható adatvesztés mellett.

Egy kereskedő vállalatnál ez jelentheti azt, hogy a beérkező webshoprendelés bekerül az ügyviteli rendszerbe, a raktár látja a komissiózási feladatot, és a számla előállítható. Egy gyártónál azt, hogy az aktuális gyártási rendelés, a termékstruktúra és a termelési adatok rendelkezésre állnak. Egy szolgáltató cégnél pedig azt, hogy a szerződések, ügyféladatok és folyamatban lévő ügyek elérhetők maradnak.

Először azt kell tisztázni, mi a kritikus

Nem minden rendszer egyformán sürgős. A gyakori hiba, hogy a mentési terv technológiai elemek szerint készül: szerverek, adatbázisok, virtuális gépek, mappák. Ez szükséges kiindulópont, de a vezetői döntéshez nem elég.

Érdemes üzleti folyamatokból kiindulni. Mi történik, ha nem lehet rendelést fogadni? Mennyi ideig állhat a raktári kiadás? Mi a következménye, ha a pénzügyi rendszer egy teljes munkanapig nem elérhető? Melyik rendszerben vannak olyan adatok, amelyeket manuálisan nem lehet újra előállítani?

Ebből két kulcsérték következik. Az egyik a helyreállítási idő célértéke: mennyi idő alatt kell újra működnie egy folyamatnak. A másik az elfogadható adatvesztés: legfeljebb mennyi időnyi adat hiányozhat. Ha a rendeléseket folyamatosan fogadja a cég, egy előző éjszakai mentés lehet, hogy technikailag rendben van, üzletileg viszont túl nagy kiesést jelent.

Ezeket a döntéseket nem lehet kizárólag az IT-ra bízni. Az üzemeltetés tudja, mi állítható vissza és mennyi idő alatt. Az értékesítés, a pénzügy, a logisztika vagy a termelés viszont azt tudja megmondani, milyen kiesés elfogadható. A jó mentési és helyreállítási terv e két nézőpont találkozásából születik.

Hogyan teszteljük rendszeresen a vállalati mentéseket?

A rendszeresség nem azt jelenti, hogy minden hónapban ugyanazt a teljes körű helyreállítást kell végrehajtani. A megfelelő gyakoriság a rendszer kritikus jellegétől, a változások számától és a kiesés üzleti következményétől függ.

Egy jól működő gyakorlat több szintből áll. A napi automatizált ellenőrzés azt vizsgálja, hogy a mentési feladatok lefutottak-e, a mentési állományok elkészültek-e, és van-e hiba vagy szokatlan méretváltozás. Ez gyors jelzés, de nem helyreállítási bizonyíték.

A következő szint a rendszeres visszaállítási próba. Ilyenkor egy elkülönített tesztkörnyezetben visszaállítanak egy kiválasztott rendszert vagy adatbázist, majd ellenőrzik annak használhatóságát. Nem elég, hogy a szerver elindul. Be kell jelentkezni, meg kell nyitni a releváns adatokat, és ellenőrizni kell néhány üzletileg fontos rekordot: legutóbbi rendelést, számlát, készletmozgást, gyártási rendelést vagy dokumentumot.

A harmadik szint a teljesebb üzletmeneti gyakorlat. Ezt jellemzően évente, kritikus környezetben akár gyakrabban érdemes elvégezni. Itt nem egyetlen komponens helyreállítása a cél, hanem egy valós üzleti lánc próbája. Az eredményből derül ki leggyakrabban, hogy egy integráció, tanúsítvány, jogosultság, hálózati szabály vagy külső szolgáltatói függőség hiányzik a tényleges működéshez.

A tesztet elkülönített környezetben kell elvégezni

Éles rendszerre mentést visszatölteni kockázatos. Felülírhat friss adatokat, megszakíthat kapcsolatokat, vagy olyan mellékhatásokat okozhat, amelyek épp a normál működést veszélyeztetik. A tesztelés alapelve ezért az elkülönítés.

A helyreállított környezetnek nem kell mindig teljesen azonos méretű infrastruktúrának lennie, de a kritikus függőségeket hitelesen kell reprezentálnia. Ha az alkalmazás egy adatbázistól, fájltárolótól, címtárszolgáltatástól és külső API-tól függ, akkor a tesztnek ezt figyelembe kell vennie. Ellenkező esetben csak azt bizonyítjuk, hogy egy mentési fájl létezik, nem azt, hogy a szolgáltatás visszaállítható.

Külön figyelmet érdemelnek az integrált rendszerek. A webshop, ERP, raktári rendszer és futárkapcsolat egyenként lehet menthető, de a köztük lévő állapotok helyreállítása már összetettebb kérdés. Ha egy rendelés az egyik rendszerben már feldolgozott, a másikban viszont még nem szerepel, a visszaállítás után dupla teljesítés, hibás készlet vagy tisztázatlan számlázási helyzet is kialakulhat.

Legyen bizonyíték, ne csak emlék

A „tavaly egyszer kipróbáltuk” nem kontroll. Minden tesztről rövid, visszakereshető jegyzőkönyv szükséges: melyik mentésből történt a visszaállítás, mikor készült a mentés, mennyi ideig tartott a helyreállítás, milyen ellenőrzéseket végeztek, mi nem működött elsőre, és ki hagyta jóvá az eredményt.

Ez nem adminisztrációs teher a teher kedvéért. Egy idő után láthatóvá teszi a trendeket. Nő-e a visszaállítási idő? Megjelent-e új függőség egy rendszerfrissítés után? A dokumentált eltérésekből lehet fejlesztési feladatot készíteni, felelőst kijelölni és határidőt adni.

A teszteknek tulajdonosuk is kell legyen. Az IT vagy külső üzemeltető lehet felelős a technikai végrehajtásért, de az üzleti elfogadást annak a területnek kell adnia, amely a folyamatot használja. Egy raktári vezető például sokkal gyorsabban felismeri, hogy a visszaállított készletadat használhatatlan, mint az, aki csak azt látja, hogy az adatbázis-kapcsolat sikeres.

A leggyakoribb hibák a mentési gyakorlatban

Az egyik tipikus probléma, hogy ugyanabba a környezetbe mentenek, amelyet az eredeti rendszer is használ. Egy zsarolóvírus, jogosultsági hiba vagy infrastruktúrahiba így a mentéseket is érintheti. A mentésnek fizikailag és logikailag is el kell különülnie, és védeni kell a jogosulatlan módosítástól vagy törléstől.

Gyakori az is, hogy csak a központi szerverre gondolnak. Kimaradnak a felhőben kezelt dokumentumok, a SaaS rendszerek exportjai, a konfigurációk, a hálózati eszközök beállításai, az integrációs kulcsok vagy az egyedi alkalmazásokhoz tartozó feltöltött fájlok. Egy rendszer helyreállításához sokszor nem csak az adatbázis kell, hanem minden olyan elem, amely a rendszer működését körülveszi.

A harmadik hiba a változások figyelmen kívül hagyása. Új webshopmodul, új telephely, megváltozott jogosultsági modell vagy átszervezett raktári folyamat után a régi mentési teszt már nem feltétlenül ad valós választ. A mentési tervet ugyanúgy változáskezeléshez kell kötni, mint bármely más kritikus üzleti folyamatot.

A jól tesztelt mentés nem látványos eredmény. Nem gyorsítja fel közvetlenül a számlázást, és nem csökkenti egyik napról a másikra az adminisztrációt. Viszont akkor, amikor egy hiba miatt mindenki ugyanazt a kérdést teszi fel - „mikor tudunk újra dolgozni?” -, a bizonyított helyreállítási képesség nem technikai részlet lesz, hanem vezetői mozgástér.