Upozorňování a reakce na výpadky: notifikace a řízení incidentů

Proč je alerting klíčový a co od něj očekávat

Alerting je proces včasného a relevantního upozorňování na odchylky v chování systémů, které mohou vést k incidentům nebo porušení SLO. Cílem není „co nejvíce notifikací“, ale správná informace ve správný čas správnému týmu. Kvalitní alerting minimalizuje MTTA (Mean Time To Acknowledge) a MTTR (Mean Time To Recovery), chrání reputaci i tržby a snižuje provozní stres.

Terminologie: SLI, SLO, SLA a error budget

• SLI (Service Level Indicator) – měřená veličina kvality služby, např. dostupnost, latence p95, chybovost.
• SLO (Service Level Objective) – cíl SLI v čase: např. „dostupnost 99,9 % za 30 dní“.
• SLA – smluvně závazný závazek vůči zákazníkovi (často s penalizací).
• Error budget – prostor pro nedodržení SLO (např. 0,1 % nedostupnosti za měsíc), který řídí tempo releasů a míru rizika.

Design alertů: od signálu k akci

• Akčnost: každý alert musí implikovat jasný krok (runbook, eskalace, rollback, feature flag).
• Specifičnost: měřte doménové SLI (uživatelskou latenci, chybovost) – metriky infrastruktury jsou podpůrné signály.
• Nízký šum: agregujte a deduplikujte; upřednostňujte alerty, které předcházejí porušení SLA („burn-rate alerting“).
• Kontext: přiložte dashboard, poslední deployment, feature flagy a odpovědnost za službu (owner).

Úrovně závažnosti a eskalační schéma

Alerting v Prometheus/Alertmanager: osvědčené vzory

• Pravidla: pro latenci, chybovost a dostupnost používejte metriky s histogramy a poměrovými výpočty.
• Šablony: standardizujte anotace – „summary“, „impact“, „runbook“, „dashboards“, „owner“.
• Směrování: Alertmanager směrujte podle „service“, „severity“, „team“; při údržbě využívejte tiché období (silence).
• Deduplikace a grouping: seskupujte podle „service“ a „cluster“, aby jeden incident znamenal jedno upozornění na pager.

Příklady výrazů v PromQL (řádkově, bez formátování bloků): rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05 – podíl 5xx > 5 %; histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 0.5 – p95 latence > 500 ms; avg_over_time(probe_success[5m]) < 0.999 – syntetická dostupnost < 99,9 %.

Alerting podle burn rate (přístup SLO-first)

Burn rate = rychlost čerpání error budgetu. Strategie se dvěma časovými okny kombinuje krátký a dlouhý horizont, aby odhalila náhlé výkyvy i pozvolné zhoršování.

• Krátké okno (např. 5–10 min): citlivé na skoky, vysoký práh (např. burn rate > 14×).
• Dlouhé okno (např. 1–2 h): potvrzuje trend, nižší práh (např. burn rate > 6×).

Princip pravidla: error_rate / error_budget_per_minute > N. Alert se spustí, pokud jsou oba časové horizonty nad prahem, což snižuje počet falešných poplachů.

Zabbix: triggery, závislosti a automatická náprava

• Triggery: definujte prahy s hysterezí (okno pro návrat), používejte OK event generation pro stabilní ukončení alertu.
• Závislosti: topologie (síťové prvky → servery → služby) sníží kaskádu alertů při kořenové poruše.
• Akce: podmíněná upozornění podle závažnosti a skupiny hostitelů; automatická eskalace na další kontakt, pokud alert není potvrzen.
• Náprava: skriptované kroky (restart jednotky, vyprázdnění fronty, přepnutí poolu) s auditním záznamem.

Jak předejít únavě z alertů

• Každý alert musí mít owner a runbook; osiřelé alerty vypněte.
• Omezte informační upozornění v nočních hodinách; upozornění s nižší závažností posílejte do chatu/e-mailu, nikoli na pager.
• Pravidelná revize alertů: každý měsíc čistěte, slučujte, upravujte prahy a kontrolujte deduplikaci.
• Využívejte složené signály (korelace: latence + 5xx + vytížení), nikoli jednotlivé metriky bez kontextu.

Runbooky: od notifikace k akci do 60 sekund

• Struktura: „Identifikace problému → Okamžité kroky → Diagnostika → Náprava → Ověření → Eskalace“.
• Atomické kroky: konkrétní příkazy, odkazy na dashboardy, skripty, feature flagy.
• Aktualizace: po každém incidentu runbook revidujte a opatřete časovým údajem.

