Što je postmortem? Lessons-Learned? Pojam mijenja naziv ovisno o kojoj grani industrije se radi. Zajedničko svima je – otkriti uzrok incidenta kako bi se u budućnosti minimizirao rizik ponavljanja istog incidenta. Bitno je da ne otkrivamo krivca. Ne igramo “the blame game”. Otkrivamo uzrok u sustavu, proceduri ili procesu koji je doveo do incidenta. Gotovo nikad je uzrok namjerna ljudska intencija. I tako se trebamo postaviti kada krećemo u postmortem analizu.

Neke grane industrije su iznimno rigorozne što se tiče postmortem procedura. Primjerice avio prijevoz. S druge strane u nekim granama industrije i ne postoji. Najčešće ako nije mandatorno zakonom ili regulativom provoditi postmortem analize – ne provode se. A ako sam nešto naučio iz Black Box Thinking – postmortem analize su ključ za napredak.

Pojedine tvrtke su svjesne te činjenice. Ne samo da provode postmortem analize već i javno objavljuju. Neke postmortem analize su i više od same analize, to su fantastični eseji koje je užitak pročitati. Primjerice, analize Spotify, Cloudflare, GitHub, Facebook, itd.

Zašto provodimo postmortem analizu

Ukratko – nitko ne želi da se incident ponovi. Incidenti su stresne situacije. Vrlo stresne. A većina ljudi ne voli i izbjegava stres. Zato, provođenjem postmortem analiza, tražimo uzrok (root cause) incidenta kako bismo ispravili grešku i spriječili ponavljanje istog incidenta u budućnosti.

Kada je otkriven uzrok incidenta, možemo krenuti s planiranjem i implementacijom trajnog rješenja. Sve ostalo je “flaster” ili “vatrogasna mjera” tj. zaobilazno rješenje (work-around). Work-around omogućava nam da u razumnom roku dovedemo uslugu do operativnog stanja. Ali, u većini slučajeva, ne rješava srž problema koji su doveli do incidenta.

Kada provodimo postmortem analizu

Odmah. Čim prije. Čim se uspostavi operativno stanje usluge tj. kada se riješi incident kreće se s postmortem analizom. Idealno bi bilo odmah prilikom detekcije incidenta, ali to zahtijeva dodatnu osobu koja ne koordinira rješavanje incidenta ili operativan rad na rješavanju incidenta. Kreće se s prikupljanjem informacija od svih sudionika koji su sudjelovali u rješavanju incidenta te log zapisa iz sustava koji su ili prouzročili incident ili bili pod utjecajem incidenta. Postmortem analiza se vodi otvorenom i dokumentira dokle god se ne implementira trajno rješenje koje rješava srž uzroka nastanka incidenta.

Što sadrži postmortem analiza

Minimum informacija koje će omogućiti da se incident ne ponovi. Ili u najgorem slučaju, kada nije moguće riješiti srž problema, informacije kako oporaviti uslugu. Slijedi prijedlog što bi minimalno postmortem analiza trebala sadržavati:

