SRE / DevOps

Incident Management

Severity levels, PagerDuty on-call rotations, blameless postmortem, Runbook i Error Budget — jak zarządzać awariami w produkcji.

PagerDuty

On-call alerting

SEV-1

Najcięższy alarm

Blameless PIR

Bez obwiniania

Error Budget

Budżet błędów

6 narzędzi Incident Management

Od klasycznego PagerDuty przez Slack-native Incident.io po automatyzację postmortemów przez Rootly.

Narzędzie	Typ	Integracje	Cena	Najlepsze na
PagerDuty	Alerting + On-call + Incident Response	500+	Od $21/user/mo	Enterprise, event intelligence, pełny lifecycle
Opsgenie (Atlassian)	Alerting + On-call scheduling	200+	Free 5 users, od $9/user/mo	Jira users, cost-conscious teams
Incident.io	Slack-first Incident Management	40+	Od $17/user/mo	Modern teams, Slack-native workflow
VictorOps (Splunk)	On-call + alerting	200+	Od $29/user/mo	Splunk ecosystem users
Statuspage.io	Public status page	30+	Od $29/mo	Komunikacja z klientami podczas incydentu
Rootly	Incident management + postmortem	40+	Od $24/user/mo	Automated workflows, postmortem automation

Często zadawane pytania

Co to jest Incident Management i jak definiować severity poziomy?

Incident Management: zestaw procesów i procedur do wykrywania, reagowania i rozwiązywania awarii systemów IT. Cel: minimalizacja czasu przestoju i wpływu na użytkowników. Cykl życia incydentu: 1. Detection — system automatycznie wykrywa anomalię (alert, monitoring). 2. Triage — ocena severity i wpływu. 3. Response — zebranie właściwego team, komunikacja. 4. Mitigation — pierwsza mitygacja (hotfix, rollback). 5. Resolution — pełne rozwiązanie przyczyny. 6. Post-Incident Review (PIR) — blameless postmortem. Severity Levels: SEV-1 (Critical) — całkowita niedostępność usługi dla wszystkich użytkowników. Wpływ finansowy natychmiastowy. Response time: 15 minut. All-hands. SEV-2 (High) — poważna degradacja dla znacznej liczby użytkowników. Response time: 30 minut. On-call engineer + TL. SEV-3 (Medium) — znaczna degradacja dla części użytkowników lub jeden kluczowy feature niedostępny. Response time: 2h. On-call engineer. SEV-4 (Low) — minor issue, obejście dostępne. Response time: next business day. Normal backlog. SEV-5 (Informational) — potencjalny problem, wymaga monitorowania. MTTD (Mean Time To Detect) — jak szybko wykrywamy. MTTR (Mean Time To Resolve) — jak szybko rozwiązujemy. MTBF (Mean Time Between Failures) — jak często awarie.

PagerDuty vs Opsgenie vs Incident.io — narzędzia do zarządzania incydentami?

