SLI, SLO, SLA: meriame dostupnosť bez ilúzií

SLI - Service Level Indicator

Konkrétna metrika, ktorou kvantifikujete spoľahlivosť služby. Príklady:

• % requestov, ktoré skončili HTTP 2xx alebo 3xx za posledných 30 dní
• % requestov s časom odozvy pod 500 ms
• % správne doručených emailov (delivered, nie bounced)
• Pomer úspešných platobných transakcií ku všetkým pokusom

Dobrý SLI má tri kľúčové vlastnosti:

• Merateľný - existuje konkrétna metóda zberu dát
• Užívateľsky relevantný - odráža reálnu skúsenosť zákazníka, nie internú technickú metriku
• Špecifický - "uptime" je príliš vágne; "% úspešných requestov na /api/v1/orders za 5-minútové okno" je SLI

SLO - Service Level Objective

Interný cieľ, ktorý stanovuje, akú hodnotu má SLI dosahovať. Vyjadruje sa percentuálne za zvolené časové okno.

Príklady:

• "99,9 % requestov na /api/orders má skončiť HTTP 2xx za 30 dní"
• "95 % requestov má mať čas odozvy pod 200 ms za 7 dní"
• "99,5 % platobných transakcií prejde úspešne za kalendárny mesiac"

SLO býva prísnejší ako SLA, aby ste mali rezervu. Ak SLA hovorí 99,9 %, interný SLO by mal byť napríklad 99,95 % - vďaka tomu vám zostáva priestor na neočakávané incidenty skôr, než porušíte zmluvu.

SLA - Service Level Agreement

Zmluvný záväzok voči zákazníkom. Definuje, čo sa stane, keď nedodržíte SLO - typicky:

• Service credits - vrátite časť mesačného poplatku (10 - 50 % podľa rozsahu porušenia)
• Termination rights - zákazník môže vypovedať zmluvu bez sankcie
• Reporting povinnosť - musíte publikovať postmortem a uptime reporty

SLA má právne dôsledky. SLO je naproti tomu len interný cieľ.

Error budget

Kľúčový koncept SRE: downtime, ktorý si môžete dovoliť bez porušenia SLO.

Príklad: SLO = 99,9 % uptime za 30 dní. To znamená 0,1 % povoleného downtime, a 0,1 % z 30 dní je 43 minút mesačne. Toto je váš error budget (pri 30-dňovom okne).

Praktické dôsledky:

• Ak ste už vyčerpali 35 min downtime za mesiac, zostáva 8 min do porušenia SLO. Tím by mal byť pri ďalších deployoch konzervatívny.
• Ak ste minuli len 5 min downtime, máte 38 min rezervy na riziko - môžete si dovoliť agresívnejšie zmeny, A/B testy a experimenty.
• Error budget tak rieši konflikt medzi rýchlosťou inovácie (dev tím) a stabilitou (ops tím). Obe strany sledujú rovnaké číslo.

Praktický príklad: e-commerce API

SLI: % HTTP requestov na POST /api/checkout, ktoré skončili 2xx, merané v 1-minútových bucketoch za posledných 30 dní.

SLO: ≥ 99,9 % úspešných requestov za 30-dňové posuvné okno.

SLA (pre Enterprise zákazníkov):

• ≥ 99,5 % uptime za kalendárny mesiac
• Pri 99,0-99,5 % = 10 % credit z mesačného poplatku
• Pri 95,0-99,0 % = 25 % credit
• Pri < 95,0 % = 50 % credit + právo vypovedať zmluvu

Error budget: 99,9 % SLO znamená 43 min downtime mesačne. SLA dáva ešte väčší buffer pred ekonomickou penalizáciou.

Zhrnutie: tabuľka

Praktické chyby

• Príliš ambiciózne SLO. 99,99 % vyžaduje active-active redundanciu vo viacerých regiónoch. Pre malú firmu je to nereálne.
• Len uptime SLO. Web môže byť "up" a napriek tomu nepoužiteľný. Pridajte aj latency SLO a error rate SLO.
• SLA bez automatického merania. Manuálne počítaný SLA report je nedôveryhodný. Investujte do automatizovaného uptime trackingu.
• SLO bez následkov. Ak sa o porušenie SLO nikto nezaujíma, nikto ho ani neberie vážne. Prepojte ho na deploy freeze, on-call eskaláciu a podobne.

Záver

SLI/SLO/SLA framework nie je papierová byrokracia - je to jazyk, ktorým engineering tím komunikuje s biznisom o spoľahlivosti. Bez týchto pojmov sa diskusia o stabilite stáva subjektívnou ("náš web je nestabilný"). S nimi je číselná ("za posledných 30 dní sme dosiahli 99,87 % SLI, čo je pod naším 99,9 % SLO - tu je akčný plán").

Merajte SLI v reálnom čase

ePulz.io poskytuje historický uptime záznam s rollupom podľa plánu (30 dní Štandard, 90 dní Profi, 365 dní Business). Solídny základ pre SLO reporting.

Spustiť monitoring →

Súvisiace

• Čo je uptime a prečo na ňom záleží
• Incident response playbook
• Status page best practices