Quick Answer
Site Reliability Engineering (SRE) är en disciplin som tillämpar mjukvarutekniska principer och praxis på operativ drift för att leverera skalbara, mycket tillförlitliga programvarusystem. Disciplinen uppstod hos Google i början av 2000-talet — när företaget upptäckte att traditionell driftsorganisation inte skalade med den växande infrastrukturen — och har spridit sig till nästan alla större teknikföretag, inklusive svenska industriledare som Spotify, Klarna, King och iZettle. Den centrala insikten i SRE: drift är ett mjukvaruproblem, inte ett människoproblem. Den här guiden förklarar vad SRE faktiskt innebär i praktiken, de centrala principerna (SLI, SLO, felbudget, toil-reduktion), hur svenska företag bygger SRE-team, vad rollen kostar att rekrytera och alternativ för företag som behöver SRE-kompetens utan att rekrytera helt internt. Vad är SRE och varför uppstod det? SRE uppstod när Google insåg att traditionell IT-drift hade ett strukturellt problem: ju mer infrastrukturen växte, desto mer behövde drifteam anställa — i en linjär eller superlinjär takt.
Site Reliability Engineering (SRE) är en disciplin som tillämpar mjukvarutekniska principer och praxis på operativ drift för att leverera skalbara, mycket tillförlitliga programvarusystem. Disciplinen uppstod hos Google i början av 2000-talet — när företaget upptäckte att traditionell driftsorganisation inte skalade med den växande infrastrukturen — och har spridit sig till nästan alla större teknikföretag, inklusive svenska industriledare som Spotify, Klarna, King och iZettle. Den centrala insikten i SRE: drift är ett mjukvaruproblem, inte ett människoproblem.
Den här guiden förklarar vad SRE faktiskt innebär i praktiken, de centrala principerna (SLI, SLO, felbudget, toil-reduktion), hur svenska företag bygger SRE-team, vad rollen kostar att rekrytera och alternativ för företag som behöver SRE-kompetens utan att rekrytera helt internt.
Vad är SRE och varför uppstod det?
SRE uppstod när Google insåg att traditionell IT-drift hade ett strukturellt problem: ju mer infrastrukturen växte, desto mer behövde drifteam anställa — i en linjär eller superlinjär takt. Tillvägagångssättet var inte skalbart för en organisation som ville bygga internet-skala-system.
SRE:s svar: anställ mjukvaruingenjörer som löser driftproblem med kod. Automatisera repetitiva uppgifter ("toil"). Etablera mätbara mål för tillförlitlighet och tillgänglighet ("SLO"). Använd en kvantifierbar "felbudget" som styr balansen mellan att leverera nya funktioner och att underhålla stabilitet. Behandla varje incident som en möjlighet att förbättra automatiseringen.
Resultatet: en organisation där drifttea växer mycket långsammare än infrastrukturen, där människor frigörs från repetitiva uppgifter, och där tillförlitligheten kontinuerligt mäts och förbättras systematiskt.
De centrala SRE-koncepten
| Begrepp | Vad det är | Praktiskt exempel |
|---|---|---|
| SLI (Service Level Indicator) | Mätbar parameter för tjänstens prestanda | Andel framgångsrika HTTP-svar; 95:e percentilen av responstid |
| SLO (Service Level Objective) | Mål för SLI, vad som anses "tillräckligt bra" | 99,9% framgångsrika svar per månad; p95-latency under 200ms |
| SLA (Service Level Agreement) | Kontraktuell utfästelse till kund, oftast lägre än SLO | 99,5% månadsuppetid med kreditkomp om underskridet |
| Felbudget | Det utrymme att "misslyckas" som SLO tillåter | 99,9% SLO ger 43 minuters felbudget per månad |
| Toil | Repetitivt manuellt arbete som inte tillför varaktigt värde | Manuell skalning, manuell incident response, manuell rollback |
| Blameless postmortem | Incident-utredning som fokuserar på system, inte individer | "Vad i vårt system tillät detta fel?" inte "Vem orsakade felet?" |
Behöver ni hjälp med cloud?
Boka ett kostnadsfritt 30-minuters möte med en av våra specialister inom cloud. Vi analyserar ert behov och ger konkreta rekommendationer — helt utan förpliktelse.
Hur skiljer sig SRE från DevOps?
DevOps och SRE är besläktade men inte synonymer. DevOps är ett bredare kulturellt och organisatoriskt rörelse som handlar om samarbete mellan utvecklare och drift. SRE är en specifik implementering av DevOps-principer med mätbara mål och tydliga rolldefinitioner.
| Aspekt | DevOps | SRE |
|---|---|---|
| Vad det är | Kulturell rörelse och uppsättning praktiker | Specifik implementering med mätbara mål |
| Mätbarhet | Generella principer (CALMS, Three Ways) | Konkreta SLI, SLO, felbudgetar |
| Rolldefinition | Brett begrepp, många olika titlar | "SRE" är en specifik roll och titel |
| Bakgrund | Uppstod ur Agile och Lean-rörelserna | Uppstod konkret hos Google |
| Verktyg | CI/CD, containerisering, IaC, monitoring | Samma + felbudgetuppföljning, postmortems, automatisering av toil |
I praktiken kompletterar SRE och DevOps varandra. De flesta moderna svenska tekniksorganisationer praktiserar DevOps-principer brett, och har dedikerade SRE-team eller SRE-roller för att operationalisera tillförlitlighetsmål för affärskritiska tjänster.
Vad gör en SRE i praktiken?
En typisk vecka för en SRE kan omfatta:
- Onroll i incident response — vakt-schema som hanterar inkomna incidenter, kör runbooks, åtgärdar problem.
- Postmortem-arbete — leda blameless postmortems av betydande incidenter, dokumentera rotorsak och åtgärdsplaner.
- Automatisering av toil — identifiera repetitiva manuella uppgifter och skriva kod som eliminerar dem.
- Tillförlitlighetsdesign — granska arkitektur-förslag från utvecklingsteam ur ett tillförlitlighetsperspektiv.
- SLO-uppföljning — granska att tjänster håller sig inom felbudget, eskalera när de inte gör det.
- Capacity planning — modellera framtida belastning, säkerställa att infrastruktur skalas i tid.
- Chaos engineering — kontrollerade experiment som testar systemets robusthet mot fel.
Hur bygger man ett SRE-team i Sverige?
SRE-kompetens är bland de mest efterfrågade i svenska teknikbranschen 2026. Tre vanliga strategier:
- Rekrytera direkt — Senior SRE-ingenjörer i Stockholm tjänar typiskt 65 000–110 000 kr/månad. Rekryteringstid 3-6 månader på grund av brist på erfarna kandidater.
- Omskola interna utvecklare eller systemadministratörer — Vanlig strategi: anställa starka utvecklare med driftintresse och investera 6-12 månader i utbildning + mentorship.
- Anlita SRE-as-a-Service från en partner — Många svenska företag, särskilt mindre och mellanstor, väljer att anlita en specialiserad partner för SRE-tjänster istället för att rekrytera internt. Detta ger snabbare access till bred kompetens utan rekryteringsrisken.
För svenska företag som vill påskynda SRE-resan utan långa rekryteringscykler erbjuder partners som Opsio SRE-as-a-Service med dedikerade ingenjörer som arbetar inbäddat i kundens drift- och utvecklingsorganisation.
Vanliga frågor
Vad är Site Reliability Engineering (SRE)?
SRE är en disciplin som tillämpar mjukvarutekniska principer på operativ drift för att leverera skalbara, mycket tillförlitliga programvarusystem. Den uppstod hos Google i början av 2000-talet och har spridit sig till nästan alla större teknikföretag. Centrala koncept inkluderar SLI (mätbara prestandaindikatorer), SLO (mål), felbudgetar (utrymme att "misslyckas"), toil-reduktion (eliminera repetitivt manuellt arbete) och blameless postmortems (incident-utredning fokuserad på system, inte individer).
Vad gör en SRE i praktiken?
En SRE arbetar typiskt med incident response (vakt-schema), postmortem-arbete (leda blameless postmortems), automatisering av repetitiva uppgifter (toil-reduktion), tillförlitlighetsdesign (arkitektur-granskning), SLO-uppföljning (säkerställa att tjänster håller felbudget), capacity planning (modellera framtida belastning) och chaos engineering (kontrollerade experiment för att testa systemrobusthet). Mycket av arbetet är att skriva kod som löser driftproblem — inte att manuellt utföra driftuppgifter.
Vad är skillnaden mellan SRE och DevOps?
DevOps är en bred kulturell rörelse och uppsättning praktiker för samarbete mellan utvecklare och drift. SRE är en specifik implementering av DevOps-principer med mätbara mål (SLI, SLO, felbudgetar) och tydliga rolldefinitioner. DevOps uppstod ur Agile och Lean; SRE uppstod konkret hos Google. I praktiken kompletterar de varandra — DevOps är det bredare paraplyet, SRE är den mätbara operationaliseringen.
Vad är SLI, SLO och SLA i SRE?
SLI (Service Level Indicator) är en mätbar parameter för tjänstens prestanda — exempelvis andel framgångsrika HTTP-svar eller 95:e percentilen av responstid. SLO (Service Level Objective) är målet för SLI — vad som anses tillräckligt bra (t.ex. 99,9% framgångsrika svar per månad). SLA (Service Level Agreement) är den kontraktuella utfästelsen till kund — oftast lägre än SLO så det finns marginal innan kund-SLA bryts. Felbudget är det utrymme att "misslyckas" som SLO tillåter (99,9% SLO ger 43 minuters felbudget per månad).
Vad är en felbudget i SRE?
Felbudget (error budget) är skillnaden mellan 100% och ditt SLO — det utrymme av "misslyckanden" som ditt mål tolererar. Om du har 99,9% SLO för tillgänglighet, har du 0,1% felbudget = 43 minuter nedtid per månad. Felbudgeten är ett strategiskt verktyg: när felbudgeten är förbrukad ska teamet pausa nya funktioner och fokusera på tillförlitlighet; när felbudgeten har stort utrymme kan teamet driva snabbare med kalkylerad risk. Det ger en kvantifierbar mekanism för balansen mellan "leverera nytt" och "underhålla stabilitet".
Vad är toil i SRE?
Toil är repetitivt manuellt arbete som krävs för att hålla tjänsten igång men som inte tillför något varaktigt värde. Exempel: manuellt skala upp servrar varje måndag, manuellt rensa loggar, manuellt köra rollbacks. SRE-disciplinens centrala arbete är att identifiera toil och eliminera den genom automatisering. Googles riktlinje: maximalt 50% av en SRE:s tid får vara toil — minst 50% ska vara projektarbete som varaktigt förbättrar systemet.
Vad kostar att rekrytera en SRE i Sverige?
Senior SRE-ingenjörer i Stockholm tjänar typiskt 65 000–110 000 kr/månad (2026), exklusive sociala avgifter och förmåner. Total årskostnad för en senior SRE i en svensk teknikorganisation: 1,2–1,8 miljoner kr. Rekryteringstiden är 3-6 månader på grund av brist på erfarna kandidater. Alternativ till intern rekrytering: omskola starka utvecklare med driftintresse (6-12 månaders utbildning), eller anlita SRE-as-a-Service från en partner för snabbare access till bred kompetens utan rekryteringsrisken.
Vilka svenska företag använder SRE?
SRE-praktiken är spridd över de flesta svenska teknikledare 2026: Spotify (en av Europas största SRE-organisationer), Klarna, King, iZettle/Zettle by PayPal, Truecaller, Tobii, Mojang/Microsoft. Inom traditionella industrier som genomgår digital transformation byggs SRE-team upp hos: Volvo Cars och Polestar (uppkopplade fordon), Klarna och Lendify (fintech), Nordnet och Avanza (fintech), samt offentliga aktörer som Skatteverket och Trafikverket för deras digitala plattformar.
Written By

Country Manager, Sverige
Johan leder Opsios verksamhet i Sverige och driver AI-införande, DevOps-transformation, säkerhetsstrategi och molnlösningar för nordiska företag. Med över 12 års erfarenhet inom molninfrastruktur har han levererat fler än 200 projekt på AWS, Azure och GCP — med specialisering inom Well-Architected-granskningar, landningszonsdesign och multi-cloud-strategi.
Editorial standards: Denna artikel är skriven av molnpraktiker och granskad av vårt ingenjörsteam. Vi uppdaterar innehållet kvartalsvis. Opsio upprätthåller redaktionellt oberoende.