Proč metriky a alerty rozhodují o spolehlivosti
Provozní týmy (SRE/DevOps/Platform) stojí za spolehlivostí služeb. Bez jasně definovaných metrik, kvalitního monitoringu a přesně zacílených alertů se zvyšuje MTTR, roste šum a klesá důvěra uživatelů. Cílem je včas odhalit uživatelsky významné problémy, minimalizovat „alert fatigue“ a poskytovat akční signály navázané na runbooky a eskalační politiky.
SLI, SLO a chyba rozpočtu (Error Budget)
- SLI (Service Level Indicator): měřitelný ukazatel kvality služby (např. p99 latence < 250 ms, dostupnost 99.9 %).
- SLO (Service Level Objective): cílová hodnota SLI za období (např. měsíční dostupnost ≥ 99.95 %).
- Error Budget: prostor pro „nespolehlivost“ (100 % − SLO). Slouží k řízení rychlosti releasů a prioritizaci stability.
Modely metrik: USE, RED a „Zlaté signály“
- USE (Utilization, Saturation, Errors): pro infrastrukturu – vytížení, saturace (fronty), chyby.
- RED (Rate, Errors, Duration): pro HTTP/RPC – počet požadavků, chybovost, trvání.
- Four Golden Signals: latence, chybovost, propustnost, saturace.
Typy metrik a jejich správné použití
- Counter: monotonně rostoucí (požadavky, chyby, bajty). Agregace rychlostí (rate).
- Gauge: okamžitá hodnota (počet spojení, využití paměti, délka fronty).
- Histogram/Summary: distribuce a kvantily latencí (p90/p95/p99) a velikostí; histogramy preferujte pro škálovatelnost.
Navrhování alertů: principy „málo, ale přesně“
- Uživatelský dopad: alertujte na symptomy, které cítí uživatel (překročení p99 latence, chyba 5xx > X %), nikoli pouze na systémové signály.
- Akčnost: každý alert musí mít owner, prioritu, runbook a jasný „first step“.
- SNR: prahové hodnoty nastavte z baseline (diurnální křivky, sezónnost). Před nasazením sledujte alert v „shadow“ režimu.
- Hystereze a tlumení: zpoždění, for okna (trvání poruchy), grace period po deployi.
Prioritizace a eskalace
- P1: výpadek produkce / masivní dopad → pager (telefon/SMS), okamžitá eskalace Incident Commanderovi.
- P2: významná degradace → pager během on-call, reakce v minutách.
- P3: menší dopad / varování → chat/e-mail, reaktivně v hodinách.
- P4: informační → bez paging, pouze dashboard/report.
Tabulka: mapování metrik na alerty
| Doména | SLI/metrika | Prahová hodnota (příklad) | Akce/Runbook |
|---|---|---|---|
| HTTP API | p99 latence | > 300 ms po dobu 5 min | Škálování repliki, kontrola DB/Cache hit-rate |
| HTTP API | Chybovost 5xx | > 2 % po dobu 3 min | Rollback posledního releasu, ověřit rate limit |
| DB | CPU / lock wait | CPU > 85 % a wait > 10 % 10 min | Analyzovat slow queries, přidat indexy, škálovat |
| K8s | Pod restart rate | > 3/5 min v namespace | Ověřit limity, OOMKilled, zdraví nodů |
| Fronty | Délka fronty | > 1000 zpráv 10 min | Navýšit consumer concurrency, backpressure |
| Obchod | Konverze | < baseline − 3σ 15 min | Incident biz/dopravní kanály, ověřit checkout |
Cardinalita a náklady: jak se nespálit
- Omezení labelů: vyhýbejte se vysoce kardinalitním štítkům (user_id, session_id). Používejte agregovatelné klíče (service, instance, region).
- Sampling a downsampling: surová data krátce, agregace (1m, 5m), dlouhodobě pouze p95/p99 a denní SUM/AVG.
- Retence: SLA/SLO na dashboardech v jemném rozlišení, historické trendy v zředěné podobě.
Blackbox vs. whitebox monitoring
- Blackbox: syntetické testy (HTTP probe, TLS expirace, DNS resoluce). Detekuje uživatelský dopad.
- Whitebox: interní metriky aplikace/infrastruktury (handler latency, cache hit-rate, GC). Pomáhá s diagnózou.
- Oba směry kombinujte: blackbox pro alerty P1/P2, whitebox pro P2/P3 a triáž.
Alerty založené na kvantilových metrikách
- Preferujte p95/p99 nad průměrem; průměr maskuje špičky.
- Pro kvantily používejte histogramy s promyšlenými buckets (např. expo 5–10–20–40–… ms).
Chybovost a kvalita odpovědí
- Rozlišujte 5xx (server), 4xx (klient/policy), timeouty, cancellations.
- Pro gRPC sledujte
status_code(UNAVAILABLE, DEADLINE_EXCEEDED) a transport chyby.
Kapacitní a výkonové metriky
- Headroom: rezervy CPU/RAM/IOPS/throughput; alert při poklesu pod definovaný práh.
- Fronty a backpressure: délka fronty, doba čekání, poměr produkce/konzumace.
- GC/Heap (JVM/Node/.NET): frekvence stop-the-world, prahy pro leak detekci.
Runbooky a akčnost alertů
- Každý alert má URL na runbook s kroky: ověření dopadu, diagnostika, mitigace, rollback, eskalace.
- Runbook obsahuje odkazy na dashboardy, log dotazy, traces a poslední releasy.
- „Feature flag kill switch“ pro rychlou izolaci problému bez plného rollbacku.
Incident management a metriky spolehlivosti
- MTTD (Time to Detect), MTTA (Time to Acknowledge), MTTR (Time to Recover).
- Automatické vytváření incidentů (ticket/slack/IM) z P1/P2 alertů, přiřazení role Incident Commander, Scribe, Tech Lead.
- Post-incident review: kořenová příčina (blameless), akční položky s jasným ownerem a termínem.
Dashboards: čitelnost a hierarchie
- Struktura: Executive (SLO/SLA) → Service (RED) → Dependency (DB/Cache/Queues) → Infra (USE).
- Každý panel s kontextem (popis, jednotky, cíle), sdílené časové okno a anotace releasů.
- Tematické barvy: zelená (OK), oranžová (varování), červená (incident). Barva není jediný signál – používejte ikony a text.
Korelace logs ⇄ metrics ⇄ traces
- Trace/Span ID propagujte přes služby a ukládejte do logů pro rychlou navigaci mezi vrstvami observability.
- Strukturované logy (JSON), sampling traces, metriky jako RED/USE extrahované z telemetrie (OpenTelemetry).
Testování alertů a „game days“
- Chaos experimenty (úmyslné degradace) ověřují, že alerty skutečně pálí, a že runbooky vedou k obnově.
- Load testy s baseline křivkami (p50/p95/p99) a definovanými SLO pro špičky.
CI/CD a observabilita
- Po deployi dočasně uvolněte prahy (grace period), ale alertujte na tvrdé chyby ihned (např. zvýšení 5xx o řád).
- Automatické anotace releasů do dashboardů a časových řad.
Bezpečnostní alerty vs. provozní alerty
- Oddělte kanály a priority (SOC vs. NOC), ale propojte korelaci (neobvyklý egress + CPU špičky).
- U bezpečnostních alertů preferujte detekce s nízkým FPR (behaviorální baseline, více signálů).
On-call hygiena a alert fatigue
- Pravidelně prune alerty bez akce, slučujte duplicitní signály, zaveďte auto-dedup a grouping.
- Měřte měsíční počet alertů na inženýra, poměr false/true positive, dobu mimo pracovní hodiny.
- Rotace on-call, tiché hodiny pro P3/P4, „follow-the-sun“ model u globálních týmů.
Cost observability a kapacitní plánování
- Tagujte zdroje (service, owner, env) pro showback/chargeback. Sledujte náklady na request, tenant, feature.
- Alerty na cost drift, náhlé odchylky (např. storage růst > X %/den).
Checklist: kvalitní alerting a metriky
- Definované SLI/SLO a propojení na error budget?
- Dashboardy: RED/USE + závislosti + anotace release?
- Alert má ownera, prioritu, runbook a tlumení (for/hysteresis)?
- Kardinalita pod kontrolou, retence a náklady optimalizované?
- On-call metriky (MTTD/MTTR, alerty/osoba/měsíc) se zlepšují?
- Game days a chaos testy validují efektivitu?
Závěr
Efektivní observabilita stojí na dobře zvolených metrikách a pečlivě navržených alertecích, které reflektují uživatelský dopad, jsou akční a udržitelné. Kombinace SLI/SLO, modelů RED/USE, přísné práce s kardinalitou a propojení metrik s logy a traces umožňuje provozním týmům zkracovat MTTR, chránit error budget a doručovat stabilní zkušenost uživatelům. Pravidelná údržba alertů, runbooků a on-call procesu je stejně důležitá jako samotná instrumentace.
