Az on-call nem attól működik, hogy “van egy ügyeletes”. Attól működik, hogy van SLA, van riasztási mátrix, és van egyértelmű felelősség. Ha bármelyik hiányzik, az on-call káosz lesz: késői reakció, pingpong, félrekommunikált ETA, és végül CSAT-esés + bevételvesztés.
1) Mitől lesz “igazi” on-call rendszer?
Az on-call rendszer 4 építőkocka:
- Kategorizálás (mi P0, mi P1, mi P2)
- SLA (mennyi időn belül történjen meg az ack + containment)
- Riasztási mátrix (kit, mikor, milyen csatornán)
- Felelősségek (ki az owner, ki az incident commander, ki dönt kompenzációról)
Ha ezt leteszed, az ügyelet nem “érzés”, hanem folyamat.
2) P0/P1/P2 – az on-call közös nyelve
P0 – Kritikus (azonnali)
- payment teljes kiesés / checkout down
- adatvédelmi incidens gyanú (PII leak)
- fraud / account takeover hullám
- rendszerleállás sok ügyfelet érint
- tömeges rendelés/booking hiba
Cél: gyors elismerés + stabilizálás.
P1 – Magas (üzlet/reputáció)
- egyedi checkout hiba (menthető nagy kosár)
- social krízis public felületen
- B2B ügyfél nem tud dolgozni
- logisztikai elakadás “holnap kell”
P2 – Normál (parkolható)
- refund kivizsgálás
- számlázás
- admin jellegű kérdések
Aranyszabály: P2 miatt nem ébresztünk.
3) SLA: mit mérj és milyen célérték kell?
Az on-call SLA nem csak “válaszidő”. 3 szintű.
3.1 MTTA (Mean Time To Acknowledge) – “láttam”
Mikor reagál az ügyeletes, hogy átvette?
Irányadó:
- P0: 10–15 perc
- P1: 15–30 perc
- P2: következő munkanap
3.2 Time to Contain – “kárt csökkenteni”
Nem kell teljesen megoldani, de legyen stabil állapot:
- workaround,
- rollback,
- status kommunikáció,
- vagy ticket + ETA.
Irányadó:
- P0: 30–60 perc
- P1: 60–120 perc
3.3 MTTR (Mean Time To Resolve) – “helyreállt”
Ez már szektorfüggő. P0-nál sokszor órák, néha napok.
Trükk: P0-nál a containment sokkal fontosabb, mint a “végső fix” éjjel.
4) Riasztási mátrix: kit ébresztünk, mikor, milyen csatornán?
A riasztási mátrix egy egyszerű táblázat logikája, amit minden L1 fejben tud.
4.1 Minimum riasztási csatornák
- Chat (Teams/Slack): kontext, log, linkek
- Telefon/SMS: felébresztés (P0)
- Ticketing: nyomkövetés, handover, audit
4.2 Riasztási szabály (fallback)
Ha az on-call nem reagál:
- P0: 10 perc → következő on-call + supervisor
- P1: 15 perc → supervisor
- P2: nincs fallback (ticket)
4.3 Mátrix mintapélda (egyszerű)
P0 (kritikus)
- Primary: L2 IT/Security on-call (telefon/SMS)
- Secondary: Supervisor on-call (telefon)
- Log: chat csatorna + incident ticket
P1 (magas)
- Primary: L2 specialist (chat)
- Fallback: 15 perc után telefon
- Escalate: supervisor, ha döntés/kompenzáció kell
P2 (normál)
- Ticket + ETA (reggel)
Fontos: mindig legyen kijelölt Incident Commander P0-ra.
5) Felelősségek: ki mit csinál? (RACI egyszerűen)
Ha nincs felelősség, az on-call szétfolyik.
A minimum szerepek:
5.1 L1 (frontline)
- triázs (P0/P1/P2)
- adatbekérés + PII védelem
- “escalation package” összeállítás
- incident log indítás
5.2 L2 on-call (specialist)
- workaround / technikai lépések
- hozzáférések
- containment döntések (mit kapcsoljunk le, mit állítsunk vissza)
5.3 Supervisor on-call (vezető)
- prioritás döntés (melyik ügy előre)
- kompenzáció jóváhagyás
- kríziskommunikáció (social/status)
- posztmortem tulajdonos másnap
5.4 Security on-call (ha releváns)
- fraud/ATO/PII incidens kezelése
- evidenciagyűjtés (logok)
- compliance döntések
RACI tipp:
P0-nál legyen 1 “A” (Accountable) személy: Incident Commander.
6) “Escalation package”: mit küldj, hogy ne legyen visszakérdezés?
Az on-call rendszerek 70%-a ott bukik, hogy az L1 nem ad kontextust.
Kötelező 7 mező (copy-paste)
- Szint: P0/P1
- Ügytípus: payment/fraud/incident/social/logistics
- Impact: hány ügyfél + bevétel/reputáció kockázat
- Azonosítók: order ID / user ID / link
- Mi történt: 2 mondat
- Mit próbáltunk: max 3 lépés
- Mit kérünk: döntés / hozzáférés / workaround / jóváhagyás
Ezt ha mindig elküldöd, gyors lesz a reakció.
7) Alert hygiene: hogyan csökkentsd a riasztási zajt?
Az on-call azért ég ki, mert túl sok “nem P0” riasztás jön.
7.1 Zajcsökkentő szabályok
- P2 soha nem ébreszt
- P1 csak timebox után
- P0 csak trigger lista alapján (nem érzésből)
- minden P0-hoz kötelező csomagolt üzenet
7.2 “False P0” KPI
Mérd:
- hány P0 lett utólag P1/P2
Ha magas: definíciót kell javítani.
8) Dokumentálás: incident log + handover (hogy reggel ne nulláról induljon)
Minden P0/P1-hez:
- incident log (időbélyeges timeline)
- ügyfélkommunikáció (mit ígértünk, ETA)
- next step reggelre (owner + határidő)
Ez védi a céget és csökkenti a reggeli káoszt.
9) 30 napos bevezetési terv (gyors, tartható)
1. hét: alapok
- P0/P1/P2 definíciók
- riasztási csatornák + fallback
- escalation package sablon
2. hét: felelősségek
- L1/L2/Supervisor RACI
- incident commander kijelölés P0-ra
- kompenzációs keret szabály
3. hét: pilot
- 5–7 éjszaka éles próba
- MTTA + containment mérés
4. hét: finomhangolás
- zaj csökkentés
- runbookok (top 10 P0/P1)
- posztmortem rutin
A Telex Center Kft. ezt a rendszert be tudja vezetni nálad úgy, hogy mérhetően javuljon a reakcióidő, csökkenjen a káosz, és stabilabb legyen a minőség.
10) Zárás: az on-call rendszer akkor jó, ha kiszámítható
- P0/P1/P2 közös nyelv
- MTTA/containment SLA
- riasztási mátrix fallbackkal
- tiszta felelősségek (Incident Commander)
- csomagolt eszkaláció
- és dokumentálás + posztmortem
Ha szeretnél a cégedre szabott on-call rendszert (SLA + mátrix + felelősségek + sablonok), keress minket.
Ajánlatért keressen minket: https://telexcenter.hu/kapcsolat/