PagerDuty: lider rynku. Alerting + On-call scheduling + Incident Response. Integracje: Prometheus, Datadog, CloudWatch, Sentry, New Relic (setki integracji). Escalation Policies: alert -> engineer -> team lead -> manager. On-call rotations: weekly, follow-the-sun. Event Intelligence: AI deduplication i korelacja alertów. Response Plays: automatyczne akcje przy incydencie (bridge call, Slack channel, Jira ticket). Ceny: od $21/user/mo (Professional). Opsgenie (Atlassian): podobne do PagerDuty ale tańsze. Dobre jeśli używasz Jira. Escalation policies, rotations, integrations. Ceny: free tier (5 users), od $9/user/mo. Incident.io: nowoczesne narzędzie. Slack-first (zarządzanie incydentem przez Slack commands). Automated workflows. Timeline i post-mortem wbudowane. Ceny: od $17/user/mo. VictorOps (Splunk On-Call): dobre dla Splunk users. Status Page: statuspage.io (Atlassian) — publiczna strona statusu. Automatyczne aktualizacje przy incydencie. Komunikacja z klientami. Instatus — tańsza alternatywa. Komunikacja podczas incydentu: Slack bridge channel (np. #incident-2024-04-13-sev1). Zoom war room. Status page update. Regularne (15-30 min) aktualizacje dla stakeholders.

Runbook i Playbook — jak pisać procedury obsługi incydentów?

Runbook: szczegółowe instrukcje krok-po-kroku dla konkretnego problemu technicznego. 'Jak zrestartować serwis X' albo 'Co zrobić gdy alarm Y'. Playbook: szerszy — proces reagowania na typ incydentu (SEV-1, Database Outage, Security Breach). Dobry Runbook zawiera: tytuł i opis problemu (kiedy używać tego runbooka). Wymagania wstępne (dostępy, narzędzia). Kroki diagnostyczne (co sprawdzić, jakie komendy). Kroki naprawcze (co zrobić krok po kroku). Rollback plan. Eskalacja (kiedy i do kogo eskalować). Powiązane zasoby (dashboard link, Slack channel, dokumentacja). Runbook jako code (docs-as-code): runbook w Markdown w repozytorium Git. Review przez PR. Versioned. Backstage TechDocs — centralizacja runbooków. Confluence — popularny ale mniej przyjazny dla developers. Automation: AWS Systems Manager Automation — uruchamia runbook automatycznie przy alercie. PagerDuty Event Orchestration — automatyczne akcje. Rundeck — planowanie i automatyzacja runbooków. Integracja z alertami: alert z linkiem do runbooka. Jedno kliknięcie do właściwych instrukcji. Redukuje MTTD i MTTR. Metryki runbooka: jak często używany. Czas od alertu do wykonania runbooka. Success rate. Runbook rotting — regularny przegląd i aktualizacja runbooków (quarterly).

Blameless Postmortem — jak przeprowadzać retrospekcję po incydencie?

Blameless Postmortem (PIR — Post-Incident Review): analiza przyczyn incydentu bez wskazywania winnych. Cel: wyciągnąć wnioski i zapobiec powtórzeniu. Kultura blameless: ludzie popełniają błędy w złożonych systemach. Systemy muszą być zaprojektowane tak żeby błędy ludzkie nie powodowały katastrof. Fokus na systemowe przyczyny, nie na jednostki. Google SRE pionierem blameless culture. Struktura Postmortem dokumentu: Summary — co, kiedy, jak długo, wpływ na użytkowników. Timeline — chronologia eventów (UTC). Root Cause Analysis — dlaczego naprawdę się stało. Impact — liczba użytkowników, SLA breach, przychód. Contributing Factors — wszystkie czynniki które przyczyniły się. What went well — co działało dobrze podczas response. Action Items — konkretne kroki zapobiegawcze z ownerami i deadline. 5 Whys — technika znajdowania root cause. Pytaj 'dlaczego?' 5 razy. Przykład: DB crash -> czemu? Brak miejsca na dysku -> czemu? Log rotation nie działało -> czemu? Zmienna konfiguracyjna -> czemu? Brak code review -> czemu? Brak procesu review. Root cause: brak procesu review dla konfiguracji. Fishbone diagram (Ishikawa): wizualizacja przyczyn. Kategorie: People, Process, Technology, Environment. Meeting Postmortem: 60-90 minut, 1-3 dni po incydencie. Facilitator (nie osoba która popełniła błąd). Wyniki -> Action Items z ownerami i datami.

On-call rotations i SLA — jak organizować dyżury i definiować umowy?

On-call rotation: kto jest dostępny 24/7 do odpowiedzi na alerty. Primary on-call — pierwsza odpowiedź. Secondary on-call — eskalacja gdy primary nie odpowiada. Tertiary — dalsza eskalacja (manager). Rotacja: co tydzień, co dwa tygodnie. Follow-the-sun: różne regiony przejmują dyżur w swoich godzinach pracy. Shadow on-call: juniorzy uczą się przez obserwację. Kompensata on-call: wynagrodzenie za gotowość. Overtime za poza-godzinowe incydenty. Fair rotation — każdy ma równo. PagerDuty/Opsgenie zarządzają schedule'em. On-call health: nie więcej niż jeden SEV-1/2 per tydzień. Max 2-3 alerty per noc. Quiet hours protection (SEV-4/5 nie budzą). SLA (Service Level Agreement): umowa z klientem. SLO (Service Level Objective): wewnętrzny cel. SLI (Service Level Indicator): miara. Przykład SLA: 99.9% uptime per miesiąc (8.7h downtime). 99.99% uptime (52 min downtime). Error Budget: 100% - SLO = Error Budget. 99.9% SLO = 0.1% error budget = 43.8 min/miesiąc. Burn rate: jak szybko zużywamy error budget. Alert przy burn rate > 1x (zużywamy budżet zbyt szybko). Google SRE Error Budget policy: przy burn rate > 1 -> zatrzymaj releases. Recovery: przy SEV-1 -> incident report. SLA breach -> penalty dla vendor lub informacja dla klientów. Status page update. Communication template: wewnętrzna (IT team) i zewnętrzna (klienci).

Czytaj dalej