# Vad är site reliability engineering? SRE för soloutvecklare URL: https://whatshouldibuildnext.com/sv/journal/vad-ar-site-reliability-engineering Type: blog Locale: sv Published: 2026-10-10 Updated: 2026-10-10 --- > SRE förklarat utan företagsjargong: SLI, SLO, felbudgetar och en kvällsuppsättning som en ensam byggare faktiskt hinner med. Vad är site reliability engineering? Det är praktiken att behandla drift som ett mjukvaruproblem. Du sätter ett mätbart tillförlitlighetsmål, räknar hur ofta du missar det och låter den siffran avgöra om du ska leverera nya funktioner eller laga det som går sönder. Google myntade begreppet, men idén fungerar i alla storlekar. För en ensam utvecklare med en app och några användare betyder det att bestämma i förväg hur mycket driftstopp du kan acceptera. Här är det som brukar fastna i praktiken: de flesta sidoprojekt har ingen sådan siffra. De är ”uppe” tills någon mailar dig. Den här guiden förklarar SRE med enkla ord och krymper sedan begreppet till något en person kan sköta under en helg. ## Vad är site reliability engineering egentligen? Den korta versionen kommer från [Googles SRE-bok](https://sre.google/sre-book/introduction/): SRE är vad man får när man frågar en mjukvaruingenjör hur ett driftteam borde se ut. I stället för att människor startar om servrar för hand skriver man kod som gör det, och man mäter resultatet. Tre idéer bär det mesta av vikten. Tillförlitlighet är en funktion med ett mål, inte en känsla. Repetitivt manuellt arbete (boken kallar det toil) är en bugg som ska automatiseras bort. Och fel väntas, så du planerar hur du lär dig av dem i stället för hur du undviker skuld. DevOps och SRE överlappar mycket. Den praktiska skillnaden: DevOps är en kultur där man bygger och kör kod tillsammans, medan SRE ger dig konkreta verktyg att diskutera det med hjälp av siffror. Man behöver inte välja läger för att använda siffrorna. ## SLI, SLO, SLA: tre förkortningar, en idé var En SLI (service level indicator) är något du mäter. För en webbapp är det oftast andelen förfrågningar som lyckas, eller andelen som svarar på under 300 ms. Välj en eller två. Inte tolv. En SLO (service level objective) är målet du sätter på det mätvärdet, till exempel ”99.9% av förfrågningarna lyckas under 30 dagar”. Den är intern. Det är ett löfte till dig själv. En SLA (service level agreement) är ett avtal med en kund, oftast med återbetalning om du missar det. Om ingen har betalat dig för upptid har du ingen SLA ännu, och du ska inte råka skriva en i pristexten på din sida. ![En stoppur bredvid en skissad cirkeldiagram-bild i en anteckningsbok, där största delen är nästan full, för att illustrera en liten felbudget](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-10/c3865f-i1.webp) ## Felbudgetar: delen som ändrar hur du jobbar Felbudgeten är helt enkelt 100 procent minus din SLO. Ett mål på 99.9% över 30 dagar lämnar cirka 43 minuters tillåtet fel. Det är budgeten du kan spendera på riskabla driftsättningar, migreringar och experiment. Den användbara biten är regeln som hör ihop med den. Så länge budget finns kvar levererar du. När den är slut slutar du leverera funktioner och fixar tillförlitligheten tills den återhämtar sig. [Kapitlet om risk i boken](https://sre.google/sre-book/embracing-risk/) beskriver det som ett sätt att avgöra striden mellan ”gå snabbare” och ”gå inte sönder” med en gemensam siffra i stället för en förhandling. Det finns också en rak poäng som är värd att upprepa: 100 procent är nästan aldrig rätt mål. Användare på ostabila mobilnät kan inte skilja 99.99% från 99.9%, och varje extra nia kostar mycket mer än den förra. Det är inget perfekt mål. Det är ett mål du faktiskt kan leva med. Om du vill ha det konkreta arbetsflödet för att välja indikatorer och skriva ditt första mål är [SRE-workbookens kapitel om att implementera SLO:er](https://sre.google/workbook/implementing-slos/) den mest praktiska delen, och den är kort. ## Vad gör en SRE egentligen under en vanlig dag? På ett stort företag delar en SRE tiden mellan jourtjänst, incidenthantering, kapacitetsplanering och automatiseringsarbete. Googles bok säger att det operativa arbetet bör begränsas till ungefär hälften av en ingenjörs tid, så att resten går till utveckling. Den gränsen är en designregel, inte en trevlig tanke. Det återkommande arbetet ser ut så här: - Att definiera SLO:er tillsammans med produktteamen och larma på budgetförbrukning i stället för på varje enskilt fel - Att köra jourrotationer och skriva runbooks, så att larmet klockan tre på natten har en checklista - Att leda incidenthanteringen och sedan skriva en postmortem utan skuldbeläggning - Att automatisera allt som gjorts för hand mer än några gånger - Att granska lanseringar för tillförlitlighetsrisker innan de når produktion Feature flags är ett bra exempel på tankesättet. En flagga låter dig stänga av en dålig release på några sekunder utan ny driftsättning, och det skyddar budgeten. Om du behöver ett hostat verktyg för det beror på hur många flaggor du har. En miljövariabel klarar de tre första. ## Behöver du SRE om du bygger ensam? Tre skäl att göra det, ett skäl att låta bli. Skälen att göra det: ditt projekt kommer förr eller senare att väcka dig själv. Ett skriftligt mål hindrar dig från att överkonstruera. Och ”jag kör produktion med en SLO” låter bra när någon avgör om de ska anställa dig eller lita på dig. Skälet att låta bli: om projektet inte har några användare ännu övar du på ett problem du inte har. Bygg först, mät när någon är beroende av det. Så hoppa över hela apparaten. Betala inte för en larmtjänst till en hobbyapp, kör inte Kubernetes för att det ska kännas seriöst och skriv inte en incidentmall på tio sidor. Det är värt att göra om du har ens tio riktiga användare: en hälsokontroll, en SLO och en plats att titta på när något går sönder. ![En liten serverrack med gröna statuslampor och en enda gul lampa](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-10/f60c6c-i2.webp) ## En SRE-uppsättning för ett sidoprojekt på en kväll Här är miniminivån som brukar hålla även när det blir 10 000 användare. Det tar en kväll. Testat. Inte optimalt. Varför vi gör det ändå: det är tråkigt, och tråkigt överlever. Först väljer du en SLI: andelen HTTP-förfrågningar som inte returnerar ett 5xx-svar. För det andra sätter du SLO:n till 99.5% över 30 dagar, vilket är ungefär 3.6 timmars budget. Börja löst och skärp målet senare. För det tredje lägger du till en extern uptime-kontroll som anropar en riktig hälsoendpoint. En hälsoendpoint som är värd namnet kontrollerar sådant som faktiskt går sönder, inte bara att processen lever: `// GET /healthz app.get("/healthz", async (req, res) => { try { await db.query("select 1"); // databasen går att nå await cache.ping(); // cachen går att nå res.status(200).json({ ok: true }); } catch (err) { res.status(503).json({ ok: false }); } });`För det fjärde skickar du larmen dit du faktiskt ser dem, till en push i telefonen hellre än till en inkorg. För det femte för du en vanlig textfil som heter `postmortems.md` och lägger till fyra rader efter varje driftstopp: vad som hände, varför, hur länge och vad som ändras. Den filen är det mest underskattade tillförlitlighetsverktyget du kommer att äga. ## Var AI-verktyg hjälper och var de inte gör det Assistenter är hyfsade på det repetitiva: att skriva hälsokontrollen, Terraform-koden för en uptime-övervakning, ett första utkast till en runbook eller ett skript som räknar ut 5xx-andelen i loggarna. De är dåliga på att bestämma din SLO, eftersom det är ett produktbeslut om vad dina användare tål. Under en incident ska du vara försiktig. En assistent kan föreslå en rimlig fix som du sedan tillämpar i produktion klockan två på natten utan att läsa den. Använd den för att förklara en stacktrace eller för att skriva utkastet till postmortemen i efterhand, och låt beslutet om rollback ligga hos en människa som är vaken. Kvalitetsgrindar i CI hör också hemma i bilden. Många driftstopp går tillbaka till en ändring som såg ofarlig ut vid granskningen. Statisk analys i CI ger inte tillförlitlighet i sig, men den tar bort en klass dumma misstag innan de kostar budget. ## Hur skriver man en postmortem som någon faktiskt läser? Håll den kort och utan skuldbeläggning. Utan skuldbeläggning betyder inte att ingen har ansvar. Det betyder att man frågar vad i systemet som tillät misstaget, inte vem som gjorde det. När du är ensam i teamet väger det tyngre än det låter, eftersom frestelsen är att må dåligt och hoppa över sammanfattningen. Fyra rubriker räcker: vad som hände, varför det hände, hur länge användarna påverkades och vad som ändras. Den sista ska namnge en åtgärd du verkligen tänker göra, med ett datum. ”Var mer försiktig” är inte en åtgärd. ”Lägg till en kontroll i staging för migreringar före nästa release” är det. Över ett år blir filen en karta över dina svagheter. Regeln efter tre driftstopp orsakade av samma utgångna certifikat blev: om samma orsak dyker upp två gånger, automatisera den. Det tog en kväll att lägga till övervakning för förnyelsen, och det har inte hänt igen. ## Larma på budgetförbrukning, inte på varje enskilt fel Ett vanligt nybörjarmisstag är att väcka sig själv varje gång en enda förfrågan misslyckas. Du stänger av kanalen inom en vecka. En bättre signal är burn rate: hur snabbt du förbrukar felbudgeten jämfört med takten som skulle tömma den exakt vid periodens slut. För ett sidoprojekt håller du det enkelt. Skicka en pushnotis om felfrekvensen under de senaste 10 minuterna ligger över 5 procent, och en sammanfattning per mail om den veckovisa frekvensen är på väg att missa SLO:n. Det ger två nivåer: vakna nu, eller titta på måndag. Allt mer avancerat kan vänta tills användarna klagar på den första nivån. ## Är SRE en bra karriärväg för en utvecklare som gillar att bygga? Det beror på vad du tycker om. SRE-roller passar folk som gillar system, felmoder och automatisering mer än att leverera UI. Om du blir glad av att göra jouren tystare kommer du att trivas. Om du vill se användare klicka på din nya funktion gör du det troligen inte. Vägen in går oftast via backend- eller infrastrukturarbete: du börjar äga en tjänsts driftsättningar och larm och tar sedan över mer av dess tillförlitlighet. Kunskaper som följer med: grunderna i Linux, nätverk, en molnleverantör, en övervakningsstack och vanan att skriva ner saker. Sidoprojekt är en bra plats att bygga alla dessa, eftersom du är hela teamet. ![En utvecklare i soffan på natten med en laptop och en lysande telefon, på jour](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-10/97ad3a-i3.webp) ## Vad ska du bygga härnäst? Välj något du redan kör, även en gratisapp, och skriv ner dess SLI, SLO och exakt vilken åtgärd du tar när budgeten tar slut. Om du inte kan säga vad du skulle sluta göra är siffran bara dekoration. Vilket av dina projekt skulle du märka var nere innan en användare berättade det för dig? ## FAQ ### Vad är site reliability engineering på enkel svenska? Det är att använda mjukvaruingenjörens metoder för att driva system. Du sätter ett mätbart tillförlitlighetsmål, följer upp det och använder avvikelsen för att avgöra om du ska leverera funktioner eller laga problem. ### Vad är skillnaden mellan SRE och DevOps? DevOps är en kultur där man bygger och kör mjukvara tillsammans. SRE är ett konkret sätt att göra det, med SLO:er, felbudgetar och gränser för manuellt arbete, så att beslut vilar på siffror. ### Vad är en felbudget? Den är 100 procent minus din SLO. Ett mål på 99.9% över 30 dagar lämnar ungefär 43 minuters tillåtet fel, som du kan spendera på riskabla driftsättningar och experiment. ### Behöver ett sidoprojekt en SLO? Inte förrän någon är beroende av det. När du har några riktiga användare är en hälsokontroll, en SLO och en larmkanal en rimlig start. ### Vilken SLO bör en ensam utvecklare börja med? Börja med 99.5% över 30 dagar på andelen förfrågningar som inte ger 5xx-fel. Den är medvetet lös, och du kan skärpa den när du vet vad som faktiskt går sönder. ### Kan AI-verktyg sköta incidenter åt mig? Nej. De kan förklara en stacktrace och skriva ett utkast till postmortemen, men beslutet om rollback bör fattas av en människa som är vaken.