ISO 27031: Koristi, redundansa opreme i ciljani RTO/RPO (8.1.5–8.2)

8.1.5 – Utvrđivanje mogućih ishoda i koristi od IRBC-a

Standard nabraja jedanaest koristi koje efektivan IRBC donosi organizaciji. Grupisano po smislu:

• vidljivost – IRBC hvata razumevanje rizika i ranjivosti kontinuiteta IT servisa, i identifikuje moguće posledice prekida i redosled aktivnosti u odgovoru
• saradnja i kompetencija – podstiče bolju saradnju između poslovnih menadžera i IT pružalaca usluga (internih i eksternih), i razvija kompetenciju IT osoblja kroz demonstrirane, kredibilne odgovore u vežbama
• uverenje menadžmenta – daje top menadžmentu garanciju da može da računa na unapred određene nivoe IT usluga uz adekvatnu podršku i komunikaciju tokom prekida, i da je bezbednost informacija (poverljivost, integritet, dostupnost) očuvana u skladu sa politikama
• finansijska i strateška korist – povezuje ulaganje u IT rešenja sa stvarnim poslovnim potrebama, obezbeđuje da IT usluge nisu ni potcenjene ni precenjene u odnosu na stepen zavisnosti od njih, može da unapredi reputaciju firme, i potencijalno donosi konkurentsku prednost kroz dokazanu sposobnost da se isporuka usluge održi tokom prekida
• razumevanje očekivanja – dokumentovanje očekivanja zainteresovanih strana prema IT servisima

Ovo je gotovo gotov argument za razgovor sa menadžmentom – ne "IRBC je dobra ideja", nego konkretna lista onoga što firma dobija, uključujući i ono što retko ko pomisli prvo: da IRBC sprečava i precenjivanje ulaganja (redundansa gde nije potrebna) i potcenjivanje (nezaštićen kritičan servis), jer prisiljava firmu da prvo razume stepen zavisnosti pre nego što odluči gde troši.

Primer: Kad je IT sektor VoxServis-a tražio budžet za testiranje identiteta i redundansu domenskog kontrolera, argument je bio tehnički – "ovo je rizično". Da je iskorišćena ova lista, argument bi bio jači i konkretniji: trenutno nemamo dokumentovan rizik ove zavisnosti, nemamo definisan redosled odgovora ako se ponovi, a klijent iz Minhena je već video posledice kad nismo mogli da garantujemo dogovoren nivo usluge. Konkretna, imenovana korist ubedljivija je od uopštenog "trebalo bi".

Šta treba uraditi

• Napraviti kratak interni dokument koji povezuje svaku planiranu IRBC investiciju sa konkretnom koristi sa ove liste – koristan alat baš za razgovore o budžetu, ne za spoljnu reviziju.
• Kad se traži budžet, imenovati tačno koju korist ta investicija donosi (npr. "zatvara rupu u vidljivosti rizika" ili "obezbeđuje garantovan nivo usluge klijentu"), umesto da se ostane na opštem "ovo je rizično".
• Izbegavati najčešću grešku – predstavljanje IRBC-a menadžmentu isključivo kao trošak i tehničku nužnost, bez pomena koristi koje idu dalje od "sprečavamo katastrofu", poput bolje saradnje ili odbranjive alokacije budžeta.
• Iskoristiti listu i da se proveri da li je ulaganje uravnoteženo – da li neki servis dobija više redundanse nego što mu treba, dok drugi ostaje nezaštićen.

8.1.6 – Planiranje redundanse opreme

Standard definiše četiri nivoa redundanse, po rastućoj brzini (i ceni):

• hladni bekap – oprema postoji, možda u magacinu ili se može brzo nabaviti, ali tek treba da se konfiguriše i instalira da zameni neispravnu
• topli bekap – oprema je već u pogonu za drugu funkciju i može brzo i lako da se prekonfiguriše
• vrući bekap – oprema je spremna za upotrebu i može direktno da zameni neispravnu
• visoka redundansa – dve identične komponente rade istovremeno, svaka sa kapacitetom da sama isporuči celu uslugu, tako da uklanjanje neispravne nema nikakav uticaj na rad

