hotline

Üzletfolytonossági és katasztrófa-elhárítási terv (BCP/DRP)

Lehet hogy érdemes lenne az üzletfolytonossági (BCP) terveket alaposabban átgondolni?

A gyakorlat, szakkönyvek, nemzetközi keretrendszerek alapján az informatikai üzletfolytonossági és katasztrófalehárítási terveket alapvetően a lehetséges kockázatok (és még sok más szempont, pl. az adatvagyon) alapján kell kialakítani. Ez a gyakorlatban a villámcsapás-, tűz-, árvíz- és hasonló kockázatok mérlegelésével történik. Ahol egyáltalán foglalkoznak ilyennel, ott a terveket a szabványok alapján elkészítik, “polcra teszik” a feladatot kipipálják.

És ha használni kell?

Mert ugye a baj előtti pillanatig soha nincs baj, tehát bármilyen BCP/DRP terv jó. És ha nem az árvíz okozza a fennakadást? Mert például lehet hatósági ellenőrzés, ami akár a számítógépek/szerverek lefoglalásával is járhat. Vagy például olyan nyári hőség, ahol kiderül hogy a szerverszoba klímája rosszul van bekötve és a szerverek felforrnak. Minden rendszergazda tudja: egy útépítés/csatornázás/kábelezés során biztosan átvágják a kommunikációs kábeleinket. Jelen idők legkomolyabb üzemzavarát, legnagyobb kockázatát pedig valószínűleg a ransomware-cunami jelenti.

És jövőre mi lesz a legfőbb kockázat? Ezekre fel vagyunk készülve?

Nem lenne egyszerűbb a hibaelhárítási terveket-forgatókönyveket most, nyugodt körülmények között alaposan végiggondolni, letesztelni, oktatni, gyakorolni és finomhangolni?

A három leggyakoribb félreértés az üzletfolytonossági tervekkel kapcsolatban

Az elmúlt időszakban több ügyfelünknél is felmerült az üzletfolytonossági (BCP) vagy a katasztrófaelhárítási terv (DRP) elkészítésének, felülvizsgálatának kérdése. Bár ezeknek a szabályzatoknak az ismertsége, helye és szerepe jelentős mértékben tisztázódott azért még mindig léteznek komoly félreértések. A három leggyakoribb:

1. Mi micsoda? Nincsenek kőbe vésett szabályok, de röviden: a Business Continuity Plan elsősorban az üzleti folyamatokra fókuszál, ezek folyamatos működtetése a célja, akár átmeneti eszközökkel. A Disaster Recovery Plan már inkább a technikai megvalósításra fókuszál, azokat a lépéseket és folyamatokat szabályozza, ahogyan az informatikai eszközök mielőbb elérhetővé válnak a felhasználók számára.

2. Az első lépés, függetlenül a cég/szervezet méretétől vagy iparágától, mindig az üzleti folyamatok elemzése! Fontoskodóan Business Impact Analysis (BIA), érthetőbben: Üzleti hatás(ok) elemzése. Azaz: mit is védünk, mi a fontos, mennyit „bírunk ki” a meglévő (IT) infrastruktúra nélkül, mik lehetnek a szervezetre gyakorolt hatások, stb. Ha jól és alaposan végezzük el ezt a fázist, már igen érdekes dolgok derülhetnek ki…

3. Az újraindítások ideje. A különböző (IT) rendszerek különböző fontossággal bírnak és ennek megfelelően különböző ideig lehet áthidalni a munkát a támogatásuk nélkül. Ez az úgynevezett Recovery Time Objective (RTO) nulla-kettő-négy óra, vagy akár nap is lehet. Persze ez is cégenként változik, de ami mindenhol azonos, hogy „mihez képest”. Azaz: tudomásul kell venni, hogy NEM az esetleges katasztrófa (üzemkiesés) pillanatától kezdődik a visszaállítás ideje. Időt kell szánni az úgynevezett azonnali reakcióra: emberi életek mentése, kárfelmérés, kríziskezelő központ létrehozása, kommunikáció, stb. Csak ezek után indulhat a helyreállítás. Azaz az RTO-ban mindkét fázis idejét együtt kell számolni!

Az ideális katasztrófa-visszállítási (DRP) terv olyan lenne, hogy egy egérkattintásra átálljon a katasztrófa-sújtotta teljes rendszer egy alternatív helyre. Szerverekkel, infrastruktúrával, kliens gépekkel és főleg munkatársakkal. Sajnos ez elég nehezen/drágán oldható csak meg. Ezért kompromisszumokat kell kötni és arra kell törekedni, hogy az üzletmenetet elfogadható időn belül egy elfogadható szintre lehessen visszaállítani.

Ez utóbbiban tud a TMSI Kft. segíteni, hiszen rendelkezünk a megfelelő tapasztalattal rendelkező szakemberekkel, aki ebben hatékonyan tudnak közreműködni.

Keresse kollégáinkat, még ma!

A honlap böngészésével elfogadja, hogy cookie-kat helyezzünk el az Ön számítógépén, hogy elemezni tudjuk, hogyan használja honlapunkat.