SRE a SLO Engineering: Jak nastavit spolehlivost služeb v roce 2026

Spolehlivost služeb přestala být doménou ops týmů na on-callu. V roce 2026 je SLO Engineering systematická disciplína, která propojuje byznys požadavky s technickými metrikami — a rozhoduje o tom, kdy tým vyvíjí nové features a kdy opravuje technický dluh. Tento článek je praktický průvodce: od základních konceptů SLI/SLO/SLA přes error budgets a burn rate alerting až po nástroje jako OpenSLO, Sloth a Nobl9 a jejich integraci do platform engineering workflow.

Proč je SRE relevantní víc než kdy dřív¶

Site Reliability Engineering (SRE) jako disciplína vznikla v Googlu kolem roku 2003. O dvacet let později by se dalo čekat, že je to vyřešený problém. Není. Důvodů je několik: distribuované systémy jsou komplexnější (microservices, multi-cloud, edge computing), AI workloady přinášejí nedeterministické chování (inference latency závisí na model size, batch size a GPU utilization), a uživatelská očekávání rostou — 100ms latence, která byla v roce 2020 akceptovatelná, je dnes důvod ke churn.

Zásadní posun v roce 2026: SRE už není role jednoho „site reliability engineera” v týmu. Je to sada principů a praktik, které se integrují do platform engineeringu. Internal Developer Platforms (IDP) dnes obsahují SLO dashboardy, error budget tracking a burn rate alerty jako first-class features. Každý vývojářský tým definuje SLO pro své služby a platforma enforceuje důsledky — včetně automatického zmrazení deploymentů, když error budget klesne pod threshold.

SLI, SLO a SLA — tři pilíře spolehlivosti¶

Než se pustíme do pokročilých konceptů, pojďme si ujasnit terminologii. Přestože zkratky SLI, SLO a SLA znějí podobně, reprezentují fundamentálně odlišné věci:

SLI — Service Level Indicator¶

SLI je kvantitativní měření chování služby z pohledu uživatele. Není to interní metrika typu „CPU utilization” nebo „memory usage” — je to měření, které přímo koreluje s uživatelskou zkušeností. Typické SLI zahrnují:

Availability — poměr úspěšných requestů k celkovému počtu requestů (např. 99,95 %)
Latency — percentilová distribuce response time (p50, p95, p99). Nikdy nepoužívejte průměr — skrývá tail latency problémy.
Throughput — počet úspěšně zpracovaných requestů za jednotku času
Error rate — poměr chybových odpovědí (5xx) k celkovému trafficu
Correctness — poměr správných výsledků (kritické pro AI inference, finanční výpočty, data pipelines)
Freshness — stáří dat v data pipeline nebo cache (klíčové pro real-time systémy)

Tip pro výběr SLI: Zeptejte se: „Kdyby toto číslo kleslo, zavolal by zákazník na support?” Pokud ano, je to dobrý SLI. Pokud ne, měříte infrastrukturní metriku, ne uživatelskou zkušenost.

SLO — Service Level Objective¶

SLO je cílová hodnota SLI, na které se tým dohodne. Říká: „Toto SLI by mělo být nad/pod touto hranicí po X % měřeného okna.” Například:

Availability SLO: 99,9 % úspěšných requestů za 30denní rolling window
Latency SLO: 95 % requestů pod 200ms (p95 ≤ 200ms) za 30denní rolling window
Correctness SLO: 99,99 % transakcí zpracováno správně za 30denní rolling window

Klíčová otázka: Proč ne 100 %? Protože 100% spolehlivost je fyzicky nemožná (i Google má výpadky) a ekonomicky nesmyslná. Rozdíl mezi 99,9 % a 99,99 % vyžaduje řádově větší investice — a pro většinu služeb zákazník ten rozdíl nepozná. SLO je kompromis mezi spolehlivostí a rychlostí inovace. Přísnější SLO = méně prostoru pro experimenty. Mírnější SLO = více prostoru, ale vyšší riziko churn.

SLA — Service Level Agreement¶

SLA je právní smlouva mezi poskytovatelem a zákazníkem, která definuje minimální úroveň služby a finanční důsledky (SLA credits, penalizace) při jejím porušení. SLA by mělo být vždy mírnější než interní SLO. Pokud vaše SLO je 99,9 %, vaše SLA by mělo být 99,5 %. Důvod: SLO je váš interní cíl — porušení SLO spouští interní akce (zmrazení deploymentů, prioritizace reliability práce). Porušení SLA spouští finanční důsledky. Nikdy nechcete, aby se tyto dvě hranice překrývaly.

99,9%

