En felbudget är den mängd otillförlitlighet som din SLO tillåter under en period: 100 % minus målet. En SLO på 99,9 % över 30 dagar ger en felbudget på 43 minuter och 12 sekunder driftstopp, eller en misslyckad förfrågan av tusen. Så länge det finns budget kvar kan teamet leverera och ta risker. När den är slut går tillförlitlighetsarbetet först tills fönstret har återhämtat sig.
Den enda regeln gör ett tillförlitlighetsmål till konkreta beslut. Den här guiden visar hur du räknar ut en felbudget, vad som ska och inte ska förbruka den, hur du ser hur snabbt du förbrukar den och hur du skriver en policy för när den tar slut.
Så räknar du ut en felbudget
Du behöver två saker: en SLO, det tillförlitlighetsmål du sätter för dig själv, och ett fönster, den period det mäts över. Felbudgeten är det som återstår mellan målet och perfektion.
Felbudget = (100 % − SLO) × fönster
För en SLO på 99,9 % över 30 dagar (43 200 minuter): 0,1 % × 43 200 = 43,2 minuter, alltså 43 minuter och 12 sekunder. Tabellen visar samma beräkning för vanliga mål, avrundat nedåt till hela sekunder.
SLOBudget per 30 dagarBudget per 90 dagar99 %7 h 12 min21 h 36 min99,5 %3 h 36 min10 h 48 min99,9 min 12 s2 h 9 min 36 s99,95 min 36 s1 h 4 min 48 s99,99 %4 min 19 s12 min 57 s
SLA- och upptidskalkylatorn gör den här beräkningen för valfritt mål och valfri period. Den utgår från en genomsnittlig månad (ett år delat med 12), så den visar 43 minuter och 49 sekunder för 99,9 % i stället för 30-dagarssiffran ovan.
Tidsbaserad eller förfrågningsbaserad
En felbudget kan räknas i två enheter, beroende på vilken SLI som ligger bakom din SLO:
Tidsbaserad: minuter av driftstopp, mätt med kontroller utifrån. Den är enkel, lätt att förklara och stämmer med hur de flesta kund-SLA:er är skrivna. En månatlig SLO på 99,9 % tillåter ungefär 43 minuter.
Förfrågningsbaserad: andelen förfrågningar som misslyckades, räknat från lastbalanserarens eller applikationens loggar. Vid 2 miljoner förfrågningar i månaden och 99,9 % är budgeten 2 000 misslyckade förfrågningar. Den väger tunga timmar högre än lugna, vilket ligger närmare det användarna märker, men kräver loggning du kan lita på.
Många team använder båda: en tidsbaserad budget från externa kontroller för tjänsten som helhet, och förfrågningsbaserade budgetar för de endpoints som betyder mest, som kassan eller API:et.
Varför ha en felbudget över huvud taget
Utan en budget blir tillförlitlighet en diskussion. Produkt vill leverera, utveckling vill sakta ned, och den som pratar sist vinner. En budget ersätter diskussionen med en siffra som båda sidor har kommit överens om i förväg.
Den gör 100 % till fel mål. Ett mål på 100 % lämnar ingen budget, så varje driftsättning blir en risk som ingen får ta. Användarna kan ändå inte skilja 99,99 % från 100 % genom sina egna wifi- och mobilnät.
Den gör risk till något du kan spendera. En stor migrering, en ny region eller en riskabel release kan planeras så att den ryms i den budget som är kvar den här månaden.
Den prioriterar åt dig. När budgeten är slut säger policyn vad som händer härnäst, så ingen behöver vinna ett möte för att få in tillförlitlighetsarbete i planeringen.
Vad som förbrukar budgeten
Allt som din SLI räknar som dåligt förbrukar budget. Bestäm det när du skriver din SLO, inte mitt under incidenten.
Bekräftade avbrott: tjänsten svarade inte, svarade med ett fel eller svarade med fel innehåll.
Långsamma svar, om din SLI säger att en förfrågan som är långsammare än en gräns räknas som misslyckad. En sida som tar 30 sekunder är uppe, men inte användbar.
Misslyckade driftsättningar och återställningar, för de minuter användarna såg fel.
Avbrott hos dina leverantörer. Om din betalleverantör eller DNS-leverantör går ned kan dina användare ändå inte slutföra köpet. Det förbrukar din budget trots att det inte är du som kan åtgärda det, vilket är ett bra skäl att bevaka tjänsterna du är beroende av.
Planerat underhåll, bara om din SLO säger det. Många team undantar aviserade underhållsfönster, med ett tak per månad.
Det som inte ska förbruka den: falsklarm. En enstaka misslyckad kontroll på grund av en tillfällig nätverksstörning är inget driftstopp. Bekräfta ett fel med en andra kontroll innan du räknar det, annars töms budgeten på problem som användarna aldrig märkte.
Burn rate: hur snabbt du förbrukar budgeten
Budgeten säger hur mycket fel du har råd med. Burn rate säger hur snabbt du använder den. Googles SRE-workbook definierar det som hur snabbt tjänsten förbrukar felbudgeten i förhållande till SLO:n (Alerting on SLOs).
En burn rate på 1 förbrukar hela budgeten precis när fönstret tar slut.
En burn rate på 2 förbrukar den på halva fönstret: 15 dagar av en 30-dagarsmånad.
Ett totalt avbrott har en burn rate på 1 000 mot en SLO på 99,9 %, eftersom varje minut nere är tusen gånger den tillåtna takten. Tjugo minuter av det förbrukar 46 % av en 30-dagarsbudget.
Workbookens rekommenderade utgångspunkt för en SLO på 99,9 % larmar någon när 2 % av en 30-dagarsbudget förbrukas inom en timme (en burn rate på 14,4) eller 5 % inom sex timmar (en burn rate på 6), och öppnar ett ärende när 10 % förbrukas inom tre dygn (en burn rate på 1). Varje larm kontrollerar också ett kort fönster, så att det slutar larma strax efter att problemet har upphört.
Vid ett totalt avbrott går ett burn rate-larm och ett vanligt larm om att ”sajten ligger nere” ungefär samtidigt. Burn rate gör verklig nytta vid partiella fel: 3 % av förfrågningarna misslyckas i flera timmar, vilket aldrig tar ned sajten men i tysthet förbrukar månadens budget redan på onsdagen.
Skriv en felbudgetpolicy
En budget utan policy är bara en siffra på en dashboard. Policyn säger i förväg vad teamet gör vid varje nivå av förbrukning. Kom överens om den tillsammans, produkt och utveckling, och skriv ned den där båda hittar den. Google publicerar ett exempel på en felbudgetpolicy som är värt att läsa innan du skriver din egen.
En enkel policy att utgå från
Budget kvar: leverera som vanligt. Planerat riskfyllt arbete genomförs.
Halva budgeten förbrukad före halva fönstret: ansvarig för jouren går igenom incidenterna hittills och pekar ut den största orsaken.
Budgeten förbrukad: bara buggfixar och tillförlitlighetsarbete levereras tills fönstret har återhämtat sig. Riskfyllda migreringar får vänta.
En enskild incident förbrukade mer än en femtedel av budgeten: den får en skriftlig postmortem med minst en åtgärdspunkt.
Undantag beslutas av namngivna personer, till exempel utvecklingschefen och produktchefen tillsammans, och skrivs ned.
Tröskelvärdena är exempel, inte regler. Välj sådana som ditt team faktiskt kommer att följa. En policy som ignoreras första gången den biter är sämre än ingen alls, eftersom den lär alla att SLO:n inte spelar någon roll.
Vanliga misstag
Att sätta SLO:n lika med SLA:n. Då tar budgeten slut i samma ögonblick som du är skyldig kunderna servicekrediter. Håll SLO:n strängare än SLA:n, så att det interna larmet går först. SLA, SLO och SLI förklarar hur de tre hänger ihop.
Ett för kort fönster. En veckobudget nollställs innan en dålig vecka hinner påverka något. Trettio dagar, rullande eller per kalendermånad, är det vanliga valet.
Att glömma hur fönstret nollställs. En kalendermånad börjar om den 1:a, så en dålig sista vecka är glömd inom några dagar. Ett rullande 30-dagarsfönster minns den i en månad, vilket är strängare och rättvisare.
Att bara titta på totalen. Ett avbrott på 40 minuter och fyrtio avbrott på 1 minut förbrukar samma budget, men det senare stör användarnas arbete varje dag. Följ antalet incidenter och MTTR bredvid budgeten.
Att bara mäta inifrån. Serverloggar kan inte registrera förfrågningar som aldrig kom fram. Ett utgånget certifikat eller en trasig DNS-post förbrukar budget som bara en extern kontroll ser.
Följ upp en tidsbaserad felbudget med Uptimecheck
Uptimecheck ger dig siffrorna som en tidsbaserad budget kräver. Upptidsövervakning kontrollerar så ofta som varje minut från Stockholm, London och New York, och bekräftar varje misslyckad kontroll från en andra plats, så att en enstaka störning inte förbrukar budget. Underhållsfönster och pausad tid räknas inte mot upptiden.
Rapporter visar upptid, driftstopp och incidenter per monitor för den här månaden, förra månaden eller de senaste 7, 30 eller 90 dagarna, mot ett SLA-mål på 99 %, 99,5 %, 99,9 %, 99,95 % eller 99,99 %, med CSV-nedladdning. Den återstående budgeten är det tillåtna driftstoppet minus driftstoppet i rapporten. Läs så tar du fram rapporter mot ett SLA-mål.
Incidenter sparar underlaget och en tidslinje över varje kontroll, larm och anteckning, precis det en postmortem behöver. Läs mer om incidenthantering.
Underhållsfönster håller planerat arbete utanför siffrorna. Läs så schemalägger du underhållsfönster.
Vill du sätta ett pris på budgeten du förbrukar kan du testa kalkylatorn för kostnaden av driftstopp. Läs vad 99,9 % upptid betyder för att se vad varje mål tillåter.
Vet hur mycket budget du har kvar innan månaden är slut. Testa Uptimecheck gratis i 14 dagar, inget kreditkort krävs.