Un postmortem este ușor de convocat și greu de făcut util. Ședința are loc, se scrie un document, se notează patru acțiuni, iar șase luni mai târziu aceeași defecțiune reapare, în timp ce cineva găsește vechiul document căutând cu totul altceva.

Expresia fără vinovați primește cea mai mare parte a atenției în discuțiile despre acest subiect, și chiar contează, dar nu acolo se produce eșecul. Multe organizații conduc analize scrupulos lipsite de vinovați care nu schimbă nimic, pentru că analiza a fost tratată drept rezultatul livrat, nu drept lucrul care produce un rezultat.

Testul care arată dacă ale voastre funcționează este jenant de simplu: ce proporție dintre acțiunile ultimelor șase luni este finalizată? Dacă răspunsul este majoritatea, procesul funcționează, indiferent cum arată. Dacă este sub jumătate, țineți ședințe în loc să conduceți un proces, iar șabloanele mai bune nu vor rezolva asta. Mai puține acțiuni, cu responsabil și termen, bat o listă completă pentru care nimeni nu are timp.

La ce folosește de fapt un postmortem

Nu pentru a explica ce s-a întâmplat. Oamenii din încăpere știu asta, de regulă, încă dinainte de închiderea incidentului.

Există pentru a găsi condițiile care au permis unei probleme mici să devină una mare și pentru a schimba câteva dintre ele. Este o întrebare diferită de ce s-a stricat, iar distincția se vede imediat în redactare. “Baza de date a rămas fără conexiuni” descrie ce s-a stricat. “Nimic nu alerta la saturarea pool-ului de conexiuni, iar tabloul de bord care ar fi arătat-o nu este în runbook-ul echipei de gardă” descrie o condiție, iar pe o condiție poți acționa.

Al doilea lucru pe care îl produce, subevaluat constant, este o relatare comună a evenimentului. Fără ea, fiecare rămâne cu propria versiune, iar versiunile alunecă spre ceea ce fiecare credea deja despre sistem. Un an mai târziu, două echipe se contrazic pe marginea unui incident pe care l-au trăit împreună.

Fără vinovați înseamnă ceva precis

Nu înseamnă că nimeni nu a greșit. Înseamnă că analiza pornește de la ideea că o persoană care a acționat rezonabil cu informațiile disponibile a luat o decizie care s-a dovedit greșită, și întreabă de ce acea decizie părea corectă în acel moment. Cartea SRE de la Google descrie această practică și tiparele de eșec care o însoțesc.

Motivul pentru care asta nu este doar bunăvoință este că vina distruge informația. Într-o organizație în care incidentele rămân lipite de persoane, oamenii descriu evenimentele cu grijă, omit detaliul care arată prost și amână raportarea până înțeleg suficient încât să o prezinte în siguranță. Analiza lucrează atunci cu o relatare retușată din instinct de autoapărare, adică cea mai proastă intrare posibilă.

Practic, fără vinovați este o proprietate a limbajului. “De ce ai repornit serviciul?” invită la apărare. “Ce arăta tabloul de bord când ai decis să repornești?” invită la informație. A doua întrebare este și cea mai utilă, pentru că răspunsul este un fapt despre monitorizarea voastră, nu despre un coleg.

Dacă există o problemă reală de performanță individuală, tratați-o separat și direct. Făcută în interiorul analizei de incident, ea corupe analiza și este oricum un mod slab de a purta acea discuție.

Cum construiești o cronologie care te învață ceva

Cronologia este partea cea mai valoroasă a documentului și partea scrisă prost cel mai des, ca o succesiune de evenimente tehnice din care oamenii au fost scoși.

Notați ce știau oamenii și când. Nu doar “serviciul a fost repornit la 14:32”, ci ce putea vedea persoana la 14:32 și ce credea că se întâmplă. Acolo stă materialul pe care poți acționa, pentru că o întârziere de cincisprezece minute cauzată de un tablou de bord ambiguu este o problemă rezolvabilă, iar o întârziere de cincisprezece minute consemnată ca o gaură nu este.

Marcați momentele care au contat: când a început, când a observat cineva prima dată, când a fost implicată persoana potrivită, când a fost înțeleasă cauza, când a fost atenuat, când a fost rezolvat. În intervalele dintre ele stă îmbunătățirea, iar timpul până la detectare este foarte des cel mai mare dintre ele.