= 43 min downtime / měsíc

99,95%

= 22 min downtime / měsíc

99,99%

= 4,3 min downtime / měsíc

99,999%

= 26 sec downtime / měsíc

Error Budgets — rozpočet na chyby¶

Error budget je koncept, který z SLO dělá actionable rozhodovací nástroj. Funguje jednoduše: pokud vaše SLO je 99,9 % availability za 30 dní, pak váš error budget je 0,1 % — tedy 43,2 minuty downtime, které si „můžete dovolit” za měsíc.

Error budget odpovídá na fundamentální otázku: „Měli bychom deployovat nový feature, nebo opravovat spolehlivost?” Pokud je error budget zdravý (zbývá hodně prostoru), tým má zelenou pro rychlé deploymenty, experimentování a risky changes. Pokud je error budget vyčerpán nebo téměř vyčerpán, tým se zastaví a soustředí se na reliability engineering — opravy bugů, performance optimalizace, chaos testing, redundance.

Toto je revoluce oproti tradičnímu přístupu „nulová tolerance k chybám”. Místo toho, aby se tým snažil o nedosažitelnou dokonalost, pracuje s explicitním rozpočtem. Error budget legitimizuje controlled risk-taking a dává SRE týmu objektivní argument proti příliš agresivnímu feature developmentu — ne „myslím, že bychom měli zpomalit”, ale „error budget je na 12 %, zmrazujeme deploymenty dokud se nevrátí nad 30 %”.

Error budget policies¶

Error budget bez policies je jen číslo na dashboardu. Aby error budget fungoval, potřebujete formální politiky, co se děje při různých úrovních čerpání:

>50 % zbývá — normální provoz, deploymenty bez omezení, experimenty povoleny
30–50 % zbývá — zvýšená pozornost, povinný canary deployment, rollback automatizace ověřena
10–30 % zbývá — zmrazení non-critical deploymentů, tým prioritizuje reliability práci, incident review pro každý výpadek
<10 % zbývá — úplné zmrazení deploymentů (pouze hotfixy), emergency reliability sprint, eskalace na engineering leadership
0 % (vyčerpán) — postmortem review, root cause analysis všech incidentů v okně, action items s deadline, review SLO relevance

Klíčové: error budget policies musí být dohodnuté předem mezi product ownerem, engineering leaderem a SRE týmem. Pokud se o nich diskutuje až v momentě, kdy je budget vyčerpán, je pozdě — politické tlaky převáží nad technickou realitou.

Burn Rate Alerting — konec alert fatigue¶

Tradiční alerting založený na statických thresholdech (alert když error rate > 1 %) je v roce 2026 považován za anti-pattern. Důvod: krátký spike na 5 % error rate po dobu 30 sekund je jiná situace než sustained 1,5 % error rate po dobu 4 hodin. Statický threshold zachytí první a ignoruje druhý — přestože druhý scénář spotřebuje řádově více error budgetu.

Řešení je burn rate alerting. Burn rate udává, jak rychle vaše služba spotřebovává error budget. Burn rate 1 znamená, že budget spotřebujete přesně na konci SLO window (30 dní). Burn rate 10 znamená, že budete na nule za 3 dny. Burn rate 100 znamená vyčerpání za 7,2 hodiny.

Google SRE Workbook doporučuje multi-window, multi-burn-rate alerting s dvěma okny: krátkým (pro detekci) a dlouhým (pro potvrzení). Typická konfigurace:

Page (okamžitá akce) — Burn rate 14,4×¶

Krátké okno: 1 hodina. Dlouhé okno: 5 minut. Při tomto tempu bude error budget vyčerpán za ~2 dny. Vyžaduje okamžitou pozornost — probuďte on-call inženýra.

Page (urgentní) — Burn rate 6×¶

Krátké okno: 6 hodin. Dlouhé okno: 30 minut. Vyčerpání za ~5 dní. Stále urgentní, ale nemusí nutně budit o půlnoci — záleží na kontextu.

Ticket (non-urgent) — Burn rate 3×¶

Krátké okno: 1 den. Dlouhé okno: 2 hodiny. Vyčerpání za ~10 dní. Vytvořte ticket, tým řeší v rámci normálního sprintu. Nebudte nikoho.

Ticket (low priority) — Burn rate 1×¶

Krátké okno: 3 dny. Dlouhé okno: 6 hodin. Budget se spotřebuje přesně na konci okna. Informační alert — tým by měl monitorovat trend.

