Et fejlbudget (error budget) er den mængde upålidelighed, dit SLO tillader over en periode: 100 % minus målet. Et SLO på 99,9 % over 30 dage giver et fejlbudget på 43 minutter og 12 sekunders nedetid, eller én fejlet forespørgsel ud af hver tusinde. Så længe der er budget tilbage, kan teamet udgive og tage chancer. Når det er brugt op, kommer pålidelighedsarbejdet først, indtil perioden er kommet sig.
Den ene regel gør et pålidelighedsmål til konkrete beslutninger. Denne guide viser, hvordan du beregner et fejlbudget, hvad der bør og ikke bør bruge af det, hvordan du ser, hvor hurtigt du bruger det, og hvordan du skriver en politik for, hvad der sker, når det er brugt op.
Sådan beregner du et fejlbudget
Du skal bruge to ting: et SLO, det pålidelighedsmål, du sætter for dig selv, og en periode, som det måles over. Fejlbudgettet er det, der er tilbage mellem målet og det perfekte.
Error budget = (100% − SLO) × window
For et SLO på 99,9 % over 30 dage (43.200 minutter): 0,1 % × 43.200 = 43,2 minutter, altså 43 minutter og 12 sekunder. Tabellen viser samme regnestykke for almindelige mål, rundet ned til hele sekunder.
SLOBudget pr. 30 dageBudget pr. 90 dage99 %7 t 12 m21 t 36 m99,5 %3 t 36 m10 t 48 m99,9 m 12 s2 t 9 m 36 s99,95 m 36 s1 t 4 m 48 s99,99 %4 m 19 s12 m 57 s
SLA- og oppetidsberegneren gør det for ethvert mål og enhver periode. Den bruger en gennemsnitlig måned (et år delt med 12), så den viser 43 minutter og 49 sekunder for 99,9 % i stedet for tallet for 30 dage ovenfor.
Tidsbaseret eller forespørgselsbaseret
Et fejlbudget kan opgøres i to enheder, afhængigt af det SLI, der ligger bag dit SLO:
Tidsbaseret: minutter med nedetid, målt af tjek udefra. Det er enkelt, let at forklare og passer til, hvordan de fleste SLA’er med kunder er skrevet. Et månedligt SLO på 99,9 % tillader cirka 43 minutter.
Forespørgselsbaseret: andelen af forespørgsler, der fejlede, talt op fra load balancerens eller applikationens logs. Ved 2 millioner forespørgsler om måneden og 99,9 % er budgettet 2.000 fejlede forespørgsler. Travle timer vejer tungere end stille timer, hvilket ligger tættere på det, brugerne mærker, men det kræver logning, du kan stole på.
Mange teams bruger begge dele: et tidsbaseret budget ud fra eksterne tjek for tjenesten som helhed og forespørgselsbaserede budgetter for de endpoints, der betyder mest, som checkout eller API’et.
Hvorfor overhovedet have et fejlbudget
Uden et budget er pålidelighed en diskussion. Produkt vil udgive, udvikling vil sætte tempoet ned, og den, der taler sidst, vinder. Et budget erstatter diskussionen med et tal, som begge sider har aftalt på forhånd.
Det gør 100 % til det forkerte mål. Et mål på 100 % efterlader intet budget, så hver deploy er en risiko, ingen må tage. Brugerne kan alligevel ikke kende forskel på 99,99 % og 100 % gennem deres egne wi-fi- og mobilnetværk.
Det gør risiko til noget, man kan bruge af. En stor migrering, en ny region eller en risikabel release kan planlægges, så den passer ind i det budget, der er tilbage denne måned.
Det afgør prioriteterne for dig. Når budgettet er brugt, siger politikken, hvad der sker nu, så ingen skal vinde et møde for at få pålidelighedsarbejde på roadmappen.
Hvad bruger af budgettet
Alt, hvad dit SLI tæller som dårligt, bruger af budgettet. Beslut det, når du skriver dit SLO, ikke midt i hændelsen.
Bekræftede nedbrud: tjenesten svarede ikke, svarede med en fejl eller svarede med det forkerte indhold.
Langsomme svar, hvis dit SLI siger, at en forespørgsel, der er langsommere end en grænse, tæller som fejlet. En side, der tager 30 sekunder, er oppe, men ikke brugbar.
Fejlslagne deploys og rollbacks, for de minutter, hvor brugerne så fejl.
Nedbrud hos dine leverandører. Går din betalingsudbyder eller DNS-vært ned, kan dine brugere stadig ikke gennemføre et køb. Det bruger af dit budget, selvom rettelsen ikke er din, og det er en god grund til at holde øje med de tjenester, du er afhængig af.
Planlagt vedligeholdelse, men kun hvis dit SLO siger det. Mange teams undtager varslede vedligeholdelsesvinduer, med et loft pr. måned.
Det, der ikke bør bruge af det: falske positiver. Ét fejlet tjek på grund af et kortvarigt netværksudfald er ikke nedetid. Bekræft en fejl med et ekstra tjek, før du tæller den med, ellers drænes dit budget af problemer, brugerne aldrig så.
Burn rate: hvor hurtigt du bruger af budgettet
Budgettet fortæller dig, hvor mange fejl du har råd til. Burn rate fortæller dig, hvor hurtigt du bruger det. Googles SRE-workbook definerer den som, hvor hurtigt tjenesten forbruger fejlbudgettet i forhold til SLO’et (Alerting on SLOs).
En burn rate på 1 bruger hele budgettet præcis ved periodens udløb.
En burn rate på 2 bruger det på halvdelen af perioden: 15 dage af en måned på 30 dage.
Et totalt nedbrud brænder med 1.000 i forhold til et SLO på 99,9 %, da hvert minuts nedetid er tusind gange den tilladte rate. Tyve minutter af det bruger 46 % af et budget for 30 dage.
Workbookens anbefalede udgangspunkt for et SLO på 99,9 % tilkalder nogen, når 2 % af et 30-dages budget brændes af inden for en time (en burn rate på 14,4) eller 5 % inden for seks timer (en burn rate på 6), og opretter en ticket, når 10 % brændes af inden for tre dage (en burn rate på 1). Hver alarm tjekker også et kort vindue, så den holder op med at gå, kort efter at problemet er væk.
Ved et totalt nedbrud går en burn rate-alarm og en almindelig “sitet er nede”-alarm omtrent samtidig. Burn rates gør deres nytte ved delvise fejl: 3 % af forespørgslerne fejler i timevis, hvilket aldrig får sitet til at gå ned, men stille og roligt bruger månedens budget op inden onsdag.
Skriv en fejlbudget-politik
Et budget uden en politik er bare et tal på et dashboard. Politikken siger på forhånd, hvad teamet gør ved hvert niveau af forbrug. Aftal den med produkt og udvikling sammen, og skriv den ned, hvor begge kan finde den. Google har udgivet et eksempel på en fejlbudget-politik, som er værd at læse, før du skriver din egen.
En enkel politik at starte med
Budget tilbage: udgiv som normalt. Planlagt risikabelt arbejde fortsætter.
Halvdelen brugt før midt i perioden: den ansvarlige for vagten gennemgår hændelserne indtil nu og udpeger den største årsag.
Budget brugt: kun fejlrettelser og pålidelighedsarbejde bliver udgivet, indtil perioden er kommet sig. Risikable migreringer må vente.
En enkelt hændelse brugte mere end en femtedel af budgettet: den får et skriftligt postmortem med mindst ét handlingspunkt.
Undtagelser afgøres af navngivne personer, for eksempel udviklingschefen og produktchefen i fællesskab, og skrives ned.
Tærsklerne er eksempler, ikke regler. Vælg nogle, dit team rent faktisk vil overholde. En politik, der bliver ignoreret første gang, den bider, er værre end ingen, fordi den lærer alle, at SLO’et ikke betyder noget.
Almindelige fejl
At sætte SLO’et lig med SLA’en. Så løber budgettet tør i samme øjeblik, som du skylder kunderne servicekreditter. Hold SLO’et strammere end SLA’en, så den interne alarm lyder først. SLA vs. SLO vs. SLI forklarer, hvordan de tre hænger sammen.
En periode, der er for kort. Et ugentligt budget nulstilles, før en dårlig uge kan nå at ændre noget. Tredive dage, løbende eller pr. kalendermåned, er det sædvanlige valg.
At glemme, hvordan perioden nulstilles. En kalendermåned starter forfra den 1., så en dårlig sidste uge er glemt på få dage. En løbende periode på 30 dage husker den i en måned, hvilket er strengere og mere retfærdigt.
Kun at se på totalen. Ét nedbrud på 40 minutter og fyrre nedbrud på 1 minut bruger det samme budget, men det sidste afbryder brugernes arbejde hver dag. Følg antallet af hændelser og MTTR ved siden af budgettet.
Kun at måle indefra. Serverlogs kan ikke registrere forespørgsler, der aldrig nåede frem. Et udløbet certifikat eller en ødelagt DNS-record bruger budget, som kun et eksternt tjek ser.
Følg et tidsbaseret fejlbudget med Uptimecheck
Uptimecheck giver dig de tal, et tidsbaseret budget har brug for. Oppetidsovervågning tjekker helt ned til hvert minut fra Stockholm, London og New York og bekræfter hvert fejlet tjek fra en anden lokation, så et enkelt kortvarigt udfald ikke bruger af budgettet. Vedligeholdelsesvinduer og tid på pause tæller ikke med i oppetiden.
Rapporter viser oppetid, nedetid og hændelser pr. monitor for denne måned, sidste måned eller de seneste 7, 30 eller 90 dage, målt mod et SLA-mål på 99 %, 99,5 %, 99,9 %, 99,95 % eller 99,99 %, med download som CSV. Det resterende budget er den tilladte nedetid minus nedetiden i rapporten. Se sådan kører du rapporter mod et SLA-mål.
Hændelser gemmer dokumentationen og en tidslinje over hvert tjek, hver alarm og hver note, præcis det et postmortem har brug for. Se hændelsesstyring.
Vedligeholdelsesvinduer holder planlagt arbejde ude af tallene. Se sådan planlægger du vedligeholdelsesvinduer.
Vil du sætte en pris på det budget, du bruger, så prøv beregneren for omkostninger ved nedetid. Vil du se, hvad hvert mål tillader, så læs hvad 99,9 % oppetid betyder.
Vid, hvor meget budget du har tilbage, før måneden er omme. Prøv Uptimecheck gratis i 14 dage, uden kreditkort.