Wat is een SLO? Handleiding met gratis Sheets-sjabloon

Wat is een SLO precies? Een service level objective is een betrouwbaarheidsdoel dat je stelt voor een service, uitgedrukt als getal over een bepaalde periode. "99,9% van de verzoeken slaagt in 30 dagen" is een SLO. Het vertelt je team hoeveel storing aanvaardbaar is voordat je stopt met updates en begint met repareren. De wiskunde erachter is gewoon delen, daarom werkt een spreadsheet prima.

Biscuit heeft de formules al voor je opgehaald. Jij brengt de getallen mee.

De drie afkortingen die je steeds tegenkomt, uit elkaar gezet

SLI, SLO, SLA. Mensen gooien ze door elkaar in meetings, dus hier komt de korte versie.

• SLI (service level indicator): wat je meet. Het aandeel verzoeken dat zonder fout terugkomt, het aandeel pagina's dat onder 300 ms inlaadt, het aandeel taken dat op tijd klaar is.

• SLO (service level objective): het doel voor die meting. "De SLI moet minstens 99,9% zijn over 30 dagen."

• SLA (service level agreement): een contract met gevolgen, meestal geld terug, gekoppeld aan een doel.

De scherpste test komt uit Google's SRE-boek: vraag jezelf af wat er gebeurt als je het doel niet haalt. Gebeurt er niets contractueel, dan heb je het over een SLO, niet een SLA. Je SLO moet strakker zijn dan elke SLA die je hebt ondertekend, zodat je een waarschuwing krijgt voordat een klant een teruggave eist.

In spreadsheet-termen: de SLI is een kolom metingen, de SLO is één cel met het doel, en de SLA is een PDF die ergens in het juridische archief ligt.

Waarom 99,9% en 99,99% heel verschillende beloftes zijn

Elk extra negen verlaagt je toegestane downtime met een factor tien. Over een maand van 30 dagen (43.200 minuten) laat elke doelstelling je het volgende toe:

• 99%: 1% budget, 432 minuten (7,2 uur) toegestane downtime per 30 dagen

• 99,5%: 0,5% budget, 216 minuten (3,6 uur)

• 99,9%: 0,1% budget, 43,2 minuten

• 99,95%: 0,05% budget, 21,6 minuten

• 99,99%: 0,01% budget, 4,32 minuten

Die laatste regel is de valstrik. Vier minuten per maand betekent dat een mens niet eens klaar is met het alarm lezen voordat het budget op is. De meeste interne tools, dashboards en kleine SaaS-producten hebben het niet nodig, en ernaar streven kost echt geld in redundantie en on-call-uren.

Sla 99,99% over tenzij een klant je daar specifiek voor betaalt. Google's advies is bot ook: begin met een los doel dat je later kunt verscherpen, omdat een strak doel dat je later moet losser maken iedereen leert het getal te negeren.

Het error budget: het getal waar je team echt over discussieert

Het error budget is wat de SLO overlaat. Doel 99,9%, dus het budget is 0,1%. Over 30 dagen zijn dat 43,2 minuten "slechte" tijd die je mag gebruiken.

Denk eraan als een brandstofmeter. Riskante updates verbruiken brandstof. Een slechte databasemigratie verbruikt brandstof. Een storing om 3 uur 's ochtends verbruikt veel brandstof. Wanneer de tank vol is, ship je sneller. Wanneer hij leeg is, stop je met features toevoegen en repareer je betrouwbaarheid.

Google's eigen voorbeeldbeleid is duidelijk erover: mocht een service zijn budget over vier weken opbranden, dan stoppen alle wijzigingen, behalve P0-fixes en beveiligingspatches, totdat de service weer binnen zijn SLO zit. Het budget is een onderhandelingsinstrument, geen straf. Het laat een productmanager en een engineer vanaf dezelfde cel discussiëren in plaats van vanuit gevoelens.

De moeite waard als meer dan een team aan dezelfde service werkt. Overkill als je een eenmanszaak bent met één landingspagina en een contactformulier.

Een SLI kiezen die je gebruikers herkennen

De beste SLI's beschrijven een moment dat iemand zou opmerken. Drie dekken de meeste services af:

• Beschikbaarheid: het aandeel verzoeken dat slaagt. Makkelijk te meten, makkelijk uit te leggen.

• Latentie: het aandeel verzoeken sneller dan een drempel. "95% van de zoekopdrachten komt terug in onder 300 ms" is beter dan een gemiddelde, omdat gemiddelden de trage staart verbergen die mensen ergernis bezorgt.

