Fejlbudget for solo-devs – sådan styrer du bugs og stabilitet

Du har allerede et fejlbudget, du har bare ikke sat tallene

De fleste solo-devs har et fejlbudget uden at kalde det det. Det lyder cirka sådan her inde i hovedet: “Hvis appen crasher igen i aften, gider jeg ikke det her projekt mere” eller “hvis brugerne mister data, så må jeg stoppe med at lege og tage det seriøst”.

Det er et fejlbudget. Bare uklart, utrygt og helt umuligt at bruge til at træffe beslutninger.

Et fejlbudget er i virkeligheden bare en aftale med dig selv om hvor meget rod, nedetid og fejl du accepterer i en periode, før du siger: nu stopper jeg med nye features og fokuserer kun på at få det her til at holde op med at brænde.

I SRE-verdenen (Site Reliability Engineering) bruger man fine ord som SLO (Service Level Objective) og SLA. Du behøver ikke alle termerne, men du kan låne strukturen. Ideen er:

Du vælger nogle få mål for hvor “stabil” din app skal opleves. Så regner du baglæns og siger: hvor meget ustabilitet må jeg have, før jeg tager en pause fra nye ting?

Som solo-dev er pointen ikke at imponere Google SRE-teamet. Pointen er at have en simpel regel, så du ikke hver uge står og tænker: “skal jeg fikse alle de her bugs, eller må jeg godt lige bygge den nye fede feature?”.

To tal der gør dit liv meget nemmere

Jeg vil foreslå at du starter helt simpelt: vælg maks to SLO’er. Flere end det, og du laver bare et Excel-ark ingen gider åbne.

For en lille webapp giver det ofte mening med:

1. Oppetid (eller fejlrate set fra brugerens side)

Det er: hvor stor en del af tiden kan brugerne faktisk bruge appen, uden at få 5xx-fejl eller hvide sider.

Du behøver ikke et dyrt monitoring-setup for at komme i gang. Du kan fx:

Logge antallet af 5xx-responser per dag
Bruge en simpel uptime-checker (fx et gratis ping hver minut)

Hvis du vil køre helt low-tech, kan du starte med at tælle “antal gange nogen skriver til dig fordi siden er nede” per uge. Det er ikke super præcist, men overraskende nyttigt.

2. Kritiske fejl i flows der betyder noget

Alle apps har et eller to “hellige” flows. Det kan være:

“Opret konto”
“Gem projekt”
“Betal” (hvis du er så langt)

Her kan du måle: hvor mange forsøg fejler i de flows?

Hvis du har analytics eller events, kan du tracke det direkte. Hvis du ikke har, kan du starte manuelt: hver gang du opdager en bug i et kritisk flow, skriver du det ned i et lille dokument med dato.

Det lyder primitivt. Men et simpelt “fejllog-notat” slår 0 data hver gang. Og du kan senere smide tallene i et ark, når du gider.

Hvordan måler du uden at bygge et helt overvågningssystem?

Jeg går efter det mindste, jeg kan slippe afsted med. Det kunne fx være:

Oppetid light: Opret en gratis uptime-monitor der pinger din side hvert minut. De fleste giver dig et procenttal for oppetid per uge/måned. Det er dit SLO-tal.

Fejlrate light: I din backend kan du logge alle 5xx-fejl til en simpel fil eller konsol, og så have en lille counter pr dag. Hvis du er klar til at gå et skridt op, kan du tage et værktøj som Sentry i brug, men det er ikke et krav fra dag 1. En håndfuld projekter har det bedre uden flere dashboards.

For mange små projekter er det faktisk nok at sige: “Mit SLO er: Maks 3 kritiske fejl i nøgleflows per uge”. Og så holde øje med det i en note.

Sådan sætter du et fejlbudget du faktisk kan leve med

Nu kommer pointen: et fejlbudget er bare den del af dit SLO, du accepterer at “brænde”.

Eksempel: Du siger at din lille app skal have 99 % oppetid over en måned. Det betyder at du må have 1 % nedetid. Hvis du oversætter det til minutter, er det cirka 7 timer nedetid på en måned. Det er dit budget. Når du har brugt det, er der ingen flere “sjove” deploys med halvfærdige features, før stabiliteten er tilbage på sporet.

Hvis du ikke gider sidde og regne med procenter, kan du gøre det endnu simplere:

Regel for hobbyapp med få brugere:
“Jeg accepterer højst 2 større nedbrud per måned, hvor appen er reelt ubrugelig i mere end 10 minutter”.

