🟡 Intermediate

Incident Management — Správa incidentov

Incident management je proces detekcie, reakcie, riešenia a učenia sa z výpadkov a degradácií produkčných systémov. Dobre nastavený proces je rozdiel medzi 5-minútovým fixom a celodenným chaosom.

Čo je incident?

Incident je neplánované prerušenie alebo degradácia služby, ktorá ovplyvňuje používateľov. Nie každý bug je incident — incident vyžaduje okamžitú reakciu.

Klasifikácia incidentov

Severita Popis Response time Príklad
P1 (Critical) Služba úplne nefunkčná < 5 min Production down, data loss
P2 (Major) Výrazná degradácia < 15 min 50% error rate, checkout nefunguje
P3 (Minor) Čiastočná degradácia < 1 hodina Pomalé odpovede, minor feature down
P4 (Low) Minimálny dopad Najbližší business day Kozmetický bug, edge case

SLA, SLO a SLI

Tieto tri koncepty tvoria základ spoľahlivosti služieb:

SLI — Service Level Indicator

Čo meriame. Konkrétna metrika, ktorá vyjadruje kvalitu služby:

SLI = (úspešné requesty / celkové requesty) × 100

Príklady SLI:
• Dostupnosť: % úspešných HTTP responses (non-5xx)
• Latencia: % requestov pod 200ms
• Throughput: requesty za sekundu
• Error rate: % chybových odpovedí

SLO — Service Level Objective

Čo chceme dosiahnuť. Interný cieľ pre SLI:

SLO príklady:
• Dostupnosť: 99.9% za 30 dní (max 43.8 min downtime/mesiac)
• Latencia: 95% requestov pod 200ms, 99% pod 500ms
• Error rate: < 0.1% za 7 dní

SLA — Service Level Agreement

Čo sľubujeme zákazníkovi. Právne záväzný dokument s následkami:

SLA: 99.9% monthly uptime
Breach: < 99.9% → 10% kredit
        < 99.0% → 25% kredit
        < 95.0% → 50% kredit

Error Budget

Error budget je rozdiel medzi 100 % a SLO. Ak je SLO 99.9 %, error budget je 0.1 % (43.8 min/mesiac).

Error budget = 1 - SLO

99.9% SLO = 43.8 min downtime/mesiac
99.95% SLO = 21.9 min downtime/mesiac
99.99% SLO = 4.3 min downtime/mesiac

Keď je error budget vyčerpaný:
→ STOP deploymenty
→ Fokus na stabilitu
→ Žiadne nové features kým sa budget neobnoví

On-Call

On-call je rotácia, kde člen tímu je zodpovedný za reakciu na incidenty mimo pracovnej doby.

On-call best practices

# PagerDuty schedule príklad
schedule:
  name: "Backend On-Call"
  rotation:
    type: weekly
    start: Monday 09:00
    participants:
      - peter
      - jana
      - martin
      - lucia

  escalation_policy:
    - level: 1
      timeout: 5min
      targets: [current_on_call]
    - level: 2
      timeout: 10min
      targets: [team_lead]
    - level: 3
      timeout: 15min
      targets: [engineering_manager]

On-call kompenzácia a zdravie

  • Kompenzácia — on-call musí byť kompenzovaný (peniaze alebo voľno)
  • Max. frekvencia — nie viac ako 1 z 4 týždňov
  • Follow-the-sun — pri globálnych tímoch rotácia podľa časových zón
  • Handoff — štrukturovaný odovzdávaní zmeny s kontextom
  • No-blame — nikdy netrestajte on-call za eskaláciu

Runbooks

Runbook je dokumentovaný postup pre riešenie známych problémov. Znižuje MTTR a umožňuje aj juniorným členom riešiť incidenty.

Štruktúra runbook-u

# Runbook: High Database CPU

## Symptómy
- Alert: `DatabaseCPUHigh` (CPU > 80% po 5 minút)
- Pomalé API odpovede (p99 > 2s)
- Grafana dashboard: Database Performance

## Diagnostika
1. Skontroluj slow queries:
   ```sql
   SELECT pid, now() - pg_stat_activity.query_start AS duration,
          query, state
   FROM pg_stat_activity
   WHERE (now() - pg_stat_activity.query_start) > interval '5 seconds'
   ORDER BY duration DESC;

  1. Skontroluj počet spojení:

    SELECT count(*) FROM pg_stat_activity;

  2. Skontroluj running migrations:

    kubectl logs -l app=migration-job --tail=50

Riešenie

Quick fix

  1. Zabite dlhé queries:
    SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE duration > interval '30 seconds'
AND state = 'active';

Ak nepomôže

  1. Škálujte read replicas: kubectl scale deploy/db-reader --replicas=3
  2. Eskalujte na DBA team (#dba-team)

Eskalácia

  • Ak problém trvá > 15 min → eskalujte na P2
  • Ak database je úplne nereachable → P1

## **Incident Response Process**

### 1. Detekcia

Monitoring → Alert → PagerDuty → On-call notifikácia │ ┌─────┴──────┐ │ Acknowledge │ │ (< 5 min) │ └─────┬──────┘ ▼ Začni response


### 2. Triage a komunikácia

```bash
# Vytvorenie incident channelu
/incident create "Payment processing failures" --severity P1

