67. Incident management a postmortem kultura

Úvod a kontext

Minulé dvě lekce zavedly SRE terminologii pro měření spolehlivosti
(SLI, SLO, SLA, error budget). Ale i s nejlépe nastavenými metrikami
se dřív nebo později stane incident — služba spadne, zpomalí se,
nebo vrátí špatná data. Tato lekce se věnuje tomu, co dělat, když se
to stane: jak incident strukturovaně zvládnout v reálném čase a jak
z něj následně napsat postmortem, který týmu skutečně pomůže, místo
aby jen "odškrtl formalitu".

Teorie

Co je incident a proč potřebuje proces

Incident je jakákoliv neplánovaná událost, která snižuje kvalitu
služby pod dohodnutou úroveň (porušuje nebo ohrožuje SLO) nebo
jinak ohrožuje uživatele či data. Bez předem dohodnutého procesu
reaguje každý incident chaoticky — lidé si šlapou na paty, nikdo
neví, kdo rozhoduje, komunikace s uživateli chybí nebo je
protichůdná. Strukturovaný incident management řeší přesně tento
problém: dává incidentu jasné role, fáze a komunikační kanály.

Fáze incidentu

1. Detekce. Incident se zjistí buď automaticky (alert z
   monitoringu, viz modul 12), nebo nahlášením od uživatele/týmu.
   Čím dřív se detekuje, tím kratší je celková doba výpadku (MTTD —
   mean time to detect).
2. Triage a deklarace. Někdo posoudí závažnost (severity) a
   rozhodne, zda jde o "opravdový" incident vyžadující formální
   proces, nebo drobnou anomálii, kterou vyřeší jeden člověk mimo
   proces. Závažnost se typicky dělí do úrovní (např. SEV1 = úplný
   výpadek, SEV2 = částečná degradace, SEV3 = drobný problém bez
   dopadu na uživatele).
3. Přiřazení rolí. U vážnějšího incidentu je klíčová role
   Incident Commander (IC) — osoba, která koordinuje reakci,
   rozhoduje a komunikuje, ale sama nemusí opravovat kód. Odděleně
   od IC existuje role Communications Lead (informuje
   stakeholdery a případně uživatele) a libovolný počet
   respondérů (lidé, kteří skutečně diagnostikují a opravují).
   Oddělení role "kdo rozhoduje" od role "kdo opravuje" je záměrné —
   IC si udržuje nadhled a nezapadne do jednoho technického detailu.
4. Mitigace před opravou. Prioritou číslo jedna je zastavit dopad
   na uživatele (rollback, přesměrování provozu, feature flag), ne
   nutně najít a opravit hlavní příčinu hned. Rychlá mitigace (např.
   rollback na předchozí verzi z modulu 9) může incident ukončit
   během minut, zatímco hledání přesné příčiny by trvalo hodiny.
5. Komunikace v průběhu. Pravidelné, stručné aktualizace
   (např. každých 15–30 minut u SEV1) do dohodnutého kanálu — i
   zpráva "stále diagnostikujeme, žádná nová informace" je lepší
   než ticho, protože ticho vede k tomu, že se stakeholdeři ptají
   jednotlivě a odvádí pozornost respondérů.
6. Vyřešení (resolution). Dopad na uživatele skončil — služba
   běží v normálním režimu. To nemusí znamenat, že je nalezena a
   opravena hlavní příčina, jen že incident z pohledu uživatele
   skončil.
7. Postmortem. Písemný rozbor po incidentu — viz níže.

Blameless postmortem — proč "blameless"

