Wat is een SLO? Praktische gids voor solo developers

Wat is een SLO? Het is een getal dat je jezelf belooft over hoe vaak je service moet werken, gemeten over een vast tijdvenster. "99.9% van de requests slaagt over 30 dagen" is een SLO. Het zet "de site voelt goed" om in iets wat je kunt controleren, en het vertelt je wanneer je moet stoppen met features bouwen en eerst dingen moet repareren.

Je hebt hier geen platformteam voor nodig. Een solo dev met één API en een Postgres-database kan in een middag een bruikbare SLO schrijven. Hieronder staat wat de term betekent, hoe je het getal kiest en waar het misgaat.

Het was 2 uur 's nachts en niemand wist of de app kapot was

Stel je een side project voor met 400 gebruikers per week. Op een nacht geeft het checkout-endpoint gedurende ongeveer 20 minuten 500-fouten. Niemand tweet, niemand mailt. Drie dagen later hoor je het uit één supportbericht.

Was dat erg? Zonder doel kun je dat niet beantwoorden. Met een doel wel: als je SLO ongeveer 43 minuten storing per maand toestaat en je er net 20 hebt verbrand, weet je dat je bijna de helft van je ruimte hebt opgemaakt aan één slechte nacht. Dat is het hele punt van een SLO. Hij vervangt een gevoel door een budget.

SLI, SLO en SLA, zonder het woordenboek

SLI, SLO en SLA door elkaar halen gebeurt constant, dus hier de korte versie.

Een SLI (service level indicator) is een meting. "Aandeel HTTP-requests dat in de afgelopen 30 dagen geen 5xx-status teruggaf" is een SLI. Het is een verhouding van goede events tot alle events.

Een SLO (service level objective) is het doel voor die meting. "Die verhouding moet op minstens 99.9% blijven" is de SLO. Die is intern. Jij stelt hem in, je kunt hem aanpassen, en niemand daagt je voor de rechter omdat je hem niet haalt.

Een SLA (service level agreement) is een contract met gevolgen, meestal terugbetalingen of tegoeden. De meeste side projects hebben geen SLA, en dat is prima. Je kunt SLO's draaien zonder. Het hoofdstuk over het implementeren van SLO's in de Google SRE workbook is de standaardreferentie als je de lange versie wilt.

De volgorde is belangrijk: kies eerst de SLI, dan de SLO, en denk pas aan een SLA als een betalende klant er schriftelijk om vraagt.

Error budgets: het deel dat je manier van werken verandert

Een SLO van 99.9% betekent ook dat 0.1% van de events mag falen. Die ruimte is je error budget, en dat is het bruikbare deel van het idee.

Over een maand van 30 dagen laat 99.9% beschikbaarheid ongeveer 43 minuten toegestane downtime toe. De rekensom is 30 dagen keer 24 uur keer 60 minuten, dat is 43,200 minuten, keer 0.001. Een doel van 99% geeft je ongeveer 7.2 uur. Een doel van 99.99% geeft je ongeveer 4.3 minuten.

Die laatste twee getallen verklaren waarom de meeste kleine projecten niet hoog moeten mikken. Vier minuten per maand betekent dat één slechte deploy en een rollback het doel al breken. In de praktijk gaat de tijd, hoe hoger je mikt, steeds meer naar het verdedigen van het getal en steeds minder naar het bouwen van het product.

Het budget geeft je ook een regel om te bepalen wat je hierna bouwt. Budget grotendeels intact: ship het riskante feature. Budget op: fix eerst het wankele ding. Geen meeting nodig, alleen een getal op een dashboard.

Neem een SLO van 99.5% beschikbaarheid over 30 dagen, en stel dat je ongeveer 600,000 requests per maand serveert. Dat doel staat 0.5% fouten toe, dus 3,000 mislukte requests voordat het budget leeg is.

Op dag 9 geeft een slechte migratie 25 minuten lang 500-fouten en kost je 1,100 mislukte requests. Je hebt in één avond ongeveer 37% van het budget opgebruikt. Op dag 17 loopt een externe API in time-outs vast en verbrandt er nog 900 bij. Nu zit je op ongeveer 67% besteed, met 13 dagen te gaan.

