Egy incidens utáni post-mortem olyan, mint egy repülőgép fekete dobozának elemzése. Nem a bűnösöket keressük, hanem a rendszerszintű okokat, hogy a jövőben elkerülhessük a hasonló eseményeket. A cél a tanulás és a megerősödés. Egy jól strukturált, „blameless” (vádaskodásmentes) post-mortem a proaktív védekezés egyik legfontosabb eszköze.
A sablon felépítése
Az alábbi sablon egy szilárd kiindulási alapot ad, amelyet a szervezet saját folyamataihoz és az incidens súlyosságához igazíthatsz. A lényeg a következetesség és az alaposság.
1. Összefoglaló (Executive Summary)
Ez a TL;DR (Too Long; Didn’t Read) szekció a vezetők és más csapatok számára. Legyen rövid, tömör és lényegre törő.
- Incidens neve: Egyedi, beszédes azonosító (pl. „PROD-DB-LATENCY-2024-10-26”).
- Dátum és idő: Az incidens kezdete, észlelése és teljes megoldása.
- Súlyosság: Előre definiált skála szerint (pl. SEV-1, SEV-2).
- Rövid leírás: 1-2 mondatban mi történt.
- Hatás: Milyen üzleti, felhasználói vagy technikai hatása volt az incidensnek? (pl. 15 perces teljes szolgáltatáskiesés, 5% hibaarány a bejelentkezésnél).
- Fő tanulságok: 2-3 kulcsfontosságú pont, ami a legfőbb tanulság.
2. Részletes idővonal (Detailed Timeline)
Ez a dokumentum legobjektívebb része. Szigorúan a tényekre koncentrál, pontos időbélyeggel ellátva minden eseményt. Itt rögzítesz mindent, a riasztás első jelétől a kommunikáción át a javításokig.
# Időpont (UTC) - Esemény
2024-10-26 14:32:15 - Automatikus riasztás érkezik: "API Gateway P99 Latency > 2000ms"
2024-10-26 14:34:02 - Kovács János (ügyeletes) nyugtázza a riasztást és megkezdi a vizsgálatot.
2024-10-26 14:41:50 - Első hipotézis: a felhasználói adatbázis túlterhelt.
2024-10-26 14:45:10 - Eskaláció a DB csapat felé (Nagy Mária).
2024-10-26 14:58:30 - A DB csapat azonosít egy rosszul optimalizált lekérdezést, amit egy új feature telepítése okozott.
2024-10-26 15:05:00 - A hibás feature flag kikapcsolásra kerül.
2024-10-26 15:07:00 - A rendszermetrikák (latencia, hibaarány) visszaállnak a normál szintre.
2024-10-26 15:15:00 - Az incidens lezárva, a post-mortem folyamat elindítva.3. Kiváltó Ok Elemzése (Root Cause Analysis – RCA)
Itt mélyebbre ásunk. Nem elégszünk meg az elsődleges okkal („egy rossz lekérdezés”). A cél megtalálni a folyamatbeli vagy rendszerszintű hiányosságot, ami lehetővé tette a hiba bekövetkezését. Az „5 Miért” (5 Whys) technika itt különösen hasznos.
- Miért lassult le az API? Mert egy lekérdezés túlterhelte az adatbázist.
- Miért került be ez a lekérdezés a rendszerbe? Mert egy új funkció részeként került telepítésre.
- Miért nem vettük észre a problémát a telepítés előtt? Mert a terheléses tesztkörnyezet nem szimulálta pontosan az éles forgalmi mintázatokat.
- Miért nem volt pontos a tesztkörnyezet? Mert a tesztadatok nem reprezentálták az éles adatok eloszlását.
- Miért nem voltak reprezentatívak a tesztadatok? Mert a tesztadat-generálási folyamatunk elavult és nem követi a felhasználói bázis növekedését. (Ez már egy rendszerszintű, orvosolandó probléma.)
4. Hatáselemzés (Impact Analysis)
Itt számszerűsítjük a kárt. Ez segít a prioritások meghatározásában és a jövőbeli befektetések indoklásában.
- Felhasználói hatás: Hány felhasználót érintett? Mennyi ideig? Milyen funkciók nem működtek?
- Üzleti hatás: Elvesztett bevétel, SLA sértés, brand kár.
- Technikai hatás: Adatvesztés, adatkonzisztencia-problémák, egyéb rendszerekre gyakorolt hatás.
- Belső hatás: Hány mérnök hány munkaóráját kötötte le az incidens kezelése?
5. Megoldási Lépések és Rövid Távú Intézkedések
Ez a rész azt dokumentálja, hogy mit tett a csapat az incidens alatt a helyzet stabilizálására. Mi működött jól, és mi nem? Ez értékes visszajelzés az incidens-reagálási folyamat (IRP) finomításához.
6. Hosszú Távú Tanulságok és Akcióterv (Action Items)
Ez a post-mortem legfontosabb eredménye. Konkrét, felelőshöz rendelt, határidős feladatok listája, amelyek megakadályozzák a probléma újbóli előfordulását. SMART célokat (Specifikus, Mérhető, Elérhető, Releváns, Időhöz kötött) tűzz ki!
| Azonosító | Feladat Leírása | Felelős | Határidő | Státusz |
|---|---|---|---|---|
| AI-01 | A terheléses tesztkörnyezet adatbázisának frissítése anonimizált éles adatokkal. | Infra Csapat | 2024.11.15. | Folyamatban |
| AI-02 | CI/CD pipeline kiegészítése automatikus lekérdezés-elemző (query analyzer) lépéssel. | DevOps Csapat | 2024.12.01. | Tervezett |
| AI-03 | Feature flag rendszerekhez kapcsolódó telepítési playbook felülvizsgálata. | Alfa Csapat | 2024.11.20. | Befejezett |
7. Résztvevők és Felelősök
Egy egyszerű lista azokról, akik részt vettek az incidens kezelésében és a post-mortem megbeszélésen. Ez nem a felelősségre vonásról, hanem az átláthatóságról szól.
- Incidens parancsnok (Incident Commander): Kovács János
- Kommunikációs felelős: Kiss Anna
- Résztvevő mérnökök: Nagy Mária (DB), Szabó Péter (Backend)
- Post-mortem moderátor: Horváth Zita