Wat zijn error budgets?

Error budgets geven je softwareteams een grote mate van autonomie. Featureteams kunnen hun prioriteiten bijstellen op basis van het serviceniveau dat op dat moment geleverd wordt. Dit artikel legt de basisbegrippen achter error budgets uit, en laat zien hoe je ze inricht met Agile Analytics van ZEN Software.

Om error budgets voor je teams in te voeren moet er een aantal dingen op zijn plek staan, zowel in de teamcultuur als in de tooling.

SLI's en SLO's zijn de dragende begrippen achter error budgets

Dit artikel vertelt je wat SLI's, SLO's en error budgets zijn en hoe je ze invoert. Aan de slag.

Deze indicator werkt met percentages: 100% is goed, 0% slecht. Hij meet een serviceniveau als de verhouding tussen 'goede' en 'geldige' gebeurtenissen.

De eenvoudigste manier om je eerste SLI te krijgen is dus: tel alle 'goede' gebeurtenissen als percentage van alle 'geldige' gebeurtenissen.

Wat maakt een gebeurtenis 'goed' en wat 'geldig'? Dat hangt af van wat je meet. Laten we beginnen met de beschikbaarheid van onze dienst, gemeten aan de kant van de load balancer.

Uit de lijst met alle responscodes die de load balancer logt, kun je de volgende 'goede' en 'geldige' gebeurtenissen onderscheiden:

een 'goede' HTTP-gebeurtenis zijn alle HTTP-responscodes behalve 500-599

een 'geldige' HTTP-gebeurtenis zijn alle HTTP-responscodes

We zijn nu klaar voor onze eerste SLI-configuratie in Agile Analytics.

We maken een nieuwe 'feature' aan met de naam “Availability” en beschrijven welk aspect we in de gaten houden.

Omdat we beschikbaarheid meten hebben we twee indicatoren: één voor goede en één voor geldige gebeurtenissen.

Onze meetmethode is dus “Good Bad Ratio”.

• Goede gebeurtenissen zijn { alle HTTP-responscodes: 429, 200-208, 226, 304 }

• Geldige gebeurtenissen zijn { alle HTTP-responscodes }

Om de feature voor deze dienst aan te maken, druk je op:

Klaar!

Door naar de volgende methode: een latency-SLI meten met een distribution cut.

Houd bij het meten van latency (hoe lang een verzoek aan je dienst duurt) dit diagram in je achterhoofd: een verdeling met een lange staart.

Dit diagram laat een GROOT aantal verzoeken zien dat een paar milliseconden duurt, en — vandaar die lange staart — een heel klein aantal dat eindeloos duurt.

Wat we willen meten is: hoeveel verzoeken zitten bij een gegeven latency eronder, en hoeveel erboven?

Hoeveel verzoeken halen de lat, en hoeveel duren simpelweg te lang?

Weten we dat, dan kunnen we de SLI-formule gewoon invullen:

• 'goede' gebeurtenissen zijn snel genoeg om de lat te halen
• 'geldige' gebeurtenissen zijn alle verzoeken

Laten we dit in Agile Analytics inrichten:

En dan: welke bak scheidt het kaf van het koren?

In dit voorbeeld zijn alle gebeurtenissen sneller dan 2048 milliseconden 'goed'.

Vul vervolgens de Google-monitoringcode in onder 'filter valid'.

Druk op 'create' en je hebt je tweede SLI gemaakt!

Door naar het stellen van doelen voor je teams.

Het service level objective is het betrouwbaarheidsdoel dat het featureteam moet halen. SLO's zijn de sleutel tot datagedreven keuzes over de prioriteiten van een featureteam. Het team heeft een doel nodig.

Een doel van 99% beschikbaarheid (zie schermafbeelding) betekent dat de dienst de volgende toegestane downtime heeft:

• 1m 26s (per dag)
• 10m 4s (per week)
• 43m 49s (per maand)

Dat zouden de getallen zijn als we tijd als grondslag voor onze meting gebruikten. Wij gebruiken in plaats daarvan gebeurtenissen en percentages, maar dit geeft een idee hoe het eruitziet op tijdbasis.

Simpel gezegd is het SLO-spel een 'spel van negens'. Hoeveel betrouwbaarheid wil je als standaard voor je diensten aanhouden, wetend dat het nooit 100% kan zijn?

Ons advies: begin bij 95% en werk omhoog naar 99%, dan 99,9% of zelfs 99,99%.

Het laatste instrument waarmee featureteams (bijna volledige) autonomie krijgen over hun prioriteiten, op basis van data, zijn error budgets.

Dit beleid is niet bedoeld als straf voor het missen van SLO's. Verandering stilleggen is onwenselijk; dit beleid geeft teams juist toestemming om zich volledig op betrouwbaarheid te richten wanneer de data aangeeft dat betrouwbaarheid op dat moment belangrijker is dan andere productfeatures.

Een SLO legt vast hoe goed een dienst moet presteren gedurende een meetperiode. Wat er in die periode overblijft, is het error budget. Het error budget drukt uit in welke mate een dienst mag falen en tóch de SLO haalt.

Een error budget is gedefinieerd als 100% − SLO%. Is je SLO-doel 99,99%, dan is je error budget 0,01% binnen de meetperiode. Een dienst die 100% moet halen heeft geen error budget; zo'n SLO stellen is geen goed idee.

Met error budgets volg je hoeveel losse slechte gebeurtenissen (zoals verzoeken) er nog mogen optreden in de rest van je meetperiode voordat je de SLO schendt. Je kunt het error budget gebruiken om onderhoudstaken te plannen, zoals het uitrollen van nieuwe versies. Is het error budget bijna op, dan kan een risicovolle actie als het doorzetten van nieuwe updates ertoe leiden dat je de SLO schendt.

Een voorbeeld: is je SLO dat 85% van de verzoeken goed moet zijn over een voortschrijdende periode van 7 dagen, dan staat je error budget toe dat 15% van de verzoeken slecht is. Krijg je gemiddeld zo'n 60.480 verzoeken per week, dan is je error budget 15% daarvan: 9.072 verzoeken die slecht mogen zijn. Je begint met een error budget van 9.072 verzoeken, en naarmate er slechte verzoeken optreden wordt dat budget opgesoupeerd tot het op 0 staat.

Error budgets stellen featureteams in staat gewaarschuwd te worden zodra betrouwbaarheid een risico wordt. Omdat het team verantwoordelijk is voor de software in productie — "you build it, you run it" — is het team ook aanspreekbaar op zowel het bouwen van features als op de stabiliteit en prestaties ervan.

SLI's, SLO's en error budgets brengen krachtige begrippen uit Site Reliability Engineering (SRE) netjes samen en geven je teams het gereedschap om autonoom, verantwoordelijk en aanspreekbaar te zijn.