Mit teszel, hogy megakadályozd, hogy ugyanaz a fajta incident másodszor is megtörténjen?

Question

Accepted Answer

Futtass egy **blameless postmortemet**, amely megtalálja a rendszerszintű okot, majd alakítsd át **konkrét, felelősökkel ellátott és követett** akciópontokká — és ellenőrizd, hogy valóban leszállnak. A cél nem az, hogy megtaláld, kit hibáztass; az, hogy úgy változtasd meg a rendszert, hogy ugyanaz a hibaosztály lehetetlenné vagy öndetektálóvá váljon.

## A mag-hurok

1. **Blameless postmortem.** Építs egy őszinte idővonalat: mi történt, mikor detektáltuk, hogyan reagáltunk, mi volt a hatás. A hibáztatás megöli az igazságot, amire szükséged van.
2. **Áss a rendszerszintű okig**, ne a kiváltóig. "Egy mérnök rossz configot pusholt" egy kiváltó; "nem volt validáció vagy fokozatos kiterjesztés a configokra" az ok. Használd az **Öt Miértet**, de állj meg a rendszernél, soha ne egy embernél.
3. **Generálj megelőzési rétegeket**, ne egyetlen javítást:
   - **Megelőzés** — tedd lehetetlenné a hibát (validáció, típusok, korlátok).
   - **Detektálás** — kapd el hamarabb (alertek, SLO-k, szintetikus ellenőrzések).
   - **Mitigáció** — korlátozd a robbanási sugarat (rollback, flagek, circuit breakerek).
4. **Rendelj felelősöket és határidőket.** Egy felelős nélküli akciópont egy kívánság. Kövesd őket valódi munkaként a backlogban.
5. **Ellenőrizd és zárd a hurkot.** Leszállt a javítás? Elkapta volna az eredetit? Valóban javult az MTTR és a detektálás?

## Kompromisszumok és buktatók

- **Postmortemek, amelyek dokumentumokat termelnek, nem változtatásokat** — a leggyakoribb kudarc. Utánkövetés nélkül újra találkozol ugyanazzal az incidenttel.
- **A konkrét tünet túljavítása**, miközben a bug-osztály nyitva marad. A kategóriát javítsd, ne csak ezt a példányt.
- **Alert fatigue** abból, hogy detektálást halmozol hangolás nélkül; a zajos alerteket figyelmen kívül hagyják, és a következő incident átcsúszik.
- **A hibáztató kultúra** föld alá kényszeríti a jelentést; elveszíted a near-misseket, amelyek a legolcsóbb leckéid.
- Kezeld az **ismétlődő incidenteket a folyamat kudarcának jeleként**, ne balszerencseként — kövesd az ismétlődést metrikaként.

## Miért fontos

Az incidentek tandíj, amit már megfizettél; az egyetlen pazarlás az, ha nem tanulsz belőlük. Egy team, amely szisztematikusan megelőzi az ismétlődést, minden negyedévben megbízhatóbbá válik, míg egy team, amely csak tüzet olt, örökké újraéli ugyanazokat a kieséseket. Ennek a tanulási huroknak — és az őszinteséghez szükséges biztonságnak — a felépítése az egyik legtartósabb dolog, amit egy Tech Lead maga után hagyhat.