• Versheid: voor datapijplijnen en rapporten, het aandeel runs dat voor de deadline klaar is. Dit past spreadsheetmensen goed: "het ochtendverkooprappel wordt op 99% van de weekdagen voor 8 uur bijgewerkt."

Schrijf de SLI als een breuk: goede events gedeeld door geldige events. Die ene gewoonte maakt elke SLO in één cel berekenbaar, en het dwingt je om te bepalen wat "goed" is voordat de storing gebeurt, niet tijdens.

Voor het venster is een voortschrijdende 30 dagen de standaardkeuze. Een kalendermaand is simpler om te rapporteren maar stelt het budget op de 1e opnieuw in, wat teams verleidt tot riskante releases aan maandeinde. In een sheet is een voortschrijdend venster gewoon het filteren van het Incidents-tabblad naar de afgelopen 30 dagen met SUMIFS(Incidents!C:C,Incidents!A:A,">="&TODAY()-30).

Bouw een SLO-tracker in Google Sheets of Excel in 10 minuten

Je hebt geen monitoringplatform nodig om te beginnen. Je hebt twee tabbladen nodig: Incidents en SLO.

Op het Incidents-tabblad noteer je elke storing met een starttijd in kolom A, eindtijd in kolom B, en duur in kolom C:

=(B2-A2)*24*60

• B2 en A2: de eind- en startdatums van de storing.

• *24*60: verandert het dagverschil in minuten.

Werkt in zowel Excel als Sheets, alle versies.

Nu het SLO-tabblad. Zet deze labels in kolom A en de formules in kolom B:

B1: 0.999                         (je SLO-doel)
B2: 30                            (venster in dagen)
B3: =B2*24*60                     (totale minuten in het venster)
B4: =B3*(1-B1)                    (error budget in minuten)
B5: =SUM(Incidents!C2:C)          (downtime tot nu toe)
B6: =1-B5/B3                      (daadwerkelijke beschikbaarheid)
B7: =B4-B5                        (budget over, in minuten)
B8: =B5/B4                        (aandeel budget gebruikt)

Met een doel van 99,9% geeft B3 43200 en B4 geeft 43,2. Log een storing van 12 minuten en B8 geeft 27,8%. Voilà, dat krijg je in een echte cel.

Een opmerking over C2:C in B5: de onbegrensde reeks is Sheets-syntaxis. In Excel, gebruik je een vaste reeks zoals Incidents!C2:C500 of een tabelverwijzing.

Voeg een statuscell toe zodat niemand het getal hoeft te lezen:

=IF(B8>=1,"Updates opschorten",IF(B8>=0.5,"Voorzichtig","Zet hem uit"))

• B8>=1: budget volledig gebruikt of overschreden.

• B8>=0.5: half weg, dus controleer riskante wijzigingen.

• Al het andere: groen licht.

Kies je eigen drempels. Vijftig procent is een startgok, geen natuurwet.

Zit je vast met de syntaxis voor je eigen versie van dit sheet? Beschrijf het in gewoon Nederlands en laat de tool het voor je schrijven.

Verzoeken tellen in plaats van minuten

Tracking op basis van tijd is makkelijk uit te leggen maar ruw. Als je service "down" is voor 5 minuten om 4 uur 's ochtends wanneer niemand online is, doet dat minder zeer dan 5 minuten rond middaguur. De meeste serieuze teams definiëren de SLI op basis van verzoeken.

Plak een export van je aanvraaglogboek in een tabblad, met de HTTP-statuscode in kolom B. Dan:

=1-COUNTIF(B2:B,">=500")/COUNTA(B2:B)

• COUNTIF(B2:B,">=500"): telt verzoeken die een serverfout gaven.

• COUNTA(B2:B): telt alle verzoeken. Eén minus het aandeel fouten geeft je het aandeel succes.

Het resultaat is je beschikbaarheids-SLI als breuk. Vergelijk het met de doelcel en je hebt de hele SLO in één regel. Excel 2016 en 365 accepteren beide COUNTIF; wissel B2:B gewoon om voor een begrensd bereik.

Twee eerlijke waarschuwingen. Spreadsheets haperen bij miljoenen rijen, dus exporteer in plaats daarvan dagelijkse totalen in plaats van onbewerkte logboeken. En een 4xx-reactie is meestal de fout van de gebruiker, niet je storing, dus bepaal die regel eenmaal en schrijf het op.

Verbrandingssnelheid: de formule die je waarschuwt voordat het te laat is

