SRE light: SLO:er, error budgets och on-call för små team

SRE har blivit ett ord som skrämmer små team. Det förknippas med Google, med tjocka böcker och med en organisation som har råd med ett helt team som bara värnar tillförlitlighet. Men kärnan i SRE är några få idéer som fungerar lika bra för fem personer som för fyra hundra. Det jag kallar SRE light är den delmängd jag tar med mig, och lämnar resten på hyllan tills teamet faktiskt behöver den.

Börja med vad användaren faktiskt märker

Den första missuppfattningen är att tillförlitlighet handlar om servrar. Det gör det inte. Det handlar om vad användaren upplever. Därför börjar jag aldrig med infrastrukturmått som CPU eller minne, utan med ett par service level indicators, alltså mätbara signaler på det användaren bryr sig om. För en webbtjänst är det oftast två saker: hur stor andel av förfrågningarna som lyckas, och hur snabbt de svarar.

Poängen med att utgå från användaren är att det skär bort larm som inte spelar någon roll. En server kan vara på nittio procents CPU och användaren märker ingenting. Då är det inte en incident, det är en kapacitetsanteckning. Genom att mäta upplevelsen larmar du om rätt saker.

SLO är ett beslut, inte en mätning

När du har dina indicators sätter du service level objectives, mål för hur bra de ska vara. Och här är insikten som förändrar allt: hundra procent är fel mål. Att jaga hundra procent tillförlitlighet är oändligt dyrt och, viktigare, det är onödigt eftersom användaren ändå inte märker skillnaden mellan 99,9 och 100 procent. Ett SLO är ett medvetet beslut om hur mycket otillförlitlighet du har råd med.

Det betyder att ett SLO är en affärsfråga lika mycket som en teknisk. 99,9 procent låter strängt men tillåter nästan nio timmars nedtid per år. 99,99 procent låter bara lite bättre men är tio gånger dyrare att uppnå. Jag sätter SLO tillsammans med den som äger produkten, inte bara med utvecklarna, eftersom det är en avvägning mellan kostnad och risk.

Error budgets gör avvägningen synlig

Om ditt SLO är 99,9 procent betyder det att du har råd med 0,1 procent fel. Den marginalen är din error budget, och den är det smartaste verktyget i hela SRE-tänket. Så länge du har budget kvar kan du släppa nya funktioner i hög takt, eftersom du har utrymme för risk. När budgeten är slut är det en signal att sakta ner på nya funktioner och lägga kraft på stabilitet i stället.

Det fina med en error budget är att den ersätter ändlösa diskussioner om hastighet kontra stabilitet med ett tal som alla kan se. I stället för att tycka olika om huruvida vi släpper för snabbt, tittar vi på budgeten. Den objektiviserar en konflikt som annars blir personlig.

On-call som människor orkar med

Här gör många små team mest skada mot sig själva. De sätter alla i en konstant beredskap utan struktur, och efter ett halvår är de bästa personerna utbrända. SRE light handlar minst lika mycket om människor som om teknik. Min utgångspunkt är att on-call ska vara hanterbart, ersatt och sällan störande.

• Larma bara på det som kräver en människa nu. Allt annat blir ett ärende på morgonen, inte ett pip klockan tre.
• Rotera och håll skiften korta. En vecka åt gången är oftast rimligt, och ingen ska ha beredskap varannan vecka i evighet.
• Ersätt beredskap. Att vara bunden vid telefonen på kvällen är arbete och ska behandlas som arbete.

Och varje larm som visar sig vara brus ska behandlas som en bugg i larmsystemet. Ett team som blir väckt av falsklarm slutar lita på larmen, och då missar de det verkliga.

Blameless postmortems bygger lärande

När något ändå går fel är det lätt att leta efter någon att skylla på. Det är mänskligt men kontraproduktivt. En blameless postmortem utgår från att människor handlade rimligt utifrån vad de visste och såg, och frågar i stället varför systemet tillät felet att ske och nå så långt. Fokus flyttas från person till system, och då vågar folk berätta vad som faktiskt hände, vilket är förutsättningen för att lära.

Det här lämnar jag åt sidan

SRE light betyder också att veta vad man inte ska göra ännu. Jag väntar med tunga felbudgetpolicyer på organisationsnivå, med dedikerade SRE-roller och med avancerad kaosteknik tills teamet har grunderna på plats och faktiskt känner ett behov. Att kopiera en stor organisations hela modell till ett litet team skapar mest ceremoni och lite värde. Hur jag väver in tillförlitlighet i en samlad plattform beskriver jag i min tjänst för DevOps-plattform.

Relaterat

• Observability-stack 2026: OpenTelemetry + Grafana + Tempo + Loki
• Incident response runbooks: Mallar och automatisering med PagerDuty
• Helm charts för nybörjare: Pakethantering och templating i Kubernetes

Vill du se hur tillförlitlighetsarbete sett ut i praktiken finns exempel i min casebook.

Vill du ta det vidare?

Om ditt team larmas för ofta eller saknar mål för tillförlitlighet hjälper jag er att sätta SLO och en human on-call. Hör av dig via kontaktsidan.