Šablona inženýrského postmortemu (bez obviňování, akční)

Proč se z postmortemů stávají obviňovací seance

Postmortemy selhávají specifickým způsobem: místnost začne přiřazovat příčinu dřív, než má společnou časovou osu. Někdo řekne „tohle způsobilo to nasazení“ ještě předtím, než je čas nasazení potvrzen. Někdo jiný řekne „alert se nespustil“, aniž by věděl, zda byl alert pro daný scénář nakonfigurován. Konverzace se změní v debatu o kauzalitě dřív, než kdokoli zjistil, co se vlastně stalo a v jakém pořadí.

Náprava je strukturální: sestavte na začátku postmortemu časovou osu incidentu společně, dřív než kdokoli pojmenuje kořenovou příčinu. Jakmile se celá místnost podívá na sled událostí — co se kdy změnilo, kdo co viděl a kdy — je příčina mnohem snazší k diskusi a mnohem méně pravděpodobně sklouzne k obviňování. Právě tuto chybu v pořadí dělá většina šablon: dávají kořenovou příčinu před časovou osu, protože kořenová příčina je to, k čemu šablona slouží. Ale právě časová osa dělá kořenovou příčinu poctivou.

Agenda (zkopírujte a vložte)

Trvání: 60 minut u přímočarého incidentu; 90 minut u komplexních selhání napříč více systémy
Formát: moderované; přítomni všichni řešitelé a pohotovostní inženýr; připravte se asynchronně s předem rozeslaným dokumentem

Sekce 1 — Shrnutí incidentu (5 min)

Data a doba trvání incidentu
Klasifikace závažnosti a zasažené systémy
Kdo ho detekoval a jak (hlášení zákazníka, alert, inženýr, monitoring)
Tato sekce je pouze faktická; zatím žádná analýza

Sekce 2 — Časová osa (20 min)

Sestavte časovou osu společně na obrazovce — ne předem napsaný dokument
Sled: co se změnilo, co bylo pozorováno, kdo jednal, co bylo rozhodnuto
Každý časový údaj by měl mít zdroj (řádek logu, PagerDuty, zpráva ve Slacku)
Když je časová osa hotová, zeptejte se: souhlasí všichni, že takto se to stalo? Neshody vyřešte, než půjdete dál

Sekce 3 — Shrnutí dopadu (5 min)

Dopad na zákazníky: kdo byl zasažen, jak dlouho, jakým způsobem
Dopad na byznys: tržby, SLA, reputace
Interní dopad: pohotovostní hodiny, narušení práce týmu
Držte to faktické; ukotví to otázku „jak zlé to bylo“ bez komentování

Sekce 4 — Kořenová příčina a přispívající faktory (20 min)

Kořenová příčina: nejbezprostřednější změna nebo podmínka, která incident umožnila
Přispívající faktory: podmínky, které ho zhoršily, ztížily detekci nebo zpomalily řešení
Nejužitečnější postmortemy identifikují vedle kořenové příčiny 3–5 přispívajících faktorů; oprava jen kořenové příčiny často mine systémové podmínky
U každého faktoru se ptejte: učinil nějaký jednotlivec nebo tým rozhodnutí, které se s dostupnými informacemi zdálo rozumné? Pokud ano, je faktor systémový, ne osobní

Sekce 5 — Co se povedlo (5 min)

Co v detekci nebo reakci fungovalo lépe, než se čekalo?
Jaký existující proces nebo nástroj omezil rozsah dopadu?
To jsou postupy, které stojí za formalizaci — pokud runbook ušetřil 20 minut, poznamenejte si to, aby se runbook udržoval

Sekce 6 — Úkoly (15 min)

Každý úkol řeší kořenovou příčinu nebo přispívající faktor — ne obecné zlepšení
Jedna odpovědná osoba na položku; termín dodání, který odráží naléhavost
Kategorizujte: detekovat dřív / zotavit se rychleji / předejít opakování
Omezte se na akce, které tým reálně stihne dokončit před dalším incidentem, ne na komplexní roadmapu spolehlivosti

Kvůli čemu šablony postmortemu selhávají

Pořadí s kořenovou příčinou na prvním místě je hlavní strukturální problém — už rozebraný výše. Druhým je zacházení s „úkoly“ jako s jedinou kategorií. Zlepšení detekce, zlepšení zotavení a zlepšení prevence vyžadují různé odpovědné osoby a různé časové horizonty. Míchání dohromady plodí seznam, který se táhne přes šest měsíců a tři týmy, což znamená, že se zodpovědnost rozptýlí a žádný z nich se nedodá.

Třetím režimem selhání je vynechání „co se povedlo“, protože to po incidentu působí jako nemístný optimismus. Není — je to jediný systematický způsob, jak identifikovat a formalizovat postupy, které fungovaly pod tlakem. Pokud monitoring, který problém zachytil, nebyl na ničí roadmapě k vybudování, poznatek, že na něm záleželo, stojí za zdokumentování. Jinak se po odeznění incidentu odsune priorita a příště budete slepí.

Nabalující se náklady incidentů, kde se přispívající faktory neřeší, a runbooků, které fungovaly, ale nikdo je neudržuje, rychle narůstají. Daň za schůzky rozebírá, jak spolu opakovaná režie schůzek a dluh z revizí incidentů interagují.

Proč je záznam z postmortemu obzvlášť obtížný

Diskuse v postmortemu rychle generují hutný, nestrukturovaný obsah: rekonstrukci časové osy, konkurenční interpretace, přiřazování úkolů více lidem, technické detaily, které v přepisu bez kontextu nedávají smysl. Shrnutí postmortemu psané z paměti nebo z upraveného zvuku je téměř vždy neúplné a neúplné záznamy postmortemů jsou k rozpoznávání vzorců napříč incidenty bezcenné.

Pavleur zachytí celou diskusi postmortemu a vygeneruje report automaticky — časovou osu tak, jak byla rekonstruována, přispívající faktory tak, jak byly pojmenovány, úkoly s odpovědnými osobami a kategoriemi tak, jak byly na schůzce vysloveny. Pokud někdo sdílel obrazovku, aby ukázal výpis logu, monitorovací graf nebo konfiguraci alertu, který se nespustil, je ten vizuál součástí reportu. Nástroje jen na zvuk tohle zcela minou; záznam postmortemu bez grafů je záznam bez důkazů. Kdokoli v týmu — včetně inženýrů, kteří se přidají po incidentu — si může přečíst úplný záznam včetně vizuálního kontextu, aniž by musel někoho žádat o rekonstrukci. Pro přímé srovnání s jinými nástroji v tomto ohledu: Pavleur vs. alternativy.

O kadenci postmortemů

Postmortem uspořádejte do 48 hodin od vyřešení incidentu, dokud jsou detaily čerstvé. Čím déle čekáte, tím víc rekonstrukce časové osy závisí na paměti místo na logách, a paměť je pod stresem nespolehlivá. U incidentů s vysokou závažností je lepších 24 hodin. U drobných incidentů mohou být asynchronní postmortemy — sdílený dokument se strukturovanými otázkami, revidovaný synchronně — efektivnější než celá schůze. Formát schůze má největší hodnotu, když byl incident nejednoznačný nebo dost závažný na to, aby na sdílené interpretaci záleželo.