Incidentmanagement voor razendsnelle teams
Wat is een foutenbudget en waarom is het belangrijk?
Elk ontwikkelings-, bedrijfs- en IT-team weet dat er soms incidenten gebeuren.
Zelfs de grootste bedrijven met het beste talent en een reputatie voor bijna 100% uptime moeten soms gefrustreerd toekijken hoe hun systemen uitvallen. Kijk maar naar Apple, Delta en Facebook, ze hebben de afgelopen vijf jaar allemaal tientallen miljoenen verloren door incidenten.
Dit feit betekent dat Service Level Agreements (SLA's) nooit 100% uptime mogen beloven. Want dat is een belofte die geen enkel bedrijf kan nakomen.
Het betekent ook dat als je bedrijf incidenten heel goed kan vermijden of oplossen, je doelstellingen voor uptime consequent haalt. Misschien beloof je 99% uptime en kom je zelfs dichter bij 99,5%. Of je belooft een uptime van 99,5% en je bereikt in een gemiddelde maand wel 99,99%.
Als dat gebeurt, raden deskundigen uit de sector aan om in plaats van de verwachtingen van gebruikers te hoog te stellen door voortdurend je beloften te overschrijden, dat je die extra 0,99% beschouwt als een foutenbudget: de tijd die je team kan gebruiken om risico's te nemen.
Wat is een foutenbudget?
Een foutenbudget is de maximale tijd dat een technisch systeem uit kan vallen of storing kan hebben zonder contractuele gevolgen.
Als in je Service Level Agreement (SLA) bijvoorbeeld is vastgelegd dat je systemen 99,99% van de tijd moeten functioneren voordat het bedrijf klanten moet compenseren voor de uitval, betekent dit dat je foutenbudget (of de tijd dat je systemen zonder gevolgen kunnen uitvallen) 52 minuten en 35 seconden per jaar bedraagt.
Als je SLA een uptime van 99,95% belooft, is je foutenbudget vier uur, 22 minuten en 48 seconden. En met een SLA-belofte van 99,9% uptime, is je foutenbudget acht uur, 46 minuten en 12 seconden.
Waarom hebben technische teams een foutenbudget nodig?
Op het eerste gezicht lijkt een foutenbudget niet zo belangrijk. Het is gewoon nog een statistiek die IT en DevOps gebruiken om ervoor te zorgen dat alles soepel verloopt, toch?
Het antwoord is gelukkig nee. Foutenbudgetten zijn niet alleen een handige manier om ervoor te zorgen dat je je contractuele beloften nakomt. Ze bieden ontwikkelingsteams ook de mogelijkheid om te innoveren en risico's te nemen.
Zoals we uitleggen in ons artikel over SRE:
"Hier is de crux: het ontwikkelteam kan dit foutenbudget op elke gewenste manier 'uitgeven'. Als het product momenteel foutloos werkt, kan het team starten wat het maar wil en wanneer het maar wil. Maar als ze het foutenbudget op is of is overschreden en er op of onder de gedefinieerde SLA wordt gewerkt, worden alle lanceringen bevroren totdat het aantal fouten is teruggebracht tot een niveau waarop de lancering kan doorgaan."
Het voordeel van deze aanpak is dat teams worden aangemoedigd om echte incidenten tot een minimum te beperken en innovatie te maximaliseren door risico's binnen aanvaardbare grenzen te nemen. Deze aanpak overbrugt ook de kloof tussen ontwikkelingsteams, die op innovatie en flexibiliteit gericht zijn, en Operations, waar ze zich bezighouden met stabiliteit en veiligheid. Zolang de downtime laag blijft, kunnen ontwikkelaars flexibel blijven en veranderingen doorvoeren zonder wrijvingen met Operations.
Een foutenbudget gebruiken
Eerst moet je je SLA's en SLO's raadplegen. Welke doelen heb je al gesteld voor beschikbaarheid of succesvolle systeemaanvragen? Welke beloftes heeft je bedrijf aan je klanten gedaan? Die zijn bepalend voor je foutenbudget.
Foutenbudgetten op basis van uptime
De meeste teams controleren de uptime maandelijks. Als de beschikbaarheid hoger is dan het in de SLA/SLO beloofde aantal, kan het team nieuwe functies uitbrengen en risico's nemen. Als de waarde onder het doel ligt, stop je met releases uitbrengen totdat de het doel weer in zicht is.
Om deze methode effectief te gebruiken, moet je je SLO-doelstelling (meestal een percentage) vertalen in reële cijfers waarmee je ontwikkelaars kunnen werken. Dit betekent dat je moet berekenen hoeveel uur en minuten 1% of 0,5% of 0,1% van de toegestane downtime daadwerkelijk inhoudt. Veelvoorkomende doelen zijn:
SLA target | Yearly allowed downtime | Monthly allowed downtime | |
|---|---|---|---|
| 99.99% uptime | Yearly allowed downtime 52 minutes, 35 seconds | Monthly allowed downtime 4 minutes, 23 seconds | |
| 99.95% uptime | Yearly allowed downtime 4 hours, 22 minutes, 48 seconds | Monthly allowed downtime 21 minutes, 54 seconds | |
| 99.9% uptime | Yearly allowed downtime 8 hours, 45 minutes, 57 seconds | Monthly allowed downtime 43 minutes, 50 seconds | |
| 99.5% uptime | Yearly allowed downtime 43 hours, 49 minutes, 45 seconds | Monthly allowed downtime 3 hours, 39 minutes | |
| 99% uptime | Yearly allowed downtime 87 hours, 39 minutes | Monthly allowed downtime 7 hours, 18 minutes | |
Foutenbudgetten gebaseerd op geslaagde aanvragen
SLO's worden meer gewaardeerd dan SLA's, maar ze kunnen net zoveel problemen veroorzaken als ze vaag, overgecompliceerd of zelfs onmogelijk te meten zijn. Om SLO's een succes te laten zijn en ervoor te zorgen dat je engineers hun haar niet uit het hoofd willen trekken, moeten ze eenvoudig en duidelijk zijn opgesteld. Alleen de belangrijkste statistieken zouden in aanmerking moeten komen voor de SLO-status. De doelstellingen moeten in duidelijke taal worden omschreven en, net als bij SLA's, moeten ze altijd rekening houden met zaken als vertragingen aan de kant van de klant.
Handel SLA's tijdig af om aanvragen op basis van prioriteiten op te oplossen en gebruik geautomatiseerde escalatieregels om de juiste teamleden op de hoogte te stellen en SLA-inbreuken te voorkomen met Jira Service Management.
Ontdek incidentcommunicatie met Statuspage
In deze tutorial laten we je zien hoe je incidentsjablonen kunt gebruiken om effectief te communiceren tijdens storingen. Aanpasbaar voor de vele soorten serviceonderbrekingen.
Lees deze tutorialHet belang van een postmortemproces bij incidenten
Een postmortemincident, ook wel bekend als een beoordeling na een incident, is de beste manier om door te werken wat er tijdens een incident is gebeurd en geleerde lessen vast te leggen.
Lees dit artikel