ISO 27031: Preduslovi za razvoj IKT plana kontinuiteta (klauzula 10.1)

10.1.1 – Određivanje i uspostavljanje organizacije za oporavak

Organizacija treba da, na osnovu IRBC strategije i plana, definiše sposobnost kroz strukturu, uloge i odgovornosti. Top menadžment određuje ko preuzima ukupnu odgovornost za IRBC. IRBC strategije treba da se implementiraju tek posle odobrenja top menadžmenta – u tom trenutku počinje faza implementacije, koja podrazumeva organizacionu strukturu, planove i procedure potrebne da se podrži sprovođenje. Organizacija treba da upravlja resursima, procedurama i radom IRBC-a, kao i da sprovede programe obuke i podizanja svesti. Implementacija treba da se vodi kao projekat kroz formalni proces upravljanja izmenama i kontrole projekta unutar BCM-a, radi pune vidljivosti i izveštavanja za menadžment.

Ovo je razlika između IRBC-a kao skupa dobrih namera i IRBC-a kao stvarnog projekta sa vlasnikom, budžetom i rokovima. Strategija sama po sebi ne sprovodi se sama – treba joj formalna implementaciona faza, sa istim nivoom projektne discipline kao bilo koja druga veća IT investicija.

Primer: Kad VoxServis odluči da uvede drugi domenski kontroler u Novom Sadu, klauzula 10.1.1 traži da se to ne sprovede kao usputan IT zadatak, nego kao projekat sa definisanom strukturom – ko je odgovoran za implementaciju, ko odobrava svaku fazu, kako se to prati kroz redovan proces upravljanja izmenama koji VoxServis već koristi za druge IT projekte. Ovo je suštinski drugačije od onoga što se desilo sa uvođenjem cloud CRM-a pre dve godine, gde IRBC razmatranje nikad nije bilo formalni deo projekta.

Šta treba uraditi

• Za svaku IRBC strategiju, tražiti formalno odobrenje top menadžmenta pre nego što implementacija uopšte počne.
• Dodeliti implementaciju konkretnom vlasniku, sa rokovima i planom faza – tretirati je kao projekat, ne kao zadatak "kad stigne vreme".
• Uključiti implementaciju u postojeći proces upravljanja izmenama, umesto da se sprovodi mimo njega.
• Izbegavati najčešću grešku – da se IRBC strategija "usvoji" na sastanku, ali nikad ne prođe kroz formalnu implementacionu fazu sa jasnom strukturom i odobrenjem, pa ostane ideja kojoj se pojedinci povremeno vraćaju, umesto projekta sa rokom završetka.

10.1.2 – Određivanje vremenskih okvira za razvoj plana, izveštavanje i testiranje

RPO se odnosi i na maksimalnu količinu podataka koja može biti izgubljena i nepovratna zbog poremećaja – to je vreme između poslednjeg dobrog bekapa i trenutka poremećaja. RPO i MBCO koji se mogu postići zavise od strategije oporavka IT servisa, posebno od aranžmana bekapa. Standard deli vreme oporavka na nekoliko faza:

• detekcija – direktna (bezbednosni incident je uočen) ili indirektna (korisnici prijavljuju gubitak ili degradaciju usluge), uz proteklo vreme pre nego što stigne prijava
• odluka o aktivaciji – može proći nekoliko sati dok se uzme u obzir vreme za komunikaciju i donošenje odluke, jer aktivacija IRBC-a često utiče na normalno poslovanje
• oporavak infrastrukture – mreža, hardver, operativni sistem, softver za bekap
• oporavak aplikacija – baza, aplikacija, batch procesi, interfejsi
• korisničko prihvatanje – sistemsko testiranje, pa tek onda puštanje osoblju za rad u režimu kontinuiteta

Ovo razbija RTO na komponente koje se retko posmatraju odvojeno. Firma koja meri samo "koliko je trebalo da se server vrati" propušta da vreme detekcije i vreme odlučivanja mogu biti jednako velika stavka, ako ne i veća.

Primer: Kod VoxServis-ovog incidenta sa domenskim kontrolerom, vreme detekcije nije mereno, ali je prošlo značajno vreme pre nego što je iko shvatio da je problem u domenskom kontroleru, a ne u CRM-u ili PBX-u – agenti su prijavljivali simptome, ne uzrok. Vreme odluke o aktivaciji je verovatno potrajalo duže nego što bi trebalo, jer nije postojao definisan prag, pa niko nije bio siguran da li situacija zaslužuje eskalaciju. Oporavak infrastrukture i aplikacija bio je izmešan, jer je domenski kontroler i infrastruktura i preduslov za sve aplikacije koje zavise od autentifikacije. Korisničko prihvatanje nikad nije formalno sprovedeno – čim je login proradio, smatralo se da je "gotovo", bez provere da li i CRM i sve integracije rade kako treba.

Šta treba uraditi

• Pri sledećem testu ili incidentu, izmeriti (ne proceniti) dužinu svake faze posebno – detekcija, odluka, oporavak infrastrukture, oporavak aplikacija, korisničko prihvatanje.
• Za svaki kritičan servis, prikupljati ove brojeve kroz stvarne testove i incidente, ne samo kroz teoretsku procenu.
• Kad se izmeri, proveriti gde stvarno odlazi najveći deo RTO budžeta – verovatno će se pokazati da detekcija i odluka troše više vremena nego što se pretpostavlja.
• Izbegavati najčešću grešku – posmatranje RTO kao jednog broja ("dva sata da vratimo sistem") bez razlaganja na faze, pa niko ne zna gde se vreme stvarno gubi.

10.1.3 i 10.1.4 – Resursi i kompetencija IRBC osoblja

Ovde standard konkretno traži da top menadžment:

• imenuje osobu odgovarajućeg senioriteta i ovlašćenja koja je odgovorna za IRBC politiku i implementaciju
• imenuje jednu ili više kompetentnih osoba koje, nezavisno od drugih odgovornosti, sprovode i održavaju IRBC
• imenuje tim kompetentnih ljudi koji operativno izvršavaju IRBC zadatke i procedure

Kao deo mandata politike, organizacija treba da definiše potrebu za IRBC programom kao deo šireg BCM cilja, i da odredi i obezbedi resurse potrebne za uspostavljanje, implementaciju, rad i održavanje tog programa – uz dokumentovane uloge, odgovornosti, kompetencije i ovlašćenja. Uz to, IRBC osoblje treba da čine kvalifikovani i obučeni ljudi, uz ažurnu obuku koja ih drži u toku sa pretnjama i ranjivostima organizacije.

Ovo je tačno mesto koje smo ranije pogrešno pripisali klauzuli 6.2, pa vredi biti eksplicitan: sadržaj o vlasniku, politici i budžetu zapravo pripada ovde. Klauzula 6.2 je o svesti i kompetenciji uopšteno; ova je o formalnom imenovanju vlasništva i resursa. Razlika je suptilna, ali bitna za tačnu primenu standarda.

Primer: Kod VoxServis-a, infrastrukturni menadžer vodi IRBC aktivnosti na sopstvenu inicijativu, bez formalnog imenovanja. Klauzula 10.1.3 tačno kaže šta nedostaje: top menadžment nikad nije formalno imenovao odgovornu osobu za IRBC politiku, osobu zaduženu da sprovodi i održava IRBC nezavisno od drugih obaveza, ili operativni tim. Sva tri nivoa trenutno postoje neformalno, kroz dobru volju jedne osobe.

Šta treba uraditi

• Formalno imenovati sve tri uloge – odgovorna osoba za politiku, osoba(e) za sprovođenje i održavanje, operativni tim – sa datumom i potpisom top menadžmenta.
• Za svaku imenovanu osobu, obezbediti resurse (vreme, budžet, ovlašćenje) potrebne da ulogu stvarno izvršava, ne samo formalno nosi titulu.
• Uvesti plan redovne, ažurne obuke koji drži IRBC osoblje u toku sa aktuelnim pretnjama, ne samo jednokratnu obuku pri imenovanju.
• Izbegavati najčešću grešku – uloge koje postoje neformalno, kroz ličnu inicijativu, bez formalnog imenovanja od strane top menadžmenta koje bi im dalo stvarno ovlašćenje da deluju brzo kad zatreba.

10.1.5 – Tehnološka rešenja

Potencijalne tačke otkaza treba kategorisati po poslovnom uticaju radi eskalacije odgovora. "Visoka dostupnost" označava sisteme koji su kontinuirano operativni tokom dužeg perioda – postoji široko prihvaćen, ali teško dostižan standard poznat kao "pet devetki" (99,999% dostupnosti). Planiranje visoke dostupnosti se često fokusira na bekap, failover obradu i skladištenje podataka, ali su druge infrastrukturne komponente, poput napajanja i hlađenja, podjednako važne:

• dostupnost napajanja – neprekidno napajanje (UPS), rezervni generatori, dvostruko napajanje sa mreže
• dostupnost i bekap podataka – redundantni nizovi diskova (RAID), mrežno skladište (SAN)
• dostupnost aplikacija – najčešće kroz klasterovanje

Ključna napomena standarda: ove tehnologije su stvarno efikasne za visoku dostupnost samo kroz istovremenu implementaciju na više od jedne geografski razdvojene lokacije – prost "failover" server na istoj lokaciji kao primarni neće obezbediti potreban nivo otpornosti ako tu lokaciju pogodi ozbiljan poremećaj životne sredine, jer bi oba servera bila pogođena istim poremećajem. I dalje vredi zapamtiti: iako je visoka dostupnost efikasan put ka većoj otpornosti, mogućnost kvara i dalje postoji – zato je ključno da postoje dobro isplanirani i testirani DR procesi i procedure, čak i uz najviši nivo dostupnosti.

Primer: Ovo direktno objašnjava zašto je incident sa domenskim kontrolerom kod VoxServis-a bio toliko štetan – jedina instanca, na jednoj lokaciji, bez ikakve geografske redundanse. Čak i kad bi VoxServis dodao drugi domenski kontroler, standard eksplicitno upozorava: ako bi taj drugi kontroler bio u istoj serverskoj sobi u Beogradu, redundansa bi zaštitila samo od kvara same mašine, ne i od gubitka cele prostorije (požar, poplava, nestanak struje). Tek kad je drugi kontroler fizički na drugoj lokaciji – prirodno, Novi Sad – redundansa stvarno znači nešto. A cloud strana (CRM, M365), koliko god dobavljač nudio visoku dostupnost na nivou platforme, i dalje zahteva testiran plan oporavka za ono što je VoxServis-ova odgovornost – visoka dostupnost dobavljača ne ukida tu potrebu.

Šta treba uraditi

• Za svaku redundantnu komponentu, potvrditi da su redundantni delovi fizički na različitim lokacijama, ne samo logički odvojeni u istoj prostoriji.
• Proceniti koje infrastrukturne zavisnosti (napajanje, hlađenje) redundantne komponente dele, čak i kad su na različitim serverima.
• Bez obzira na nivo dostupnosti kod cloud dobavljača, zadržati sopstveni testiran plan oporavka za ono što je u domenu firme (nalozi, konfiguracija, integracije).
• Izbegavati najčešću grešku – da se "redundansa" svede na drugi server ili disk u istoj prostoriji, što štiti od kvara hardvera, ali ne i od poremećaja koji pogađa celu prostoriju ili lokaciju odjednom.