SLI vs SLO vs SLA: rozdíly a jak je nastavit

Ve zkratce: SLI je co měříte, SLO je jaký cíl chcete dosáhnout, SLA je smluvní závazek. Tyto pojmy z Google SRE knihy jsou jedny z nejpoužívanějších slovních spojení v provozování webových služeb - a často mísených.

SLI - Service Level Indicator

Konkrétní metrika, kterou kvantifikujete spolehlivost služby. Příklady:

• % requestů, které skončily HTTP 2xx nebo 3xx za posledních 30 dní
• % requestů s response time pod 500 ms
• % správně doručených emailů (delivered, ne bounced)
• Poměr úspěšných platebních transakcí ke všem pokusům

Klíčové vlastnosti dobrého SLI:

• Měřitelný - existuje konkrétní metoda sběru dat
• Uživatelsky relevantní - odráží reálnou zkušenost zákazníka, ne interní technickou metriku
• Specifický - "uptime" je příliš vágní; "% úspěšných requestů na /api/v1/orders za 5-minutové okno" je SLI

SLO - Service Level Objective

Interní cíl, jakou hodnotu má SLI dosahovat. Vyjadřuje se procentuálně za časové okno.

Příklady:

• "99,9 % requestů na /api/orders má skončit HTTP 2xx za 30 dní"
• "95 % requestů má response time pod 200 ms za 7 dní"
• "99,5 % platebních transakcí projde úspěšně za kalendářní měsíc"

SLO je vyšší než SLA, abyste měli buffer. Pokud SLA říká 99,9 %, interní SLO by mělo být např. 99,95 % - abyste měli rezervu na neočekávané incidenty.

SLA - Service Level Agreement

Smluvní závazek vůči zákazníkům. Definuje co se stane, když nedodržíte SLO - typicky:

• Service credits - vrátíte část měsíčního poplatku (10-50% podle velikosti porušení)
• Termination rights - zákazník může vypovědět smlouvu bez sankce
• Reporting povinnost - musíte publikovat postmortem a uptime reporty

SLA má právní důsledky. SLO je interní cíl.

Error budget

Klíčový koncept SRE: downtime, který si můžete dovolit bez porušení SLO.

Příklad: SLO = 99,9 % uptime za 30 dní. To je 0,1 % povoleného downtime. 0,1 % z 30 dní = 43 minut měsíčně. Toto je váš error budget.

Praktické důsledky:

• Pokud máte už 35 min downtime v měsíci, zbývá 8 min do "porušení SLO". Tým by měl být konzervativní při dalších deployech.
• Pokud máte 5 min downtime, máte 38 min budget na rizika - můžete dělat agresivnější změny, A/B testy, experimenty.
• Error budget řeší konflikt mezi rychlostí inovace (dev team) a stabilitou (ops team). Oba sledují stejné číslo.

Praktický příklad: e-commerce API

SLI: % HTTP requestů na POST /api/checkout, které skončily 2xx, měřené v 1-minutových bucketech za posledních 30 dní.

SLO: ≥ 99,9 % úspěšných requestů za rolling 30-day window.

SLA (pro Enterprise customers):

• ≥ 99,5 % uptime za kalendářní měsíc
• Při 99,0-99,5 % = 10% credit z měsíčního poplatku
• Při 95,0-99,0 % = 25% credit
• Při < 95,0 % = 50% credit + právo vypovědět smlouvu

Error budget: 99,9 % SLO znamená 43 min downtime / měsíc na budget. SLA dává ještě větší buffer před ekonomickou penalizací.

Shrnutí: tabulka

Praktické chyby

• SLO příliš ambiciózní. 99,99 % vyžaduje active-active redundancy v multiple regions. Pro malou firmu nereálné.
• Pouze uptime SLO. Web může být "up" a stejně nepoužitelný. Přidejte latency SLO a error rate SLO.
• SLA bez automatického měření. Manuálně kalkulovaný SLA report je nedůvěryhodný. Investujte do automatizovaného uptime trackingu.
• SLO bez consequences. Pokud SLO breach nikoho nezajímá, nikdo se o něm nestará. Linkujte na deploy freeze, on-call escalation, atd.

Závěr

SLI/SLO/SLA framework není papírová byrokracie - je to jazyk, kterým engineering tým komunikuje s business stakeholdery o spolehlivosti. Bez těchto pojmů se diskuse o stabilitě stává subjektivní ("náš web je nestabilní"). S nimi je číselná ("za posledních 30 dní jsme dosáhli 99,87 % SLI, což je pod naším 99,9 % SLO - tady je akční plán").

Měřte SLI v reálném čase

ePulz.io poskytuje historický uptime záznam s 30/90/365-denním rollupem. Základ pro SLO reporting.

Spustit monitoring →