Operativno upravljanje IT incidentima

Koliko puta ste čuli ili pročitali: “Kada krene sr*nje najvažnije je ostati pribran. Bez nervoze i paničnih reakcija”? Lako je nešto takvo napisati ali teško provesti jednom kada krene incident. Srećom ima načina da se i u najgorim incidentnim situacijama razina stresa zadrži na minimalnim razinama. Budimo iskreni, nikada se neće u potpunosti ukloniti stres ali se može znatno smanjiti.

Ako smanjimo stres u procesu rješavanja incidenta, smanjuje se mogućnosti dodatnih grešaka a nedostupnost se efikasnije otklanja. Za smanjenje stresa ne moram objašnjavati kakav pozitivan utjecaj ima na zdravlje i moral djelatnika.

Prije incidenta

Priprema je najvažnija. Pripremu za incident možemo imati kroz pisanje dokumentacije, definiciju odgovornosti osoba, definiciju kanala komunikacije te vježbu.

U najvećem broju organizacijama brzina rješavanja incidenta direktno je proporcionalna iskustvu djelatnika. Međutim iskustvo je pojam na koji se ne treba pretjerano oslanjati jer – ljudi se mijenjaju. Iskustvo se može dobrim dijelom pretočiti u dokumentaciju. Dokumentacija, korektno napisana sa svim relevantnim informacijama, je oslonac koji će itekako pomoći u efikasnosti rješavanja incidenta i eliminiranju paničnih reakcija. Prijedlog kako izraditi dokumentaciju možete pronaći u članku IT Operational Manal.

Sljedeća bitna informacija koju moramo definirati su osobe koje sudjeluju u rješavanju incidenta:

  1. Voditelj rješavanja – osoba koja će koordinirati rješavanje incidenta. Osoba koja ne mora nužno imati jaka tehnička znanja već je sposobna sagledati širu sliku i zna postaviti prava pitanja. Također od te osobe se očekuje da smireno vlada situacijom, zna smiriti tenzije, koordinira djelatnike i – najvažnije – donosi odluke i definira prioritete
  2. Koordinator komunikacije – osoba koja će odrađivati komunikaciju između tima koji rješava incident i “ostatka svijeta”. Prikupiti će relevantne informacije te poslati ih svim osobama koje od tih informacija imaju koristi. Također će prikupljati sve upite, sažeti ih, dobiti odgovore i sažeto prenijeti. Cilj je da se operativni tim čim manje opterećuje brojnim upitima u trenutcima najvećeg stresa i potrebe za koncentracijom
  3. Operativni tim – tim koji radi na sustavima da bi riješio incident. Vrlo je važno imati jasno dogovorenu segregaciju odgovornosti i prije nego što krene incident. Najmanje što želimo je da dvoje djelatnika rade dvije različite promjene u isto vrijeme na istom sustavu. To često dovede do gore situacije nego koja je bila prije početka incidenta. Segregaciju dužnosti moguće je postići klasičnom hijerarhijskom podjelom. A ako je dvoje kolega istog opisa radnog mjesta, na samom početku incidenta Voditelj rješavanja incidenta jasno komunicira tko će što raditi na kojem sustavu.

Jasno definirajte komunikacijske kanale za rad tima te kanale za obavještavanje korisnika na koje utječe incident. Ne pretjerujte s velikim brojem komunikacijskih kanala, koristite minimalan broj alata. Vrlo lako je zaplesti se u beskrajne mogućnosti.

Vježbajte proces rješavanja incidenta (en. fire-drill). Testove oporavka sustava nakon katastrofalnog događaja je uobičajeno provoditi. Vježbe rješavanja incidenata nije. Uzmite neki postmortem prethodnog incidenta i provedite vježbu bez referenciranja na postmortem. Vježbe nije lako osmisliti niti provesti ali je moguće. Vježbe se mogu raditi i pre-mortem principom. Stavite u sobu 5 kolega, odaberite sustav i neka svaki kolega smisli dvije najgore situacije koje se mogu dogoditi. Odaberite dvije za vježbu: ona za koju se svi slože da je najveća mogućnost pojavljivanja i onu za koja može prouzročiti najveću štetu. I krenite.

Tijekom incidenta

Vrlo je često pitanje kada proglašavamo incident da je potrebno postupati prema ovim smjernicama. Svaka organizacija to može imati drugačije definirano ili propisano. Ako nemate, možda vam može pomoći sljedeće. Ako na bilo koje od ovih pitanja je potvrdan, onda da, proglasite incident i postupajte prema uputama niže:

  1. da li incident utječe na rad krajnjih korisnika?
  2. da li je potrebno uključiti drugi tim u rješavanje?
  3. da li i nakon više sati intenzivnog rada incident nije riješen?