Scrieți cronologia cât totul este proaspăt, ideal în una sau două zile. Amintirea a ceea ce credea cineva într-un anumit moment se pierde mult mai repede decât amintirea a ceea ce s-a întâmplat.

Rareori există o singură cauză rădăcină

Expresia încurajează oprirea la prima explicație plauzibilă, iar incidentele de orice mărime sunt lanțuri în care mai multe lucruri trebuiau să fie adevărate simultan.

O analiză utilă enumeră în schimb factori contribuitori: modificarea care a declanșat totul, testul care ar fi prins-o și care nu exista, alerta trimisă pe un canal pe care nu îl urmărește nimeni, runbook-ul corect pentru o arhitectură anterioară. Fiecare este o oportunitate separată, iar voi puteți repara cele două mai ieftine în locul celui care se nimerea primul în lanț.

Asta reduce și o distorsiune frecventă. Când o analiză numește o singură cauză rădăcină, aceea este foarte des “eroarea umană”, care este o descriere și nu o explicație, și care închide investigația exact acolo unde ar fi trebuit să înceapă.

Cum faci să se întâmple urmărirea

Aici trăiesc sau mor postmortem-urile, iar remediile nu au nimic spectaculos.

Mai puține acțiuni. Două care se fac bat opt care nu se fac. Ordonați-le după cât reduc timpul de detectare, raza de impact sau probabilitatea, și tăiați restul.

Un responsabil cu nume și un termen, în trackerul vostru obișnuit de lucru, nu în document. Acțiunile care trăiesc doar în postmortem sunt invizibile în planificare, adică exact atunci când munca se programează.

Revedeți acțiunile deschise la următorul postmortem. Acest singur obicei face mai mult decât orice șablon. Face vizibil ce nu s-a terminat și transformă un șir de ședințe fără legătură într-un proces.

Acceptați cinstit unele acțiuni. O echipă care termină constant jumătate din ce promite ar trebui să promită pe jumătate. A consemna o intenție pe care nimeni nu o va finanța este mai rău decât a consemna decizia de a nu acționa, pentru că a doua este măcar adevărată.

Îmbunătățirile care ies din asta sunt din aceeași familie cu ghidul de recuperare după dezastru și cu strategiile de testare software: detectare mai rapidă, rază mai mică, sistem operabil de altcineva.

Mecanik conduce analize de incident pe sistemele pe care le întreținem, ca parte din analiză securitate server. Tiparul se repetă aproape mereu: cauza tehnică a fost înțeleasă repede, iar decalajul până la detectare a fost partea scumpă.

Întrebări frecvente

La ce folosește un postmortem? Să găsească condițiile care au lăsat o problemă mică să devină mare și să schimbe câteva dintre ele, ceea ce este o întrebare diferită de ce s-a stricat. Produce și o relatare comună a evenimentului, fără de care fiecare rămâne cu o versiune privată care alunecă spre ceea ce credea deja despre sistem.

Ce înseamnă de fapt fără vinovați? Că analiza pornește de la ideea că o persoană care a acționat rezonabil cu informațiile disponibile a luat o decizie care s-a dovedit greșită, și întreabă de ce părea corectă atunci. Contează pentru că vina distruge informația: oamenii își retușează relatarea ca să se protejeze, iar analiza lucrează apoi cu o intrare coruptă.

Trebuie un postmortem să identifice o singură cauză rădăcină? Nu. Incidentele de orice mărime sunt lanțuri în care mai multe condiții trebuiau să fie adevărate simultan, deci enumerarea factorilor contribuitori este mai utilă. Vă lasă să reparați cele două mai ieftine în loc de primul din lanț și evită concluzia “eroare umană”, care este o descriere, nu o explicație.

Ce trebuie să conțină o cronologie a incidentului? Ce știau oamenii și când, nu doar ce au făcut sistemele. Notați când a început, când a observat cineva prima dată, când a fost implicată persoana potrivită, când a fost înțeleasă cauza, când a fost atenuat și când s-a rezolvat. În intervale stă îmbunătățirea, iar timpul până la detectare este de obicei cel mai mare.

De ce nu se termină niciodată acțiunile din postmortem? Pentru că trăiesc în document, nu în trackerul de lucru, deci sunt invizibile când munca se programează. Se rezolvă cu mai puține acțiuni, un responsabil cu nume și un termen în trackerul obișnuit, plus o trecere în revistă a acțiunilor deschise la începutul următorului postmortem, care face vizibil ce nu s-a terminat.