Proces on-call a dohodnuté provozní SLA

• Rotace: primární a sekundární on-call, střídání po týdnu; u nováčků „buddy“ – stínování zkušenějším kolegou.
• Předání služby: předávací poznámky (probíhající incidenty, ztlumené alerty, známé problémy).
• Pohoda zaměstnanců: měřte noční zásahy; pokud překročí limit, zaveďte kompenzaci nebo přepracujte alerty.

Reakce na incident: od detekce k obnově

1. Detekce – alert → upozornění on-call pracovníka → potvrzení (ack).
2. Stabilizace – aktivace incident commandera, komunikační kanál (ChatOps), stavová stránka.
3. Zmírnění dopadu – rollback, přesměrování provozu, omezení rychlosti (rate limiting), izolace porouchané části.
4. Obnova – ověření SLI, postupné obnovení alertů, sledování po incidentu (soak).

Komunikace a ChatOps

• Integrujte Alertmanager/Zabbix do chatu (Slack/Teams): ack, silence a runbook přímo ve vlákně.
• Automatický kontext: poslední deployment, změny konfigurace, anomálie v grafu (sparklines v notifikaci).
• Externí komunikace: šablony pro stavovou stránku, srozumitelné i pro netechnické publikum.

Testování alertů a chaos engineering

• Jednotkové testy pravidel: syntetické metriky a simulace – ověřte, že pravidla reagují správně.
• Game days: řízené poruchy (latence databáze, výpadek uzlu) a měření doby detekce i kvality reakce.
• Stínové alerty: nové definice běží v „tichém“ režimu a jejich dopad se vyhodnocuje před ostrým zapnutím.

Metriky provozní kvality alertingu

• Precision/Recall: kolik alertů vedlo k akci a kolik incidentů bylo včas detekováno.
• MTTA/MTTR: zkracujte úzká místa (latenci upozornění na pager, eskalaci, kvalitu runbooků).
• Index šumu: podíl alertů, které nevedou k akci; cílem je jeho trvalé snižování.

Datová vrstva pro SLI a tracing

• End-to-end SLI sestavujte z APM (tracing, latence spanů) a syntetických testů.
• Korelujte metriky s logy a trasami (OpenTelemetry) – notifikace by měla obsahovat trace_id nebo odkaz na vyhledávání.

Model vyspělosti alertingu

1. Úroveň 1: ad hoc prahy, příliš mnoho infrastrukturních alertů, chybějící runbooky.
2. Úroveň 2: standardizované šablony, základní SLO, deduplikace, on-call rotace.
3. Úroveň 3: burn rate řízený podle SLO, korelační alerty, ChatOps, pravidelné revize, game days.
4. Úroveň 4: automatizovaná náprava, prediktivní signály, obchodní SLI (konverze, nákupní košík).

Integrace s řízením releasů

• K alertům automaticky přikládejte informaci o tom, „co se právě změnilo“ (commit, značka releasu, feature flagy).
• U releasů s vysokým rizikem zvyšte citlivost alertů a aktivujte dočasné ochranné mechanismy (přísnější prahy burn rate).

Revize po incidentu a poučení

• Bez obviňování (blameless) – zaměřte se na systémové příčiny a zlepšení.
• Akční body: změna pravidel alertingu, úprava runbooků, posílení pozorovatelnosti.
• Sdílení znalostí: stručné shrnutí pro produkt a podporu, aby rozuměly dopadu a nápravě.

Minimální standardy, které můžete zavést hned

• Definujte 3–5 hlavních SLI a jejich SLO pro klíčové služby.
• Zaveďte alerting podle burn rate se dvěma časovými okny pro dostupnost a chybovost.
• Všechny alerty doplňte o runbook, dashboard a owner.
• Napojte Alertmanager/Zabbix na ChatOps s možností ack/silence.
• Každý měsíc provádějte revizi alertů a každý kvartál uspořádejte game day.

Shrnutí

Moderní alerting stojí na přístupu SLO-first, korelaci signálů a jednoznačné akčnosti. Prometheus+Alertmanager a Zabbix poskytují robustní základ, pokud nastavíte smysluplné SLI, pravidla burn rate, deduplikaci a kvalitní runbooky. Když alerty vedou k rychlé a opakovatelné reakci, zkracuje se MTTR, mizí „únava z alertů“ a provoz získává předvídatelnost – i během výpadků.