Wat is een SLO? Een beginner's gids voor service reliability

Wat is een SLO? Een service level objective (SLO) is je interne betrouwbaarheidsdoel. Geen contract met klanten, geen grondtal uit je observability-stack. Een SLO beantwoordt één vraag: hoe betrouwbaar hoeft deze service te zijn, en hoe meten we dat?

Een volledige SLO ziet er zo uit: 99,9% van HTTP-requests naar /api/checkout retourneren een success-status en voltooien zich in 300ms, gemeten over een rolling 30-daags venster. Drie componenten: de meting, het doel, het venster. Alle drie zijn belangrijk.

SLI, SLO, SLA: Drie Afkortingen Met Elk Een Eigen Betekenis

Deze drie termen duiken constant samen op. Teams gebruiken ze door elkaar. Ze beschrijven iets anders.

Een SLI (Service Level Indicator) is de ruwe meting die je monitoringtool produceert. Error rate als percentage van totale requests. P99 latency in milliseconden. Percentage succesvol afgeronde databaseschrijfoperaties. De SLI komt uit Datadog, Grafana of wat je ook draait. Het vertelt wat er gebeurde.

Een SLO (Service Level Objective) is het doel dat jij bovenop de SLI definiëert. Het beantwoordt: van alle mogelijke waarden die deze SLI kan hebben, welk bereik telt als acceptabel? Als je SLI de error rate is en je SLO is "error rate onder de 0,1% gedurende 99% van vijf-minuten-blokken", dan heb je een pass/fail-test, niet zomaar een getal op een dashboard.

Een SLA (Service Level Agreement) is de externe variant met contractuele gevolgen. Je SLA zegt misschien "99,5% uptime of we geven 20% servicecredit." Je SLO moet hoger liggen, zodat je team een verslechtering opmerkt voordat het SLA-breuk een klantgesprek wordt.

De ruimte tussen SLO en SLA is geen marge voor slordigheid. Het is een ingebouwd buffer die "we gaan richting een breuk" omzet in "we hebben nu de tijd om dit te repareren."

Nog één belangrijk onderscheid: SLI's worden continu gemeten, maar SLO's worden geëvalueerd over een venster. Dezelfde error rate over zeven dagen versus 30 dagen geeft heel andere resultaten. Eén slecht uur weegt zwaar in een zeven-daags venster. In 30 dagen is dat ruwweg een procent van de periode. Het juiste venster kiezen is net zo belangrijk als het juiste doel.

Waarom "Hoe Betrouwbaar?" Geen Volledige Vraag Is

Voordat je een getal kiest, moet je snappen wat gebruikers ervaren als de service afneemt. "We moeten naar vijf nines" is ambitie, geen meting. Een checkout-API op 99,999% availability betekent ruwweg 26 seconden fouten per maand. Voor een service die tien transacties per seconde verwerkt, kan dat prima. Voor real-time financiële settlement misschien niet.

Het juiste SLO hangt van twee zaken af: de impact op gebruikers als het misgaat, en de operationele kosten van een strenger doel.

Als je service 99,3% beschikbaarheid heeft gehad over de afgelopen 90 dagen, een SLO van 99,9% instellen is aspiratie, niet kalibrering. De praktische aanpak: haal 90 dagen SLI-data op, zet de SLO iets strakker dan huidge performance, review dan per kwartaal. Een 99,5% SLO met echt foutbudgetbeleid slaat een 99,9% SLO die je elke keer negeren de hand van.

Gangbare SLO-doelen per servicetype:

• Klant-gerichte API's (checkout, auth): 99,9% beschikbaarheid, P99 latency onder 500ms

• Interne services (datapijplijnen, batchjobs): 99,5% succes, gemeten op job-voltooiing

• Admin-tools: 99% beschikbaarheid volstaat vaak

• Achtergrondwerkers: SLO op job-completetietijd, niet HTTP-status

Wanneer je kiest welke SLI te meten, gebruik Google's vier signalen uit hun SRE-boek als startpunt: beschikbaarheid (geslaagd request?), latency (hoe lang duurde het?), doorvoer (hoeveel requests verwerkt het systeem?), error rate (welke fractie mislukte?). Niet elke service heeft alle vier nodig. De meeste teams krijgen echt inzicht uit beschikbaarheid plus één latency-percentiel. Meer SLI's toevoegen voordat je een betrouwbare baseline hebt voor de eerste twee is een klassieke manier om ruis te creëren zonder inzicht.

Het Foutbudget: Van Doel naar Operationele Beslissing