Regel for lille sideprojekt med rigtige brugere:
“Jeg accepterer højst 1 kritisk bug i et nøgleflow per uge, som rammer en bruger”.

Et fejlbudget i den model er bare: hvor mange nedbrud / bugs har du “råd” til i perioden, før du lover dig selv at stoppe feature-arbejdet.

Her er en simpel formel:

Fejlbudget per måned = Antal kritiske fejl du kan acceptere, før du går i “kun-fiks” mode.

For en lille app kan det f.eks. være: “Mit fejlbudget er 4 kritiske fejl i måneden”. Rammer du nummer 5, så er resten af måneden reserveret til at reparere, rydde op og forbedre tests.

Beslutningsreglen: hvornår stopper du med features?

Nu mangler du kun den del, der gør forskellen på “nice idé” og noget, du faktisk bruger: en konkret beslutningsregel.

Jeg plejer at formulere den som en enkelt sætning, som jeg kan skrive øverst i mit projekt-board. For eksempel:

“Hvis jeg bruger mere end halvdelen af mit fejlbudget inden midten af måneden, sætter jeg alle nye features på pause og bruger næste sprint/uge på stabilitet.”

Det er grimt effektivt. For pludselig er det ikke længere et spørgsmål om humør. Det er matematik. Lidt løs matematik, men stadig.

Du kan også lave en ugeregel, hvis du arbejder i små hop:

“Hvis der kommer 3 eller flere kritiske bugs i løbet af en uge, dropper jeg alt nyt i næste uge og rydder op.”

Det vigtige er, at du beslutter det, før du står i kaosset. For når siden er nede, og nogen skriver til dig på Instagram kl. 22.37, så er det meget svært at tage rolige, langsigtede valg.

Her giver et fejlbudget dig noget overraskende rart: tilladelse til ikke at reagere overdrevet på den ene fejl, der måske bare var en edge case. Og modsat: et lille skub i ryggen, når du ellers var ved at ignorere, at det hele er ved at vippe.

En incident-note på 10 minutter

Der er én ting, der gør et fejlbudget langt stærkere: du skriver kort ned, når det går galt.

Det behøver ikke være en corporate “post-mortem”. For solo-devs kan en incident-note ligge i en enkelt fil i repoet, i en Notion-side eller i et Google Docs. Pointen er, at du kan se tilbage på hvad der faktisk skete, når du rammer dit budget.

Jeg bruger en mini-skabelon, inspireret af blandt andet Martins Fowler om incident reviews:

Incident-note, 5 punkter:

Hvornår: Dato og cirka tidspunkt
Hvad så brugeren: Fx “hvid skærm når man trykker gem”
Årsag: Hvad var den tekniske fejl? (så konkret som du orker)
Fix: Hvad gjorde du for at løse det nu?
Læring: Hvad gør du anderledes, så det er mindre sandsynligt igen?

Det sidste punkt er det vigtigste. Ikke fordi du skal love aldrig at lave fejl igen, men fordi du kan koble det direkte til dine næste opgaver.

Hvis du vil have mere struktur på hele det her drift-område, kan du senere koble det sammen med for eksempel en lille monitoring-plan som den jeg skitserer i artiklen om logs og metrics, men du behøver ikke starte der.

En uge med 3 fejl: sådan ændrer planen sig

Lad os tage et konkret eksempel, fordi alt lyder fint, indtil der er virkelige mennesker involveret.

Sig du har en lille app hvor folk kan gemme deres læste bøger. Du har sat dit fejlbudget til 3 kritiske fejl per uge. En kritisk fejl er defineret som: “brugeren kan ikke logge ind, gemme en bog eller se sin liste”.

Mandag:
Du deployer en ny feature: tags på bøger. Alt ser fint ud lokalt. I produktion viser det sig, at brugere uden nogen bøger får en server-fejl på deres liste-side. Du får en besked fra en ven, der tester. Du retter det samme aften. Du skriver en kort incident-note. Fejlbudget: 1/3 brugt.

Onsdag:
Du laver en lille ændring i login-flowet for at forberede social login. I en time efter deploy kan ingen med gammel cookie logge ind. De får bare en ulogisk fejl. Du opdager det i logs og ruller tilbage. Fejlbudget: 2/3 brugt.

Fredag:
Du vil egentlig bare lave en lille UI-ændring. En CSS-ting. Men du kommer til at bygge frontend med forkerte miljøvariabler, så API-URL’en peger et forkert sted hen. I 15 minutter loader appen ikke data.

Så står du der. Fejlbudget: 3/3. Din egen regel siger: “Rammes 3 kritiske fejl i en uge, så droppes nye features i næste uge”.