Dat is het moment waarop het budget zijn geld verdient. Je hoeft niet in paniek te raken, maar je moet ook de riskante refactor die je voor dag 20 had gepland niet uitrollen. Je voegt een timeout en een fallback toe voor die externe call, schrijft de migratiecheck die je oversloeg, en schuift de refactor naar volgende maand.

De conclusie is niet dat fouten slecht zijn. Fouten worden verwacht en zijn al meegerekend. Wat het getal je geeft, is een rustig, gedeeld antwoord op de vraag "kunnen we dit risico nu betalen?", ook als jij de enige persoon in de kamer bent.

Een SLI kiezen die je echt kunt meten

Begin bij wat een gebruiker "kapot" zou noemen. Bij een webapp komt dat meestal neer op twee vragen: is de request geslaagd, en was hij snel genoeg?

Voor de meeste side projects dekken twee SLI's 90% van de waarde:

• Beschikbaarheid: goede requests gedeeld door alle requests, waarbij goed betekent: geen 5xx-antwoord.

• Latentie: het aandeel requests dat binnen een drempel antwoordt, bijvoorbeeld 95% van de requests onder 500 ms.

Let op: latentie schrijf je als aandeel requests onder een drempel, niet als gemiddelde. Gemiddelden verbergen de trage staart, en die staart is waar gebruikers afhaken. Een gemiddelde van 300 ms kan prima samengaan met een p99 van 4 seconden.

Meet aan de rand van je systeem, zo dicht mogelijk bij de gebruiker. Een health check op /healthz vanuit hetzelfde VPC vertelt je dat het proces leeft, niet dat gebruikers kunnen inloggen. Kun je maar één meting betalen, meet dan een echt gebruikerspad, zoals inloggen of afrekenen, van buitenaf.

Een kleine SLO heb je vandaag al klaar. Je hebt geen leverancier nodig om te beginnen. Zet dit in je repo, in een bestand dat SLO.md heet:

service: checkout-api
window: 30d
slis:
  availability:
    good: status code is not 5xx
    total: all requests except /healthz
  latency:
    good: response time under 500ms
    total: all requests except /healthz
objectives:
  availability: 99.5%
  latency: 95%
if_budget_burned:
  - freeze non-urgent features
  - fix the top error source first

Als je stack al requestaantallen exporteert, is de beschikbaarheids-SLI in Prometheus-syntax één regel:

sum(rate(http_requests_total{status!~"5.."}[30d]))
  / sum(rate(http_requests_total[30d]))

Die verhouding, vergeleken met je doel, is je hele SLO-dashboard. Al het andere is bijzaak. Drie panelen zijn genoeg: huidige SLI, resterend budget en een burn rate-lijn.

Het getal kiezen: begin lager dan het voelt

Het eerlijke antwoord voor een nieuw project is 99% of 99.5%. Kijk naar je laatste 30 dagen aan data, bepaal wat je werkelijk hebt geleverd, zet de SLO iets daaronder en strak hem later aan als gebruikers klagen.

Een ruwe gids voor een solo project:

• Hobbytool zonder omzet: 99% is ruim genoeg. Ongeveer 7 uur storing per maand is voor de meeste gebruikers onzichtbaar.

• Betaalde SaaS met een paar tientallen klanten: 99.5% tot 99.9%, afhankelijk van hoe tijdgevoelig het product is.

• Alles waar klanten tijdens werkuren op rekenen: 99.9%, en test je rollbackpad voordat je het belooft.

Getest, niet optimaal, en toch de moeite waard: een SLO die je 100% van de tijd haalt, is een getal dat te laag staat. Een SLO die je elke maand mist, is een getal dat niemand vertrouwt. Mik erop hem af en toe te missen, want dan doet het budget zijn werk.

Herzie elke SLO één keer per kwartaal, of na elke maand waarin je het budget ruim hebt gemist of nooit hebt aangeraakt. Twee keer na elkaar missen betekent dat het systeem echt werk nodig heeft, of dat het doel te ambitieus was voor je fase. Beide zijn nuttige feiten.

