68. On-call procesy a eskalace

Úvod a kontext

Předchozí lekce popsala, jak reagovat na incident, jakmile ho někdo
řeší. Tahle lekce se ptá na otázku o krok dřív: kdo je vůbec
upozorněn, když se v noci nebo o víkendu něco pokazí? Odpověď je
on-call — pohotovostní služba, kdy je vždy alespoň jeden člověk
"na drátě" a připravený reagovat na alert. Špatně nastavený on-call
dokáže tým dlouhodobě vyčerpat; dobře nastavený je únosný i pro malý
tým.

Teorie

Co je on-call

On-call znamená, že konkrétní osoba (nebo malá skupina) je v daném
časovém okně odpovědná za reakci na produkční alerty, obvykle i
mimo běžnou pracovní dobu. Když monitoring (Prometheus/Alertmanager
z modulu 12) vyhodnotí, že nastala kritická situace, pošle
notifikaci — nejčastěji přes tzv. pager nástroj (historicky
fyzický pager, dnes aplikace jako PagerDuty, Opsgenie nebo
self-hosted alternativy), který dokáže probudit člověka i přes
telefon (push notifikace, SMS, hovor), protože e-mail se dá snadno
přehlédnout.

Rotace (on-call schedule)

Aby stejný člověk nebyl "na pageru" pořád, existuje rotace —
harmonogram, kdo je on-call v daném období (typicky týden). Běžné
vzory:

• Týdenní rotace mezi členy týmu — jednoduché na pochopení,
  ale u malého týmu znamená on-call poměrně často.
  Doporučuje se, aby stejný člověk neměl dvě po sobě jdoucí
  on-call směny.
• Follow-the-sun — u geograficky distribuovaných týmů předává
  se odpovědnost podle časových pásem, takže nikdo není on-call
  přes noc ve svém vlastním pásmu. Vyžaduje tým rozprostřený přes
  více zeměpisných oblastí, takže je dostupný jen pro větší firmy.
• Primární a sekundární on-call — pokud primární osoba
  nezareaguje na alert do určitého času (např. 5 minut), pager
  automaticky eskaluje na sekundární osobu. Chrání proti situaci,
  kdy primární člověk spí příliš tvrdě nebo má výpadek signálu.

Eskalační řetězec (escalation policy)

Eskalační řetězec definuje, co se stane, když se na alert nikdo
nepřihlásí (acknowledge) v daném čase:

Úroveň 1: primární on-call inženýr    (0–5 min)
Úroveň 2: sekundární on-call inženýr  (5–10 min)
Úroveň 3: team lead                   (10–15 min)
Úroveň 4: manažer / širší tým         (15+ min)

Tento řetězec zajišťuje, že žádný kritický alert nezůstane bez
odpovědi jen proto, že jeden konkrétní člověk je nedostupný.
Nástroje jako PagerDuty tuto logiku vykonávají automaticky na
základě definované politiky, takže není potřeba, aby ji někdo
sledoval ručně.

Co dělá alert dobrým pro on-call

Navazuje na lekci o alertingu z modulu 12 — pro on-call platí
obzvlášť přísně, že alert, který probudí člověka v noci, musí být
akční (vyžaduje okamžitý lidský zásah) a skutečně naléhavý
(má reálný dopad na uživatele právě teď). Alerty, které jen
informují ("disk je na 70 %"), nemají do on-call pageru patřit —
mají jít do běžného tiketu nebo dashboardu, který se zkontroluje
příští pracovní den. Ideálně má mít každý pagerový alert odkaz na
runbook — dokument s konkrétními kroky, jak problém diagnostikovat
a zmírnit, aby respondér v 3 hodiny ráno nemusel improvizovat.

Udržitelnost on-call (proti vyhoření)

Časté chyby, které vedou k vyhoření on-call inženýrů:

• Příliš mnoho alertů (alert fatigue). Pokud pager budí
  několikrát za noc kvůli nedůležitým alertům, respondér přestane
  na pager důvěřovat a začne alerty ignorovat nebo je "snoozovat"
  automaticky — což je nebezpečné, protože jednou mezi nimi bude
  skutečný incident.
• Chybějící kompenzace. Firmy s udržitelnou on-call kulturou
  obvykle poskytují finanční kompenzaci nebo náhradní volno za
  on-call týden, i když se žádný incident nestane — samotná
  dostupnost má cenu.
• Chybějící limit na frekvenci. Doporučuje se, aby jeden člověk
  nebyl on-call víc než např. jednou za 4–6 týdnů (u týmu s
  dostatkem lidí) — u menších týmů to není vždy možné, ale je to
  cíl, ke kterému se plánování kapacit (viz pozdější lekce o
  kapacitním plánování) má přibližovat.
• Neřešení opakujících se příčin. Pokud stejný typ alertu budí
  tým opakovaně, prioritou má být oprava hlavní příčiny (viz
  postmortem z minulé lekce), ne jen opakované "hašení" stejného
  požáru.

Runbooky

Runbook je krok-za-krokem dokument pro konkrétní typ alertu —
například "Alert: vysoká latence API" → runbook obsahuje: jak
ověřit rozsah dopadu, kde hledat logy, jaké jsou obvyklé příčiny,
jaké příkazy pro diagnostiku spustit, kdy a jak provést rollback.
Dobrý runbook umožňuje i méně zkušenému respondérovi zvládnout
incident bez toho, aby musel budit seniornějšího kolegu. Runbooky
je potřeba průběžně aktualizovat (viz "zastaralý rollback runbook"
v postmortemu z minulé lekce) — zastaralý runbook je někdy horší
než žádný, protože vede respondéra špatným směrem.

Praktický příklad

Ukázka jednoduché eskalační politiky ve formátu, jaký používají
nástroje typu PagerDuty/Opsgenie (konceptuální YAML, ne konkrétní
API):

escalation_policy:
  name: "API tym - produkce"
  rules:
    - escalate_after_minutes: 5
      targets:
        - schedule: "api-tym-primarni-rotace"
    - escalate_after_minutes: 10
      targets:
        - schedule: "api-tym-sekundarni-rotace"
    - escalate_after_minutes: 15
      targets:
        - user: "team-lead-jana"
        - notify: "slack:#incidenty"

schedules:
  api-tym-primarni-rotace:
    rotation_type: weekly
    handoff_time: "10:00"
    participants: [petr, martin, lucie, tomas]

Alert napojený na tuto politiku (např. z Alertmanageru) obsahuje
mimo popisu problému i odkaz na runbook:

[SEV2] Vysoká latence API (p95 > 2s po dobu 5 min)
Runbook: https://wiki.interni/runbooks/api-vysoka-latence
Dashboard: https://grafana.interni/d/api-overview

Shrnutí

On-call zajišťuje, že je vždy někdo odpovědný za reakci na
produkční problémy i mimo pracovní dobu, prostřednictvím rotace
a eskalačního řetězce, který automaticky přesune odpovědnost dál,
pokud primární osoba nezareaguje včas. Udržitelný on-call vyžaduje
akční, skutečně naléhavé alerty s odkazem na aktuální runbook,
rozumnou frekvenci směn a řešení opakujících se příčin — jinak vede
k alert fatigue a vyhoření týmu.

Kontrolní otázky

1. K čemu slouží eskalační řetězec a proč se on-call politika
   nespoléhá jen na jednu osobu?
2. Jaký je rozdíl mezi alertem, který patří na pager, a alertem,
   který má jít jen do běžného dashboardu nebo tiketu?
3. Proč je alert fatigue nebezpečný i pro budoucí skutečné
   incidenty, ne jen nepříjemný pro respondéra?
4. Mini cvičení: navrhněte třístupňovou eskalační politiku pro
   jednočlenný tým, který nemá žádného sekundárního on-call
   inženýra — koho by měl řetězec kontaktovat na druhé a třetí
   úrovni?