SLI vs SLO vs SLA: verschillen en hoe ze in te stellen

SLI - Service Level Indicator

Een concrete metriek waarmee je de betrouwbaarheid van de dienst kwantificeert. Voorbeelden:

• % requests die eindigden in HTTP 2xx of 3xx in de laatste 30 dagen
• % requests met responstijd onder 500 ms
• % correct afgeleverde emails (delivered, niet bounced)
• Verhouding van geslaagde betaaltransacties tot alle pogingen

Een goede SLI heeft drie sleuteleigenschappen:

• Meetbaar - er is een concrete methode van dataverzameling
• Gebruikersrelevant - weerspiegelt de echte klantervaring, geen interne technische metriek
• Specifiek - "uptime" is te vaag; "% geslaagde requests naar /api/v1/orders in een venster van 5 minuten" is een SLI

SLO - Service Level Objective

Een intern doel dat bepaalt welke waarde de SLI moet bereiken. Uitgedrukt in een percentage over een gekozen tijdvenster.

Voorbeelden:

• "99,9 % van de requests naar /api/orders moeten in HTTP 2xx eindigen in 30 dagen"
• "95 % van de requests moet een responstijd onder 200 ms hebben in 7 dagen"
• "99,5 % van de betaaltransacties slaagt in een kalendermaand"

Het SLO is doorgaans strenger dan het SLA, zodat je een buffer hebt. Als het SLA 99,9 % zegt, zou het interne SLO bijv. 99,95 % moeten zijn - zo houd je reserve over voor onverwachte incidenten voordat je het contract schendt.

SLA - Service Level Agreement

Een contractuele verbintenis richting klanten. Het definieert wat er gebeurt als je het SLO niet haalt - typisch:

• Service credits - je geeft een deel van de maandelijkse bijdrage terug (10-50% afhankelijk van de grootte van de overtreding)
• Termination rights - de klant kan het contract zonder sanctie opzeggen
• Reporting-plicht - je moet postmortem en uptime-rapporten publiceren

Het SLA heeft juridische gevolgen. Het SLO is daarentegen slechts een intern doel.

Error budget

Een sleutelconcept van SRE: downtime die je je kunt veroorloven zonder het SLO te schenden.

Voorbeeld: SLO = 99,9 % uptime in 30 dagen. Dat is 0,1 % toegestane downtime, en 0,1 % van 30 dagen is 43 minuten per maand. Dit is je error budget.

Praktische implicaties:

• Als je al 35 min downtime in de maand hebt verbruikt, blijft er 8 min over tot de SLO breach. Het team moet conservatief zijn bij verdere deploys.
• Als je slechts 5 min downtime hebt verbruikt, heb je 38 min budget voor risico - je kunt je agressievere wijzigingen, A/B-tests en experimenten veroorloven.
• Het error budget lost zo het conflict op tussen innovatiesnelheid (dev team) en stabiliteit (ops team). Beide kanten volgen hetzelfde getal.

Praktisch voorbeeld: e-commerce API

SLI: % HTTP requests naar POST /api/checkout die in 2xx eindigden, gemeten in 1-minuut buckets over de laatste 30 dagen.

SLO: ≥ 99,9 % geslaagde requests in een rolling 30-day venster.

SLA (voor Enterprise klanten):

• ≥ 99,5 % uptime in een kalendermaand
• Bij 99,0-99,5 % = 10% credit van de maandelijkse bijdrage
• Bij 95,0-99,0 % = 25% credit
• Bij < 95,0 % = 50% credit + recht het contract op te zeggen

Error budget: een SLO van 99,9 % betekent 43 min downtime per maand. Het SLA geeft een nog grotere buffer voordat er een economische bestraffing volgt.

Samenvatting: tabel

Praktische fouten

• Een te ambitieus SLO. 99,99 % vereist active-active redundancy in meerdere regio's. Onrealistisch voor een klein bedrijf.
• Alleen een uptime SLO. Het web kan "up" zijn en toch onbruikbaar. Voeg een latency SLO en een error rate SLO toe.
• Een SLA zonder automatische meting. Een handmatig berekend SLA-rapport is onbetrouwbaar. Investeer in geautomatiseerde uptime tracking.
• Een SLO zonder consequenties. Als een SLO breach niemand interesseert, neemt niemand het serieus. Koppel het aan deploy freeze, on-call escalation, enz.

Conclusie

Het SLI/SLO/SLA framework is geen papieren bureaucratie - het is de taal waarmee het engineering team communiceert met business stakeholders over betrouwbaarheid. Zonder deze termen wordt de discussie over stabiliteit subjectief ("ons web is instabiel"). Met hen is het numeriek ("in de laatste 30 dagen hebben we 99,87 % SLI bereikt, wat onder ons 99,9 % SLO is - hier is het actieplan").

Meet SLI in real time

ePulz.io biedt een historische uptime-record met 30/90/365 dagen rollup. Een solide basis voor SLO reporting.

Monitoring starten →