Facebook Instagram Linkedin Youtube
Gyors megkeresés

On-call vezetői rutinok: eseménynapló, posztmortem

Az on-call ügyelet éjszaka akkor működik jól, ha nem hősies tűzoltás, hanem vezetett rendszer. A legtöbb cég ott csúszik el, hogy van ugyan ügyelet, de nincs:

  • egységes eseménynapló (incident log),
  • döntési rend (ki mit dönthet),
  • visszacsatolás (posztmortem),
  • és “tanuló rendszer”, ami ettől hétről hétre jobb lesz.

Eredmény: ugyanazok a hibák újra és újra visszajönnek, az on-call csapat kiég, a frontvonal bizonytalan lesz, a CSAT esik.

1) Mit jelent az “on-call vezetői rutin”?

A vezetői rutin nem azt jelenti, hogy a vezető éjjel fent ül.
Azt jelenti, hogy van rendszer, ami:

  • gyorsan reagál (containment),
  • csökkenti a kárt,
  • egységesen kommunikál,
  • és másnap javítja a gyökérokot.

Vagyis a rutin célja: kevesebb ismétlődés, kevesebb stressz, jobb minőség.

2) On-call szerepkörök (hogy ne legyen káosz)

A minimum on-call modell:

2.1 L1 (frontline) – “triázs és csomagolás”

  • P0/P1 besorolás
  • alap workaround
  • eseménynapló indítása
  • eszkaláció csomaggal

2.2 L2 on-call (specialist) – “megoldás”

  • technikai / szakmai lépések
  • hozzáférések
  • workaround implementálás

2.3 Supervisor on-call (vezető) – “döntés és kommunikáció”

  • prioritás és erőforrás döntés
  • kompenzációs keret jóváhagyás
  • kríziskommunikáció jóváhagyás
  • posztmortem levezetés másnap

Fontos: legyen 1 fő “Incident Commander” szerep P0-ra (akár L2 vagy supervisor).

3) Eseménynapló (Incident log): miért ennyire fontos?

Mert ha nincs log, másnap:

  • nem lehet visszafejteni, mi történt,
  • nem lehet tanulni,
  • és a felelősség elfolyik.

Éjszaka az eseménynapló a “vezetői memóriád”.

4) Eseménynapló sablon (kötelező mezők)

Ezt a sablont érdemes űrlapként vagy ticket formként bevezetni.

4.1 Alapadatok

  • Incident ID (automatikus)
  • Dátum / idő
  • Érintett szolgáltatás / csatorna
  • P-szint (P0/P1/P2)
  • Owner (ki viszi)

4.2 Impact

  • hány ügyfél érintett (becslés)
  • bevétel kockázat (alacsony/közepes/magas)
  • reputáció kockázat (public social? sajtó?)
  • adatvédelmi kockázat (PII érintett?)

4.3 Tünet és kiváltó ok (ahogy épp látjuk)

  • mi a tünet 2 mondatban
  • mi az első feltételezés (nem végleges)

4.4 Mit tettünk eddig (időrendi)

  • 00:12 L1 észlelte
  • 00:14 L2 riasztva
  • 00:20 workaround 1
  • 00:35 status update ügyfélnek
    Időbélyeggel, bulletben.

4.5 Ügyfélkommunikáció

  • mit ígértünk (ETA!)
  • hol kommunikáltunk (chat/email/social/status page)

4.6 Következő lépés (handover)

  • kinek a feladata reggel
  • mi a “definition of done”
  • határidő

Ez a rész menti meg a reggelt.

5) On-call riasztás: timebox és csatorna (hogy működjön)

5.1 Timebox szabályok (irányadó)

  • P0: 10–15 perc alatt L2 ack, 30–60 perc containment
  • P1: 15–30 perc reakció, 60–120 perc workaround/ETA
  • P2: ticket + reggeli handover

5.2 Csatorna szabály

  • P0: telefon/SMS/pager + chat log
  • P1: chat + fallback telefon 10–15 perc után
  • P2: ticket, nem ébreszt

