Opsio - Cloud and AI Solutions
Cloud6 min read· 1,279 words

SRE — Site Reliability Engineering förklarat: principer, mätetal och roller

Johan Carlsson
Johan Carlsson

Country Manager, Sverige

Publicerad: ·Uppdaterad: ·Granskad av Opsios ingenjörsteam
Översatt från engelska och granskad av Opsios redaktion. Visa originalet →

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

BegreppVad det ärPraktiskt exempel
SLI (Service Level Indicator)Mätbar parameter för tjänstens prestandaAndel 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 SLO99,5% månadsuppetid med kreditkomp om underskridet
FelbudgetDet utrymme att "misslyckas" som SLO tillåter99,9% SLO ger 43 minuters felbudget per månad
ToilRepetitivt manuellt arbete som inte tillför varaktigt värdeManuell skalning, manuell incident response, manuell rollback
Blameless postmortemIncident-utredning som fokuserar på system, inte individer"Vad i vårt system tillät detta fel?" inte "Vem orsakade felet?"
Kostnadsfri experthjälp

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.

Solution ArchitectAI-specialistSäkerhetsexpertDevOps-ingenjör
50+ certifierade ingenjörerAWS Advanced Partner24/7 support
Helt kostnadsfritt — ingen förpliktelseSvar inom 24h

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.

AspektDevOpsSRE
Vad det ärKulturell rörelse och uppsättning praktikerSpecifik implementering med mätbara mål
MätbarhetGenerella principer (CALMS, Three Ways)Konkreta SLI, SLO, felbudgetar
RolldefinitionBrett begrepp, många olika titlar"SRE" är en specifik roll och titel
BakgrundUppstod ur Agile och Lean-rörelsernaUppstod konkret hos Google
VerktygCI/CD, containerisering, IaC, monitoringSamma + 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:

  1. 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.
  2. Omskola interna utvecklare eller systemadministratörer — Vanlig strategi: anställa starka utvecklare med driftintresse och investera 6-12 månader i utbildning + mentorship.
  3. 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

Johan Carlsson
Johan Carlsson

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.