Alerty a metriky pro provozní týmy

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 prodlužuje MTTR, přibývá šumu a klesá důvěra uživatelů. Cílem je včas odhalit problémy významné pro uživatele, minimalizovat „únavu z alertů“ (alert fatigue) a poskytovat akční signály navázané na provozní příručky a eskalační politiky.

SLI, SLO a rozpočet na chyby (Error Budget)

• SLI (Service Level Indicator): měřitelný ukazatel kvality služby (např. latence p99 < 250 ms, dostupnost 99,9 %).
• SLO (Service Level Objective): cílová hodnota SLI za určité období (např. měsíční dostupnost ≥ 99,95 %).
• Error Budget: prostor pro „nespolehlivost“ (100 % − SLO). Slouží k řízení rychlosti nasazování nových verzí a určování priorit v oblasti stability.

Modely metrik: USE, RED a „zlaté signály“

• USE (Utilization, Saturation, Errors): pro infrastrukturu – využití, saturace (fronty), chyby.
• RED (Rate, Errors, Duration): pro HTTP/RPC – počet požadavků, chybovost, doba trvání.
• Four Golden Signals: latence, chybovost, propustnost, saturace.

Typy metrik a jejich správné použití

• Counter: monotónně rostoucí hodnota (požadavky, chyby, bajty). Agregace pomocí rychlosti (rate).
• Gauge: okamžitá hodnota (počet spojení, využití paměti, délka fronty).
• Histogram/Summary: rozdělení a kvantily latencí (p90/p95/p99) a velikostí; z hlediska škálovatelnosti upřednostňujte histogramy.

Navrhování alertů: princip „méně, ale přesně“

• Dopad na uživatele: upozorňujte na příznaky, které uživatel skutečně vnímá (překročení latence p99, chybovost 5xx > X %), nikoli pouze na systémové signály.
• Akčnost: každý alert musí mít vlastníka, prioritu, provozní příručku a jasný „první krok“.
• SNR: prahové hodnoty nastavte podle výchozího stavu (denní křivky, sezónnost). Před nasazením sledujte alert v režimu „shadow“.
• Hystereze a tlumení: zpoždění, časová okna for (doba trvání poruchy), ochranná lhůta (grace period) po nasazení.

Prioritizace a eskalace

• P1: výpadek produkce / masivní dopad → pager (telefon/SMS), okamžitá eskalace veliteli incidentu (Incident Commander).
• P2: významné zhoršení služby → pager během pohotovosti, reakce během několika minut.
• P3: menší dopad / varování → chat/e-mail, reakce v řádu hodin.
• P4: informační → bez pageru, pouze dashboard/report.

Tabulka: mapování metrik na alerty

Kardinalita a náklady: jak se nespálit

• Omezení štítků: vyhýbejte se štítkům s vysokou kardinalitou (user_id, session_id). Používejte agregovatelné klíče (service, instance, region).
• Vzorkování a snížení rozlišení: surová data uchovávejte krátce, používejte agregace (1m, 5m) a dlouhodobě uchovávejte pouze p95/p99 a denní SUM/AVG.
• Retence: SLA/SLO na dashboardech zobrazujte v jemném rozlišení, historické trendy v hrubším.

Blackbox vs. whitebox monitoring

• Blackbox: syntetické testy (HTTP probe, expirace TLS, překlad DNS). Odhaluje dopad na uživatele.
• Whitebox: interní metriky aplikace/infrastruktury (latence obsluhy požadavků, míra zásahů do cache, GC). Pomáhá s diagnostikou.
• Kombinujte oba přístupy: blackbox pro alerty P1/P2, whitebox pro P2/P3 a třídění incidentů.

Alerty založené na kvantilových metrikách

• Upřednostňujte p95/p99 před průměrem; průměr maskuje špičky.
• Pro kvantily používejte histogramy s promyšlenými intervaly (buckets) (např. exponenciálně 5–10–20–40–… ms).

Chybovost a kvalita odpovědí

• Rozlišujte 5xx (server), 4xx (klient/politika), timeouty a zrušené požadavky (cancellations).
• U gRPC sledujte status_code (UNAVAILABLE, DEADLINE_EXCEEDED) a chyby přenosové vrstvy (transport).

Kapacitní a výkonové metriky

• Kapacitní rezerva (headroom): rezervy CPU/RAM/IOPS/propustnosti; upozornění při poklesu pod stanovený práh.
• Fronty a řízení zpětného tlaku: délka fronty, doba čekání, poměr produkce a spotřeby.
• GC/heap (JVM/Node/.NET): frekvence pauz stop-the-world, prahové hodnoty pro detekci úniků paměti.

