Wat is een SLO? Een praktische gids voor platformteams

Wat is een SLO? Een service level objective is een doel voor hoe betrouwbaar één specifiek gedrag van je product voor de gebruiker moet zijn, gemeten over een vast venster. "99.9% van de checkout-verzoeken slaagt binnen 800 ms, over 30 dagen" is een SLO. "De site moet snel zijn" is een wens. Het getal is minder belangrijk dan wat het bepaalt: de SLO beslist wanneer je blijft uitrollen en wanneer je stopt.

Het is 03:12. PagerDuty meldt dat de checkout-latentie "verhoogd" is. Je opent het dashboard en ziet een p99-lijn die al veertig minuten omhoog kruipt. Niemand kan zeggen of dat een probleem is, want niemand heeft ooit opgeschreven hoeveel latentie te veel is. De discussie die volgt, in een call, met één oog op Slack, is de prijs van het ontbreken van een SLO.

SLI, SLO en SLA: drie woorden, drie eigenaars

Mensen gebruiken deze termen door elkaar. Het zijn niet dezelfde dingen, en juist die verwarring zorgt dat teams belanden bij een contract dat ze niet kunnen halen.

• SLI (service level indicator) is de meting. Een verhouding van goede events tot geldige events: verzoeken die binnen 800 ms een 2xx gaven, gedeeld door alle verzoeken die dat hadden moeten doen.

• SLO (service level objective) is het doel voor die verhouding over een venster. 99.9% over 30 dagen.

• SLA (service level agreement) is het contract met een klant, met geld erbij als je het niet haalt. Hij staat altijd losser dan de SLO. Als je SLA 99.9% belooft en je SLO ook 99.9%, heb je geen ruimte om een probleem op te merken voordat je credits verschuldigd bent.

Het hoofdstuk over service level objectives in het Google SRE-boek trekt dezelfde lijn: de SLO is een intern doel dat strakker staat dan alles wat je extern belooft. Engineers zijn eigenaar van de SLI en de SLO. Product en juridische zaken zijn eigenaar van de SLA.

Voeg niet voor elke metric die je al verzamelt een vierde woord toe. CPU, geheugen en wachtrijdiepte zijn nuttig om te debuggen. Het zijn geen SLI's, omdat geen klant ze rechtstreeks ervaart.

Hoe een goede SLI er in de praktijk uitziet

Een goede SLI is een verhouding, wordt zo dicht mogelijk bij de gebruiker gemeten, en heeft een heldere definitie van "goed".

Voor een request-gedreven service zijn de standaard twee SLI's: beschikbaarheid (niet-5xx-antwoorden over alle geldige verzoeken) en latentie (verzoeken onder een drempel over alle geldige verzoeken). Gebruik een drempel, geen gemiddelde. Een gemiddelde verbergt de staart, en de staart is waar de supporttickets vandaan komen.

Meet op de load balancer of aan de rand, niet binnen de service. Een service die bij het opstarten crasht, rapporteert een perfecte foutratio voor de verzoeken die hij nooit heeft ontvangen. Server-side metrics zien die storing niet, terwijl de gebruiker het ervaart als een outage.

Wees expliciet over wat je uitsluit. Health checks, synthetische probes van je eigen monitoring en 4xx-antwoorden door foute input van de client tellen meestal niet tegen je. Schrijf de uitsluitingen op naast de SLO. Als iemand in een incident review over het getal discussieert, moet het gaan over de definitie, niet over wat het dashboard toevallig toont.

De rekensom die niemand maakt voordat hij negens kiest

Elke extra negen verkleint je toegestane downtime met een factor tien. Dit is de tabel om in het document te bewaren.

• 99% over 30 dagen: 1% foutbudget, 7.2 uur toegestane volledige outage.

• 99.9%: 0.1% budget, 43.2 minuten.

• 99.95%: 0.05% budget, 21.6 minuten.

• 99.99%: 0.01% budget, 4.32 minuten.

Lees die laatste regel nog eens. Bij 99.99% heeft één slechte deploy die vijf minuten nodig heeft om gedetecteerd en teruggedraaid te worden, de maand al opgebruikt. Mensen kunnen niet op een pager reageren, een laptop openen en binnen vier minuten terugdraaien. Dat doel is dus alleen haalbaar met automatisering: een geautomatiseerde poort die de rollout stopt voordat het budget op is.

Kies dus het getal dat de service echt nodig heeft. De meeste interne API's leven prima bij 99.9%. Een betalingspad kan meer rechtvaardigen. Een nachtelijke batchjob mag prima op 99%. 99.99% kiezen omdat het serieus klinkt, is de manier waarop een team zich aanmeldt voor een pagerrotatie die het niet kan bemannen.

Het foutbudget is het punt, niet de SLO