Een foutbudget is de wiskundige inverse van je SLO. Als je beschikbaarheidsSLO 99,9% is, mag 0,1% van de requests in het venster mislukken. Voor een service die een miljoen requests per maand krijgt, zijn dat 1.000 mislukte requests voordat het SLO breekt.

Het foutbudget maakt SLO's operationeel bruikbaar. Zonder het is een SLO gewoon een grens die voorbij wordt gegaan en dan besproken. Met een foutbudgetbeleid wordt het een beslissingskader.

Als het budget gezond is – zeg 80% over, twee weken op het venster, dan kan het team snel builden. Nieuwe features, experimenten, riskantere deployments passen allemaal. Het foutbudget geeft het signaal dat snelheid nu niet het knelpunt is.

Als het budget wegsmelt, verschuift het team. Niet-kritische veranderingen gaan in hold. Deployment-beleid wordt strakker. Betrouwbaarheidsoplossingen krijgen voorrang. Het foutbudget bepaalde de beslissing, geen manager-oordeel over of het "voelt stabiel genoeg."

Concreet voorbeeld: een checkout-service had op dinsdag een 12-minuten-verslechtering, consumeerde 15% van het maandelijkse foutbudget. Incident donderdag at nog 12%. Op 27% gebruikt in week één stelt het foutbudgetbeleid in werking: geen nieuwe feature-deployments totdat de postmortem klaar is en het probleem gefixt. Die beslissing hoort niet bij productontwikkeling/engineering. Het is puur data.

Google publiceerde zijn beleid in de SRE Workbook: één incident dat meer dan 20% van het driemaandelijkse foutbudget verbruikt vraagt om postmortem. Eén concreet beleid om aan te passen.

Burnrate-alerts gaan verder. Wacht niet tot het budget almost op, alarm op het moment dat de verbruikssnelheid suggereert dat je het budget vóór het venster eindigt. Eet je service foutbudget op met 14 keer de normale snelheid, dan burn je een 30-daags budget in ruwweg 50 uur. Een alert op die snelheid geeft het team twee dagen om te reageren, niet een postmortem na de breuk. Tools als Datadog en Grafana ondersteunen multi-window, multi-burnrate-alerting out of the box. Instellen duurt een middag. Zonder luidt dat betekent SLO-breuken ontdekken nadat klanten het al zagen.

Je Eerste SLO Zetten Zonder Het Getal Fout Te Krijgen

De meest voorkomende fout: het doel kiezen voordat je de meting hebt vastgelegd.

Stap 1: Definieer de SLI. "Beschikbaarheid" is geen SLI. "HTTP-requests die non-error status retourneren (2xx/3xx), gedeeld door alle HTTP-requests" is een SLI. De meting moet produceerbaar zijn uit telemetrie die je al hebt. Beloven om iets "snel" in te instrumenteren betekent dat de SLO geen databron heeft.

Stap 2: Haal historische data op. Kijk naar de afgelopen 60 tot 90 dagen. Hoe ziet de SLI er echt uit? Wat waren de twee, drie slechtste dagen? Dit zegt wat doel vandaag haalbaar is en hoeveel buffer je hebt voordat de eerste breuk.

Stap 3: Zet het meetvenster. Rolling 30-daagse vensters zijn meest gangbaar en geven reactieve, altijd-actuele data. Kalendermaandvensters creëren cliff-effecten aan maandgrenzen. Zeven-daags rolling-vensters zijn gevoeliger maar kunnen te veel alarmen geven voor teams die nog betrouwbaarheid-discipline aan het opbouwen zijn.

Stap 4: Schrijf het foutbudgetbeleid voordat je het nodig hebt. Bij welke foutbudget-burnrate pauzeren teams niet-kritische veranderingen? Bij welke snelheid escalatieert on-call? Documenteer dit vóór de incident, niet erin.

Stap 5: Begin met één service. SLO's voor 15 services tegelijk definiëren levert 15 dashboards op die niemand leest. Start met de meest zichtbare service, run één kwartaal, zet bij, daarna uitbreiden.

Meetvenster-opties en hun trade-offs:

• 7-daags rolling: snelle feedback, gevoeliger voor korte incidents, kan alert-vermoeidheid geven

• 30-daags rolling: meest gangbaar, balanceert signaal en ruis

• 90-daags rolling: handig voor zeldzame maar kritische operaties als batchjobs

Uitgewerkt voorbeeld: voor een e-commerce API stel je je eerste SLO in als "95% van requests naar /checkout slagen en retourneren binnen 500ms, gemeten over een rolling 28-daags venster." Dat geeft je een concrete SLI (succes plus latency), een specifiek doel (95%), een bepaald venster (28 dagen). Van daaraf bereken je het foutbudget: 5% van totale requests mag mislukken of traag zijn. Als je 200.000 requests per dag krijgt, is je maandelijk foutbudget ruwweg 280.000 mislukte requests voordat het SLO breekt.