Uz ovo, standard uvodi i koncept privremenih rešenja (workarounds) koja omogućavaju da poslovna aktivnost nastavi uz najmanji prekid dok tim radi na oporavku "normalnog" sistema – potpuno ručno, delimično ručno, ili automatizovano rešenje sa smanjenim učinkom. Isti koncept hladnog i toplog bekapa se proširuje i na objekte za obradu podataka – odluka, uz potrebne ugovore i planiranje, da se nastavak aktivnosti (uključujući IT) organizuje u drugom objektu.

Ovaj spektar daje firmi jezik da svesno bira, komponentu po komponentu, umesto da sve tretira isto. Ne mora svaki sistem da ima visoku redundansu – to bi bilo skupo i često nepotrebno. Ali svaki sistem treba da ima svesno izabran nivo, ne slučajan.

Primer: Kod VoxServis-a, domenski kontroler trenutno nema nikakvu redundansu – jedna instanca, jedna tačka otkaza, što objašnjava zašto je incident bio toliko dramatičan. Telefonska/PBX platforma verovatno ima hladni bekap u najboljem slučaju – oprema za zamenu postoji, ali svaka zamena zahteva vreme za konfiguraciju. Cloud CRM po prirodi platforme obično dobija nešto blisko visokoj redundansi na nivou infrastrukture od dobavljača, ali to ne znači da je VoxServis-ov nalog i podaci unutar njega isto tako zaštićeni.

Šta treba uraditi

• Za svaku kritičnu komponentu svesno dodeliti nivo redundanse (hladno/toplo/vruće/visoka redundansa), sa obrazloženjem zašto taj nivo odgovara njenom RTO zahtevu.
• Za identitet kod VoxServis-a, razuman sledeći korak nije automatski "kupimo visoku redundansu za sve", nego bar topli bekap za domensku kontrolu – sekundarni kontroler koji već radi, spreman da preuzme ulogu brzo, umesto da se sve gradi od nule usred krize.
• Definisati privremena rešenja (workarounds) za period dok se čeka puni oporavak – ko radi šta ručno, dok sistem nije vraćen.
• Izbegavati najčešću grešku – da nivo redundanse bude posledica istorijske slučajnosti (šta je kupljeno kad, šta je "ostalo" iz prethodnog projekta), a ne svesne odluke povezane sa RTO zahtevom te konkretne komponente.

8.1.7 – Određivanje obima IT servisa vezanih za ciljeve

Standard definiše šest ključnih elemenata IRBC-a:

• ljudi – specijalisti sa odgovarajućim veštinama i znanjem, i kompetentno rezervno osoblje
• objekti – fizičko okruženje u kom se nalaze IT resursi, uključujući kritičnu klimatizaciju
• tehnologija – hardver (rekovi, serveri, storage nizovi), mreža (konekcija za podatke i glas, svičevi, ruteri), softver (operativni sistemi, aplikacije, veze i interfejsi između aplikacija, batch procesi)
• podaci – podaci aplikacija, glasovni podaci i drugi tipovi
• procesi – prateća dokumentacija koja opisuje konfiguraciju IT resursa i omogućava efektivan rad, oporavak i održavanje
• dobavljači – ostale komponente end-to-end usluge koje zavise od spoljnog pružaoca ili druge organizacije u lancu snabdevanja, na primer dobavljač finansijskih podataka, telekom operater ili internet provajder

Ova šestorka nije slučajan spisak – to je isti okvir koji se koristi i za određivanje IRBC strategija. Vredi je zapamtiti kao proveru potpunosti: za svaki kritičan servis, da li smo razmislili o svih šest kategorija, ili smo, kao što se često dešava, razmišljali samo o tehnologiji i zaboravili ljude, procese i dobavljače?

Primer: Kad primenimo svih šest elemenata na VoxServis-ovu zavisnost identiteta, brzo se vidi gde su rupe. Ljudi: znanje postoji kod jedne osobe – rupa. Objekti: domenski kontroler je fizički u istoj serverskoj sobi kao i sve ostalo, bez geografske razdvojenosti. Tehnologija: jedna instanca, bez redundanse – rupa. Podaci: nejasno da li se konfiguracija domenskog kontrolera uopšte bekapuje odvojeno od operativnih podataka. Procesi: ne postoji pisan postupak oporavka – ono što se desilo posle incidenta je improvizacija, ne izvršenje dokumentovane procedure. Dobavljači: cloud strana sinhronizacije zavisi od dobavljača identitetske usluge čija sopstvena spremnost nikad nije formalno proverena. Od šest elemenata, VoxServis ima rupu u pet.

