ISO 27031: Prvih šesnaest nedelja – plan primene od nule do prve testirane spremnosti

Sedamnaest tekstova kasnije, imamo kompletnu teoriju. Ovaj tekst je drugačiji – ne objašnjava novu klauzulu, nego slaže sve što smo do sad naučili u jedan konkretan, hronološki plan. Ako ste firma veličine VoxServis-a i danas, u ponedeljak, odlučite da počnete, evo tačno šta radite, nedelju po nedelju, za jedan kritičan servis – ne za celu infrastrukturu odjednom.

Zašto samo jedan servis? Zato što smo u četvrtom tekstu ove serije bili eksplicitni: bolje je potpuno sprovesti ceo krug za dve ili tri prioritetne aktivnosti nego površno skicirati trideset. Ovaj plan prati VoxServis-ovu zavisnost identiteta – onu koju smo pratili kroz celu seriju – kao radni primer, ali koraci važe za bilo koji prvi kritičan servis koji izaberete.

Faza 0 (pre početka) – Dobiti sponzora

Pre bilo kog tehničkog koraka, potreban je jedan razgovor sa nekim u top menadžmentu ko može da odobri vreme ljudi i budžet. Ne treba vam ceo IRBC program odobren unapred – treba vam dozvola da sprovedete ovaj šesnaestonedeljni ciklus za jedan servis. Argument za taj razgovor već imate: lista koristi iz devete klauzule (osmi tekst ove serije) – vidljivost rizika, uverenje menadžmenta da može da računa na dogovoren nivo usluge, odbranjiva alokacija budžeta. Za VoxServis, konkretan argument je još jednostavniji: konkretan incident koji se već desio, sa imenom klijenta i brojem časova prekida.

Izlaz iz ove faze: jedno ime – ko je sponzor – i njegovo/njeno usmeno ili pisano odobrenje da krenete.

Faza 1 (nedelje 1–4) – Upravljanje i opseg

Prve četiri nedelje idu na uspostavljanje osnove, ne na tehniku.

Nedelja 1: Formalno imenovanje – ne celog IRBC tima, samo jedne osobe koja je, nezavisno od drugih obaveza, zadužena da sprovede i održava IRBC za ovaj prvi servis (deseti tekst, klauzula 10.1.3). Kod VoxServis-a, to bi mogao da bude isti infrastrukturni menadžer koji je do sad ove aktivnosti vodio neformalno – razlika je što sad ima pisano ovlašćenje.

Nedelja 2: Izbor tačno jednog do tri kritična servisa za ovaj prvi krug. Kriterijum: najveći poslovni uticaj, ne najlakši za rešiti. Za VoxServis, to je zavisnost identiteta – ne zato što je jednostavna (nije), nego zato što je već pokazala da može da zaustavi ceo kontakt centar.

Nedelja 3: Definisanje praga eskalacije – u kom trenutku "obična" IT intervencija postaje IRBC pitanje (osmi tekst, klauzula 8.1.1). Za VoxServis: ako je pogođena autentifikacija i traje duže od petnaest minuta, ili je pogođen bilo koji ugovor sa definisanim SLA penalom, automatski se eskalira.

Nedelja 4: Kratak sastanak sa top menadžmentom – ne da se nešto odobri, nego da se pokaže plan za narednih dvanaest nedelja i dobije formalna saglasnost da se nastavi.

Faza 2 (nedelje 3–8, preklapa se sa fazom 1) – BIA i mapiranje zavisnosti

Ovde počinje stvaran rad, i namerno se preklapa sa krajem prve faze – nema razloga čekati da administrativni koraci budu gotovi pre nego što se krene sa analizom.

Nedelje 3–5: Razgovor sa vlasnikom poslovne aktivnosti (za VoxServis: rukovodilac tima za podršku najvećem klijentu) radi utvrđivanja stvarnog RTO, RPO i MBCO (sedmi i osmi tekst, klauzule 7.2 i 8.2) – ne procene IT sektora, nego stvaran poslovni zahtev, po mogućstvu izvučen direktno iz ugovora. Za VoxServis, ovo je gde se prvi put crno na belo zapisuje "30 minuta" kao ugovoren zahtev.

Nedelje 5–7: Mapiranje kompletnog end-to-end lanca zavisnosti za taj servis – ne samo ono što se vidi u serverskoj sobi, nego i cloud strana, mrežne veze između njih, dobavljači (sedmi i deveti tekst, klauzule 7.3 i 9.2.7). Za VoxServis: telefonija → autentifikacija (on-premise + cloud sinhronizacija) → CRM → integracija → mrežna veza. Svaka karika dobija ime i vlasnika.

Nedelja 8: Poređenje – gde trenutna sposobnost (izmerena ili procenjena) ne ispunjava zahtev iz nedelje 3–5. Ovo je trenutak kad se jaz prvi put formalno vidi, umesto da postoji samo neformalno, u nečijoj glavi.

Izlaz iz ove faze: dokumentovan lanac zavisnosti sa jednim ili više identifikovanih jazova, spreman da uđe u sledeću fazu.

Faza 3 (nedelje 6–12, preklapa se sa fazom 2) – Izbor strategije

