Alerting a reakce na výpadky: Řízení oznámení a 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 na nedodržení SLO (např. 0,1 % nedostupnosti/měsíc), který řídí tempo releasů a riziko.

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živatelská latence, chybovost) – infra metriky jsou podpůrné signály.
• Nízký šum: agregujte a deduplikujte; preferujte alerty, které předcházejí SLA porušení („burn-rate alerting“).
• Kontext: přiložte dashboard, poslední deploy, feature flagy a majetkovou odpovědnost (owner).

Severity 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“.
• Routování: Alertmanager směruje alerty podle „service“, „severity“, „team“; tiché okno (silence) při údržbě.
• Deduplikace a grouping: seskupujte podle „service“ a „cluster“, aby jeden incident znamenal jedno page.

Příklady výrazů v PromQL (inline, 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 %.

Burn-rate alerting (SLO-first přístup)

Burn-rate = rychlost čerpání error budgetu. Dvouokenní strategie kombinuje krátké a dlouhé horizonty, aby detekovala jak náhlé výkyvy, tak pozvolné degradace.

• 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×).

Pravidlo v principu: error_rate / error_budget_per_minute > N. Alert se spouští, pokud jsou oba horizonty nad prahem, čímž se snižují falešné poplachy.

Zabbix: triggery, závislosti a autoremediace

• Triggery: definujte prahy s hysterézí (okno pro návrat), používejte OK event generation pro stabilní vyřešení.
• Závislosti: topologie (síťové prvky → servery → služby) snižuje kaskádu alertů při kořenové poruše.
• Akce: podmíněné notifikace dle závažnosti a host group; automatická eskalace na další kontakt po neacknutém alertu.
• Remediace: skriptované kroky (restart služby, vyprázdnění fronty, přepnutí poolu) s auditním logem.

Jak předejít „alert fatigue“

• Každý alert musí mít owner a runbook; alerta bez vlastníka vypněte.
• Omezujte informační upozornění v nočních hodinách; nižší severity do chatu/e-mailu, nikoli na pager.
• Pravidelný Alert Review: měsíční úklid, slučování alertů, úprava prahů, audit deduplikace.
• Využívejte složené signály (korelace: latence + 5xx + saturace), ne jednotlivé metriky bez kontextu.

Runbooky: z notifikace k akci do 60 sekund

• Struktura: „Identifikace problému → Okamžité kroky → Diagnostika → Remediace → Verifikace → Eskalace“.
• Atomické kroky: konkrétní příkazy, odkazy na dashboardy, skripty, feature flagy.
• Aktualizace: po každém incidentu runbook revidujte a časově označte.

On-call proces a smluvené SLA provozu

• Rotace: primární a sekundární on-call s týdenní střídáním; „buddy“ shadowing u nováčků.
• Hand-off: předávací poznámky (probíhající incidenty, utlumené alerty, známé problémy).
• Well-being: sledujte noční zásahy; pokud překročí limit, zaveďte kompenzace nebo refaktoring alertů.

Incident response: od detekce k obnově

1. Detekce – alert → page on-call → potvrzení (ack).
2. Stabilizace – aktivace incident commander, komunikační kanál (ChatOps), status page.
3. Mitigace – rollback, přesměrování trafficu, škrcení (rate limiting), izolace porouchané části.
4. Obnova – validace SLI, postupné odtlumení alertů, sledování po incidentu (soak).

Komunikace a ChatOps

• Integrujte Alertmanager/Zabbix do chatu (Slack/Teams): ack, silence a runbook přímo z konverzace.
• Automatický kontext: poslední deploy, změny konfigurací, anomálie v grafech (sparklines v notifikaci).
• Externí komunikace: šablony pro status page, srozumitelné netechnickému publiku.

Testování alertů a chaos engineering

• Unit testy pravidel: syntetické metriky a simulace – ověřte správnou reakci pravidel.
• Game days: řízené poruchy (latence DB, výpadek uzlu) a měření doby detekce a kvality reakce.
• Shadow alerts: nové definice běží v „tichém“ režimu, porovnejte zásahy před ostrým nasazením.

Metriky provozní kvality alertingu

• Precision/Recall: kolik alertů bylo akčních a kolik incidentů bylo detekováno včas.
• MTTA/MTTR: odstraňujte úzká místa (page latence, eskalace, kvalita runbooků).
• Noise index: poměr neakčních alertů; cílem je trvalý pokles.

Datová vrstva pro SLI a tracing

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

Zralostní model alertingu

1. Úroveň 1: ad-hoc prahy, přemíra infra alertů, bez runbooků.
2. Úroveň 2: standardizované šablony, základní SLO, deduplikace, on-call rota.
3. Úroveň 3: SLO-driven burn-rate, korelační alerty, ChatOps, pravidelné review, game days.
4. Úroveň 4: automatizovaná remediace, prediktivní signály, business SLI (konverze, košík).

Integrace s release managementem

• Automaticky přikládejte k alertům „co se právě změnilo“ (commit, release tag, feature flags).
• Pro high-risk releasy zvyšte citlivost alertů a zapněte dočasné guardrails (přísnější burn-rate prahy).

Post-incident review a učení

• Bez viny (blameless) – soustřeď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í: krátké shrnutí pro produkt a podporu, aby porozuměli dopadu a nápravě.

Minimální standardy, které zavedete hned

• Definujte 3–5 hlavních SLI a jejich SLO pro klíčové služby.
• Zaveďte dvouokenní burn-rate alerting pro dostupnost a chybovost.
• Všechny alerty doplňte o runbook, dashboard a vlastníka (owner).
• Alertmanager/Zabbix napojte na ChatOps s možností potvrzení (ack) a utlumení (silence).
• Měsíční Alert Review a čtvrtletní game day.

Souhrn

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