ISO 27031: Kriterijumi učinka i program testiranja (klauzula 11.1–11.2.3)

11.1 – Kriterijumi učinka

Kriterijumi učinka za IRBC mogu biti kvalitativni ili kvantitativni. Kvalitativni kriterijumi su subjektivni kad se koriste za određivanje učinka IRBC-a, ali obično zahtevaju manje resursa u procesu merenja – što može biti prikladno za malu ili srednju organizaciju sa ograničenim resursima. Mogu uključivati određivanje efikasnosti procesa korišćenih u planiranju, pripremi i izvršavanju IRBC aktivnosti, merenih kroz:

• anketu sa strukturisanim ili nestrukturisanim upitnikom
• povratne informacije od učesnika i zainteresovanih strana
• sprovođenje radionica za povratne informacije i drugih fokus-grupa

Ovo je koristan podsetnik da mereni kvantitativni pristup nije jedini "ispravan" način – firma ne treba da odustane od merenja učinka samo zato što nema resurse za sofisticiranu kvantitativnu metriku. Anketa posle vežbe je bolja od ničega, i standard to eksplicitno legitimiše.

Primer: VoxServis, sa 560 zaposlenih i realnim finansijskim posledicama (SLA penali), verovatno ima dovoljno resursa da vremenom pređe na kvantitativne kriterijume – izmerena vremena detekcije i odgovora. Ali za prvu vežbu, dok se program tek uspostavlja, sasvim je razumno početi kvalitativno – kratka anketa posle vežbe ("da li je procedura bila jasna? gde je zapelo?") daje vredne podatke bez potrebe za skupom infrastrukturom za merenje.

Šta treba uraditi

• Za prvu vežbu ili dve, izabrati kvalitativni pristup – kratku anketu ili radionicu posle vežbe – umesto da se čeka na resurse za kvantitativno merenje.
• Sačuvati korišćeni upitnik ili format povratne informacije radi poređenja kroz vreme, čak i kad je pristup jednostavan.
• Vremenom, kako program sazreva, uvesti i kvantitativne pokazatelje (izmerena vremena detekcije i odgovora) uz zadržani kvalitativni deo.
• Izbegavati najčešću grešku – da se učinak vežbi uopšte ne meri, jer se pretpostavlja da bi to zahtevalo skupu kvantitativnu infrastrukturu.

11.2.1 – Test i vežba

Organizacija treba da vežba ne samo oporavak IT usluge, nego i njene elemente zaštite i otpornosti, kako bi utvrdila da li:

• usluga može biti zaštićena, održana i/ili oporavljena bez obzira na ozbiljnost incidenta
• IRBC aranžmani upravljanja mogu da minimizuju uticaj na poslovanje
• procedure za povratak na redovno poslovanje su validne

Ovo proširuje ono što "testiranje" znači daleko izvan uske definicije "da li server ponovo radi". Tri odvojena pitanja – zaštita/otpornost, minimizacija uticaja, i validnost povratka na normalu – mapiraju se direktno na pet ciljeva spremnosti koje smo videli ranije u seriji: detekcija i prevencija (zaštita), prihvatljiva degradacija (minimizacija uticaja), i sam oporavak (povratak na normalu).

Primer: Kad VoxServis konačno testira oporavak identitetske zavisnosti, test ne treba da se završi čim je login ponovo proradio. Prvo pitanje: da li bi monitoring uopšte detektovao problem ranije nego što su ga primetili agenti – zaštita/otpornost, još uvek ne postoji. Drugo: da li je privremeno rešenje stvarno omogućilo da pozivi nastave uz minimalan uticaj, ili je i ono improvizovano. Treće: da li je povratak na normalan rad bio čist – jesu li svi ručno zabeleženi podaci tokom incidenta ispravno uneti nazad u CRM, ili su neki zauvek izgubljeni. Sve troje mora da bude provereno da bi test bio potpun.

Šta treba uraditi

• Za svaku vežbu, definisati sva tri pitanja unapred – zaštita/otpornost, minimizacija uticaja, validnost povratka – ne samo "da li se server digao".
• Beležiti rezultate po sva tri pitanja odvojeno, ne samo binarnu ocenu uspeh/neuspeh za sam oporavak.
• Posebno proveriti povratak na normalu – da li su svi privremeno zabeleženi podaci ili radnje ispravno vraćeni u sistem, ne samo da li osnovna usluga ponovo radi.
• Izbegavati najčešću grešku – smatranje testa uspešnim čim je usluga ponovo dostupna, bez provere da li je detekcija bila blagovremena, da li je privremeno rešenje stvarno funkcionisalo, ili da li je povratak na normalu ostavio nedovršenog posla.

11.2.2 – Program testiranja i vežbi

U većini slučajeva, ceo skup IRBC elemenata i procesa, uključujući oporavak IT-a, ne može se dokazati u jednoj vežbi. Postepen program obuke je zato prikladan pristup ka izgradnji pune simulacije stvarnog incidenta – program treba da uključi različite nivoe vežbi, od upoznavanja do otpornosti serverske sobe, i da razmotri sve aspekte isporuke IT usluge od kraja do kraja.

