Inžinerinio postmortem šablonas (be kaltinimų, veiksmingas)

Kodėl postmortem'ai virsta kaltinimo sesijomis

Postmortem'ai žlunga specifiniu būdu: kambarys pradeda priskirti priežastį dar prieš kambariui turint bendrą laiko juostą. Kažkas sako „diegimas tai sukėlė“ dar nepatvirtinus diegimo laiko. Kažkas kitas sako „įspėjimas nesuveikė“ nežinodamas, ar įspėjimas apskritai buvo sukonfigūruotas tam scenarijui. Pokalbis virsta debatais apie priežastingumą dar prieš kam nors nustačius, kas iš tikrųjų įvyko ir kokia tvarka.

Sprendimas yra struktūrinis: postmortem pradžioje kartu sukurkite incidento laiko juostą dar prieš kam nors įvardijant pagrindinę priežastį. Kai visas kambarys apžvelgė įvykių seką — kas pasikeitė kada, kas ką matė kuriuo metu — priežastį kur kas lengviau aptarti ir kur kas mažiau tikėtina, kad ji virs kaltinimu. Tai eiliškumo klaida, kurią daro dauguma šablonų: jie pagrindinę priežastį iškelia prieš laiko juostą, nes pagrindinei priežasčiai šablonas ir skirtas. Bet būtent laiko juosta daro pagrindinę priežastį sąžiningą.

Darbotvarkė (nukopijuokite ir įklijuokite)

Trukmė: 60 minučių paprastam incidentui; 90 minučių sudėtingiems kelių sistemų gedimams
Formatas: vedamas; dalyvauja visi reagavusieji ir budėjęs inžinierius; ruoškitės asinchroniškai su iš anksto skaitomu dokumentu

1 skiltis — Incidento santrauka (5 min.)

Incidento datos ir trukmė
Sudėtingumo klasifikacija ir paveiktos sistemos
Kas jį aptiko ir kaip (kliento pranešimas, įspėjimas, inžinierius, stebėsena)
Ši skiltis tik faktinė; jokios analizės kol kas

2 skiltis — Laiko juosta (20 min.)

Sukurkite laiko juostą kartu ekrane — ne iš anksto parašytą dokumentą
Seka: kas pasikeitė, kas buvo pastebėta, kas veikė, kas buvo nuspręsta
Kiekviena laiko žymė turi turėti šaltinį (žurnalo eilutė, PagerDuty, Slack žinutė)
Kai laiko juosta baigta, paklauskite: ar visi sutinka, kad taip įvyko? Išspręskite nesutarimus prieš eidami toliau

3 skiltis — Poveikio santrauka (5 min.)

Poveikis klientams: kas paveiktas, kiek ilgai, kokiu būdu
Poveikis verslui: pajamos, SLA, reputacija
Vidinis poveikis: budėjimo valandos, komandos sutrikdymas
Laikykite tai faktine; tai įtvirtina klausimą „kiek buvo blogai“ be redakcinių pastebėjimų

4 skiltis — Pagrindinė priežastis ir prisidedantys veiksniai (20 min.)

Pagrindinė priežastis: artimiausias pokytis ar sąlyga, dėl kurios incidentas tapo įmanomas
Prisidedantys veiksniai: sąlygos, dėl kurių jis pablogėjo, tapo sunkiau aptinkamas ar lėčiau šalinamas
Naudingiausi postmortem'ai įvardija 3–5 prisidedančius veiksnius greta pagrindinės priežasties; ištaisant vien pagrindinę priežastį dažnai praleidžiamos sisteminės sąlygos
Kiekvienam veiksniui paklauskite: ar koks nors asmuo ar komanda priėmė sprendimą, kuris atrodė pagrįstas turint tuo metu prieinamą informaciją? Jei taip, veiksnys yra sisteminis, o ne asmeninis

5 skiltis — Kas pavyko (5 min.)

Koks aptikimas ar reagavimas suveikė geriau nei tikėtasi?
Koks esamas procesas ar įrankis apribojo poveikio spindulį?
Tai vertos formalizuoti praktikos — jei „runbook“ sutaupė 20 minučių, pažymėkite tai, kad „runbook“ būtų prižiūrimas

6 skiltis — Veiksmai (15 min.)