Det føles surt i øjeblikket, især hvis du lige havde en sjov idé på vej. Men i næste uge er dine opgaver pludselig krystalklare:

Få automatiske tests på de vigtigste flows (login, liste, gem bog)
Rydde op i build-processen, så env-variabler er mindre skrøbelige (evt. med inspiration fra artiklen om miljøvariabler)
Tilføje en simpel health-check, der kan fortælle dig, når appen ikke kan nå sit API

Efter sådan en uge er du måske lidt træt af at høre om stabilitet. Men ugen efter det, når du igen bygger features, gør du det oven på noget, der er lidt mindre porøst.

Det er pointen. Fejlbudgettet styrer hvornår du må “lege” og hvornår du er nødt til at være den kedelige voksen i rummet. Selv når rummet bare er din stue og katten ligger på tastaturet.

Kobl fejlbudgettet til dine deploys

En sidste ting, der gør det her endnu mere brugbart: lad fejlbudgettet påvirke hvordan du releaser.

Hvis du ofte nærmer dig eller rammer dit fejlbudget, kan du beslutte:

At alle større ændringer først rulles ud bag et feature flag, så du kan slå dem fra uden at rulle kode tilbage
At du altid deployer tidligt på dagen, ikke kl. 23.45 lige inden du skal sove
At hver release har et lille notat: “Hvad er det værste, der kan gå galt her?” og evt. hvordan du opdager det hurtigt

Du kan faktisk lade dit fejlbudget være en slider for hvor “aggressiv” du tør være:

Når du har brugt meget lidt af dit budget i en periode, kan du godt tage lidt større chancer. Når du ligger og balancerer på kanten, går du mere forsigtigt frem og holder nye features bag flag.

Hvis du på et tidspunkt vil sætte CI/CD op, som i vores artikel om GitHub Actions, kan du også bygge små checks ind der: blokér deploys til produktion, hvis antal åbne kritiske bugs overstiger dit fejlbudget.

Det lyder stort, men i den mindste version er det bare dig, der kigger på din lille fejl-log før du trykker “deploy” og tænker: “Har jeg egentlig mere plads i budgettet til at risikere en fejl mere i denne uge?”.

Hvis du kun gør én ting anderledes efter det her

Så lav en lille note til dig selv for dit vigtigste projekt:

“Mit fejlbudget er X kritiske fejl per uge/måned. Hvis jeg rammer X, stopper jeg med nye features og bruger næste uge på at gøre det sværere for de samme fejl at ske igen.”

Du kan fint starte med X = 3 og justere senere. Det vigtige er ikke det perfekte tal. Det vigtige er at du ikke længere gætter på, hvornår du skal skifte fra “bygge nyt” til “holde det i live”.

Resten kan du bygge ovenpå stille og roligt, ligesom alt andet kode.

Hvordan vælger jeg konkrete tal for mit fejlbudget - fx hvilke procentsatser eller hvor mange fejl er acceptable?

Start med en simpel regel-of-thumb: for hobbyprojekter er 99% til 99,9% oppetid ofte rimeligt (99% svarer til ~7 timer nedetid om måneden, 99,9% til ~43 minutter). For kritiske flows sæt et tangibelt loft, fx højst 0-2 fejl i et vigtigt flow per måned. Vælg tal ud fra hvor hurtig genoprettelse brugerne forventer og din egen tilbøjelighed til at prioritere fejlfinding frem for nye features.

Hvad gør jeg konkret, når jeg har brugt mit fejlbudget op?

Stop nye features midlertidigt og lav en kort prioriteret triage: identificer root cause, lav en hurtig hotfix for højeste impact, deploy og test. Efterfølgende skriv en kort postmortem med årsag, løsning og forebyggelse, og brug den til at justere SLO eller arbejdsgange.

Hvilken periode skal mit fejlbudget måles over - uge eller måned?

Brug uge hvis du vil have hurtig feedback og opdage trendbrud tidligt; brug måned hvis du vil udjævne korte spikes og få et mere stabilt billede. Match perioden til din release- og arbejdsrytme - deployer du sjældent, er måned ofte bedre; deployer du ofte, kan uge være mere handlingsrettet.

Skal tredjepartsudfald tælle mod mit fejlbudget?

Det giver mening at spore dem separat: registrer brugerimpact fra tredjepart som en brugeroplevelsesfejl, men noter root cause som ekstern. Hvis tredjeparten ofte rammer dit SLO, overvej redundans, fallback eller at inkludere deres tilgængelighed i dit budget - ellers risikerer du konstant at blive tvunget til at rette eksterne problemer.