Klasická reakce na incident bývá hledat, kdo udělal chybu ("kdo
nasadil ten buggy release"). Blameless kultura, kterou popularizoval
Google a řada dalších firem, vychází z předpokladu, že lidé
jednají racionálně na základě informací, které v danou chvíli měli
— pokud inženýr nasadil kód, který způsobil výpadek, problém není
"špatný inženýr", ale to, že proces (testy, code review, postupné
nasazování) mu umožnil takovou změnu nasadit. Cílem postmortemu je
najít systémové příčiny a opravit proces, ne potrestat jednotlivce.
Praktický důvod je i motivační: pokud lidé vědí, že přiznání chyby
vede k trestu, přestanou chyby hlásit a otevřeně o nich mluvit —
což je pro bezpečnost systému mnohem horší než samotná chyba.

Struktura dobrého postmortemu

Kvalitní postmortem typicky obsahuje:

• Shrnutí (1–2 věty, co se stalo a jaký byl dopad).
• Časovou osu (timeline) — kdy incident začal, kdy byl
  detekován, kdy byla zahájena mitigace, kdy skončil, s přesnými
  časy. Časová osa je základ pro výpočet MTTD/MTTR a odhaluje, kde
  proces zabral zbytečně dlouho.
• Dopad — kolik uživatelů/požadavků bylo zasaženo, jak dlouho,
  případně finanční nebo reputační dopad.
• Hlavní příčinu (root cause) — technický popis, co skutečně
  způsobilo problém. Často se používá technika "5x proč" (ptát se
  "proč" opakovaně, dokud se nedostane od povrchního symptomu
  k systémové příčině).
• Co se povedlo / co nepovedlo — např. "alerting zafungoval
  rychle" (povedlo) vs. "runbook byl zastaralý a respondér ztratil
  10 minut hledáním správného postupu" (nepovedlo).
• Akční položky (action items) — konkrétní, přiřaditelné úkoly
  s vlastníkem a termínem, které mají zabránit opakování nebo
  zkrátit reakci příště. Postmortem bez akčních položek je jen
  vyprávění, ne nástroj zlepšení.

Časté chyby v postmortem procesu

• Postmortem se píše týdny po incidentu, kdy si nikdo nepamatuje
  detaily — má se psát co nejdřív, ideálně do 1–2 pracovních dnů.
• Akční položky se zapíšou, ale nikdy se nedokončí — bez vlastníka
  a termínu (a bez pravidelné kontroly) zůstanou navždy "TODO".
  Odpovídá to stejnému principu jako promítnutí odhadovaných kapacit
  z modulu 14 — bez závazku ke konkrétnímu termínu se plán nestane
  realitou.
• Postmortem se soustředí na hledání viníka místo systémové příčiny,
  což ničí důvěru a otevřenost týmu do budoucna.

Praktický příklad

Zjednodušená šablona postmortemu, kterou lze uložit jako
postmortem-template.md v repozitáři a vyplňovat při každém
vážnějším incidentu:

# Postmortem: Výpadek API 2024-03-14

**Severity:** SEV1
**Autor:** Jana Nováková
**Stav akčních položek:** 2/4 dokončeno

## Shrnutí
API bylo nedostupné 23 minut kvůli vyčerpání connection poolu
databáze po nasazení verze 2.14.0.

## Časová osa (UTC)
- 14:02 — nasazena verze 2.14.0
- 14:05 — Prometheus alert "vysoká latence API" (SEV2 zvednuto)
- 14:07 — IC deklarován, incident povýšen na SEV1 (5xx > 50 %)
- 14:11 — rozhodnutí o rollbacku
- 14:15 — rollback dokončen, chybovost klesá
- 14:25 — potvrzeno, že metriky jsou v normě, incident uzavřen

## Dopad
~40 % požadavků selhalo po dobu 23 minut, cca 12 000 uživatelů.

## Hlavní příčina
Verze 2.14.0 zavedla novou databázovou dotaz bez limitu na
connection pool, což při špičce provozu vyčerpalo dostupná
spojení.

## Co se povedlo
Alerting detekoval problém do 3 minut od nasazení.

## Co se nepovedlo
Code review nezachytilo chybějící limit na pool; rollback trval
déle, než by měl, protože runbook pro rollback byl neaktuální.

## Akční položky
1. Přidat automatický test na connection pool limity — @petr, do 21.3.
2. Aktualizovat rollback runbook — @jana, do 18.3.
3. Přidat alert na využití connection poolu nad 80 % — @petr, do 25.3.
4. Zavést povinné load-testování před nasazením do produkce — @tym, Q2

Shrnutí

Incident management dává reakci na výpadek jasnou strukturu — role
(Incident Commander, Communications Lead, respondéři), fáze
(detekce, triage, mitigace, komunikace, vyřešení) a pravidlo
priority mitigace před hledáním přesné příčiny. Po vyřešení
incidentu následuje blameless postmortem, který hledá systémové
příčiny místo viníka a končí konkrétními, přiřaditelnými akčními
položkami s termínem — bez nich zůstává jen vyprávěním o tom, co se
stalo.

Kontrolní otázky

1. Proč se role Incident Commandera záměrně odděluje od role
   respondéra, který incident technicky opravuje?
2. Co znamená "mitigace před opravou" a proč je to obvykle správná
   priorita během vážného incidentu?
3. Vysvětlete, proč blameless kultura dlouhodobě zlepšuje
   spolehlivost systému, i když na první pohled "nikoho netrestá".
4. Mini cvičení: k šabloně postmortemu výše navrhněte jednu další
   akční položku, která by pomohla, aby se stejný typ incidentu
   (vyčerpání connection poolu) v budoucnu nestal.