Nedelje 6–9: Za svaki identifikovan jaz, formulisati dve do tri strategijske opcije koristeći šest kategorija iz devete klauzule (deseti i jedanaesti tekst) – veštine i znanje, objekti, tehnologija, podaci, procesi, dobavljači. Za VoxServis-ovu identitetsku zavisnost, to su konkretno: topli standby drugi domenski kontroler u Novom Sadu (objekti + tehnologija), cross-training bar još jedne osobe (veštine), dokumentovana procedura restore-a (procesi), i provera sposobnosti cloud dobavljača za istovremenu aktivaciju (dobavljači).

Nedelje 9–11: Grubo koštanje svake opcije – ne detaljna ponuda, dovoljno da top menadžment može da poredi. Ovde se vraćate na iskrenost iz četvrtog teksta: neke opcije će biti prekomerne za ovaj servis, neke premale.

Nedelja 12: Formalna prezentacija top menadžmentu, koji bira između opcija i, ako izbor i dalje ostavlja jaz u odnosu na zahtev iz faze 2, eksplicitno se donosi odluka – zatvoriti ili svesno prihvatiti (poslednji tekst klauzula-po-klauzula dela, klauzula 12–13). Za VoxServis: top menadžment formalno bira topli standby plus dokumentovanu proceduru, uz svest da to verovatno spušta RTO ispod 30 minuta, ali se to tek treba potvrditi testom.

Izlaz iz ove faze: potpisana odluka top menadžmenta o izabranoj strategiji.

Faza 4 (nedelje 10–14, preklapa se sa fazom 3) – Izgradnja plana

Nedelje 10–12: Sprovođenje izabrane tehničke strategije – u VoxServis-ovom slučaju, konfiguracija drugog domenskog kontrolera u Novom Sadu kao toplog standby-ja.

Nedelje 12–13: Pisanje same procedure – korak po korak, dovoljno detaljno da je kompetentna osoba može izvršiti bez improvizacije, uz definisano privremeno rešenje za period dok se ne izvrši pun oporavak (deveti i deseti tekst, klauzule 10.3.5 i 10.4). Za VoxServis: procedura promocije sekundarnog kontrolera u primarnu ulogu, plus procedura ručne verifikacije identiteta koju supervizori koriste dok traje oporavak.

Nedelja 14: Umnožavanje plana na više lokacija/formata, tako da ne zavisi od sistema koji bi upravo mogao da otkaže (deveti tekst, klauzula 10.3.1) – i uspostavljanje osnovne kontrole verzija (dvanaesti tekst, klauzula 11.5).

Izlaz iz ove faze: pisan, odobren, dostupan plan – ali još netestiran.

Faza 5 (nedelje 14–16) – Prva vežba

Nedelja 14: Familijarizacija – tim prolazi kroz proceduru za stolom, bez diranja produkcije (dvanaesti tekst, klauzula 11.2.5). Cilj nije da se nešto dokaže, nego da se otkriju očigledne rupe pre nego što se rizikuje bilo šta u produkciji.

Nedelja 15: Test na nivou komponente – restore/promocija domenskog kontrolera u izolovanom okruženju, van produkcije, sa referentnim okvirom potpisanim unapred (jedanaesti tekst, klauzula 11.2.4) i definisanim protokolom za hitno zaustavljanje (dvanaesti tekst, klauzula 11.2.6).

Nedelja 16: Izveštaj i zatvaranje kruga – prikupljeni rezultati, poređenje sa kriterijumima uspeha, identifikovane rupe, dodeljene akcije sa rokovima, formalni izveštaj za sponzora (dvanaesti tekst, klauzula 11.3).

Izlaz iz ove faze: prvi, dokumentovan dokaz da nešto od onoga što je izgrađeno stvarno radi – makar delimično.

Šta posle šesnaest nedelja

Ovaj ciklus ne završava priču – tek je pokreće za jedan servis. Sledeći koraci: integrisan test koji uključuje ceo lanac (ne samo domenski kontroler izolovano), zatim uživo test sa stvarnim ili gotovo stvarnim saobraćajem (dvanaesti tekst, "digitalna otpornost"), i, paralelno, ponavljanje cele ove šesnaestonedeljne šeme za sledeći kritičan servis po prioritetu – ne po abecednom redu, kako smo naglasili u četvrtom tekstu.

Vredi primetiti nešto ohrabrujuće u ovom planu: većina od šesnaest nedelja ide na razgovore, mapiranje i pisanje, ne na skupu tehnologiju. Topli standby drugi domenski kontroler jeste investicija, ali je jedina prava tehnička stavka u celom planu – sve ostalo je disciplina koju firma već ima resurse da sprovede, samo joj nedostaje redosled.

Sledeći tekst

Drugi tekst o primeni ide na ono što se dešava posle prvog uspešnog kruga – kako se IRBC širi sa jednog servisa na ostatak kritične infrastrukture, kako se integriše sa postojećim ISO 27001 i ISO 22301 procesima umesto da ostane paralelan sistem, i kako izgleda godišnji ciklus kad program jednom postane rutina, ne projekat.