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

Kort: SLI is wat je meet, SLO is welk doel je wilt halen, SLA is de contractuele verbintenis. Deze termen uit het Google SRE-boek behoren tot de meest gebruikte uitdrukkingen in webdienstoperatie - en worden vaak verward.

SLI - Service Level Indicator

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 response time onder 500 ms
• % correct afgeleverde emails (delivered, niet bounced)
• Verhouding van geslaagde betaaltransacties tot alle pogingen

Sleuteleigenschappen van een goede SLI:

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

SLO - Service Level Objective

Intern doel, welke waarde de SLI moet bereiken. Uitgedrukt in percentage over tijdvenster.

Voorbeelden:

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

SLO is hoger dan SLA zodat je buffer hebt. Als SLA 99,9 % zegt, zou interne SLO bijv. 99,95 % moeten zijn - om reserve te hebben voor onverwachte incidenten.

SLA - Service Level Agreement

Contractuele verbintenis richting klanten. Definieert wat gebeurt als je het SLO niet haalt - typisch:

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

SLA heeft juridische gevolgen. SLO is intern doel.

Error budget

Sleutelconcept van SRE: downtime die je kunt veroorloven zonder SLO te schenden.

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

Praktische implicaties:

• Als je al 35 min downtime in de maand hebt, blijft 8 min over tot "SLO breach". Het team moet conservatief zijn bij verdere deploys.
• Als je 5 min downtime hebt, heb je 38 min budget voor risico's - je kunt agressievere wijzigingen, A/B-tests, experimenten doen.
• Error budget lost het conflict op tussen innovatiesnelheid (dev team) en stabiliteit (ops team). Beiden volgen hetzelfde nummer.

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 rolling 30-day venster.

SLA (voor Enterprise klanten):

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

Error budget: 99,9 % SLO betekent 43 min downtime / maand budget. SLA geeft nog grotere buffer voor economische bestraffing.

Samenvatting: tabel

Praktische fouten

• SLO te ambitieus. 99,99 % vereist active-active redundancy in meerdere regio's. Onrealistisch voor klein bedrijf.
• Alleen uptime SLO. Het web kan "up" zijn en toch onbruikbaar. Voeg latency SLO en error rate SLO toe.
• SLA zonder automatische meting. Handmatig berekend SLA-rapport is onbetrouwbaar. Investeer in geautomatiseerde uptime tracking.
• SLO zonder consequenties. Als SLO breach niemand interesseert, geeft niemand erom. Link naar 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 historische uptime-record met 30/90/365 dagen rollup. Basis voor SLO reporting.

Monitoring starten →