Wat zijn Error Budgets?

Error Budgets geven uw softwareteams veel autonomie. Deze feature teams kunnen hun prioriteiten sturen op basis van het serviceniveau dat zij op dit moment aan stakeholders leveren. In dit artikel lichten we de basisbegrippen toe die Error Budgets mogelijk maken. Ook laten we zien hoe u dit implementeert met Agile Analytics van ZEN Software.

Bij het invoeren van Error Budgets moet u zowel in de teamcultuur als in de tooling een aantal zaken inrichten.

SLI & SLO’s zijn de drijvende concepten achter Error Budgets

In dit artikel leest u wat SLI, SLO’s en Error Budgets zijn en hoe u ze implementeert. Laten we beginnen

Deze indicator werkt met percentages. 100% is goed, 0% slecht. Hij meet een serviceniveau als de verhouding tussen ‘good’ en ‘valid’ events.

De eenvoudigste manier om uw eerste SLI te definiëren, is alle ‘good’-events te tellen als percentage van alle ‘valid’-events.

Wat is een ‘good’- en wat is een ‘valid’-event? Dat hangt af van wat u meet: laten we beginnen met het meten van de beschikbaarheid van onze service, aan de kant van de load balancer.

Uit de lijst met alle responsecodes die door de load balancer worden gelogd, onderscheiden we de volgende ‘good’- en ‘valid’-events:

‘Good’ HTTP-events zijn alle HTTP-responsecodes behalve 500-599

‘Valid’ HTTP-events zijn alle HTTP-returncodes

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 monitoren.

Omdat we Availability meten, hebben we twee indicatoren: één voor Good-events en één voor Valid-events.

Onze meetmethode is daarom “Good Bad Ratio”

• Good Event zijn { alle HTTP-returncodes: 429, 200-208, 226, 304 }

• Valid Events zijn { alle HTTP-returncodes }

om de Feature voor deze service te maken, klikt u op:

Klaar!

Laten we doorgaan met de volgende methode, het meten van een Latency SLI met een distribution cut

Bij het meten van latentie (hoe lang een request naar uw service duurt), houd deze grafiek in gedachten: een long-tail-verdeling:

Deze grafiek toont een GROOT aantal requests die enkele milliseconden duren en (vandaar de lange staart) een heel klein aantal requests die extreem lang duren.

Wat we moeten meten is: gegeven een latentie, hoeveel requests zitten onder die latentie en hoeveel erboven.

Hoeveel requests halen de drempel en hoeveel duren simpelweg te lang?

Als we dat weten, kunnen we de SLI-formule eenvoudig invullen:

• ‘good’-events zijn snel genoeg om de drempel te halen
• ‘valid’-events zijn alle requests

Laten we dit configureren in Agile Analytics:

Vervolgens: wat is de bucket die het kaf van het koren scheidt?

In dit voorbeeld zijn alle events sneller dan 2048 milliseconden ‘good’

vul daarna de Google Monitoring-code in onder ‘filter valid’

Klik op Create en u hebt nu uw tweede SLI gemaakt!

Laten we doorgaan met het instellen van doelen voor uw teams.

Het service level objective is het betrouwbaarheidsdoel dat het feature team moet halen. SLO’s zijn de sleutel tot datagedreven beslissingen over de prioriteit van het feature team. Het team heeft een doel nodig.

Een doel instellen van 99% beschikbaarheid (zoals in de screenshot) betekent dat de service een toegestane downtime/onbeschikbaarheid heeft van

• 1m 26s (Dagelijks)
• 10m 4s (Wekelijks)
• 43m 49s (Maandelijks)

Dat zouden de waarden zijn als we tijd als basis zouden gebruiken. Wij werken echter met events en percentages, maar dit geeft een idee hoe het zou zijn op tijdbasis.

Kort gezegd is het SLO-spel een ‘game of nines’. Hoeveel betrouwbaarheid accepteert u als standaard voor uw services, wetende dat 100% nooit haalbaar is.

Wij adviseren te beginnen bij 95% en vervolgens door te groeien naar 99%, daarna 99.9% of zelfs 99.99%.

Het laatste instrument waarmee feature teams (nagenoeg volledige) autonomie krijgen in hun prioriteitskeuzes op basis van data, zijn Error Budgets.

Dit beleid is niet bedoeld als straf voor het missen van SLO’s. Veranderingen stilzetten is onwenselijk; dit beleid geeft teams toestemming om zich uitsluitend op betrouwbaarheid te richten wanneer de data aantoont dat betrouwbaarheid belangrijker is dan andere productfeatures.

Een SLO specificeert in welke mate een service moet presteren binnen een nalevingsperiode. Wat in die periode “overblijft”, wordt het error budget. Het error budget kwantificeert in welke mate een service binnen de nalevingsperiode mag falen en toch nog aan de SLO voldoet.

Een error budget is gedefinieerd als 100% − SLO%. Als uw SLO-doel 99.99% is, dan is uw error budget 0.01% binnen de nalevingsperiode. Een service die een SLO van 100% moet halen, heeft geen error budget. Zo’n SLO instellen is geen best practice.

Met error budgets houdt u bij hoeveel slechte individuele events (zoals requests) nog mogen optreden in de rest van de nalevingsperiode voordat u de SLO schendt. U kunt het error budget gebruiken om onderhoudstaken te sturen, zoals het deployen van nieuwe versies. Als het error budget bijna op is, kunnen risicovolle acties zoals het pushen van nieuwe updates ertoe leiden dat u de SLO schendt.

Stel bijvoorbeeld dat uw SLO is dat in een rolling periode van 7 dagen 85% van de requests ‘good’ is; dan mag uw error budget 15% ‘bad’ requests toestaan. Als u gemiddeld bijvoorbeeld 60,480 requests per week krijgt, is uw error budget 15% van dat totaal, oftewel 9,072 requests die ‘bad’ mogen zijn. Uw startende error budget is 9,072 requests en naarmate ‘bad’ requests optreden, wordt het budget verbruikt tot het 0 is.

Error Budgets stellen feature teams in staat te worden gealarmeerd zodra betrouwbaarheid een risico voor het team vormt. Omdat het team verantwoordelijk is voor de software in productie — “you build it, you run it” — is het team aanspreekbaar op zowel de ontwikkeling van features als de stabiliteit en performance van die features.

Door SLI, SLO en Error Budgets te gebruiken, combineert u krachtige concepten uit Site Reliability Engineering (SRE) en geeft u uw teams de middelen om autonoom en verantwoordelijk te handelen.