Krijg je betalende klanten, vraag ze dan wat "kapot" voor hen betekent. Een klant die een wekelijks rapport draait, let op de maandagochtend, niet op een blip op zaterdagavond. Je SLO kan dat weerspiegelen met een strakker doel tijdens hun uren.

Drie fouten die SLO's nutteloos maken. Eerst: meten wat makkelijk is in plaats van wat gebruikers voelen. CPU-gebruik is geen SLI. Gebruikers geeft het niet om je CPU op 40%. Ze willen dat de pagina laadt. Tweede: het doel vanuit ambitie zetten. "We willen vijf negens" klinkt serieus en betekent niets als je database één instantie is op een kleine VM. Zet de SLO op basis van de werkelijkheid, verbeter het systeem, en strak dan het getal aan. Derde: het budget nooit gebruiken. Als je elke maand met 98% van het budget over eindigt, ship je te traag of staat het doel te ruim. Ongebruikt budget is verspilde ruimte voor risico.

Is een SLO gewoon uptime-monitoring met extra stappen?

Niet helemaal, al overlappen ze. Een ping-monitor vertelt je dat de site op een bepaalde minuut antwoordde. Een SLO vertelt je welk aandeel echte gebruikersrequests over een maand slaagde, en wat dat betekent voor je volgende beslissing.

Stel je twee weken voor waarin de ping-monitor elke minuut groen toont, terwijl één trage databasequery ervoor zorgt dat de dashboardpagina voor 3% van de ingelogde gebruikers time-out. De monitor zegt dat alles goed is. De SLI zegt dat je je latentiedoel hebt gemist. Maar één van de twee verandert wat je op maandag doet.

Hou de ping-monitor toch. Hij is goedkoop en vangt totale uitval snel op. Behandel hem alleen als één input, niet als de definitie van "werkt".

Alerteren op burn rate, niet op elke piek

De fout die bijna iedereen maakt: alarmeren zodra de foutfrequentie een drempel passeert. Dan word je om 3 uur 's nachts gepaged voor een spike van 90 seconden die 0.2% van het maandbudget kostte.

Burn rate lost dat op. Het vraagt hoe snel je het budget opbrandt, vergeleken met het tempo dat het precies aan het einde van het venster zou opmaken. Een burn rate van 1 betekent dat je de maand met een leeg budget afsluit, zonder verrassingen. Een burn rate van 10 betekent dat je na drie dagen leeg bent.

Voor één persoon is een gezonde opzet twee alerts. Een snel alert, bijvoorbeeld een burn rate boven 10 over een uur, dat je wakker maakt. Een traag alert, bijvoorbeeld een burn rate rond 2 over een dag, dat een ticket wordt voor de ochtend. Het hoofdstuk over service level objectives in het Google SRE-boek legt de redenering achter dit alles uit, en de multi-window-variant staat in de workbook hierboven.

Welke tool kies je als jij het hele ops-team bent

Je kunt een maand lang SLO's draaien vanuit een spreadsheet en een cronjob, terwijl je leert wat je echt belangrijk vindt. Zodra de getallen ertoe doen, verdient een tool zijn plaats. Drie om naar te kijken, met de kanttekening dat je stack meer beslist dan de featurelijst.

Grafana is de standaard voor mensen die al Prometheus-metrics exporteren. De gratis laag is ruim voor een side project, en de SLO-functie zit bovenop data die je waarschijnlijk al hebt. Sla hem over als je nog geen metrics-pipeline hebt en er geen zin in hebt er een te bouwen.

New Relic heeft een gratis laag met 100 GB dataopname per maand en SLO-tooling die in het platform zit. Het past als je een agentgebaseerde opzet wilt met weinig configuratie. De afweging is dat de kosten minder voorspelbaar worden zodra je de gratis ruimte overschrijdt.

Datadog is de meest complete optie en de duurste, met infrastructuur, APM en logs apart gefactureerd. Het loont als er om je heen een team groeit. Voor een solo project sla je hem over, tenzij iemand anders betaalt.

Wat je ook kiest: weersta de drang om op dag één vijftien SLO's te definiëren. Eén beschikbaarheids-SLO en één latentie-SLO per gebruikersgerichte service is genoeg om van te leren.

Welke van je services vertrouw je er nu het minst op?