Observability & SRE
Monitoring říká ŽE. Observability říká PROČ.
Tři pilíře observability + SRE procesy. SLO/SLI, error budgets, incident management, post-mortemy bez blame.
Tři pilíře observability¶
Metriky (Prometheus)¶
Numerická data v čase. Latence, error rate, throughput, saturation. Efektivní pro alerting a trendování. Counter, gauge, histogram, summary.
Logy (Loki / Elasticsearch)¶
Textové záznamy událostí. Structured logging (JSON) s kontextem (trace ID, user ID, request ID). Korelace s traces pro root cause analysis.
Traces (Jaeger / Tempo)¶
Distribuovaný trace přes celý request path. Vidíte, kolik trvá každý service call, kde je bottleneck, kde selhává. OpenTelemetry pro vendor-agnostic instrumentaci.
Propojení¶
Klikněte na alert (metrika) → vidíte relevantní logy → proklikáte na trace → vidíte přesně, který service call je pomalý. Toto je observability — ne tři izolované nástroje.
SLO/SLI Framework¶
SLI (Service Level Indicator): Metrika, která měří kvalitu z pohledu uživatele. - Availability: podíl úspěšných requestů - Latency: podíl requestů pod thresholdem (např. P99 < 500ms) - Throughput: počet zpracovaných requestů
SLO (Service Level Objective): Cíl pro SLI. - „99.9% requestů je úspěšných za rolling 30 dní” - „95% requestů má latenci < 200ms”
Error Budget: SLO = 99.9% → error budget = 0.1% = ~43 minut/měsíc. - Error budget zbývá → ship features, experiment, innovate - Error budget se blíží nule → stop features, fix reliability - Error budget vyčerpán → freeze deploys, focus na stabilitu
Alerting Philosophy¶
Alert na symptomy, ne příčiny: - ✅ „API error rate > 1% za posledních 5 minut” - ❌ „CPU > 80%” (CPU může být vysoké a vše funguje)
Multi-window alerting: - Fast burn: velký spike za krátkou dobu → page okamžitě - Slow burn: pomalá degradace → ticket, ne page
Page vs. Ticket: - Page (PagerDuty/OpsGenie): requires immediate action, wakes people up - Ticket: important but not urgent, řeší se v pracovní době
SRE Procesy¶
Incident Management¶
- Detection — Automatický alert na SLO violation
- Triage — Severity classification (P1-P4)
- Response — On-call engineer, runbook, communication
- Mitigation — Rollback, feature flag off, scale up
- Resolution — Root cause fix, deploy
- Post-mortem — Blameless, action items, follow-up
Post-Mortem Template¶
- Timeline (co se stalo, chronologicky)
- Impact (kolik uživatelů, jak dlouho)
- Root cause (technická příčina)
- Contributing factors (co umožnilo, že se to stalo)
- Action items (co uděláme, aby se to neopakovalo)
- Lessons learned
Žádné blame. Cíl: systémové zlepšení, ne hledání viníka.
Časté otázky
Monitoring říká, že API je pomalé. Observability ukáže konkrétní trace: query na tabulce orders trvá 8s kvůli missing indexu. Fix za 5 minut místo 5 hodin.
Open-source stack (Grafana, Prometheus, Loki, Jaeger): 4-6 týdnů implementace. SaaS (Datadog, New Relic): rychlejší setup, vyšší ongoing cost. Rozhodujeme podle budget a team capability.
Ne nutně dedicated SRE tým. SRE principy (SLO/SLI, error budgets, post-mortemy) může adoptovat každý engineering tým. Začněte s principy, ne s organizační změnou.