Három szintű incidenskezelés — 30 nap tapasztalata 121 riasztáson
Az incidenskezelés nem "szerencsére nem történt semmi". Megmutatjuk a 3 szintű playbookot, amit a 30 nap alatt 121 riasztáson csiszoltunk.
A jó incidenskezelés nem akkor látszik, amikor minden rendben — hanem akkor, amikor épp valami nincs.
A Nortinia 2026 Q1-ben 38 szervert, 83 site-ot és öt saját terméket üzemeltetett. 30 nap alatt 121 riasztás jött be a monitoring rendszerből. Hogy mi történt ezekkel? A 3 szintű playbook válaszol.
L1 — automatikus válasz
A 121 riasztásból 98 az L1 szinten zárult le: automatikus újraindítás, self-heal, vagy egyszerű tisztítás. Ezekre emberi beavatkozás nem volt szükséges, de minden egyes incidens automatikusan audit logba került, és az AI-asszisztens megírta a post-mortem vázát.
L2 — ügyeletes mérnök (15 perc SLA)
- 19 incidens eljutott az L2-ig
- Ügyeletes mérnök 15 percen belül válaszolt
- A NIP Platform incident UI azonnal mutatta a kontextust
- Minden L2 incidenshez automatikus dedikált csatorna készült
- A runbook link automatikusan benn volt a ticketben
L3 — architect és ügyfélkommunikáció
4 incidens ért el L3-ig. Ezek mindegyike architect-szintű beavatkozást igényelt — egy adatbázis migrációs visszaállítás, egy DLQ replay, egy TLS cert rotation és egy hypervisor migráció. Mind a 4-nél kimenő ügyfélkommunikáció kötelező volt, a mi oldalunkon egyetlen sablon szövegcsomaggal.
A 121 incidensből 117-et automatikus vagy L2-szintű reakcióval megoldottunk — ügyfélhatás nélkül. A maradék 4 is 45 percen belül zárult. Ezek a számok az oka annak, hogy a Nortinia-tól kapott monitoring nem csak "ok, kapcsolva van".
A legrosszabb incidens nem az, amelyik megtörténik. Hanem az, amiről három napig nem is tudsz.
A runbook, ami a háttérben fut
Minden L2+ incidenshez tartozik egy runbook: 5-7 lépés, amit az ügyeletes mérnök követ, mielőtt bárkit felébresztene. A lépések sorrendje fontos — először mindig a "kit érint" kérdés (customer impact assessment), aztán a "mi változott az elmúlt 4 órában" (deploy history), és csak utána jön a konkrét tünet elemzés. A runbook egy markdown file a monorepo-ban, és a NIP Platform auto-linkeli a ticket mellé. A lépések 80%-át egy junior mérnök is végig tudja csinálni — a maradék 20% az, amihez senior kell.
A post-mortem kadencia
Minden L2 és L3 incidensről blameless post-mortem készül 48 órán belül. Nem az "aki rontotta el" kérdésre keressük a választ, hanem arra, hogy mi volt az a rendszer-szintű hiányosság, ami megengedte az incidenst. A post-mortemek nyilvánosak a csapatnak, és az akcióelemek egy közös munkaboardra kerülnek saját due date-tel. 30 nap alatt 23 post-mortem készült, és ebből 41 akcióelem jött ki — 38 már megvalósult. Ez a 83% valós javítási arány az oka, hogy a havi incidensszám csökken.