Produkce hoří ve vývoji — co to je, příčiny a algoritmus postupu

Co znamená „produkce hoří” a jaké existují typy výpadků

Výraz „produkce hoří” (production is on fire, everything is down) popisuje situaci, kdy produkční prostředí nepracuje správně a to ovlivnilo uživatele. Výpadek se může projevit jako úplná nedostupnost aplikace (blank screen, chyba 502), částečná nedostupnost (platební modul nefunguje, ale ostatní funkce jsou dostupné) nebo degradace výkonu (extrémně dlouhé načítání). Severity incidentu se určuje procentem postižených uživatelů a dobou trvání výpadku.

Podle Atlassian Statuspage (2025) činil průměrný downtime pro mobilní aplikace v roce 2024 27 minut na incident. Nejčastější příčiny: regrese kódu po deploy (34 %), výpadek cloudového poskytovatele (22 %), problémy s databází (18 %), chyby konfigurace (15 %) a DDoS útoky (11 %). Hlavní závěr: většina výpadků souvisí se změnami, které tým sám provedl, nikoli s vnějšími faktory.

Je důležité rozlišovat crash (pád aplikace na straně klienta) a backend outage (nedostupnost serveru). Crash se obvykle opravuje hotfixem klientského kódu, backend outage infrastrukturními změnami nebo redeploy služby. Sledované metriky: pro klienta — crash-free rate, pro server — error rate 5xx a p95 latency. APM (Application Performance Monitoring) — Sentry, New Relic, Datadog — pomáhá rychle určit typ výpadku.

Úrovně severity incidentů: P0, P1, P2 a kritéria klasifikace

Jednotná klasifikace severity je základem rychlé reakce. Bez ní tým ztrácí čas diskusí „jak je to naléhavé” místo jednání. Klasická škála: P0 (critical) — aplikace je zcela nedostupná nebo unikají uživatelská data, doba reakce — okamžitě; P1 (high) — kritická funkčnost nefunguje pro 50 %+ uživatelů, doba reakce — 15 minut; P2 (medium) — nekritická funkčnost je nedostupná pro část uživatelů, doba reakce — 1 hodina.

P0 vyžaduje okamžitou eskalaci: službu konající inženýr přeruší veškerou aktuální práci a přepne se na incident. Pokud po 10 minutách problém není vyřešen — připojí se tech lead. Pokud po 30 minutách — eskalace engineering managerovi. Pro incidenty P0 je povoleno porušovat jakékoli procesy: hotfix bez úplného code review, deploy přímo na produkci, ignorování pravidel branch protection. Emergency override musí být předem dohodnut na úrovni týmu.

Tabulka severity

Je nesmírně důležité neudělat chybu v severity směrem dolů. P0 + P1 klasifikované jako P2 vedou k opožděné reakci a prodloužení doby výpadku. Pravidlo: pokud máte pochybnosti — nastavte P0. Over-classification je lepší než under-classification: raději svolat zbytečnou schůzku než ztratit hodinu doby obnovy.

Prvních 10 minut: algoritmus postupu při výpadku

Timer starts: od okamžiku, kdy přijde alert nebo zpráva od uživatele. Prvních 10 minut — nejdůležitějších. Algoritmus: 1) confirm the issue — ujistěte se, že problém je skutečný (ne falešný alarm); 2) stop the bleeding — okamžitě snižte dopad (rollback, feature toggle, blokace endpointu); 3) communicate — napište na obecný kanál #incident status: co se stalo, severity, co se dělá. Prvních 10 minut se nevěnuje analýze hlavní příčiny.

Současně se zastavením krvácení jeden inženýr zahájí diagnostiku, druhý — komunikaci. Komunikační kanály: Slack #incident channel (pro tým), stavová stránka (pro uživatele), e-mail/SMS eskalace (pro management). Každých 15 minut — aktualizace stavu s informacemi: co je známo, co se dělá, odhadovaný čas obnovy. Stavová stránka (Status page) (StatuPage, Statuspal) zobrazuje uptime a historii incidentů pro externí uživatele.

Jak zastavit krvácení: rollback, feature toggle a hotfix

První a nejdůležitější pravidlo: nesnažte se opravit problém na produkci. Pokud nový release způsobil výpadek — rollback na předchozí stabilní verzi. Pokud je výpadek způsoben konkrétní funkcí, která je vypnutá pomocí feature toggle — jednoduše toggle vypněte. Pokud není k dispozici rollback ani toggle — hotfix s minimálním diffem. Rollback je nejbezpečnější varianta, protože se vracíme do stavu, který již fungoval.

