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

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 válaszidővel 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 három kulcstulajdonsággal rendelkezik:

• 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, amely meghatározza, milyen értéket kell az SLI-nek elérnie. Százalékosan, választott 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 válaszidővel kell rendelkeznie 7 napon belül"
• „A fizetési tranzakciók 99,5 %-a sikeresen átmegy a naptári hónapban"

Az SLO általában szigorúbb mint az SLA, hogy legyen tartalékod. Ha az SLA 99,9 %-ot mond, a belső SLO-nak pl. 99,95 %-nak kell lennie - így marad mozgástered a váratlan incidensekre, mielőtt megsértenéd a szerződést.

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 ezzel szemben csak 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, és 0,1 % 30 napból 43 perc havonta. Ez a te error budget-ed.

Gyakorlati következmények:

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

Gyakorlati példa: e-commerce API

SLI: a 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: a 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

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 veszi komolyan. 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. Szilárd alap az SLO reportinghoz.

Monitoring indítása →