Šta treba uraditi

• Za svaki kritičan IT servis, proceniti spremnost kroz svih šest elemenata – ljudi, objekti, tehnologija, podaci, procesi, dobavljači – ne samo kroz tehnologiju, koja obično dobije svu pažnju.
• Za svaki element koji ostane neproveren (kao ljudi, procesi i dobavljači kod VoxServis-ove identitetske zavisnosti), tretirati to kao rupu koja se dokumentuje i zatvara, ne kao nešto što se prećutno preskoči.
• Iskoristiti ovu šestorku kao pripremu za sledeći korak – određivanje IRBC strategija – gde će isti okvir poslužiti kao osnovna struktura.

8.2 – Određivanje ciljanog IT RTO i RPO

Iz poslovne perspektive postoji jedan RTO po proizvodu, usluzi ili aktivnosti, koji počinje od trenutka prekida i traje do oporavka. Više IT servisa može biti potrebno da bi se to postiglo, a svaki od njih sastoji se od više sistema ili aplikacija – svaka komponenta se vraća prema sopstvenom RTO, tako da se zavisni IT proizvodi, usluge i aktivnosti vraćaju u okviru odobrenog RTO. RPO se odnosi na količinu informacija koju poslovni proces sme da izgubi, izražen u vremenu – politika bekapa treba da obezbedi da su potrebni, upotrebljivi podaci dostupni unutar tog RPO. MBCO se odnosi na najkritičnije poslovne konfiguracije, i pripadajuću IT opremu i servise, potrebne da se nastavi pružanje usluge ili postignu minimalni poslovni ciljevi.

Neke usluge mogu privremeno da se zaustave da bi se oprema preusmerila ka podršci ključnijim procesima – tek posle faze restauracije usluge se vraćaju u puni pogon. Često je potrebno postepeno povećavati kapacitet oporavljenih IT servisa da bi podržali rastući obim aktivnosti, sve do pune obnove na normalan nivo transakcija. Ciljani IT RTO, RPO i MBCO treba definisati sa periodom važenja i redovno ih revidirati.

Ovo formalizuje ideju "triaže" – svesnog žrtvovanja manje važnog da bi se sačuvalo najvažnije – umesto pokušaja da se sve podjednako spase odjednom, što retko uspeva pod pritiskom stvarnog incidenta. MBCO nije "sve radi na sniženom nivou", nego precizno definisano najmanje šta mora da radi.

Primer: Za VoxServis-ovu kritičnu aktivnost, podršku najvećem klijentu, MBCO bi mogao da glasi otprilike ovako: telefonske linije moraju da zvone i pozivi moraju da se prime, čak i bez pristupa CRM istoriji klijenta, uz ručno beleženje interakcije do povratka sistema. To je minimum ispod kog se ne ide. Da bi se taj minimum održao tokom incidenta poput onog sa domenskim kontrolerom, VoxServis bi svesno mogao da zaustavi manje kritične IT servise – na primer, interne analitičke izveštaje ili portal za samouslugu zaposlenih – i preusmeri i ljude i pažnju IT sektora na održavanje MBCO za prijem poziva. Trenutno ništa od ovoga nije definisano unapred; odluke o tome šta se žrtvuje donose se u trenutku panike, umesto po unapred dogovorenom planu.

Šta treba uraditi

• Definisati MBCO za svaku prioritetnu aktivnost, sa periodom važenja i datumom sledeće revizije.
• Unapred dogovoriti i zapisati spisak IT servisa koji se svesno mogu privremeno zaustaviti radi preusmeravanja resursa – ne odlučivati o tome usred incidenta.
• Napraviti plan povratka na pun kapacitet, uključujući mogućnost da povratak znači novi, a ne stari raspored rada.
• Izbegavati najčešću grešku – da MBCO nikad nije eksplicitno definisan, pa firma otkriva u hodu, usred incidenta, koji je "prihvatljiv minimum", umesto da je ta odluka doneta unapred, bez pritiska.