SLI vs SLO vs SLA: különbségek és hogyan állítsd be őket

Röviden: Az SLI az, amit mérsz, az SLO az, milyen célt akarsz elérni, az SLA pedig a szerződéses kötelezettség. Ezek a kifejezések a Google SRE könyvből a leggyakrabban használt szóösszetételek közé tartoznak a webszolgáltatások üzemeltetésében - és gyakran keveredő.

Röviden: Az SLI az, amit mérsz, az SLO az, milyen célt akarsz elérni, az SLA pedig a szerződéses kötelezettség. Ezek a kifejezések a Google SRE könyvből a leggyakrabban használt szóösszetételek közé tartoznak a webszolgáltatások üzemeltetésében - és gyakran keveredő.

SLI - Service Level Indicator

Konkrét metrika, amellyel a szolgáltatás megbízhatóságát számszerűsíted. Példák:

a HTTP 2xx vagy 3xx-szel végződő kérések %-a az utóbbi 30 napban
500 ms alatti response time-mal rendelkező kérések %-a
helyesen kézbesített emailek %-a (delivered, nem bounced)
sikeres fizetési tranzakciók aránya az összes próbálkozáshoz

Egy jó SLI kulcs tulajdonságai:

Mérhető - létezik konkrét adatgyűjtési módszer
Felhasználói szempontból releváns - a valódi ügyfélélményt tükrözi, nem belső technikai metrikát
Specifikus - az „uptime" túl homályos; „a /api/v1/orders sikeres kéréseinek %-a 5 perces ablakban" egy SLI

SLO - Service Level Objective

Belső cél, milyen értéket kell az SLI-nek elérnie. Százalékosan, időablakra kifejezve.

Példák:

„A /api/orders-ra irányuló kérések 99,9 %-ának HTTP 2xx-ben kell végződnie 30 napon belül"
„A kérések 95 %-ának 200 ms alatti response time-mal kell rendelkeznie 7 napon belül"
„A fizetési tranzakciók 99,5 %-a sikeresen átmegy a naptári hónapban"

Az SLO magasabb mint az SLA, hogy legyen buffer. Ha az SLA 99,9 %-ot mond, a belső SLO-nak pl. 99,95 %-nak kell lennie - hogy legyen tartalék a váratlan incidensekre.

SLA - Service Level Agreement

Szerződéses kötelezettség az ügyfelek felé. Definiálja, mi történik, ha nem tartod be az SLO-t - jellemzően:

Service credits - visszaadod a havi díj egy részét (10-50% a megszegés mértéke szerint)
Termination rights - az ügyfél felmondhatja a szerződést szankció nélkül
Reporting kötelezettség - postmortem-et és uptime jelentéseket kell közzétenned

Az SLA-nak jogi következményei vannak. Az SLO belső cél.

Error budget

Az SRE kulcskoncepciója: az a downtime, amit megengedhetsz magadnak az SLO megsértése nélkül.

Példa: SLO = 99,9 % uptime 30 napra. Ez 0,1 % megengedett downtime. 0,1 % 30 napból = 43 perc havonta. Ez a te error budget-ed.

Gyakorlati következmények:

Ha már 35 perc downtime-od van a hónapban, 8 perc marad az „SLO breach"-ig. A csapatnak konzervatívnak kell lennie a további deployoknál.
Ha 5 perc downtime-od van, 38 perc budgeted van kockázatokra - csinálhatsz agresszívebb változtatásokat, A/B teszteket, kísérleteket.
Az error budget feloldja a konfliktust az innováció sebessége (dev team) és a stabilitás (ops team) között. Mindketten ugyanazt a számot követik.

Gyakorlati példa: e-commerce API

SLI: POST /api/checkout-ra irányuló HTTP kérések %-a, amelyek 2xx-szel végződtek, 1 perces bucketekben mérve az utóbbi 30 napban.

SLO: ≥ 99,9 % sikeres kérés egy rolling 30 napos ablakban.

SLA (Enterprise ügyfeleknek):

≥ 99,5 % uptime naptári hónapban
99,0-99,5 %-nál = a havi díj 10%-a credit
95,0-99,0 %-nál = 25% credit
< 95,0 %-nál = 50% credit + jog a szerződés felmondására

Error budget: 99,9 % SLO 43 perc downtime / hónap budget-et jelent. Az SLA még nagyobb buffert ad a gazdasági büntetés előtt.

Összegzés: táblázat

Fogalom	Mi az	Kinek
SLI	Konkrét megbízhatósági metrika	Engineering csapat
SLO	Belső cél az SLI-re	Engineering + product
SLA	Szerződéses kötelezettség	Ügyfél + legal
Error budget	Downtime amit megengedhetsz SLO breach előtt	Engineering risk management

Gyakorlati hibák

Túl ambiciózus SLO. A 99,99 % active-active redundancy-t igényel több régióban. Egy kis cégnek irreális.
Csak uptime SLO. A web lehet „up" és mégis használhatatlan. Adj hozzá latency SLO-t és error rate SLO-t.
SLA automatikus mérés nélkül. A manuálisan számolt SLA jelentés megbízhatatlan. Fektess be automatizált uptime trackingbe.
SLO konzekvenciák nélkül. Ha az SLO breach senkit nem érdekel, senki nem törődik vele. Linkeld deploy freeze-hez, on-call escalation-höz stb.

Következtetés

Az SLI/SLO/SLA framework nem papír bürokrácia - ez az a nyelv, amelyen az engineering csapat kommunikál a business stakeholderekkel a megbízhatóságról. E fogalmak nélkül a stabilitásról szóló vita szubjektívvé válik („a webünk instabil"). Velük számszerű („az utóbbi 30 napban 99,87 % SLI-t értünk el, ami a 99,9 %-os SLO-nk alatt van - itt az akciótervünk").

Mérd az SLI-t valós időben

Az ePulz.io történeti uptime feljegyzést biztosít 30/90/365 napos rolluppal. Alap az SLO reportinghoz.

Monitoring indítása →