Hlavní výhoda burn rate alertingu: dramaticky snižuje alert fatigue. Místo desítek false positive alertů denně dostanete jednotky actionable alertů, které jsou přímo napojené na byznys dopad (error budget consumption). On-call inženýr přestane ignorovat alerty, protože každý alert skutečně znamená „zákazníci mají problém”.

Praktické příklady — SLO pro reálné služby¶

E-commerce checkout API¶

Pro platební API e-commerce platformy bychom definovali:

SLI: Availability — poměr HTTP 2xx/3xx odpovědí ku všem requestům (exkluze health checks)
SLI: Latency — p99 response time pro POST /checkout
SLO: Availability — 99,95 % za 30denní rolling window (max 21,6 min downtime/měsíc)
SLO: Latency — p99 ≤ 500ms za 30denní rolling window

Proč 99,95 % a ne 99,9 %? Protože checkout je revenue-critical path. Každá minuta downtime = přímá ztráta příjmů. Pro interní admin API by bylo 99,9 % zcela adekvátní.

AI inference endpoint¶

AI inference má specifika — latence je variabilnější a závisí na input size:

SLI: Availability — poměr non-5xx odpovědí (429 rate limiting excluded)
SLI: Latency — p95 response time segmentovaný podle model size (small/medium/large)
SLI: Correctness — poměr odpovědí, které projdou output validation (non-hallucination check)
SLO: Availability — 99,9 % za 30denní window
SLO: Latency — p95 ≤ 2s pro small model, p95 ≤ 8s pro large model
SLO: Correctness — 99,5 % validních odpovědí za 7denní window

Data pipeline (batch)¶

Pro ETL pipeline měříme jiná SLI než pro synchronní API:

SLI: Freshness — čas od vzniku dat k jejich dostupnosti v data warehouse
SLI: Completeness — poměr zpracovaných záznamů ku celkovému počtu
SLI: Correctness — poměr záznamů, které projdou data quality checks
SLO: Freshness — data dostupná do 2 hodin od vzniku (99 % čas)
SLO: Completeness — 99,99 % záznamů zpracováno za 24h window

Nástroje pro SLO Engineering v roce 2026¶

SLO Engineering v roce 2026 má konečně zralý tooling. Tři hlavní přístupy:

OpenSLO

Open-source specifikace pro definici SLO jako kódu. Vendor-agnostic YAML formát, který lze integrovat do CI/CD a GitOps workflow.

Sloth

Generátor Prometheus recording rules a alertů z SLO definic. Zero-code SLO setup pro Prometheus/Grafana stack. Open-source.

Nobl9

Enterprise SLO platform. Multi-source SLI ingestion (Datadog, Prometheus, CloudWatch, New Relic), error budget tracking, reporting.

Google Cloud SLO Monitoring

Nativní SLO monitoring v Google Cloud. Integrace s Cloud Monitoring, auto burn rate alerting, SLO dashboardy v konzoli.

OpenSLO — SLO as Code¶

OpenSLO je vendor-neutral specifikace, která definuje SLO v YAML formátu. Klíčová myšlenka: SLO definice žijí v git repozitáři vedle aplikačního kódu, procházejí code review a jsou verzované. Žádné klikání v GUI, žádné „někdo to nastavil v Datadog a nikdo neví jak”. Příklad OpenSLO definice:

apiVersion: openslo/v1
kind: SLO
metadata:
  name: checkout-availability
  displayName: Checkout API Availability
spec:
  service: checkout-api
  description: Availability SLO for checkout endpoint
  budgetingMethod: Occurrences
  objectives:
    - displayName: 99.95% availability
      target: 0.9995
      ratioMetrics:
        good:
          source: prometheus
          queryType: promql
          query: sum(rate(http_requests_total{service="checkout",code=~"2.."}[5m]))
        total:
          source: prometheus
          queryType: promql
          query: sum(rate(http_requests_total{service="checkout"}[5m]))
  timeWindow:
    - duration: 30d
      isRolling: true

Sloth — SLO pro Prometheus stack¶

Pokud váš observability stack je Prometheus + Grafana (a v roce 2026 to platí pro většinu organizací), Sloth je nejpraktičtější volba. Z jednoduché SLO definice vygeneruje:

Recording rules — předpočítané SLI metriky pro efektivní dashboardy
Multi-window burn rate alerting rules — kompletní alerting setup podle Google SRE best practices
Grafana dashboardy — error budget remaining, burn rate trend, SLI over time

Sloth definice je minimalistická — stačí specifikovat dobrý event, celkový event a SLO target. Zbytek (burn rate výpočty, alert thresholds, recording rules) se vygeneruje automaticky. Pro tým, který chce SLO-based alerting za odpoledne práce, je Sloth ideální startovní bod.

