ISO 27031: DR plan koji imate vs. IRBC koji vam treba

VoxServis ima plan oporavka od katastrofe – DR plan, disaster recovery plan, tehnički dokument koji IT sektor vodi već godinama. U njemu piše: ako otkaže server na kom radi telefonska platforma (PBX – Private Branch Exchange, uređaj koji usmerava pozive), vraća se iz bekapa za dva sata. Test se radi jednom godišnje, oko stola: pročita se plan, svi klimnu glavom.

Onda je jednog utorka otkazao domenski kontroler – server koji proverava korisničke prijave i lozinke za celu firmu. Ne PBX. Nešto što u DR planu uopšte nije postojalo, jer se nikad ranije nije pokvarilo i niko ga nije doživljavao kao "pravi" sistem. Agenti u Beogradu nisu mogli da se uloguju na radne stanice. Oni koji su već bili ulogovani mogli su da rade lokalno, ali čim bi cloud CRM (sistem za praćenje klijenata, koji radi kod spoljnog dobavljača) pokušao da proveri njihov identitet preko sinhronizacije sa domenskim kontrolerom – ništa. Za klijenta u Minhenu, nije bitno da li je otkazao PBX ili domenski kontroler. Vidi samo da podrška ne odgovara, dok mu SLA ugovor (service level agreement, ugovoreni nivo usluge sa novčanom kaznom za kašnjenje) broji minute.

DR plan je bio tehnički tačan i potpuno beskoristan, jer nije predvideo baš ovaj kvar.

Pet razlika između DR plana i IRBC-a

1. Odakle se kreće. DR plan pita: šta imamo, i kako to vraćamo? IRBC pita: šta poslovanje mora da radi, dokad, i šta nam to zahteva? Kod VoxServis-a, poslovni zahtev glasi: podrška za klijenta iz Minhena mora da bude dostupna za 30 minuta od prekida, jer to ugovor kaže. Tek iz tog zahteva se izvodi koji IT sistemi – telefonija, prijava korisnika, CRM – moraju da imaju usklađen rok oporavka.

2. Šta se uopšte mapira. DR plan mapira ono što se vidi – servere, baze podataka. IRBC traži da se mapiraju i zavisnosti koje se ne vide na prvi pogled: sistem za prijavu korisnika, DNS (sistem koji imena sajtova/servera prevodi u adrese), digitalni sertifikati, mrežne veze, i deo infrastrukture koji drži cloud dobavljač. Domenski kontroler je tačno takva zavisnost – ne "aplikacija koju neko koristi", pa se lako ispusti, iako od njega zavisi skoro sve ostalo.

3. Ko učestvuje. DR plan piše IT, za IT. IRBC zahteva i vlasnike poslovnih procesa (da kažu šta je prioritet), bezbednosni tim, pravnu službu (da proveri šta dobavljači ugovorno garantuju), i menadžment (da odobri budžet). Kad plan piše samo IT, on odražava ono što IT vidi kao rizik – ne ono što firma stvarno gubi kad nešto stane.

4. Da li je ikad stvarno testiran. "Pročitali smo plan i izgleda dobro" nije test. Pravo testiranje ide u koracima: prvo se prođe kroz scenario u sali za sastanke, zatim se testira pojedinačna komponenta (da li restore iz bekapa stvarno radi, za koliko vremena), i tek na kraju se radi pravi failover – stvarno prebacivanje na rezervni sistem dok je sve u pogonu. VoxServis je imao samo prvi korak.

5. Da li prati promene u firmi. DR plan se napiše i onda se povremeno osveži datum na naslovnoj strani. IRBC je deo redovnog ciklusa – svaka veća promena (nova aplikacija, novi dobavljač, selidba u cloud) automatski pokreće pitanje: da li ovo menja naše zavisnosti? Kod VoxServis-a, uvođenje cloud CRM-a pre dve godine nikad nije prošlo kroz to pitanje.

Stari plan nije bezvredan

Ovo ne znači da treba baciti postojeći DR plan i početi ispočetka. Tehničke procedure koje već postoje – kako se vraća baza, kako se PBX diže iz bekapa – ostaju korisne. IRBC im ne dodaje novi skup procedura umesto starih. Dodaje im okvir: koji su prioriteti i zašto, koje zavisnosti nedostaju, i disciplinu da se sve to stvarno testira.

Najčešća greška

Test koji se svodi na čitanje dokumenta oko stola, umesto na stvarno pokretanje oporavka. Sve dok se testiranje tu zaustavi, brojevi u planu ("za dva sata") ostaju čista pretpostavka – nikad provereni. Cenu te pretpostavke VoxServis je platio tačno onog dana kad je restore domenskog kontrolera potrajao duže nego što je iko očekivao, dok je klijent iz Minhena već brojao minute prekida.

Šta sledi

Zavisnost prijave korisnika od domenskog kontrolera – i njena veza sa cloud stranom – prati nas kroz ostatak serije, na isti način na koji je jedan deljeni administratorski nalog pratio seriju o ISO 27001. Sledeći tekst ide dublje u ono što je ovaj primer već pokazao: zašto je hibridna infrastruktura, deo na svom serveru i deo u cloud-u, poseban izazov, i šta znači "deljena odgovornost" kad padne servis koji ne kontrolišete.