Kiekvienas veiksmas sprendžia pagrindinę priežastį ar prisidedantį veiksnį — o ne bendrą patobulinimą
Vienas atsakingas asmuo vienam punktui; įgyvendinimo data, atspindinti skubą
Suskirstykite: greičiau aptikti / greičiau atsigauti / užkirsti kelią pasikartojimui
Apsiribokite veiksmais, kuriuos komanda realiai gali užbaigti iki kito incidento, o ne visapusišku patikimumo kelrodžiu

Kas postmortem šablonus daro nesėkmingus

Pagrindinės priežasties pirmumo eiliškumas yra pagrindinė struktūrinė problema — jau aptarta aukščiau. Antra — „veiksmų“ traktavimas kaip vienos kategorijos. Aptikimo patobulinimams, atsigavimo patobulinimams ir prevencijos patobulinimams reikia skirtingų atsakingų asmenų ir skirtingų terminų. Juos sumaišius gaunamas sąrašas, apimantis šešis mėnesius ir tris komandas, o tai reiškia, kad atskaitomybė išsisklaido ir nė vienas iš jų neįgyvendinamas.

Trečias nesėkmės režimas — „kas pavyko“ praleidimas, nes tai atrodo kaip netinkamas optimizmas po incidento. Bet taip nėra — tai vienintelis sisteminis būdas atpažinti ir formalizuoti praktikas, kurios veikė spaudimo sąlygomis. Jei stebėsena, pagavusi problemą, nebuvo niekieno kelrodyje, sužinojimas, kad ji buvo svarbi, vertas dokumentavimo. Kitaip jai bus skiriamas mažesnis prioritetas, kai incidentas išblanks, ir kitą kartą būsite akli.

Incidentų, kuriuose prisidedantys veiksniai lieka nesutvarkyti, o veikę „runbook'ai“ lieka neprižiūrimi, besikaupianti kaina auga greitai. Susitikimų mokestis aptaria, kaip pasikartojančios susitikimų pridėtinės sąnaudos ir incidentų peržiūros skola sąveikauja.

Kodėl postmortem fiksavimas ypatingai sunkus

Postmortem diskusijos greitai sugeneruoja tankų, nestruktūruotą turinį: laiko juostos atkūrimą, konkuruojančias interpretacijas, kelių asmenų veiksmų priskyrimą, techninę detalę, kuri stenogramoje be konteksto neturės prasmės. Postmortem santrauka, parašyta iš atminties ar suredaguoto garso, beveik visada nepilna, o nepilni postmortem įrašai nenaudingi šablonų atpažinimui tarp incidentų.

Pavleur užfiksuoja pilną postmortem diskusiją ir automatiškai sugeneruoja ataskaitą — laiko juostą, kaip ji atkurta, prisidedančius veiksnius, kaip jie įvardyti, veiksmus su atsakingais asmenimis ir kategorijomis, kaip išsakyta susitikime. Jei kas nors bendrino ekraną, kad parodytų žurnalo ištrauką, stebėsenos grafiką ar įspėjimo konfigūraciją, kuri nesuveikė, tas vizualas yra ataskaitos dalis. Vien garso įrankiai to visiškai nepagauna; postmortem įrašas be grafikų yra įrašas be įrodymų. Bet kuris komandos narys — įskaitant inžinierius, prisijungusius po incidento — gali perskaityti pilną, su vizualiniu kontekstu, įrašą neprašydamas jo atkurti. Tiesioginiam palyginimui su kitais įrankiais šiuo klausimu: Pavleur ir alternatyvos.

Apie postmortem kadenciją

Postmortem veskite per 48 valandas nuo incidento išsprendimo, kol detalės šviežios. Kuo ilgiau laukiate, tuo labiau laiko juostos atkūrimas priklauso nuo atminties, o ne nuo žurnalų, o atmintis streso sąlygomis nepatikima. Aukšto sudėtingumo incidentams 24 valandos geriau. Nedideliems incidentams asinchroniniai postmortem'ai — bendras dokumentas su struktūruotais klausimais, peržiūrimas sinchroniškai — gali būti efektyvesni nei pilnas susitikimas. Susitikimo formatas vertingiausias, kai incidentas buvo pakankamai dviprasmiškas ar didelės rizikos, kad bendra interpretacija svarbi.