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

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 dobou odezvy 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

Dobrý SLI má tři klíčové vlastnosti:

• 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, jaké hodnoty má SLI dosahovat. Vyjadřuje se procentuálně za zvolené časové okno.

Příklady:

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

SLO bývá přísnější než SLA, abyste měli rezervu. Pokud SLA říká 99,9 %, interní SLO by mělo být např. 99,95 % - díky tomu vám zůstává prostor na neočekávané incidenty, než smlouvu porušíte.

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 naproti tomu jen 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, a 0,1 % z 30 dní je 43 minut měsíčně. Toto je váš error budget.

Praktické důsledky:

• Pokud máte v měsíci už 35 min downtime, zbývá 8 min do porušení SLO. Tým by měl být při dalších deployech konzervativní.
• Pokud máte jen 5 min downtime, máte 38 min rezervy na rizika - můžete dělat agresivnější změny, A/B testy a experimenty.
• Error budget tak řeší konflikt mezi rychlostí inovace (dev team) a stabilitou (ops team). Obě strany 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íčně. SLA dává ještě větší buffer před ekonomickou penalizací.

Shrnutí: tabulka

Praktické chyby

• Příliš ambiciózní SLO. 99,99 % vyžaduje active-active redundancy v multiple regions. Pro malou firmu je to 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 se o porušení SLO nikdo nezajímá, nikdo ho nebere vážně. Propojte ho 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. Solidní základ pro SLO reporting.

Spustit monitoring →