Postoje rizici povezani sa testovima i vežbama, i takve aktivnosti ne treba da izlože organizaciju neprihvatljivom nivou rizika – program vežbi treba da definiše kako se rizici identifikovani tokom pojedinačnih vežbi adresiraju sada ili u budućnosti, uz odobrenje top menadžmenta za program i jasno dokumentovano objašnjenje povezanih rizika. Svaka vežba treba da ima i poslovne ciljeve (čak i kad nema direktnog učešća poslovne strane) i definisane tehničke ciljeve. Standard nudi primere opsega vežbi na visokom nivou:

• oporavak podataka – pojedinačan fajl ili baza posle oštećenja
• oporavak pojedinačnog servera, uključujući punu izgradnju
• oporavak aplikacije – može uključivati više servera i infrastrukture
• failover usluga hostovanih na platformi visoke dostupnosti
• oporavak podataka sa trake
• testiranje mreže
• testovi failover-a komunikacione infrastrukture

Dve stvari ovde retko ko uzme ozbiljno. Prva: sama vežba nosi rizik – testiranje failover-a domenskog kontrolera, urađeno nepažljivo, može samo po sebi da izazove baš onaj prekid koji se pokušava sprečiti, pa program mora svesno da upravlja tim rizikom, ne da ga ignoriše. Druga: program ide postepeno, od malih, niskorizičnih koraka ka punoj simulaciji – pokušaj da se odmah sprovede puna simulacija, bez prethodnih manjih koraka, sam po sebi je rizičan poduhvat.

Primer: Za VoxServis, postepen program bi mogao da izgleda ovako: prvo, vežba upoznavanja – tim prolazi kroz zapisanu proceduru oporavka domenskog kontrolera za stolom, bez diranja produkcije. Zatim, test na nivou komponente – restore domenskog kontrolera u izolovanom test okruženju, van produkcije. Tek posle toga, integrisan test – kontrolisan failover u produkciji, planiran van radnog vremena, sa svim podacima bekapovanim unapred i sa top menadžmentom koje je svesno odobrilo rizik. Pokušaj da se odmah krene na treći korak, bez prva dva, tačno je rizik koji ova klauzula upozorava da se izbegne.

Šta treba uraditi

• Napraviti postepen plan vežbi – od upoznavanja sa procedurom, preko testa na nivou komponente, do pune simulacije u produkciji.
• Za svaku planiranu vežbu, proceniti rizik koji sama vežba nosi i tražiti odobrenje top menadžmenta pre nego što se sprovede.
• Definisati i poslovne i tehničke ciljeve za svaku vežbu, ne samo tehničke.
• Izbegavati najčešću grešku – firmu koja ili uopšte ne vežba, ili pokuša odmah punu simulaciju u produkciji bez prethodnih, manjih koraka.

11.2.3 – Opseg vežbi

Vežbe treba sprovoditi da bi:

• izgradile poverenje kroz organizaciju da strategija otpornosti i oporavka može da ispuni poslovne zahteve
• pokazale da se kritični IT servisi mogu održati i oporaviti u okviru dogovorenih nivoa usluge ili ciljeva oporavka bez obzira na incident
• pokazale da se kritični IT servisi mogu vratiti u stanje pre testa na lokaciji oporavka u slučaju incidenta
• pružile priliku osoblju da se upozna sa procesom oporavka
• obučile osoblje i obezbedile da imaju adekvatno znanje o IRBC planovima i procedurama
• proverile da IRBC ostaje sinhronizovan sa IT infrastrukturom i opštom infrastrukturom
• identifikovale potrebna unapređenja IRBC strategije, arhitekture ili procesa oporavka
• pružile dokaz za potrebe audita, demonstrirajući kompetenciju organizacije u oblasti IT usluga

Vežbe treba da se primenjuju na celo IT okruženje identifikovano unutar IRBC opsega i sve komponente koje isporučuju uslugu od kraja do kraja – od serverske sobe do korisničkog desktopa ili bilo kog drugog kanala isporuke usluge.

Svrha "proveriti da IRBC ostaje sinhronizovan sa infrastrukturom" direktno rešava problem koji smo identifikovali ranije u seriji – uvođenje cloud CRM-a koje nikad nije prošlo kroz proveru uticaja na kontinuitet. Redovan program vežbi je upravo mehanizam koji bi tu vrstu drifta uhvatio, umesto da se otkrije tek kad je prekasno.

Primer: Da je VoxServis imao redovan program vežbi u trenutku uvođenja cloud CRM-a, prva sledeća planirana vežba bi verovatno otkrila da procedura oporavka identiteta više ne odgovara stvarnoj arhitekturi – jer bi vežba, po definiciji, morala da pokrije celo IT okruženje od serverske sobe do korisničkog desktopa, što uključuje i noviju cloud komponentu. Umesto toga, rupa je otkrivena tek kroz stvaran incident, na najskuplji mogući način.

Šta treba uraditi

• Napraviti plan vežbi koji eksplicitno pokriva sve komponente unutar IRBC opsega, uključujući cloud i hibridne delove, ne samo on-premise infrastrukturu.
• Posle svake vežbe, zapisati identifikovane rupe između plana i stvarne infrastrukture – ne samo da li je vežba "prošla".
• Kad se uvede nova IT usluga ili komponenta, uključiti je u sledeći ciklus vežbi umesto da čeka na poseban projekat.
• Izbegavati najčešću grešku – vežbe fokusirane samo na on-premise infrastrukturu, jer je "vidljivija" i lakša za testiranje, dok cloud i hibridne komponente ostaju netestirane.