ISO 27031: Upravljanje IRBC-om i usklađivanje sa ciljevima kontinuiteta (klauzula 6.1–6.3)

6.1 – Opšte

Standard deli uzroke prekida u nekoliko grupa:

• prirodni uzroci – požar, poplava. Retki, ali fizički pogađaju celu lokaciju odjednom, ne samo jednu komponentu.
• tehnički kvarovi – hardver, softver, napajanje, klimatizacija. Najčešća kategorija u praksi, i ona za koju firme obično imaju najviše iskustva.
• ljudska greška – loše podešen bekap, propust u upravljanju izmenama. Retko ko je namerno kriv, ali posledice su iste kao da jeste.
• namerna akcija – hakovanje, malver, sabotaža. Ovde je pored oporavka bitna i istraga – ko je i kako ušao.
• društveni faktori – pandemija, štrajk. Ne pogađaju tehnologiju direktno, nego ljude koji je održavaju.
• cyber napadi – DoS, DDoS, napadi koji preplave sistem saobraćajem dok ne prestane da radi.
• lanac snabdevanja – prekid kod cloud provajdera, nejasni bezbednosni uslovi u ugovoru sa dobavljačem. Ovde firma nema direktnu kontrolu, samo ugovor i poverenje.

Rizik da IT prestane da radi ima jedan prepoznatljiv obrazac: retko se dešava, ali kad se desi, posledice su velike. Zato je i lako potceniti – ljudski mozak nije dobar u proceni rizika koji se retko materijalizuje, pa firme godinama žive bez ikakvog problema i zaključe da problema neće ni biti. Taj rizik se ne da ukloniti do kraja, samo smanjiti. Uvek postoji scenario koji niko nije predvideo. Poslednjoj grupi iz spiska iznad, izdanje standarda iz 2025. daje mnogo više prostora nego ono iz 2011 – tada firme nisu toliko zavisile od cloud-a, pa taj rizik nije ni bio dovoljno vidljiv da bi zaslužio posebnu pažnju.

Primer: Za VoxServis, fiktivnu firmu koju pratimo kroz ovu seriju (kontakt centar sa 560 zaposlenih i hibridnom infrastrukturom – deo na sopstvenim serverima, deo u cloud-u), pad domenskog kontrolera je tehnički kvar po definiciji. Ali pošto taj isti kvar vuče sa sobom i cloud stranu (CRM, Microsoft 365), jer su i jedno i drugo povezani preko iste prijave korisnika, isti incident spada i u poslednju grupu. Jedan kvar, dve kategorije – i to je tačno razlog zašto je hibridna infrastruktura teža za mapiranje nego što izgleda na prvi pogled.

Šta treba uraditi

• Proći kroz svih sedam kategorija uzroka i za svaku zapisati konkretan primer koji se odnosi na sopstvenu infrastrukturu – ne prepisivati listu iz standarda, nego je popuniti sopstvenim rizicima.
• Posebno obratiti pažnju na komponente koje spadaju u više kategorija istovremeno, kao domenski kontroler kod VoxServis-a – to su tačno mesta gde se rizik potcenjuje, jer se posmatra samo iz jednog ugla.
• Za lanac snabdevanja, proveriti šta ugovor sa cloud provajderom i ključnim dobavljačima stvarno kaže o vremenu oporavka i podeli odgovornosti – ne pretpostaviti da je to "neko drugi već sredio".
• Ne raditi ovaj spisak kao dokument koji se jednom napiše i zaboravi – on je ulazna tačka za klauzulu 6.4, gde se svaki od ovih uzroka formalno procenjuje sa verovatnoćom i uticajem.

6.2 – Omogućavanje upravljanja

Standard ovde traži tri odvojene stvari:

• opštu sliku sopstvene spremnosti – ne detaljno tehničko znanje, nego uvid po sedam oblasti: koje IT usluge postoje, gde je oprema fizički smeštena, koja tehnologija se koristi, koji podaci su bitni, koji procesi postoje, ko su dobavljači, i kakve veštine ima osoblje
• redovno informisanje svih zaposlenih, ne samo IT sektora, zašto IRBC (spremnost IT-a za kontinuitet poslovanja) postoji i kako njihov posao doprinosi tome
• kompetentnost ljudi sa formalno dodeljenom IRBC ulogom, što znači da su ispunjena sva četiri uslova zajedno:
  • jasno je šta ta uloga mora da ume
  • ta osoba je prošla obuku za to
  • neko je proverio da zna, ne samo pretpostavio
  • to je zapisano negde kao dokaz

Lako je sva tri zahteva strpati u jednu rečenicu "firma treba da bude spremna" – ali svaka rešava drugačiji problem. Prvi zahtev je važan jer cilj nije da jedna osoba zna sve u detalje – cilj je da negde u firmi postoji cela slika, umesto da je znanje rasuto po pojedincima koji ni ne znaju šta drugi znaju. Firma bez te slike ne zna ni odakle da počne kad nešto krene po zlu, jer niko ne vidi ceo lanac. Drugi zahtev je izgradnja kulture, ne tehnička obuka – agent na telefonu ne mora da zna kako se restore radi, ali treba da zna da postoji procedura za slučaj prekida, i da je njegov posao da je prati kad se aktivira, ne da improvizuje. Treći zahtev je najkonkretniji: bez i jedne od četiri stavke, "kompetentnost" ostaje samo reč na papiru.

