Et feilbudsjett (error budget) er hvor mye upålitelighet SLO-et ditt tillater over en periode: 100 % minus målet. Et SLO på 99,9 % over 30 dager gir et feilbudsjett på 43 minutter og 12 sekunder nedetid, eller én feilet forespørsel av tusen. Så lenge det er budsjett igjen, kan teamet lansere og ta risiko. Når det er brukt opp, går pålitelighetsarbeid først til vinduet har hentet seg inn igjen.
Den ene regelen gjør et pålitelighetsmål om til beslutninger. Denne guiden viser hvordan du beregner et feilbudsjett, hva som bør og ikke bør bruke av det, hvordan du ser hvor raskt du bruker det, og hvordan du skriver en policy for når det er tomt.
Slik beregner du et feilbudsjett
Du trenger to ting: et SLO, pålitelighetsmålet du setter for deg selv, og et vindu, perioden det måles over. Feilbudsjettet er det som er igjen mellom målet og det perfekte.
Error budget = (100% − SLO) × window
For et SLO på 99,9 % over 30 dager (43 200 minutter): 0,1 % × 43 200 = 43,2 minutter, altså 43 minutter og 12 sekunder. Tabellen viser samme regnestykke for vanlige mål, rundet ned til nærmeste sekund.
SLOBudsjett per 30 dagerBudsjett per 90 dager99 %7 t 12 min21 t 36 min99,5 %3 t 36 min10 t 48 min99,9 min 12 s2 t 9 min 36 s99,95 min 36 s1 t 4 min 48 s99,99 %4 min 19 s12 min 57 s
SLA- og oppetidskalkulatoren gjør dette for alle mål og perioder. Den bruker en gjennomsnittlig måned (et år delt på 12), så den viser 43 minutter og 49 sekunder for 99,9 % i stedet for 30-dagerstallet over.
Tidsbasert eller forespørselsbasert
Et feilbudsjett kan telles i to enheter, avhengig av hvilken SLI som ligger bak SLO-et ditt:
Tidsbasert: minutter med nedetid, målt med sjekker utenfra. Det er enkelt, lett å forklare og stemmer med hvordan de fleste SLA-er overfor kunder er skrevet. Et månedlig SLO på 99,9 % tillater rundt 43 minutter.
Forespørselsbasert: andelen forespørsler som feilet, talt fra lastbalanserer- eller applikasjonslogger. Med 2 millioner forespørsler i måneden og 99,9 % er budsjettet 2 000 feilede forespørsler. Travle timer veier tyngre enn rolige, noe som ligger nærmere det brukerne merker, men det krever logging du stoler på.
Mange team bruker begge: et tidsbasert budsjett fra eksterne sjekker for tjenesten som helhet, og forespørselsbaserte budsjetter for endepunktene som betyr mest, som kassen eller API-et.
Hvorfor ha et feilbudsjett i det hele tatt
Uten et budsjett blir pålitelighet en diskusjon. Produkt vil lansere, utvikling vil roe ned, og den som snakker sist, vinner. Et budsjett erstatter diskusjonen med et tall begge sider har blitt enige om på forhånd.
Det gjør 100 % til feil mål. Et mål på 100 % gir null budsjett, så hver utrulling blir en risiko ingen får lov til å ta. Brukerne merker uansett ikke forskjell på 99,99 % og 100 % gjennom sitt eget wifi og mobilnett.
Det gjør risiko til noe du kan bruke. En stor migrering, en ny region eller en risikabel lansering kan planlegges så den får plass i budsjettet som er igjen denne måneden.
Det bestemmer prioriteringene for deg. Når budsjettet er brukt opp, sier policyen hva som skjer videre, så ingen trenger å vinne et møte for å få pålitelighetsarbeid inn på veikartet.
Hva som bruker av budsjettet
Alt SLI-en din teller som dårlig, bruker av budsjettet. Bestem dette når du skriver SLO-et, ikke midt i hendelsen.
Bekreftede driftsavbrudd: tjenesten svarte ikke, svarte med en feil eller svarte med feil innhold.
Trege svar, hvis SLI-en din sier at en forespørsel over en viss grense regnes som feilet. En side som bruker 30 sekunder, er oppe, men ikke brukbar.
Mislykkede utrullinger og tilbakerullinger, for minuttene brukerne så feil.
Driftsavbrudd hos leverandørene dine. Hvis betalingsleverandøren eller DNS-leverandøren din svikter, kan brukerne dine fortsatt ikke fullføre kjøpet. Det bruker av budsjettet ditt selv om det ikke er du som må fikse det, og det er en god grunn til å følge med på tjenestene du er avhengig av.
Planlagt vedlikehold, bare hvis SLO-et sier det. Mange team holder varslede vedlikeholdsvinduer utenfor, med et tak per måned.
Det som ikke skal bruke av budsjettet: falske alarmer. Én feilet sjekk på grunn av et kort nettverksbrudd er ikke nedetid. Bekreft en feil med en ny sjekk før du teller den, ellers tømmes budsjettet på problemer brukerne aldri så.
Burn rate: hvor raskt du bruker budsjettet
Budsjettet forteller hvor mye feil du har råd til. Burn rate forteller hvor raskt du bruker det. Googles SRE-workbook definerer det som hvor raskt tjenesten forbruker feilbudsjettet sammenlignet med SLO-et (Alerting on SLOs).
En burn rate på 1 bruker hele budsjettet akkurat ved slutten av vinduet.
En burn rate på 2 bruker det på halve vinduet: 15 dager av en måned på 30 dager.
Et fullstendig driftsavbrudd har en burn rate på 1 000 mot et SLO på 99,9 %, siden hvert minutt nede er tusen ganger den tillatte raten. Tjue minutter av det bruker 46 % av et 30-dagersbudsjett.
Workbookens anbefalte utgangspunkt for et SLO på 99,9 % varsler vakthavende når 2 % av et 30-dagersbudsjett brukes i løpet av en time (burn rate 14,4) eller 5 % i løpet av seks timer (burn rate 6), og oppretter en sak når 10 % brukes i løpet av tre dager (burn rate 1). Hvert varsel sjekker også et kort vindu, så det slutter å utløses kort tid etter at problemet er borte.
Ved et fullstendig driftsavbrudd utløses et burn rate-varsel og et vanlig «nettstedet er nede»-varsel omtrent samtidig. Burn rate gjør nytten sin ved delvise feil: 3 % av forespørslene feiler i flere timer, noe som aldri tar ned nettstedet, men i det stille bruker opp månedens budsjett innen onsdag.
Skriv en policy for feilbudsjettet
Et budsjett uten policy er bare et tall på et dashbord. Policyen sier på forhånd hva teamet gjør ved hvert forbruksnivå. Bli enige om den sammen, produkt og utvikling, og skriv den ned der begge finner den. Google har publisert et eksempel på en policy for feilbudsjett som er verdt å lese før du skriver din egen.
En enkel policy å starte med
Budsjett igjen: lanser som normalt. Planlagt risikabelt arbeid går som planlagt.
Halvparten brukt før midten av vinduet: lederen for vaktordningen går gjennom hendelsene så langt og peker ut den største årsaken.
Budsjettet brukt opp: bare feilrettinger og pålitelighetsarbeid lanseres til vinduet har hentet seg inn. Risikable migreringer må vente.
Én enkelt hendelse brukte mer enn en femtedel av budsjettet: den får en skriftlig postmortem med minst ett tiltak.
Unntak avgjøres av navngitte personer, for eksempel utviklingssjefen og produktsjefen sammen, og skrives ned.
Tersklene er eksempler, ikke regler. Velg terskler teamet faktisk vil holde seg til. En policy som ignoreres første gang den biter, er verre enn ingen, fordi den lærer alle at SLO-et ikke betyr noe.
Vanlige feil
Å sette SLO-et likt SLA-en. Da går budsjettet tomt i samme øyeblikk som du skylder kundene servicekreditter. Hold SLO-et strengere enn SLA-en, så den interne alarmen går først. SLA vs SLO vs SLI forklarer hvordan de tre henger sammen.
Et for kort vindu. Et ukesbudsjett nullstilles før en dårlig uke rekker å endre noe. Tretti dager, rullerende eller per kalendermåned, er det vanlige valget.
Å glemme hvordan vinduet nullstilles. En kalendermåned starter på nytt den 1., så en dårlig siste uke er glemt etter noen dager. Et rullerende 30-dagersvindu husker den i en måned, noe som er strengere og mer rettferdig.
Å se bare på totalen. Ett driftsavbrudd på 40 minutter og førti avbrudd på 1 minutt bruker like mye av budsjettet, men det siste ødelegger brukernes arbeid hver dag. Følg antall hendelser og MTTR ved siden av budsjettet.
Å måle bare innenfra. Serverlogger kan ikke registrere forespørsler som aldri kom fram. Et utløpt sertifikat eller en ødelagt DNS-post bruker av budsjettet uten at noe annet enn en ekstern sjekk ser det.
Følg et tidsbasert feilbudsjett med Uptimecheck
Uptimecheck gir deg tallene et tidsbasert budsjett trenger. Oppetidsovervåking sjekker så ofte som hvert minutt fra Stockholm, London og New York, og bekrefter hver feilet sjekk fra et annet sted, så et kort blipp ikke bruker av budsjettet. Vedlikeholdsvinduer og pausert tid teller ikke mot oppetiden.
Rapporter viser oppetid, nedetid og hendelser per monitor for denne måneden, forrige måned eller de siste 7, 30 eller 90 dagene, mot et SLA-mål på 99 %, 99,5 %, 99,9 %, 99,95 % eller 99,99 %, med nedlasting som CSV. Budsjettet som er igjen, er tillatt nedetid minus nedetiden i rapporten. Se hvordan du kjører rapporter mot et SLA-mål.
Hendelser tar vare på bevisene og en tidslinje over hver sjekk, hvert varsel og hvert notat, som er det en postmortem trenger. Se hendelseshåndtering.
Vedlikeholdsvinduer holder planlagt arbeid utenfor tallene. Se hvordan du planlegger vedlikeholdsvinduer.
For å sette en pris på budsjettet du bruker, prøv kalkulatoren for nedetidskostnader. For å se hva hvert mål tillater, les hva 99,9 % oppetid betyr.
Vit hvor mye budsjett du har igjen før måneden er over. Prøv Uptimecheck gratis i 14 dager, uten kredittkort.