Prioritizirajte. Nije sve jednako važno. Ako je incident utjecao na više usluga, sustava i aplikacija rješavajte po definiranom prioritetu. Organizacije se najčešće referenciraju na Business Impact Analysis (BIA) dokumente za potrebe definiranja prioriteta u rješavanju nedostupnosti. Ako vaša organizacije nema BIA-u, dogovorite interno prioritet. Nema jednoznačnog savjeta kako, vjerujte svojim inženjerima i korisnicima.

Kada je potreban war room? Teško je definirati pravilo. Iz mojeg iskustva rekao bih da ako je potrebno uključiti više od troje ljudi u rješavanje incidenta – treba. Zašto tri? Prema teoriji Dunbar’s Number, broj komunikacijskih veza se znatno povećava s dodavanjem svakog novog člana. Kompleksnija komunikacija bez istovremene koordinacije svih članova brzo postane kaotična i igra pokvarenog telefona. Bez obzira da li je war room fizički – pokrenite chat/call instancu na alatu koji koristite u organizaciji. Takav način rada ima nekoliko prednosti:

  1. Ako je i potrebno dodati nekoga tko nije prisutan fizički, vrlo lako i brzo ga se uključuje u rješavanje incidenta. Tako se usred rješavanja incidenta ne troši vrijeme na pokretanje chata/calla, dodavanje svih potrebnih osoba, itd. Dodatno, u chatu je odmah dostupna sva povijest rješavanja incidenta
  2. Razmjena informacija u chatu je puno brža nego putem mail poruka
  3. Na poruke u chatu kasnije se može referencirati za potrebe postmortem analize

Pravovremena komunikacija kritična je komponenta. Iz više razloga: uključivanje adekvatnih osoba u rješavanje incidenta, smanjenje pritiska od krajnjih korisnika te transparentnost prema istima. Komunikacija je nužna minimalno: u trenutku kada je krenuo ili otkriven incident te kada je proglašen kraj incidenta. Jako dobra praska je i periodički izvještavati o napretku rješavanja.

Nikada ne odgađajte s komunikaciju da se dogodio incident. Incidenti se ne događaju nečijom namjerom. Komunicirajte rano – čim je incident otkriven. Komunikacija mora sadržavati što je nedostupno te, ako je ikako moguće i procjenu vremena potrebnog za otklanjanje nedostupnosti.

Tijekom rješavanja potrebno je periodički – recimo svakih 30 minuta – slati obavijest o statusu rješavanja incidenta. Komunicirajte što je napravljeno, koje su greške otklonjene i što je preostalo. Čak i ako nema napretka – komunicirajte i to, uz napomenu da timovi intenzivno rade na rješavanju. U komunikaciju je poželjno uključiti procjenu vremena potrebnog za otklanjanje nedostupnosti.

Jedna od najefikasnijih metoda komunikacije je statusna stranica s informacijama o incidentu. Sve veće tvrtke koriste takav kanal komunikacije za pružanje informacija krajnjim korisnicima. Vrlo često takve statusne stranice sadrže i informacije o napretku rješavanja incidenta. Time se smanjuje ponavljanje upita tipa “koliko još?”, “što ne radi?”, itd.

Ako postoji potreba obavještavanja regulatora, provjerite u svojoj organizaciji pravilnike i dokumentaciju. Upoznajte se s potrebama kada i s kojim informacijama je potrebno obavijestiti regulatora u slučaju incidenta.

Vjerujte timu koji rješava incident. Vjerujte njihovim kompetencijama. Dajte im autonomiju u rješavanju i, najvažnije, osigurajte im okruženje u kojem mogu samostalno donijeti odluke. U tim trenutcima izbjegavajte mikro menadžment. Međutim, to ne znači da nema ograničenja i odgovornosti. Najveće ograničenje je vremensko. Ako se tijekom određenog vremena ne vidi napredak bez jasnih idućih koraka, razmotrite opciju da zaustavite trenutne aktivnosti. Razmotrite druge opcije i krenete u drugom smjeru.

Nakon incidenta

Kada je nedostupnost otklonjena tj. incident riješen, proglasite kraj incidenta. Komunicirajte da su usluge, sustavi i aplikacije ponovo dostupni. U komunikaciju uključite i vrijeme koje je bilo potrebno za otklanjanje incidenta.

Incidenti se događaju i to nije neuspjeh. Neuspjeh je ako iz incidenata ne učimo. Učenje ima višestruke pozitivne efekte. Najvažniji – minimiziramo rizik ponavljanja incidenta. Zatim rješavamo srž problema koja je dovela do incidenta. Oboje je moguće postići provođenjem postmortem analize. Ne dozvolite da postmortem analiza ostane samo napisan dokument. Provodite retrospektive što je napravljeno dobro, što je moglo biti bolje a što je loše odrađeno.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.