# V incident channeli:
# - Incident Commander (IC) — koordinuje
# - Tech Lead — diagnostikuje a opravuje
# - Communications Lead — informuje stakeholderov

3. Mitigation

Priorita je obnoviť službu, nie nájsť root cause:

  • Rollback posledného deploymentu
  • Reštart služby
  • Škálovanie zdrojov
  • Failover na backup

4. Resolution a follow-up

Po obnovení služby:

  1. ✅ Potvrdiť že služba je stabilná (monitorovať 30 min)
  2. 📝 Zapísať timeline do incident dokumentu
  3. 📅 Naplánovať postmortem (do 48 hodín)
  4. 🔔 Informovať stakeholderov o resolution

Postmortems

Postmortem (tiež retrospektíva) je blameless analýza incidentu. Cieľ nie je nájsť vinníka, ale zlepšiť systém.

Postmortem šablóna

# Postmortem: Payment Service Outage
**Dátum:** 2026-03-14
**Severita:** P1
**Trvanie:** 47 minút (14:23 - 15:10 UTC)
**Impact:** 100% payment failures, ~2300 affected transactions

## Sumár
Deployment novej verzie payment-service obsahoval bug v connection
pooling, ktorý spôsobil exhaustion DB spojení po 15 min.

## Timeline
- 14:08 — Deploy payment-service v2.3.1
- 14:23 — Alert: Payment error rate > 5%
- 14:25 — On-call acknowledged, začal diagnostiku
- 14:32 — Identifikovaný connection pool exhaustion
- 14:35 — Rozhodnutie: rollback na v2.3.0
- 14:38 — Rollback spustený
- 14:42 — Rollback dokončený, error rate klesá
- 15:10 — Služba stabilná, incident resolved

## Root Cause
Connection pool v novej verzii nemal nastavený `maxLifetime`,
čo spôsobilo leak spojení pri DB failover.

## Čo fungovalo
- Alert sa spustil do 15 min
- Rollback bol rýchly (< 10 min)
- Incident communication bola jasná

## Čo nefungovalo
- Chýbal integration test pre connection pooling
- Canary deployment by zachytil problém skôr
- Runbook pre DB connection issues neexistoval

## Action Items
| # | Akcia | Vlastník | Deadline |
|---|-------|----------|----------|
| 1 | Pridať integration test pre connection pool | Peter | 2026-03-21 |
| 2 | Nastaviť canary deployment pre payment-service | Jana | 2026-03-28 |
| 3 | Napísať runbook pre DB connection issues | Martin | 2026-03-21 |
| 4 | Pridať maxLifetime do všetkých connection pools | Lucia | 2026-03-18 |

## Lessons Learned
- Connection pool konfigurácia je kritická a musí byť testovaná
- Canary deploymenty by zachytili problém pri 5% trafficu

Blameless kultúra

  • Nikdy nepýtajte "kto to pokazil?"
  • Vždy pýtajte "čo zlyhalo v systéme?"
  • Ľudia robia chyby — systém by ich mal zachytiť
  • Trest za chyby vedie k skrývaniu problémov

Nástroje

Kategória Nástroje
On-call management PagerDuty, OpsGenie, VictorOps
Incident tracking Rootly, Incident.io, FireHydrant
Status pages Statuspage, Cachet, Instatus
Communication Slack, Microsoft Teams
Postmortems Blameless, Jeli
Runbooks Rundeck, Notion, Confluence

KPI pre incident management

Metrika Popis Cieľ
MTTA Mean Time to Acknowledge < 5 min
MTTD Mean Time to Detect < 5 min
MTTR Mean Time to Resolve < 1 hodina (P1)
MTBF Mean Time Between Failures Rastúci trend
Incident count Počet incidentov/mesiac Klesajúci trend
Action item completion % splnených action items > 90 %

Best Practices

  1. Definujte severity levels — jasná klasifikácia od P1 po P4
  2. Automatizujte alerting — PagerDuty/OpsGenie pre on-call
  3. Píšte runbooks — pre každý opakujúci sa incident
  4. Blameless postmortems — po každom P1/P2 incidente
  5. Sledujte action items — postmortem bez akcie je zbytočný
  6. Precvičujte — Game Days a tabletop exercises
  7. Merajte a zlepšujte — MTTR, MTTA trending

Incident management nie je len o hasení požiarov — je o budovaní systémov a procesov, ktoré minimalizujú dopad výpadkov a zabezpečujú, že sa tie isté chyby neopakujú.