Waar SLO-monitoring raakt je codebase-werk

Een foutbudget dat sneller brandt dan verwacht is vaker een codebase-probleem dan infra. Latency-pieken traceren terug naar N+1-queries die code review ontsnappen. Beschikbaarheidsdalingen traceren naar een null pointer exception in een code-pad dat alleen onder specifieke load-combinatie triggert. Het SLO vindt de symptomen. Je codebase bevat de oorzaak.

Dit is waar de tijd tussen "alert" en "rootcause gevonden" het praktische knelpunt wordt. Als de checkout-service 30% van het foutbudget in drie dagen verbruikt en je on-call must door een 150.000-regel monolith grepppen om de retry-logica te vinden die onder load anders gedraagt, doet het SLO zijn werk. De tooling voor diagnose niet.

Teams die AI-ondersteunde codesearch naast observability hebben gebouwd rapporteren significant kortere diagnose-tijd in incidents. Een natural-language query waar de payment-service 503-retries afhandelt brengt de relevante functie in seconden boven, niet de 20 minuten om door vijf files en één Confluence-pagina te lezen. Het 43-minuten foutbudget-venster gaat naar repareren, niet naar codelezing.

Vier Manieren Waarop Teams SLO's Fout Doen

Te veel SLO's. Een team dat gelijktijdig 12 SLO's volgt gaat die alerts over twee maanden als achtergrondgeluid behandelen. Drie tot vijf SLO's gericht op het meest klant-zichtbare gedrag is een werkbaar plafond voor tien engineers. Heb je meer nodig, gestratificeerd: kritische SLO's die foutbudgetbeleid triggeren, en informatieve SLO's die gewoon data genereren.

Infra meten, niet gebruikerservaring. CPU, geheugen, disk I/O zijn bruikbare debug-signalen. Ze zijn slechte SLI's tenzij je kan bewijzen dat ze rechtstreeks correleren met zichtbare verslechtering. Meet wat gebruikers ervaren: request-succes, responstijd op P95 of P99, tijd tot eerste betekenisvolle data-render.

SLO's zonder operationele kostenanalyse. 99,99% beschikbaarheid vraagt meestal actieve redundantie, multi-region failover en directe on-call-respons elk uur. Kan je team dat duurzaam runnen? Nee, dan breekt het SLO regelmatig en wordt genegeerd. Een genegeerd SLO is erger dan niets: het traint het team om betrouwbaarheidswaarschuwingen af te wijzen.

Foutbudget-data gebruiken om schuld toe te wijzen. Gaat de eerste reactie op verbruikt budget naar "wie shipped dit?", rapportage stopt eerlijk zijn. Foutbudgets zijn teamresource. Budget laag, vraag "wat fiksen we?" niet "wie is verantwoordelijk?"

De organisatie-gezondheidstest: zou je huids foutbudget-status delen in je engineering all-hands zonder dat het politieke discussie triggert? Nee? Dan verdient cultuur rond SLO's meer aandacht dan de doelen zelf. Betrouwbaarheidsmeting werkt als beslissingstool alleen wanneer het team vertrouwt dat problemen melden geen persoonlijk risico oplevert.

SLO's Vragen om Driemaandelijkse Reviews, Niet Jaarlijks

Een SLO instellen is geen eenmalige kalibrering. Services veranderen, verkeerspatronen verschuiven, operationele kosten van een bepaald betrouwbaarheidsniveau veranderen mee.

Elke 90 dagen vier vragen:

1. Hield het SLO? Ja – comfortabel, dus kan het strakker?

2. Budget volledig weg? Welke incidents deden dat?

3. Opperde het SLO bruikbare signalen, of ignoreerde het team het foutbudgetbeleid?

4. Past het meetvenster nog bij hoe de service wordt gebruikt?

Als het team het foutbudgetbeleid meer dan twee keer per kwartaal negeerde, is het SLO waarschijnlijk verkeerd gekalibreerd. Doel te strak, venster te kort, of de meting reflecteert niet wat gebruikers voelen.

SLO's zijn kalibreerwerktuigen. Ze moeten bijgesteld wanneer betrouwbaarheid verbetert, traffic groeit, en de business-tolerantie voor downtime verschuift. Een team dat voortdurend zijn SLO's quarterly herziet, rundt betrouwbaarheidspraktijk. Een team dat ze éénmaal instelde en sindsdien niet meer aanraakt heeft een dashboard met nummers waar niemand iets aan meent.