Hoppa till innehåll
DevOps & PlattformSREMognadsanalysOn-call12 min läsning

SRE för 5-personers team: Error budgets, SLO:er och on-call light

Hur ett team på fem personer kan ta tillförlitlighet på allvar utan att kopiera en stor organisations apparat. En praktisk spelbok från verkliga uppdrag.

00
SRE för 5-personers team: Error budgets, SLO:er och on-call light
Tillförlitlighet i ett litet team handlar lika mycket om människor som om mätvärden.Photo: Unsplash

SRE i litet team. Praktisk guide till error budgets och on-call.

Det finns en föreställning om att SRE är något bara stora bolag har råd med. Men ett team på fem personer behöver tillförlitlighet precis som ett på fem hundra, de behöver bara en annan dosering. Den här texten är en konkret spelbok för hur jag inför SRE-tänk i ett litet team utan att tynga ner det med ceremoni det inte har nytta av. Den kompletterar min mer principiella genomgång av SRE light med praktiska steg.

Det första steget: gör tillförlitlighet mätbar

Innan ett team kan styra tillförlitlighet måste det kunna se den. Det låter självklart men förvånansvärt få små team mäter det användaren faktiskt upplever. Jag börjar därför med att sätta ett par enkla mått: andelen lyckade förfrågningar och svarstiden för det viktigaste flödet. Det räcker för att gå från magkänsla till siffror.

Poängen är att börja smått. Du behöver inte instrumentera allt på en gång. Ett enda väl valt mått på ert mest kritiska flöde är mer värt än tjugo mått som ingen tittar på. När det första måttet är på plats och ger värde är det lätt att lägga till fler.

Sätt ett SLO ni faktiskt kan stå för

Med mått på plats sätter ni ett mål. Här är den vanligaste fällan att sikta för högt. Ett litet team som lovar sig själva 99,99 procent kommer att bryta löftet och sluta bry sig om det. Sätt ett SLO som är ambitiöst men realistiskt för er bemanning, ofta är 99,9 procent en bra start, och skärp det över tid när ni har marginal.

Det viktiga är att SLO:n är ett gemensamt beslut, inte något en ensam utvecklare hittar på. När hela teamet, och gärna den som äger produkten, står bakom målet blir det ett verktyg för prioritering snarare än en siffra i ett dokument.

Error budgets gör prioritering enkel

När SLO:n finns har ni automatiskt en error budget, marginalen mellan målet och hundra procent. För ett litet team är detta särskilt värdefullt, eftersom det avgör den eviga dragkampen mellan att bygga nytt och att stabilisera. Har ni budget kvar, bygg på. Är den slut, lägg ett par dagar på stabilitet. Beslutet blir mekaniskt i stället för en diskussion där den som tjatar mest vinner.

Det fina är att en error budget är ärlig mot verkligheten. Ett litet team kan inte göra allt, och budgeten tvingar fram en prioritering som annars hade skjutits upp tills något gick sönder.

On-call light: var snäll mot ert framtida jag

Det här är där ett litet team kan göra mest skada mot sig själva. Med få personer blir varje on-call-skift tungt, och utan struktur leder det rakt till utbrändhet. Min modell för ett litet team vilar på några principer.

  • Larma bara på det som kräver handling nu. Med få personer har ni inte råd att väckas i onödan.
  • Korta, roterande skift. Sprid bördan jämnt så att ingen bär den oproportionerligt.
  • Ersätt beredskapen. Att vara tillgänglig på kvällen är arbete, inte en gratis förväntan.
  • Sänk larmtröskeln för brus. Varje falsklarm som väcker någon är en bugg att rätta omgående.

För ett team av den här storleken är det också rimligt att fråga om ni ens behöver dygnet runt-beredskap. Ibland räcker det att larm fångas under arbetstid och att ni accepterar en något lägre ambition nattetid. Det är ett medvetet val som er error budget kan hjälpa er fatta.

Lär av incidenter utan att skuldbelägga

När något går fel i ett litet team är det extra lätt att det blir personligt, för alla känner alla. Just därför är en blameless hållning viktig. Fokusera på vad i systemet som lät felet ske, inte på vem som tryckte på knappen. Ett kort, ärligt eftersnack där ni noterar vad ni lär er räcker långt, och det bygger en kultur där folk vågar berätta vad som faktiskt hände.

Hur jag väver in tillförlitlighet, larm och deploy i en samlad plattform beskriver jag i min tjänst för DevOps-plattform.

Relaterat

Vill du se hur tillförlitlighetsarbete sett ut i ett skarpt uppdrag finns exempel i min casebook.

Vill du ta det vidare?

Om ert lilla team larmas för ofta eller saknar mål för tillförlitlighet hjälper jag er att sätta en lagom dos SRE. Du kan testa min mognadsanalys först, eller höra av dig via kontaktsidan.

Ett litet team kan inte göra allt, och error budgeten tvingar fram en prioritering som annars skjuts upp tills något går sönder.

- Simon Axelsson

Vanliga frågor

Behöver ett team på fem personer dygnet runt-beredskap?
Inte nödvändigtvis. Det är ett medvetet val. Ibland räcker det att larm fångas under arbetstid och att ni accepterar en något lägre ambition nattetid, vilket er error budget kan hjälpa er väga.
Hur många SLO:er ska vi börja med?
En. Välj ert mest kritiska flöde och sätt en SLO där. Det är mer värt än en handfull mål som ingen följer upp. Lägg till fler först när det första ger värde.
Hur undviker vi att on-call sliter ut oss?
Larma bara på det som kräver omedelbar handling, rotera korta skift jämnt, ersätt beredskapen och åtgärda varje falsklarm direkt. Med få personer är disciplin kring larm avgörande.
Simon Axelsson
Simon AxelssonIT-konsult & teknisk rådgivare

Simon Axelsson är senior IT-konsult och grundare av SIAX Technology AB. Han hjälper nordiska företag med molninfrastruktur, dataplattformar och AI-automation.

Fler artiklar