Een SLO van 99.9% betekent dat je 0.1% van de tijd mag falen. Die 0.1% is je foutbudget, en het is het nuttigste idee in de hele discipline.

Het budget maakt van een discussie een getal. Product wil de riskante migratie uitrollen. De SRE zegt dat het riskant is. Zonder budget is dat mening tegen mening, en wint de senioriteit. Met een budget wordt de vraag: hoeveel is er nog over, en hoeveel brandt deze wijziging waarschijnlijk op?

Twee regels maken het werkbaar.

1. Budget over: uitrollen. Je mag risico nemen, dus doe het. Een team dat zijn budget nooit opmaakt, investeert te veel in betrouwbaarheid waar gebruikers niet om vroegen.

2. Budget op: bevriezen. Featurewerk pauzeert tot het reliability-werk de SLI weer boven het doel brengt. Dit werkt alleen als leiding er vóór het eerste incident mee akkoord is gegaan, niet tijdens het incident.

Als de tweede regel niet vooraf is afgesproken, heb je geen SLO. Dan heb je een dashboard met een groene en een rode zone.

Alarmeren op burn rate, niet op de SLI zelf

Hier struikelen de meeste eerste pogingen. Iemand zet een alarm dat afgaat als de beschikbaarheid onder 99.9% zakt. Het alarm gaat af nadat de schade er is, of het flapt bij elke piek, of beide.

Het betere signaal is burn rate: hoe snel je het budget opmaakt, vergeleken met het tempo dat het exact aan het einde van het venster zou uitputten. Een burn rate van 1 betekent dat je de maand met nul budget afsluit. Een burn rate van 14.4 betekent dat je op koers ligt om het budget van een hele maand in ongeveer twee dagen op te maken.

De Google SRE Workbook over alerteren op SLO's raadt aan een lang en een kort venster te combineren, zodat het alarm zowel significant is als nog steeds aan de gang is. Voor een SLO van 30 dagen zijn twee pagina's een goed startpunt:

• Burn rate 14.4 over 1 uur, bevestigd over 5 minuten: verbruikt 2% van het maandbudget. Pagina iemand.

• Burn rate 6 over 6 uur, bevestigd over 30 minuten: verbruikt 5% van het maandbudget. Pagina iemand.

De rekensom is simpel. Een venster van 30 dagen is 720 uur. Een uur lang op 14.4x branden kost 14.4 / 720 = 2% van het budget. Het korte venster zorgt ervoor dat het alarm niet nog een uur afgaat nadat het probleem al voorbij is.

Hier is de eerste regel als Prometheus-alert, ervan uitgaande dat je per venster een error ratio vastlegt:

groups:
  - name: checkout-slo-burn
    rules:
      - alert: CheckoutErrorBudgetFastBurn
        expr: |
          job:checkout_error_ratio:rate1h > (14.4 * 0.001)
          and
          job:checkout_error_ratio:rate5m > (14.4 * 0.001)
        labels:
          severity: page
        annotations:
          summary: "Checkout verbrandt 2% van zijn 30-daagse foutbudget per uur"

De 0.001 is de toegestane foutratio voor een SLO van 99.9%. Verander het doel en die constante verandert mee. Houd hem op één plek, anders lopen het alarm en de SLO uit elkaar zonder dat iemand het merkt.

Langzamere branden hebben geen pagina nodig. Een burn rate van 1 die drie dagen aanhoudt, hoort in een ticket voor de volgende werkochtend. Iemand wakker maken voor een langzaam lek is hoe on-callteams leren de pager te negeren.

Waar je de SLI berekent zonder een tweede platform te kopen

Je hebt geen aparte SLO-tool nodig om te beginnen. Je hebt een teller voor goede events, een teller voor alle events, en een plek om die 30 dagen op te slaan.

Als je metrics al in een gehost platform staan, is de SLO-functie meestal een dunne laag bovenop data waarvoor je al betaalt.

Datadog heeft SLO's native, met burn-rate-alerts, en het is het makkelijke pad als je traces en metrics er al staan. De rekening is de adder onder het gras: custom metrics en tags met hoge cardinaliteit vermenigvuldigen snel, dus controleer de prijs van de SLI-reeksen voordat je je vastlegt.

Als je Prometheus draait, dekt Grafana hetzelfde terrein via recording rules en zijn SLO-tooling, tegen de prijs van meer setup en meer van je eigen tijd.

De eerlijke vergelijking is tijd tot het eerste bruikbare alarm tegenover kosten op schaal. Datadog wint het eerste. Grafana met Prometheus wint meestal het tweede. Kies op basis van waar je team een tekort aan heeft.

De SLO koppelen aan de rollout, het deel dat de meeste teams overslaan

Een SLO die alleen een rapport oplevert, wordt maar half gebruikt. De stap die gedrag verandert, is het budget in het deploypad aansluiten, zodat de release zichzelf stopt.