6) Posztmortem: “blameless”, de kőkemény

A jó posztmortem nem bűnbakkeresés.
A jó posztmortem a rendszer javítása.

6.1 Mikor kell posztmortem?

  • minden P0-ra kötelező
  • P1-re, ha:
    • ügyfélimpact nagy,
    • vagy ismétlődő,
    • vagy reputációs.

6.2 Mikor tartsd?

  • ideális: 24–72 órán belül
  • rövid: 30–45 perc (nem meeting-maraton)

A lényeg: friss legyen az emlékezet.

7) Posztmortem sablon (copy-paste struktúra)

7.1 Tények (nem vélemény)

  • Mi történt? (timeline)
  • Mikor észleltük? (MTTA)
  • Mikor stabilizáltuk? (MTTR vagy “time to contain”)

7.2 Impact

  • hány ügyfél
  • mekkora bevétel/kár becslés
  • CSAT/kommentek

7.3 Gyökérok (root cause)

  • technikai/folyamat/emberi tényező
  • “miért” kérdés 3–5 lépésben (5 Whys egyszerűen)

7.4 Mi működött jól?

  • gyors riasztás?
  • jó workaround?
  • jó kommunikáció?

7.5 Mi nem működött?

  • hiányzó runbook?
  • túl késői eszkaláció?
  • rossz jogosultság?
  • rossz monitoring?

7.6 Action item lista (a posztmortem lényege)

Minden action item így nézzen ki:

  • Mit csinálunk
  • Ki a felelős
  • Határidő
  • Hogyan mérjük a kész állapotot

Példa:
“Checkout hiba runbook frissítése workaround lépésekkel – Feri – 2026.02.05 – QA checklistben ellenőrizve.”

8) Action item rendszer: így lesz belőle javulás, nem csak jegyzőkönyv

A posztmortem 80%-a az action item követés.

8.1 3 szabály

  1. max 3–5 action item / posztmortem (különben elhal)
  2. legyen owner + dátum
  3. legyen “definition of done”

8.2 Heti 15 perces “follow-up”

Hetente egyszer:

  • melyik action item kész?
  • melyik csúszik?
  • mi a blokk?

Ennyi. Ettől él a rendszer.

9) KPI-k vezetőknek (hogy lásd, javul-e az on-call)

9.1 Sebesség

  • MTTA (észlelés/ack)
  • MTTR (megoldás vagy containment)

9.2 Minőség

  • ismétlődés (recurrence rate)
  • reopened incidentek aránya
  • csatornákon CSAT

9.3 Zaj

  • alert noise (mennyi fals riasztás)
  • P0 arány (ha túl magas, definíció rossz)

9.4 Tudás

  • runbook coverage (top 20 ügyre van-e runbook?)
  • tréning completion (mikrotananyagok)

10) 30 napos bevezetési roadmap: on-call rutinok élesítése

1. hét: alapok

  • P0/P1 definíció
  • riasztási csatorna + fallback
  • incident log sablon bevezetése

2. hét: runbook és eszkaláció

  • top 10 P0/P1 runbook (1 oldalas)
  • escalation message template

3. hét: posztmortem rendszer

  • posztmortem sablon
  • action item tracker (táblázat / ticketing)

4. hét: mérés és finomhangolás

  • MTTA/MTTR baseline
  • zaj csökkentés (false P0)
  • tréning hiányok pótlása

A Telex Center Kft. segít ezt “kulcsrakészen” felépíteni: folyamat, sablonok, tréning, QA és riport.

11) Zárás: a jó on-call nem éjszakai hősködés, hanem tanuló rendszer

Eseménynapló nélkül nincs tanulás.
Posztmortem nélkül nincs javítás.
Action item követés nélkül nincs változás.

Ha szeretnél stabil, fenntartható on-call vezetői rendszert (incident log + posztmortem + action tracking + KPI-k), ebben a Telex Center Kft. partner.

Ajánlatért keressen minket: https://telexcenter.hu/kapcsolat/

Vissza a Blog bejegyzésekhez!