Nobl9 — enterprise SLO management¶

Pro organizace s heterogenním observability stackem (část služeb v Datadog, část v Prometheus, část v CloudWatch) je Nobl9 enterprise řešení. Nobl9 agreguje SLI data z desítek zdrojů do jedné platformy, kde definujete SLO, sledujete error budgets a generujete reporty pro management a stakeholdery.

Hlavní výhoda Nobl9: cross-platform error budget tracking. Pokud vaše služba závisí na AWS Lambda (CloudWatch), vlastním Kubernetes clusteru (Prometheus) a third-party API (synthetic monitoring), Nobl9 dokáže všechny SLI zdroje spojit do jednoho composite SLO. Nevýhoda: komerční licence, vendor lock-in na Nobl9 platformu.

SLO Engineering × Platform Engineering¶

V mature organizacích v roce 2026 je SLO Engineering integrální součástí Internal Developer Platform. Jak to vypadá v praxi:

Service catalog obsahuje SLO — každá služba v Backstage/Port má přiřazené SLO, aktuální error budget stav a burn rate. Product owner vidí, kolik „reliability budget” zbývá.
Golden paths zahrnují SLO setup — když vývojář scaffolduje novou službu, platforma automaticky vytvoří default SLO definici, alerting rules a Grafana dashboard. Vývojář jen upraví targety.
CI/CD pipeline respektuje error budget — pokud error budget služby je pod 10 %, pipeline automaticky blokuje deploymenty (kromě hotfixů) a notifikuje tým. Žádné manuální rozhodování.
SLO review je součástí sprint retro — platform tým generuje weekly SLO report pro všechny služby. Týmy, jejichž error budget je trvale blízko vyčerpání, dostávají automatický reliability sprint.
Compliance reporting — platforma automaticky generuje SLO compliance reporty pro NIS2, DORA a ISO 27001 audity. Žádné ruční sbírání dat z deseti dashboardů.

Toto je přesně ten bod, kde SRE přestává být „věc toho jednoho ops člověka” a stává se organizační capability. Každý tým vlastní reliability svých služeb, platforma poskytuje nástroje a guard rails, a engineering leadership má real-time přehled o health celého portfolia.

Trendy SRE/SLO pro rok 2026¶

AI-driven SLO recommendations¶

Platformy začínají navrhovat SLO na základě historických dat. Analyzují traffic patterns, latency distribuce a business impact a doporučí optimální SLO target — ani příliš agresivní (neustálé porušování), ani příliš volný (žádná value).

Composite SLO a dependency-aware budgets¶

Služba A závisí na službě B, která závisí na službě C. Error budget služby A by měl zohlednit error budgets závislostí. Composite SLO modelují end-to-end user journey přes celý dependency graph, ne jen jednotlivé microservicy.

SLO pro AI workloady¶

AI inference přináší nové SLI typy: correctness (hallucination rate), consistency (odpovědi na stejný prompt), fairness (bias metriky). SLO Engineering pro AI je v roce 2026 emerging practice s rychlou adopcí.

FinOps × SLO — cost-aware reliability¶

Každé „devítko” navíc v SLO stojí peníze. Cost-aware SLO Engineering explicitně modeluje náklady na dosažení vyšší spolehlivosti a pomáhá business stakeholderům rozhodnout, zda investice za to stojí.

Závěr: SLO jako jazyk mezi byznysem a engineering¶

SRE a SLO Engineering v roce 2026 nejsou o monitoring dashboardech nebo alerting rules. Jsou o společném jazyku mezi byznysem a engineering. Product owner říká: „Potřebujeme, aby checkout fungoval.” SRE inženýr odpovídá: „OK, definujme SLO na 99,95 % availability a 500ms p99 latency. To nám dává error budget 21,6 minuty za měsíc. Při současné burn rate máme prostor na 3 risky deploymenty týdně.”

Toto je konkrétní, měřitelné a actionable. Žádné „snažíme se, aby to fungovalo”. Žádné „zase spadl server”. Místo toho: explicitní rozpočet na nespolehlivost, automatizované alerty při překročení, a jasné policies co se děje dál.

Začněte malým krokem: vyberte jednu kritickou službu, definujte 2 SLI (availability + latency), nastavte SLO a burn rate alerty pomocí Sloth. Za týden budete mít error budget dashboard. Za měsíc budete dělat rozhodnutí na základě dat místo pocitů. Za kvartál budete mít SLO pro všechny kritické služby.

A to je ten skutečný cíl SRE: spolehlivost jako engineering disciplína, ne jako štěstí.

sreslo / sli / slaerror budgetsburn rate alertingplatform engineering