1. Vrijeme nastanka incidenta – točan datum i vrijeme kada je incident nastao. Od ovog trenutka kreće računanje SLA i SLO
2. Vrijeme završetka incidenta – točan datum i vrijeme kada je usluga dovedena do stanja punog operativnog rada. U ovom trenutku ne gleda se da li je riješena srž problema, već da je usluga operativna tako da krajnji korisnici mogu nastaviti raditi
3. Vrijeme primjene trajnog rješenja – točan datum i vrijeme kada je primijenjeno trajno rješenje koje rješava srž problema koja je dovela do incidenta. Ovo ovisi od tvrtke do tvrtke te da li postoje ugovorne obaveze (SLA) za ovaj tip aktivnosti
4. Uzročnik incidenta – usluga/sustav/aplikacija koja je uzrokovala incident tj. degradaciju usluge prema krajnjim korisnicima
5. Usluge degradirane incidentom – usluge/sustavi/aplikacije na koje je incident imao utjecaj tako da je njihova funkcionalnost naručena tijekom incidenta
6. Izvor incidenta – odnosi se da li je usluga koja je uzrokovala incident interno rješenje ili vanjska usluga. Ovo je sve relevantnija informacija s obzirom na doba Cloud computing paradigme te sve veću ovisnost o vanjskim davateljima usluga
7. Utjecaj – razina utjecaja incidenta, primjerice: niski, srednji, visok. Ovisno od tvrtke do tvrtke može se razlikovati. Savjet, ne komplicirajte s više od tri razine. Niska razina može označavati pojedinca, srednja odjel ili zgradu a visoka cijelu tvrtku ili sve vanjske korisnike usluge
8. Hitnost – prioritet u rješavanju incidenta, primjerice: niska, srednja, visoka. Ovisi o kritičnosti, RTO i/ili SLA za uslugu koja je degradirana incidentom. Također, ne preporučujem da komplicirate s više od tri razine. Ako imate definiran RTO za usluge, savjetujem sljedeće: niska za RTO > 8h, srednja za RTO > 4h, visoka za RTO < 4h
9. Nedostupnost – da li je incident uzrokovao nedostupnost. Incident ne znači nužno nedostupnost usluge/sustava/aplikacije. U modernim tehnološkim rješenjima grade se visoko dostupni redundantni sustavi koji mogu, za krajnje korisnike, ostati dostupni iako je dio sustava nedostupan. U tim slučajevima ispad jednog dijela sustava ne znači nedostupnost cijele usluge. Međutim, to ne umanjuje važnost incidenta i provođenja postmortem analize. Srž problema je i dalje prisutna te zahtijeva da se posvetimo pronalasku rješenja kako bi izbjegli ponavljanje incidenta ili, potencijalno, punu nedostupnost usluge
10. Opis – kratak opis incidenta
11. Vremenski slijed događaja – većina će se fokusirati na vremenski okvir od kada je počeo incident do trenutka rješavanja incidenta. To nije adekvatno. Tome nas je naučila avio industrija. Uzrok pojave incidenta je najčešće prije pojave samog incidenta. Shodno, da bi otkrili srž problema bitno je razmotriti i dokumentirati i postupke te događaje i prije samog incidenta. Druga bitna informacija koju učimo iz dokumentiranja slijeda događaja su postupci koje smo poduzeli da bi usluga vratila u operativno stanje. Na ovo se uvijek možemo referencirati ako je incident ponovi
12. Zaobilazno rješenje – opis primijenjenog zaobilaznog rješenja (mitigacijske mjere) koja je primijenjena kako bi se usluga vratila u operativno stanje. Ovo je tehnički dug s kojim se živi do trenutka otkrivanja srži problema te implementacije trajnog rješenja
13. Srž problema – analiza koja opisuje što je stvarni uzrok incidenta. Fokus nikako ne smije biti na traženju krivca. Gotovo nikada incident nije uzrokovan namjernim ljudskim ponašanjem u cilju uzrokovanja štete. Čak i kada je to slučaj, postoji srž problema koja je dovela do toga. A i plan rješavanja tog problema. Najčešće se greške događaju zbog nedostatnih procedura ili grešaka u sustavu. Ako se fokus usmjeri na procese i sustave umjesto na osobe, omogućava se korektan i konstruktivan rad na pronalasku srži problema
14. Trajno rješenje – plan i opis implementacije trajnog rješenja koje će anulirati srž problema i tako smanjiti rizik ponavljanje incidenta s istim uzrokom

Kako dokumentirati postmortem analizu

Ukratko – kako god želite dokle god su uključene ranije navedene informacije. Strukturirano u Excelu, u Word dokumentu, u nekom dediciranom sustavu, kao blog post. Nije bitno, samo da je provedeno i dokumentirano čime postižemo edukativne lekcije i znanje za budućnosti.

Ali prije svega, provjerite u vašoj organizaciji da li postoji pravilnik, uputa, regulativa ili zakonska obaveza dokumentiranja postmortem analize. U tom slučaju pridržavate se traženog. Ali, siguran sam da nitko neće imati ništa protiv da proširite traženo s informacijama koje su vama bitne te vam pomažu za svakodnevni rad ili budućnost.

Da li radite postmortem analize? Smatrate li da je napisano pretjerano ili je korisno? Pišite u komentare. Moje iskustvo pokazalo je da jedino tako je moguće stvarno i trajno riješiti problem. A time smanjiti si stres koji uzrokuje incident.