Een progressieve rollout met een SLO-poort werkt zo. Zet de nieuwe versie live voor 1% van het verkeer achter een flag. Vergelijk de SLI van die cohort met de baseline. Als de burn rate van het canary-cohort je drempel overschrijdt, draai je automatisch terug. Houdt hij stand, dan ga je naar 5%, daarna 25%, daarna 100%.

Dat is iets anders dan een dashboard waar iemand om 03:12 naar hoort te kijken. Om 03:12 wil je niet nadenken. Je wilt een knop, of beter, helemaal geen knop.

Hier verdienen feature flags hun plaats, want een flag maakt van een terugdraai een configuratiewijziging die seconden kost, in plaats van een redeploy die tien minuten duurt.

LaunchDarkly en vergelijkbare platformen geven je de percentage-rollout en de kill switch. Wat de meeste aan jou overlaten, is de beslissing: welke SLI je leest, welke drempel als slecht geldt, en wie mag overrulen. Dat is de kloof die een geautomatiseerde pilot met auto-rollback op SLO moet dichten, en het is de invalshoek die wij bij upstreamapi kiezen. LaunchDarkly wint op SDK-breedte en enterprise-controls, en dat zeggen we ook.

Hier is de vorm van de poort in TypeScript. De beslislogica is het deel dat het de moeite waard is zelf te schrijven, welk flagsysteem je ook gebruikt:

type Cohort = { good: number; total: number };

const SLO_TARGET = 0.999;
const BUDGET = 1 - SLO_TARGET; // 0.001
const PAGE_BURN_RATE = 14.4;

function burnRate(c: Cohort): number {
  if (c.total === 0) return 0;
  const errorRatio = 1 - c.good / c.total;
  return errorRatio / BUDGET;
}

export function rolloutDecision(canary: Cohort): "advance" | "hold" | "revert" {
  if (canary.total < 500) return "hold"; // niet genoeg verkeer om te oordelen
  return burnRate(canary) > PAGE_BURN_RATE ? "revert" : "advance";
}

Let op de tak hold. Een canary op 1% van een rustige service ziet misschien veertig verzoeken in tien minuten, en één fout op veertig is een foutratio van 2.5%. Zonder minimale steekproef draait de poort terug op ruis, en dan leert je team hem wantrouwen.

Fouten die we steeds zien bij teams van 80 ingenieurs, en wie de eerste SLO schrijft

Dezelfde paar fouten duiken bij teams steeds weer op, en bijna geen van die fouten is technisch.

Te veel SLO's. Twintig doelen per service betekent dat niemand er één onthoudt. Twee of drie per gebruikersreis is genoeg.

SLO's waar niemand mee akkoord ging. Een engineer schrijft ze alleen in een weekend. Product heeft ze nooit gezien, dus het budgetbeleid valt om de eerste keer dat het nee zegt tegen een lancering.

SLO's gezet op de huidige prestatie. Als de service vandaag op 99.97% draait en je het doel ook op 99.97% zet, blijft er geen budget over en is een misser gegarandeerd. Zet hem waar gebruikers begint te ontevreden worden, wat bijna altijd lager ligt.

De SLO als eeuwig beschouwen. Bekijk het getal elk kwartaal. Als je het budget nooit opmaakt, strak het doel dan aan of ship sneller. Als je het elke maand misloopt, los dan het systeem op of geef toe dat het doel een fantasie was.

Tellen wat makkelijk is in plaats van wat de gebruiker voelt. Een 200-antwoord met een lege winkelwagen is in je logs een succes en voor de klant een mislukking. Definieer "goed" vanuit de kant van de gebruiker.

Je hebt geen programma nodig. Kies de ene reis waarbij de CEO iemand zou bellen als die stukging. Definieer daarvoor één beschikbaarheids-SLI en één latentie-SLI. Zet het doel op 99.9% voor het eerste kwartaal, schrijf het bevriesbeleid in twee zinnen, en laat product schriftelijk antwoorden dat het akkoord is.

Voeg daarna een burn-rate-alarm toe, en een plek waar het hele team het resterende budget kan zien.

Heb je een lichtgewicht startpunt nodig voordat je je aan een volledig platform vastlegt, dan regelt Better Stack uptime-monitoring en incident-paging met een veel kleinere opzet, al geeft het je de budgetrekening niet gratis erbij.

De eerste versie wordt fout. Dat is acceptabel. Wat telt is dat de volgende incident review begint bij een getal dat je vooraf hebt opgeschreven, en niet bij een gevoel. Hoe ziet je 03:12 er nu uit? Neem het laatste incident van je team. Stond er ergens een getal opgeschreven dat zei of het ertoe deed? Als het eerlijke antwoord nee is, is dat je eerste SLO, en de post-mortem heeft je al verteld wat je moet meten.