- A cél a tanulás, nem a bűnbak: a jó postmortem blameless (hibáztatás nélküli).
- A gyökérokot az 5 miért tárja fel — a tünet (újraindítás) helyett a rendszerszintű okig (hiányzó policy).
- Kötelező elemek: pontos idővonal (MTTD/MTTR), hatás, gyökérok, mi ment jól és rosszul.
- A legfontosabb rész: felelőshöz és határidőhöz kötött akció-elemek — a gazdátlan feladat sosem készül el.
- Mikor: minden jelentős (P1/P2, ügyfél-hatású, SLA-sértő) incidens és a near-miss után, 1–3 napon belül.
01A lényeg 30 másodpercben
Egy incidens után a cél nem a bűnbak, hanem a tanulás. A jó postmortem blameless (hibáztatás nélküli), strukturált, és a végén konkrét akció-elemekkel zárul, amelyek megakadályozzák az ismétlődést. A gyökérokot az 5 miért tárja fel — a tünet (újraindítottuk) helyett a rendszerszintű okig (hiányzott a policy).
Ami nélkül nem ér semmit: pontos idővonal (mikor kezdődött, mikor észleltük, mikor hárult el), őszinte mi ment jól/rosszul, és felelőshöz + határidőhöz kötött akció-elemek. Lentebb egy kész, kitölthető sablon.
A tünetet bárki elhárítja — a jó csapat a gyökérokot javítja. Ezért zárul minden postmortem konkrét, felelőshöz kötött akció-elemekkel.
02Miért „blameless"?
A blameless postmortem abból indul ki, hogy az emberek a rendelkezésükre álló információval a legjobb döntést hozták. Ha mégis hiba lett, akkor a rendszer, a folyamat vagy az eszköz hagyta cserben őket — nem a személy a hibás. Ennek gyakorlati haszna van: ha nincs félelem a következménytől, az emberek őszintén elmondják, mi történt valójában — így a valódi gyökérok feltárható. A hibáztató kultúra ezzel szemben elrejti a részleteket, és a hiba megismétlődik.
Ha az emberek félnek a következménytől, nem mondják el, mi történt valójában — a valódi gyökérok rejtve marad, és a hiba visszatér. Ne személyt keress: a rendszert, a folyamatot vagy az eszközt vizsgáld, ami cserben hagyta őket.
03Az incidens idővonala — MTTD és MTTR
A jó postmortem gerince a pontos idővonal. Két kulcs-metrika: az MTTD (észlelési idő — mennyi idő telt el a kezdet és az észlelés között) és az MTTR (elhárítási idő — az észleléstől a helyreállásig). Az akció-elemek jellemzően ezeket csökkentik.
04A kész postmortem-sablon
Másold ki és töltsd ki — ennyi kell egy használható postmortemhez:
| Cím / azonosító | Rövid, beszédes cím + dátum + súlyosság (P1/P2…) |
| Összefoglaló | 2–3 mondat: mi történt, mekkora hatás, hogyan oldódott meg |
| Hatás | Kit/mit érintett, mennyi ideig, SLA/SLO-sérülés, üzleti/ügyfél-hatás |
| Idővonal | Időbélyeges események: kezdet · észlelés · eszkaláció · elhárítás · helyreállás (MTTD, MTTR) |
| Gyökérok | A valódi, rendszerszintű ok (5 miért) — nem a felszíni tünet |
| Közreható tényezők | Mi tette lehetővé / súlyosbította (hiányzó riasztás, dokumentáció, terhelés…) |
| Mi ment jól | Amit érdemes megőrizni (gyors észlelés, jó kommunikáció…) |
| Mi ment rosszul | Őszintén, hibáztatás nélkül |
| Akció-elemek | Konkrét feladatok, felelőssel és határidővel — ez a legfontosabb rész |
| Tanulságok | Amit a szervezet egésze megtanult |
05Gyökérok — az 5 miért
Az 5 miért egyszerű, de erős: a tünettől indulva egymás után kb. ötször felteszed a „miért?" kérdést, amíg a rendszerszintű okig nem jutsz. Példa:
- Szolgáltatás leállt
- Elfogyott a memória
- Memory leak
- Nem volt memória-limit
- Nincs kötelező erőforrás-policy
06Jó akció-elemek ismérvei
- Konkrét és cselekvő — nem „legyünk óvatosabbak", hanem „vezessünk be kötelező memória-limit policy-t".
- Felelős + határidő — gazdátlan akció-elem soha nem készül el.
- A gyökérokot célozza, nem a tünetet.
- Követett — a ticket-rendszerben nyomon követve, lezárásig.
- Vegyesen megelőző (ne forduljon elő) és detektáló (ha mégis, hamarabb lássuk).
07Mikor és hogyan?
Készíts postmortemet minden jelentős incidens után: ügyfél-hatás, SLA/SLO-sérülés, adatvesztés vagy biztonsági esemény, vagy szokatlanul hosszú helyreállás esetén. Sok érett csapat küszöböt használ (minden P1/P2). A near-miss (majdnem-baleset) is megér egy rövid elemzést — olcsóbban tanulsz. Időzítés: 1–3 napon belül, amíg friss; a megbeszélés legyen blameless és időkeretes; az eredmény legyen megosztott (a szervezet egésze tanuljon belőle).
A near-miss (majdnem-baleset) esetekből olcsóbban tanulsz, mint a valódi kiesésből — ezeket is elemezd röviden. A postmortemet készítsd el 1–3 napon belül, amíg friss, és oszd meg, hogy az egész szervezet tanuljon belőle.
08A kör bezárása
A postmortem akkor ér valamit, ha az akció-elemek tényleg elkészülnek, és a tanulság visszafolyik a rendszerbe: a monitoringba (jobb riasztás → kisebb MTTD), a runbookokba és az SLO-kba, a kapacitástervezésbe és a review-checklistekbe. Itt kapcsolódik a 24/7 NOC és az observability — a pontos idővonal és a gyors detektálás az ő feladatuk. A DR-oldalhoz lásd az RTO/RPO cikket, a kiesés árához a leállás-költség kalkulátort.
09Gyakran ismételt kérdések
Mi a blameless postmortem?
Hibáztatás nélküli, tanulás-központú incidens-elemzés: a rendszer/folyamat hibáját keresi, nem a személyét — így őszinte beszámolók és valódi gyökérok-feltárás lesz.
Mit tartalmazzon?
Összefoglaló, hatás, idővonal (MTTD/MTTR), gyökérok, közreható tényezők, mi ment jól/rosszul, és felelőshöz + határidőhöz kötött akció-elemek.
Mi az 5 miért?
Gyökérok-elemzés: ~5-ször felteszed a „miért?"-et a tünettől a rendszerszintű okig; a javítás az utolsó szintre kell.
Mikor készítsek?
Minden jelentős (P1/P2, ügyfél-hatású, SLA-sértő) incidens és a near-miss esetek után, 1–3 napon belül.
Hogyan kapcsolódik a postmortem a monitoringhoz és az SLO-hoz?
Szorosan. A jó idővonalhoz pontos telemetria kell (mikor mi történt) — ez a monitoring/observability dolga. Az incidens hatása az SLO/error budget terhére megy, így a postmortem akció-elemei gyakran a detektálás (MTTD) és az elhárítás (MTTR) gyorsítását célozzák — riasztás-finomítás, runbook, automatizáció. A postmortem zárja a kört: az incidensből tanulás visszafolyik a monitoringba, a runbookokba és a kapacitástervezésbe.
10Építsünk tanuló incidenskezelést
Bevezetjük a blameless postmortem gyakorlatát, a sablonokat és az akció-elem-követést, és összekötjük a monitoringgal és a runbookokkal — hogy az incidensekből a céged tényleg tanuljon, és csökkenjen az MTTD/MTTR. Banki és nagyvállalati NOC-tapasztalatból, a te csapatod méretére szabva.