Feature toggle (aka feature flag) — mocný nástroj pro stop-the-bleeding bez deploy. Pokud platební modul spadl, ale je vypnutý přes toggle — uživatelé prostě nevidí tlačítko platby, nedostávají chybovou obrazovku. Toggle nevyžaduje sestavení buildu, nevyžaduje review obchodu, funguje během několika sekund. Každá kritická funkce by měla být pod feature toggle s možností vypnutí na úrovni serveru (remote config). Feature flag — první linie obrany.

Pokud rollback není možný (např. kvůli nevratné migraci DB) a toggle není k dispozici — poslední prostředek: hotfix s minimální opravou. Hotfix se vytváří od posledního release tagu, obsahuje pouze řádky potřebné k odstranění výpadku a prochází fast-track deploy (viz článek „Hotfix — naléhavé opravy”). Golden rule: po stabilizaci vždy proveďte root cause analysis, i když se zdá příčina zřejmá.

Diagnostika příčin: logy, metriky a alarmy

Po zastavení krvácení (nebo paralelně, pokud to počet inženýrů umožňuje) začíná diagnostika. První zdroj — logy. Centralizované logování (ELK, Grafana Loki, Datadog Logs) umožňuje najít chybu podle timestampu, ID uživatele nebo ID požadavku. Důležité: logy by měly být strukturované (JSON), aby grep fungoval rychle. Strukturované logování (structured logging) je povinný požadavek pro všechny služby.

Druhý zdroj — metriky. Grafana, Datadog, New Relic ukazují, kdy došlo ke špičce chyb, na jakých endpointech, s jakými stavovými kódy. Porovnání metrik před a po deploy pomáhá lokalizovat problém na konkrétní službu nebo endpoint. RED metriky (Rate, Errors, Duration) jsou standardem monitorování mikroslužeb.

Třetí zdroj — distributed tracing. Jaeger, Zipkin, Datadog APM ukazují cestu požadavku přes mikroslužby a identifikují, kde přesně došlo ke zpoždění nebo chybě. Tracing je zvláště užitečný při kaskádových výpadcích, kdy chyba v jedné službě způsobuje chyby ve všech závislých službách. Trace ID musí být předáváno od klienta do všech backendových služeb.

# Rychlý příklad diagnostiky pomocí kubectl a logů
# Seznam podů s chybami
kubectl get pods --field-selector=status.phase!=Running

# Zkontroluj logy spadlého podu
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Hledej chyby ve službě za posledních 30 minut
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Důležité: nesnažte se diagnostikovat příčinu před zastavením krvácení. Pokud 50 % uživatelů vidí crash — nejprve rollback, poté analýza. Výjimka: pokud by rollback trval déle než přímý hotfix (např. při nekompatibilitě dat). V tomto případě se hotfix aplikuje okamžitě a post-mortem se provede po stabilizaci. Diagnosis before fix — nebezpečný vzor zvyšující dobu výpadku.

Post-mortem: jak analyzovat incidenty bez hledání viníků

Post-mortem (také nazývaný incident review) — strukturovaná analýza incidentu provedená 24-72 hodin po jeho vyřešení. Cíl: pochopit, proč k výpadku došlo, proč monitorování a testy nezachytily problém před produkcí a co změnit v procesech, aby se předešlo opakování. Blameless culture — základní princip: post-mortem diskutuje procesy, nástroje a komunikaci, nikoli chyby konkrétních lidí.

Struktura dokumentu post-mortem: timeline (chronologie událostí s timestampy), impact (postižení uživatelé, doba trvání, finanční ztráty), root cause (technická hlavní příčina), detection (jak bylo zjištěno, proč nebylo zachyceno dříve), response (co bylo provedeno, co šlo udělat rychleji), action items (konkrétní úkoly s odpovědnými osobami a termíny). Action items by měly být S.M.A.R.T.: specific, measurable, assignable, realistic, time-bound.

Typické action items po produkčním výpadku: přidat monitorování a alert na metriku, která mlčela; rozšířit testovací pokrytí na vynechaný případ; přidat stránku do runbooku s algoritmem krok za krokem pro podobnou situaci; provést školení týmu na nástroj, který byl používán nesprávně. Každý action item je konkrétní změna, která snižuje pravděpodobnost opakování incidentu.