Primer: Kod VoxServis-a, znanje kako se oporavlja sinhronizacija identiteta – veza između domenskog kontrolera i cloud naloga – postoji kod jedne osobe. Nije zapisano, niko drugi to nije radio, niko nije proverio da li bi neko drugi mogao da uskoči pod pritiskom. Ako ta osoba ode na bolovanje, na godišnji odmor u pogrešnom trenutku, ili jednostavno promeni posao, znanje odlazi s njom – i firma se vraća na tačku nula, tačno usred krize kad joj to najmanje treba.

Šta treba uraditi

• Napraviti i održavati pregled po svih sedam oblasti spremnosti (usluge, lokacije, tehnologija, podaci, procesi, dobavljači, veštine osoblja) na jednom mestu – ne dozvoliti da to znanje ostane rasuto po glavama pojedinaca.
• Uvesti redovan i jednostavan način informisanja svih zaposlenih – kratak sastanak, interni mejl, deo uvodne obuke pri zapošljavanju – da svako zna da IRBC postoji i šta je njegova uloga kada se aktivira. Nije potreban tehnički detalj, samo svest.
• Za svaku formalno dodeljenu IRBC ulogu proveriti sva četiri uslova kompetentnosti – da li je jasno definisano šta osoba mora da ume, da li je prošla obuku, da li je neko stvarno proverio da zna (ne samo pretpostavio), i da li postoji pisani trag o tome.
• Tamo gde znanje postoji samo kod jedne osobe – kao sinhronizacija identiteta kod VoxServis-a – odrediti zamenu, obučiti je, i testirati je u kontrolisanim uslovima. Ne čekati krizu da se otkrije da zamene nema.

6.3 – Ciljevi upravljanja kontinuitetom

IRBC ima pet ciljeva:

• ranije otkrivanje problema – da se zna da nešto nije u redu pre nego što korisnici počnu da se žale
• sprečavanje naglog i potpunog pada – da kvar ne bude iznenadan i totalan, nego postepen i delimičan
• mogućnost oslabljenog rada umesto potpunog prekida – da sistem nastavi da radi, makar sporije ili sa manje funkcija, umesto da potpuno stane
• brži oporavak – da se, kad do prekida ipak dođe, vrati u pogon što pre
• manja šteta kad se incident ipak desi – da posledice, finansijske i reputacione, budu što manje, bez obzira na sve ostalo

Redosled kojim ljudi obično zamišljaju ove ciljeve je skoro uvek pogrešan. Većina firmi meri samo četvrti cilj – koliko brzo se sistem vratio. To je razumljivo, jer je najlakše izmeriti i najlakše objasniti menadžmentu jednim brojem. Problem je što se time propuštaju prva tri, koja su, u praksi, često vrednija od četvrtog. Sistem koji se kvari sporo i uz jasno upozorenje (prva dva cilja) daje vremena da se šteta spreči pre nego što uopšte nastane. Sistem koji nastavi da radi oslabljeno (treći cilj) znači da klijent možda ni ne primeti da postoji problem. Brzina oporavka postaje bitna tek kad su prva tri propala – a upravo je to trenutak u kom većina firmi počinje da meri.

Primer: Kod VoxServis-a, incident sa domenskim kontrolerom je dobar test svih pet, i firma je pala na četiri od pet. Ranije otkrivanje: nije ga bilo, niko nije primetio dok se agenti nisu žalili da ne mogu da se uloguju – što znači da je problem već bio pun razvijen kad je uopšte primećen. Nagao i potpun pad: tačno se to i desilo, jer nije postojala nikakva rezerva koja bi ublažila udar. Oslabljen rad: nije postojao kao opcija – sistem je ili radio, ili nije, bez ičega između. Brzina oporavka: jedino je to izmereno, i bilo je sporije od dogovorenog roka sa klijentom. Šteta: koliko je incident stvarno koštao – u izgubljenim pozivima, u riziku od penala, u poverenju klijenta – niko nije računao, pa se ni ne zna prava cena onoga što se desilo.

Šta treba uraditi

• Za svaki kritičan servis definisati merljive pokazatelje za svih pet ciljeva, ne samo za brzinu oporavka – npr. koliko brzo se problem uočava, da li kvar dolazi postepeno ili naglo, da li sistem može da radi u oslabljenom režimu.
• Ako trenutno postoji samo jedan pokazatelj (obično vreme oporavka), sledeći korak nije da se on dodatno poboljša, nego da se uvede bar jedan pokazatelj za rano otkrivanje – tu obično leži najveći i najjeftiniji napredak.
• Posle svakog incidenta proceniti kroz koliko je od pet ciljeva firma prošla, a kroz koliko nije – to postaje osnova za sledeći krug poboljšanja, ne samo izveštaj da je "sistem vraćen u pogon".
• Uključiti procenu štete – finansijske i reputacione – kao redovan deo posle-incidentne analize, a ne kao nešto što se računa samo kad neko konkretno pita.