66. SLI, SLO, SLA a error budgets

Úvod a kontext

Minulá lekce zmínila SLI, SLO, SLA a error budget jako klíčové
nástroje SRE pro měřitelné rozhodování o spolehlivosti. Tyto čtyři
zkratky se často pletou, přitom mají přesně definovaný a odlišný
význam. Bez jejich pochopení není možné error budget prakticky
používat — tato lekce jde do detailu, jak každý z pojmů definovat
a spočítat.

Teorie

SLI — Service Level Indicator (indikátor)

SLI je konkrétní, měřitelná metrika, která vyjadřuje, jak dobře
služba funguje z pohledu uživatele. Není to cíl, je to jen měření.
Typické SLI:

• Dostupnost (availability) — podíl úspěšných požadavků
  (např. bez chyby 5xx) z celkového počtu požadavků za dané období.
• Latence — podíl požadavků, které se vyřídily pod určitým
  prahem (např. "podíl požadavků rychlejších než 300 ms").
• Propustnost/chybovost pipeline — pro dávkové systémy, podíl
  úspěšně zpracovaných úloh.
• Čerstvost dat (freshness) — u datových pipeline, jak stará
  jsou nejnovější zpracovaná data.

Dobré SLI musí přímo odrážet zkušenost uživatele — proto se často
měří co nejblíž hranici, kterou uživatel skutečně vnímá (např. na
úrovni load balanceru nebo API gateway), ne hluboko uvnitř
infrastruktury.

SLO — Service Level Objective (cíl)

SLO je interní cíl, jaké hodnoty by SLI mělo dlouhodobě
dosahovat — např. "99,9 % požadavků za posledních 30 dní má
odpovědět úspěšně" nebo "99 % požadavků odpoví do 300 ms". SLO je
vždy vázané na konkrétní SLI a konkrétní časové okno. Volba SLO
je kompromis: vyšší SLO (víc devítek) znamená víc investic do
spolehlivosti a pomalejší vývoj nových funkcí; nižší SLO uvolňuje
kapacitu pro rychlejší vývoj, ale zvyšuje riziko nespokojenosti
uživatelů. SLO by nemělo být 100 % — kromě extrémní nákladnosti to
navíc znemožňuje jakoukoliv údržbu nebo nasazení bez porušení cíle.

SLA — Service Level Agreement (smlouva)

SLA je formální, často smluvně vymahatelná dohoda se zákazníkem,
obvykle obsahující i důsledky nedodržení (finanční kompenzace,
penále). SLA bývá nastavené volnější než interní SLO — pokud
máte interní SLO 99,9 %, SLA směrem k zákazníkovi může slibovat jen
99,5 %, aby zbyl bezpečnostní polštář a drobné podkročení interního
cíle nevedlo automaticky k porušení smlouvy a penále. Ne každá
služba SLA vůbec má — interní služby v rámci firmy typicky mají jen
SLO, žádnou vymahatelnou smlouvu.

Vztah mezi nimi

Zjednodušený vztah: SLI je měření → SLO je interní cíl nad tímto
měřením → SLA je smluvní závazek, obvykle volnější než SLO, s
důsledky při porušení. Typická chyba začátečníků je nastavit SLO
stejné jako SLA nebo dokonce SLI bez jasného SLO vůbec definovat —
bez SLO nemá tým žádné vodítko, kdy je situace v pořádku a kdy už je
třeba zpomalit vývoj a soustředit se na stabilitu.

Error budget — most mezi metrikou a rozhodováním

Error budget je odvozená veličina: 1 − SLO, vyjádřená jako
množství "povoleného selhávání" za dané období. Pokud SLO je
99,9 % za 30 dní, error budget je 0,1 % z celkového počtu požadavků
(nebo ekvivalentně z celkového času, cca 43 minut). Dokud SLI zůstává
v rámci error budgetu, tým má formální mandát nasazovat nové funkce
rychleji a přijímat rozumné riziko. Jakmile je error budget vyčerpán,
platí dohodnuté pravidlo — typicky zastavení rizikových nasazení a
soustředění na stabilizaci, dokud se budget v dalším období neobnoví.

Praktický příklad

Definice SLI a SLO v podobě, jakou lze přímo implementovat jako
Prometheus alerting rule (navazuje na modul 12) — tzv. multi-window
multi-burn-rate alert, běžná SRE praxe pro alertování na porušení
error budgetu:

# SLI: podíl úspěšných HTTP požadavků (ne-5xx) za posledních 5 minut
# SLO: 99.9 % úspěšnost za rolující 30 dní

groups:
  - name: slo-objednavky
    rules:
      - record: sli:requests_success_ratio:rate5m
        expr: |
          sum(rate(http_requests_total{job="objednavky", status!~"5.."}[5m]))
          /
          sum(rate(http_requests_total{job="objednavky"}[5m]))

      - alert: RychleVycerpavaniErrorBudgetu
        expr: |
          (1 - sli:requests_success_ratio:rate5m) > (14.4 * 0.001)
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Error budget se vyčerpává rychlostí, která by ho spotřebovala za méně než 2 dny"

Výpočet error budgetu a "burn rate" (jak rychle se budget spotřebovává)
v Pythonu, pro dashboard nebo měsíční report:

SLO = 0.999
OBDOBI_DNU = 30
MINUT_CELKEM = OBDOBI_DNU * 24 * 60

error_budget_minut = MINUT_CELKEM * (1 - SLO)   # 43.2 min
vycerpano_minut = 30                             # naměřeno z metrik

zbyvajici_pomer = 1 - (vycerpano_minut / error_budget_minut)
print(f"Error budget: {error_budget_minut:.1f} min")
print(f"Vyčerpáno: {vycerpano_minut} min ({100 - zbyvajici_pomer*100:.0f} %)")
print(f"Zbývá: {zbyvajici_pomer*100:.0f} % budgetu do konce období")

if zbyvajici_pomer < 0.1:
    print("POZOR: méně než 10 % budgetu zbývá — pozastavit riziková nasazení.")

Praktický příklad rozdílu SLO vs. SLA: interní tým má SLO 99,9 % pro
API, ale zákaznická smlouva (SLA) garantuje jen 99,5 % s finanční
kompenzací při nedodržení — rozdíl 0,4 procentního bodu je záměrný
bezpečnostní polštář, aby drobné, krátkodobé podkročení interního
cíle nevedlo automaticky k porušení placené smlouvy.

Shrnutí

SLI je konkrétní měřitelná metrika (co měříme), SLO je interní cíl
nad touto metrikou (jaké hodnoty chceme dosahovat), SLA je formální,
obvykle volnější smluvní závazek s důsledky při porušení. Error
budget (1 − SLO) převádí abstraktní cíl spolehlivosti na konkrétní
"rozpočet" povoleného selhávání, který týmu dává jasné, předem
dohodnuté pravidlo, kdy je bezpečné nasazovat rizikové změny a kdy je
třeba se soustředit na stabilizaci. Tento mechanismus nahrazuje
subjektivní debaty objektivním číslem.

Kontrolní otázky

1. Vysvětlete vlastními slovy rozdíl mezi SLI, SLO a SLA a uveďte
   příklad každého z nich pro webovou aplikaci.
2. Proč bývá SLA nastavené volnější (nižší číslo) než interní SLO?
3. Jak se počítá error budget ze SLO a k čemu konkrétně tým tento
   výpočet používá při rozhodování o nasazení?
4. Mini cvičení: služba má SLO 99,95 % za 30denní období. Kolik minut
   nedostupnosti (error budget) má tým k dispozici, a kolik z něj
   zbývá, pokud už bylo vyčerpáno 10 minut?