# Fyrtiotre minuter om månaden: felbudgeten är ett avtal, inte ett mätvärde - Författare: [Jonas Odencrants](https://paperphyte.com/konsulter/jonas-odencrants), [Paperphyte](https://paperphyte.com) - Publicerad: 2026-10-24 - Kategori: DevOps - Etiketter: DevOps, SRE, SLO, Felbudget, Larm, Observability - Källa: Avtalet säger 99,9 procent. Ingen i teamet vet vad det är i minuter, larmen går på CPU och varje incident blir en diskussion om huruvida den ”räknas”. Ett tillförlitlighetsmål är inte en siffra i ett dokument utan ett avtal om hur mycket som får gå sönder innan nytt får vänta. Så här sätter ni ett mål ni kan hålla, larmar på det som förbrukar budgeten och använder resten till att leverera. Måndag morgon, standup. Natten till lördag låg kassan nere i tjugo minuter, enligt en kund som mejlade supporten. Larmet som gick klockan 03.12 handlade om CPU på en server och tystnade av sig självt. Någon frågar om det var allvarligt. Någon annan svarar att avtalet säger 99,9 procent, så det är nog inom ramen. Ingen vet hur många minuter 99,9 procent är, hur många av dem som redan är förbrukade den här månaden, eller vem som bestämmer vad som händer när de tar slut. **Ett tillförlitlighetsmål som ingen kan räkna om till minuter är inget mål. Det är en siffra i ett avtal, och den styr ingenting.** Begreppen som gör något av siffran kommer från Googles [SRE-bok](https://sre.google/sre-book/service-level-objectives/) från 2016, och de är inte komplicerade: en indikator på vad användaren faktiskt får, ett mål för den, och en [felbudget](https://paperphyte.com/ordlista/felbudget) som är skillnaden mellan målet och perfektion. Det svåra är inte matematiken. Det svåra är att få budgeten att betyda något, så att en förbrukad budget ändrar vad teamet gör nästa vecka. ## Nior är ett löfte, minuter är ett beslut Det första steget är att räkna om. Över ett fönster på 30 dagar betyder niorna så här mycket nedtid: - **99 procent** är 7 timmar och 12 minuter. Det räcker för att en människa ska hinna vakna, förstå felet och backa en ändring, flera gånger i månaden. - **99,5 procent** är 3 timmar och 36 minuter. Fortfarande utrymme för ett par riktiga incidenter, om rollbacken är snabb. - **99,9 procent** är 43 minuter. En incident, om jouren svarar direkt och vet vad den ska göra. Två, om ni har tur. - **99,99 procent** är 4 minuter och 19 sekunder. Ingen människa hinner läsa ett larm, logga in och fatta ett beslut på den tiden. Den nian förutsätter att systemet lagar sig självt. Tabellen säger två saker. Varje nia till ger inte tio procent mindre utrymme utan tio gånger mindre, och någonstans mellan den tredje och den fjärde nian byter kostnaden karaktär: från ”en jour som svarar” till ”en arkitektur som inte behöver jouren”. Det andra är att den som lovade niorna sällan är den som betalar för dem. Siffran skrevs in i ett avtal av någon som ville stänga en affär, och teamet ärvde den utan att någon frågade vad den kostar. ## Tre ord, en mening var Hela vokabulären ryms i tre begrepp, och det är värt att hålla isär dem: - **SLI, indikatorn, är det ni mäter.** Andelen förfrågningar som lyckades. Andelen svar som kom inom 300 millisekunder. Andelen beställningar som gick igenom. Den ska uttryckas i vad användaren upplever, inte i vad servern gör, och mätas så nära användaren som möjligt. - **SLO, målet, är vilket värde indikatorn ska ha över ett fönster.** ”99,9 procent av förfrågningarna till kassan lyckas, mätt över rullande 30 dagar.” Fönstret är en del av målet. Utan fönster är det en önskan. - **Felbudgeten är resten.** Hundra procent minus målet, uttryckt i något som går att förbruka: 0,1 procent av förfrågningarna, eller 43 minuter totalt avbrott. [Felbudgeten](https://paperphyte.com/ordlista/felbudget) är det enda av de tre begreppen som säger något om vad ni får göra. Ett SLA, avtalet med kunden, är något annat: ett löfte med en påföljd. Ert SLO ska vara strängare än ert SLA. Annars får ni veta att ni bröt avtalet i samma ögonblick som kunden får det. ## Budgeten är ett avtal, inte ett mätvärde Det är här de flesta införanden stannar. Teamet mäter indikatorn, ritar en graf med målet som en linje, och grafen hänger på en skärm. Ett mätvärde berättar hur det gick. Ett avtal berättar vad som händer, och det är avtalet som gör budgeten till något: - **Finns budget kvar får teamet ta risk.** Driftsätta på fredag, köra migreringen, slå på flaggan för tio procent av användarna. Budgeten är ett tillstånd att göra sådant som ibland går fel, utan att be om lov varje gång. - **Är budgeten slut går stabilitet före nytt.** Inte som straff, utan som ett beslut som redan är fattat: nästa sprint går till det som [post-mortems](https://paperphyte.com/anteckningsbok/post-mortem-utan-syndabock) pekat på, tills budgeten återhämtat sig. Ingen behöver argumentera för det i stunden, för det stod i avtalet. - **Produktägaren skriver under.** Budgeten är den första siffran som drift och produkt äger tillsammans. Om det bara är driftteamet som satt målet är det en önskan från drift, och inbromsningen kommer aldrig att hända när det väl brinner i roadmapen. - **Kalendern slutar bestämma.** Frysperioder i december och releasefönster på torsdagar är sätt att hantera risk utan data. Med en budget bromsar ni när budgeten säger det och kör när den säger det, oavsett vilken dag det är. Resten av den tanken skrev vi om i [Deploy är inte release](https://paperphyte.com/anteckningsbok/deploy-ar-inte-release). - **Budgeten avgör vad ni bygger.** Med 43 minuter om månaden är en rollback som tar tjugo minuter nästan halva budgeten. En flagga som slår av på sekunder är nästan gratis. Vilken av dem ni bygger är ingen smaksak. Det är budgeten som bestämmer. ## Larma på budgeten, inte på servern Larmen är där budgeten möter natten. De flesta larm vi möter när vi kommer in i en ny miljö handlar om orsaker: CPU över 80 procent, disk över 90, en container som startat om. Varje sådant larm kan vara ett problem, och de flesta är det inte. Jouren lär sig att tystnad är det normala svaret på ett pip, och den natt kassan faktiskt ligger nere ser larmet ut som alla andra. Ett larm som ingen agerar på är inget larm. Det är ett brus som gömmer nästa riktiga. Alternativet är att larma på hur fort budgeten förbrukas, det som brukar kallas brinntakt. Brinntakt 1 betyder att ni gör av med exakt hela budgeten under fönstret, vilket är planen. Brinntakt 10 betyder att den är slut på tre dagar. Googles [SRE Workbook](https://sre.google/workbook/alerting-on-slos/) landar i tre larm som visat sig fungera för ett fönster på 30 dagar: - **Det som väcker jouren:** 2 procent av budgeten borta på en timme. Det är brinntakt 14,4, och i den takten är hela månadens budget slut på ett par dagar. - **Det som kan vänta till morgonen:** 5 procent av budgeten på sex timmar, brinntakt 6. - **Det som blir ett ärende:** 10 procent av budgeten på tre dagar, brinntakt 1. Något läcker, men det är inte akut. Varje larm mäts i två fönster samtidigt: ett långt, för att felet ska vara betydande, och ett kort på en tolftedel av det långa, för att larmet ska tystna när problemet gör det. Som regel i Prometheus ser det snabba larmet ut så här: **slo-alerts.yaml** ```yaml - alert: FelbudgetBrinnerFort expr: | ( sum(rate(http_requests_total{route="/kassa", code=~"5.."}[1h])) / sum(rate(http_requests_total{route="/kassa"}[1h])) ) > (14.4 * 0.001) and ( sum(rate(http_requests_total{route="/kassa", code=~"5.."}[5m])) / sum(rate(http_requests_total{route="/kassa"}[5m])) ) > (14.4 * 0.001) for: 2m labels: severity: page annotations: summary: "Kassans felbudget brinner 14 gånger för fort" ``` Tröskeln är brinntakten gånger felbudgeten: 14,4 gånger 0,001 betyder att mer än 1,44 procent av förfrågningarna misslyckas, både den senaste timmen och de senaste fem minuterna. Det första larmet ni tar bort när det här finns är CPU-larmet. Orsakerna hör hemma i era [observability](https://paperphyte.com/ordlista/observability)-verktyg, i en dashboard där den som blivit väckt letar efter dem. De ska inte väcka någon själva. ## Där det brukar gå sönder - **Målet sätts till det systemet råkar klara.** Förra kvartalet låg ni på 99,97 procent, så någon skriver 99,95 i dokumentet. Nu har ni lovat något ingen bad om, och budgeten är så liten att ingen vågar driftsätta. Ett SLO ska vara den lägsta nivå användarna är nöjda med, inte den högsta ni någonsin klarat. Allt däremellan är budget att leverera för. - **Indikatorn mäts på fel ställe.** Applikationen rapporterar hundra procent lyckade svar medan lastbalanseraren framför den svarar 502 till alla. Mät vid kanten, eller med en sond utifrån som gör det användaren gör. Det som räknas är det som syns från utsidan. - **Alla förfrågningar väger lika.** Hälsokontroller och statiska filer är nio tiondelar av trafiken och misslyckas aldrig, så indikatorn ser frisk ut medan kassan ligger. Räkna bort det som inte är användare, och ge det som kostar pengar en egen indikator. - **Budgeten tar slut och inget händer.** Det är testet. Om budgeten är förbrukad och roadmapen ser likadan ut nästa vecka har ni ett mätvärde, inte ett avtal. Gå tillbaka till produktägaren och börja om vid underskriften. - **Ett mål för hela systemet.** En siffra för allt döljer kassan bakom sökningen. Sätt få mål, ett per användarresa som betyder något, inte ett per mikrotjänst. Börja med ett: det som kostar pengar när det inte fungerar. - **Fönstret är kalendermånaden.** Den första varje månad nollställs budgeten och allt är grönt, hur illa den sista veckan än var. Använd ett rullande fönster. Fyra veckor, 28 dagar, ger dessutom lika många helger varje gång. - **Alla larm går till samma kanal.** Ett larm som väcker och ett ärende som väntar till morgonen är två olika saker. När båda hamnar i samma chattkanal lär sig alla att ignorera kanalen, och det är så de riktiga larmen blir ljudlösa. ## Så börjar du Det här kräver ingen [SRE](https://paperphyte.com/ordlista/site-reliability-engineering)-organisation. Det kräver en siffra, en underskrift och två larm: 1. Räkna om det ni redan lovat till minuter per månad. Finns det ingen som vet vad ni lovat vet ni vad som ska göras först. 2. Välj en användarresa, den som kostar pengar när den inte fungerar, och definiera en indikator för den i användarens termer: andel lyckade, andel snabba. Mät vid kanten. 3. Mät i fyra veckor utan att larma och utan att sätta något mål. Ni behöver veta var ni står innan ni bestämmer vart ni ska. 4. Sätt målet tillsammans med produktägaren: den lägsta nivå användarna är nöjda med. Skriv i samma dokument vad som händer när budgeten är slut. Den meningen är avtalet. 5. Inför två brinntaktslarm, ett snabbt som väcker och ett långsamt som skapar ett ärende. Ta sedan bort ett orsakslarm i veckan som budgetlarmen gjort överflödigt. 6. Visa återstående budget där teamet redan tittar, bredvid deployerna och flaggändringarna. Den som ska driftsätta en fredag ska kunna se om det finns råd. 7. Gå igenom målet varje kvartal med en fråga: förutsåg det när användarna var missnöjda? Om inte, flytta det. Två av [DORA-mätvärdena](https://paperphyte.com/ordlista/dora-matvarden), andelen misslyckade ändringar och [återställningstiden](https://paperphyte.com/ordlista/mttr), är i praktiken ett annat sätt att läsa samma budget: hur ofta ni tar av den och hur mycket varje gång kostar. Det är också därför felbudgeten är en av de första sakerna vi frågar efter i ett [DevOps-uppdrag](https://paperphyte.com/konsulttjanster/devops): inte hur många nior ni har, utan vad som händer när de tar slut. Svaret på den frågan säger mer om hur [SRE](https://paperphyte.com/ordlista/site-reliability-engineering) fungerar hos er än någon dashboard gör. ## Vårt korta svar > Ett tillförlitlighetsmål är ett avtal om hur mycket som får gå sönder. Räkna om niorna till minuter, mät det användaren ser, larma när budgeten brinner för fort och låt en förbrukad budget bestämma vad teamet gör härnäst. Då är siffran ett beslut, inte en dekoration. Niorna i avtalet lovade kunden något. Felbudgeten är hur ni håller det. --- Det här är Markdown-versionen av ett inlägg i [Paperphytes anteckningsbok](https://paperphyte.com/anteckningsbok). Originalet finns på . © Paperphyte AB. Ange källan med länk när du citerar eller sammanfattar texten. Frågor om innehållet? [Kontakta Paperphyte](https://paperphyte.com/kontakt).