Provozní příručky a akčnost alertů

• Každý alert obsahuje URL na provozní příručku s kroky: ověření dopadu, diagnostika, zmírnění dopadu, návrat k předchozí verzi, eskalace.
• Provozní příručka obsahuje odkazy na dashboardy, dotazy do logů, trasování a poslední verze.
• „Vypínač funkce“ (feature flag kill switch) pro rychlou izolaci problému bez úplného návratu k předchozí verzi.

Řízení incidentů a metriky spolehlivosti

• MTTD (doba do detekce), MTTA (doba do potvrzení) a MTTR (doba do obnovení).
• Automatické vytváření incidentů (ticket/slack/IM) na základě alertů P1/P2, přiřazení rolí Incident Commander, zapisovatel (Scribe) a technický vedoucí (Tech Lead).
• Kontrola po incidentu: analýza základní příčiny (bez hledání viníka), akční úkoly s jasně určeným vlastníkem a termínem.

Dashboardy: přehlednost a hierarchie

• Struktura: Executive (SLO/SLA) → Service (RED) → Dependency (DB/Cache/Queues) → Infra (USE).
• Každý panel má kontext (popis, jednotky, cíle), společné časové okno a anotace verzí.
• Tematické barvy: zelená (v pořádku), oranžová (varování), červená (incident). Barva nesmí být jediným signálem – používejte také ikony a text.

Korelace logů ⇄ metrik ⇄ trasování

• ID tras/spanu propagujte napříč službami a ukládejte do logů, aby bylo možné rychle přecházet mezi vrstvami observability.
• Strukturované logy (JSON), vzorkování trasování a metriky RED/USE extrahované z telemetrie (OpenTelemetry).

Testování alertů a „herní dny“

• Experimenty s chaosem (záměrná zhoršení) ověřují, zda se alerty skutečně spouštějí a zda provozní příručky vedou k obnovení služby.
• Zátěžové testy s výchozími křivkami (p50/p95/p99) a definovanými SLO pro období špičky.

CI/CD a observabilita

• Po nasazení dočasně uvolněte prahové hodnoty (ochranná lhůta, grace period), ale na závažné chyby upozorňujte ihned (např. řádový nárůst chybovosti 5xx).
• Automatické anotace verzí do dashboardů a časových řad.

Bezpečnostní a provozní alerty

• Oddělte kanály a priority (SOC vs. NOC), ale propojte korelaci (neobvyklý odchozí provoz + špičky využití CPU).
• U bezpečnostních alertů upřednostňujte detekce s nízkým podílem falešně pozitivních výsledků (behaviorální výchozí stav, více signálů).

Hygiena pohotovostní služby a únava z alertů

• Pravidelně odstraňujte alerty, které nevyžadují žádnou akci, slučujte duplicitní signály a zavádějte automatické odstraňování duplicit (auto-dedup) a seskupování (grouping).
• Měřte měsíční počet alertů na inženýra, poměr falešně a skutečně pozitivních výsledků a dobu zásahů mimo pracovní dobu.
• Střídejte pohotovostní služby, zavádějte klidové hodiny pro P3/P4 a u globálních týmů využívejte model „follow-the-sun“.

Finanční observabilita a kapacitní plánování

• Označujte zdroje (service, owner, env) pro showback/chargeback. Sledujte náklady na požadavek, tenanta a funkci.
• Nastavujte alerty na odchylky nákladů a náhlé změny (např. růst úložiště > X %/den).

Kontrolní seznam: kvalitní alerting a metriky

• Jsou definovány SLI/SLO a propojeny s rozpočtem na chyby?
• Obsahují dashboardy metriky RED/USE, závislosti a anotace verzí?
• Má alert vlastníka, prioritu, provozní příručku a nastavené tlumení (for/hystereze)?
• Je kardinalita pod kontrolou a jsou optimalizovány retence i náklady?
• Zlepšují se provozní metriky pohotovostních služeb (MTTD/MTTR, alerty/osoba/měsíc)?
• Ověřují herní dny a testy chaosu účinnost?

Závěr

Efektivní observabilita stojí na vhodně zvolených metrikách a pečlivě navržených alertech, které odrážejí dopad na uživatele, vedou ke konkrétní akci a jsou udržitelné. Kombinace SLI/SLO, modelů RED/USE, důsledné kontroly kardinality a propojení metrik s logy a trasováním umožňuje provozním týmům zkracovat MTTR, chránit rozpočet na chyby a poskytovat uživatelům stabilní služby. Pravidelná údržba alertů, provozních příruček a pohotovostního procesu je stejně důležitá jako samotná instrumentace.