Weten dat je 27,8% van je budget hebt gebruikt is aardig. Weten dat je het sneller verbruikt dan de kalender, is nuttig. Die ratio is de verbrandingssnelheid.

=B8/(B9/B2)

• B8: aandeel budget tot nu toe gebruikt.

• B9: afgelopen dagen in het venster (voer het handmatig in of gebruik =TODAY()-B10, met de startdatum van het venster in B10).

• B2: totaal venster in dagen.

Een verbrandingssnelheid van 1 betekent dat je de periode eindigt met exact nul budget over. Hoger dan 1 en je loopt naar een bevriering. Lager dan 1 en je hebt ruimte. Als je 10 dagen in een 30-daagse periode bent en al 60% hebt opgebrand, is de verbrandingssnelheid 1,8. Dat is het getal om op een scherm te zetten.

Dit is hetzelfde idee dat de grote monitoringtools gebruiken voor burn-rate-alerts. Een sheet zal je niet om 3 uur 's ochtends oproepen, dus behandel het als een rapportagelaag, niet als een alarm.

Hier is een werkelijk voorbeeld met echte getallen. Je SLO is 99,9% over 30 dagen, dus het budget is 43,2 minuten. Dag 1 tot 8: een slechte update haalt de kassatoepassing neer voor 14 minuten. Dat is 32,4% van het budget weg in een kwart van het venster, een verbrandingssnelheid van ongeveer 1,2. Er brandt niets, maar het sheet zegt nu "Voorzichtig", en de volgende riskante migratie krijgt een tweede blik. Dag 15: een provideruitsluiting voegt 30 minuten toe. Totaal 44 minuten, 101,9% opgebrand. De statuscell verandert in "Updates opschorten", en het gesprek over prioriteiten gebeurt met een getal op tafel in plaats van een gevoel.

Dat is de hele waarde van de oefening. Niet de negen, maar de gedeelde cel waar iedereen naar kan wijzen.

Wanneer het spreadsheet niet meer volstaat

Een tracker als deze werkt voor één of twee services en een wekelijkse review. Het breekt neer wanneer je tientallen services hebt, automatische dataverzameling nodig hebt, of alerts wilt die in minuten in plaats van bij de volgende maandagvergadering afgaan.

Tijd om naar een echt observabiliteitstool te kijken. Datadog en Grafana hebben beide native SLO-functies die de SLI rechtstreeks uit je metriek halen en tekenen het budget voor je.

Kies Grafana als je open source wilt en al Prometheus draait. Kies Datadog als je liever betaalt om zelf niets te draaien. Hoe dan ook, hou het sheet voor het maandelijks review-deck, omdat iedereen in de kamer het kan openen en niemand een login bij een leverancier nodig heeft.

Wil je hulp bij het opstellen van een eerste set SLI's voor een service? Een algemene assistent is een fatsoenlijke brainstormpartner. Verifieer elk getal dat het je geeft, want het zal graag een aannemelijk klinkend doel uit het niets bedenken.

Fouten die een SLO nutteloos maken, en wat je maandag moet doen

Een paar patronen die Biscuit heeft zien misgaan:

• Je huidige prestatie als doel kopiëren. Als je vorig kwartaal op 99,97% draaide, een SLO van 99,97% blokkert een tempo dat je misschien niet kunt volhouden.

• Te veel SLO's. Twee of drie per service. Daarna herinnert niemand zich welke eigenlijk telt.

• Meten wat makkelijk is, niet wat gebruikers voelen. CPU-gebruik is geen SLI. Mislukte betalingen wel.

• Geen gevolgen. Een SLO zonder error-budgetbeleid is een wens. Bepaal van tevoren wat gebeurt op 50%, 100% en 150% opgebrand.

• Nooit het doel herzien. Controleer het elk kwartaal. Als je je nooit dicht bij het opbranden van het budget bent, is het doel te los.

Nu het maandagdeel. Pak één service. Schrijf één SLI op in één zin die een niet-engineer kan volgen. Stel een los doel in, 99,5% of 99,9%. Bouw de twee tabbladen hierboven, noteer de storingen van vorige maand, en kijk wat het budget zegt.

Als het antwoord "we hebben 300% van het budget verbruikt" is, heb je zojuist ontdekt waarom iedereen zich moe voelt. Als het antwoord "we hebben 4% verbruikt" is, verscherp het doel of zet sneller zaken uit. Hoe dan ook, je hebt nu een getal om over te discussiëren in plaats van een gevoel.

Braaf. Nu die storingen gaan noteren.