Incydent: linia produkcyjna zatrzymuje się na 2 godziny. To P1, MTTR max 1 godzina. Incydent: email pracownika nie działam Niekaż. To P3, MTTR max 8 godzin. W produkcji, incident management to nie tylko helpdesk — to live operacyjne, finansowe. Jeden incydent może kosztować 50 000 PLN utraty produkcji. W tym artykule rozkładam severity vs priority, macierz klasyfikacji, SLA dla produkcji i benchmark MTTR.
Severity vs Priority — co jest inna
Severity — wpływ na biznes. Jak źle jest? Czy można pracować? Czy sieć pada dla 500 osób czy dla 1 osoby?
Priority — pilność naprawy. Jak szybko trzeba to naprawić?
Przykład: Email CEO nie działa (severity: LOW — 1 osoba, ale priority: CRITICAL — bo to CEO). Sieć pada dla całego piątku (severity: CRITICAL — 100+ osób, priority: CRITICAL).
Macierz Severity × Priority
| Severity \ Priority | P1 (Immediate) | P2 (Urgent) | P3 (Standard) | P4 (Low) |
|---|---|---|---|---|
| Critical (cała produkcja) | P1-CRIT (1h MTTR) | P1-URG (2h) | P2 (4h) | P3 (8h) |
| High (dział/zespół) | P1-URG (2h) | P2 (4h) | P3 (8h) | P4 (24h) |
| Medium (1 użytkownik) | P2 (4h) | P3 (8h) | P4 (24h) | P4 (48h) |
| Low (1 OS, nie wpływa) | P3 (8h) | P4 (24h) | P4 (24h) | P4 (48h) |
Benchmark MTTR — ile czasu masz?
P1-Critical (prod down): max 1 godzina. W praktyce: IT na miejscu w 15 minut, diagnoza w 20, fix w 30. Po rozwiązaniu: RCA w ciągu 2 dni.
P2-Urgent (dział down): max 4 godziny. IT 30 min, diagnoza 30 min, fix 2h. RCA w ciągu 1 tygodnia.
P3-Standard (1 osoba nie może pracować): max 8 godzin. Fix może być „patch tymczasowy" — np. restart aplikacji, reset hasto, jeśli permanent fix będzie jutro.
P4-Low (coś działa ale wolno, nie krytyczne): max 48 godzin. To może czekać do następnego okna maintenance.
RCA po incydencie P1 — obowiązkowe dla produkcji
Zawsze! Po każdym P1 — zespół robi RCA w ciągu 2 dni. Dokumentujesz:
- Timeline (o 10:30 sieć pada, o 10:35 IT wezwany, o 11:00 router restartował, o 11:15 usługa wznowiona)
- Pierwotna przyczyna (upgrade oprogramowania routera ze środą przeszłość i bez testów wprowadził buga)
- Rozwiązanie (rollback wersji, restart router)
- Długoterminowa naprawa (testowanie upgrade w środowisku qa — 1 tydzień pracy, budżet 20k PLN)
- Zapobieganie (procedura: każdy upgrade musi być testowany, change board approval)
Incident management w ManageEngine SDP
Setup:
- Admin → Incident Management → Priorities — zdefiniuj P1-P4 i SLA
- Admin → Impact/Urgency — zdefiniuj severity matrix (Critical/High/Medium/Low)
- Konfiguruj escalation rules: P1 → wezwij managera IT + VP Operations, after 30 min
- Konfiguruj notifications: P1 → SMS + email + Slack alert wszystkim techniką
- Reports → SLA compliance — track ile % P1 meetujesz 1h MTTR target
SLA Compliance w produkcji — co śledzić
KPI #1: % P1 meetings MTTR < 1h — Target: 90%+. Poniżej 80% = proces nie działa.
KPI #2: MTTR trend per priority — Czy MTTR rośnie czy maleje? Trend malejący = dobrze, ludzie się uczą.
KPI #3: Repeat incident rate (% powtórzeń) — Po P1 powinny być RCA i rozwiązanie. Jeśli ten sam incydent wraca — RCA nie zadziałała.
KPI #4: Time to detect incident — Idealizmu P1 powinien być auto-detected przez monitoring (sieć pada = alert w 30 sekund). Jeśli P1 jest zgłaszany przez pracownika mejlem = monitoring jest źle skonfigurowany.
Incident management dla Twojej produkcji?
Rotech Group skonfiguruje incident management w ManageEngine SDP, zdefiniuje SLA dla P1-P4, i przeszkoliści zespół na RCA. Gwarancja 90% P1 MTTR compliance.
Umów konsultację →