De fyra pelarna i praktisk SRE

1. Service Level Objectives (SLO:er) och felbudgetar

SLO:er är hjärtat i SRE. De översätter affärskrav till mätbara tekniska mål. En SLO säger inte "systemet ska vara snabbt" utan definierar exakt: "99,9 % av API-anrop ska besvaras under 200 ms, mätt över en rullande 30-dagarsperiod."

Felbudgeten är det matematiska komplementet. Om din SLO tillåter 99,9 % tillgänglighet har du en felbudget på 0,1 % – ungefär 43 minuter per månad. Så länge felbudgeten inte är förbrukad kan utvecklingsteamet skeppa nya funktioner. När budgeten är slut skiftar fokus till stabilisering.

Denna mekanism löser den eviga konflikten mellan "skeppa snabbare" och "rör ingenting". Felbudgeten gör avvägningen explicit och datadriven istället för politisk.

Praktiskt exempel från vår drift: En e-handelsplattform vi hanterar i eu-north-1 (Stockholm) definierade separata SLO:er för sitt checkout-flöde (99,95 %) och sin produktkatalog (99,5 %). Det innebar att teamet kunde göra mer aggressiva experiment med katalogens sökalgoritm utan att riskera betalningsflödet.

2. Observerbarhet – mer än övervakning

Traditionell övervakning frågar: "Är servern uppe?" Observerbarhet frågar: "Varför upplever användare i Göteborg 3x längre laddtider sedan kl. 14:00?"

De tre pelarna i observerbarhet:

• Metrics – tidsseriedata som CPU, minnesanvändning, requestfrekvens, felfrekvens (Prometheus, CloudWatch, Azure Monitor)
• Loggar – strukturerade händelseposter som berättar vad som hände (ELK-stacken, CloudWatch Logs, Loki)
• Traces – distribuerade spår som visar var i en mikrotjänstkedja fördröjningen uppstår (Jaeger, AWS X-Ray, OpenTelemetry)

Utan alla tre saknar du kontext. Metrics berättar att något är fel, loggar berättar vad, och traces berättar var i kedjan problemet sitter. OpenTelemetry har på kort tid blivit de facto-standard för instrumentering, och enligt CNCFs Annual Survey ser vi en stadig ökning av adoption bland organisationer med mikrotjänstarkitekturer.

Opsios rekommendation: Börja alltid med att definiera vilka signaler som speglar användarupplevelsen (Golden Signals: latens, trafik, felfrekvens, mättnad) och bygg dashboards kring dem – inte kring infrastrukturmetrics.

Molnsäkerhet

3. Toil-eliminering genom automatisering

Google definierar "toil" som manuellt, repetitivt arbete som saknar bestående värde och växer linjärt med tjänstens storlek. Att manuellt starta om en pod, rensa loggar, eller köra samma deploy-kommando varje gång – det är toil.

SRE-teamets mål är att hålla toil under 50 % av arbetstiden. Resten ska gå åt till ingenjörsarbete som permanent förbättrar systemet.

Vanliga automatiseringsmål i praktiken:

Varje automatiserat steg frigör tid för arbete som faktiskt förbättrar systemet långsiktigt.

Managerade molntjänster

4. Incidenthantering och postmortems

Incidenter händer – det är en axiom i SRE. Frågan är inte om utan hur snabbt du återhämtar dig och vad du lär dig.

En mogen SRE-organisation har:

• Definierade svårighetsgrader (SEV1–SEV4) med tydliga eskaleringsvägar
• Incident commander-rotation – en person äger beslutsfattandet under incidenten
• Blameless postmortems – analyser som fokuserar på systemfel, inte individer
• Action items med ägare och deadline – annars är postmortem bara dokumentation

Vi driver Opsios 24/7 SOC/NOC med exakt dessa principer. Det som skiljer en organisation som lär sig från sina incidenter från en som upprepar dem är disciplinen att faktiskt genomföra åtgärderna som postmortem identifierar.

Chaos Engineering – att bryta saker med flit

Chaos engineering kompletterar SRE genom att proaktivt testa systemets motståndskraft. Istället för att vänta på att verkligheten avslöjar svagheter injicerar du kontrollerade fel: stänger av en availablity zone, introducerar nätverkslatens, dödar slumpmässiga containrar.

Verktyg som AWS Fault Injection Service (FIS), Gremlin och Litmus gör detta tillgängligt utan att du behöver bygga egna ramverk. Nyckeln är att alltid köra experiment med en hypotes: "Vi tror att systemet klarar bortfall av en AZ utan användarsynlig påverkan." Om hypotesen stämmer – bra. Om inte har du hittat en svaghet innan dina kunder gjorde det.

Börja smått. Kör chaos-experiment i staging först. Säkerställ att observerbarheten finns på plats så att du ser effekterna. Och ha alltid en rollback-plan.

Implementera SRE – steg för steg

Att gå från noll till fullskalig SRE-organisation tar tid. Här är en pragmatisk roadmap:

Fas 1 (månad 1–2): Grundläggande observerbarhet

Implementera metrics, loggar och traces för era mest kritiska tjänster. Definiera Golden Signals-dashboards. Inför strukturerad on-call-rotation.

Fas 2 (månad 3–4): SLO:er och felbudgetar

Definiera SLO:er baserat på faktiska användarbehov, inte godtyckliga procentsatser. Koppla felbudgeten till releaseprocessen. Börja mäta toil.

Fas 3 (månad 5–8): Automatisering och toil-reducering

Identifiera de tre mest tidskrävande manuella processerna och automatisera dem. Inför blameless postmortems som standard.

Fas 4 (månad 9–12): Mognad

Inför chaos engineering. Utöka SLO:er till fler tjänster. Börja mäta SRE-teamets effektivitet i termer av minskad incidentfrekvens och toil-procent.

Molnmigrering

När det lönar sig att ta in en managerad SRE-partner

Att bygga ett internt SRE-team kräver minst 3–5 seniora ingenjörer med erfarenhet av observerbarhet, incidenthantering, IaC och molnarkitektur. I Sverige, där konkurrensen om den kompetensen är brutal, tar rekryteringen ofta 6–12 månader – och under den tiden fortsätter incidenterna.

En managerad SRE-tjänst ger:

• Omedelbar tillgång till beprövade processer och verktyg
• 24/7-täckning utan att du behöver bygga en egen on-call-rotation
• Erfarenhet från hundratals miljöer – mönster som tar år att bygga internt
• Kostnadskontroll – förutsägbar månadskostnad istället för rekryteringsrisk

Opsio kombinerar SRE-kompetens med FinOps-perspektiv, vilket innebär att vi inte bara ser till att dina system är tillförlitliga – vi ser också till att du inte betalar för resurser som ingen använder.

Cloud FinOps

NIS2 och regulatoriska krav på driftstillförlitlighet

Med NIS2-direktivets implementering i svensk lag ställs hårdare krav på incidentrapportering och riskhantering för organisationer inom kritisk infrastruktur. SRE-praktiker som strukturerad incidenthantering, blameless postmortems och dokumenterade SLO:er ger en solid grund för att uppfylla dessa krav.

Specifikt kräver NIS2 att väsentliga och viktiga entiteter rapporterar betydande incidenter inom 24 timmar. En organisation med mogen SRE-praxis har redan den observerbarhet och de eskaleringsrutiner som behövs – incidentrapportering blir en naturlig förlängning av befintliga processer snarare än en panikinsats.

Vanliga frågor

Vad är skillnaden mellan SRE och DevOps?

DevOps är en kulturell och organisatorisk filosofi som bryter ner silos mellan utveckling och drift. SRE är en konkret implementering av den filosofin med specifika metoder som felbudgetar, SLO:er och toil-reducering. Google beskriver det som: "SRE is what happens when you ask a software engineer to design an operations function."

Behöver vi SRE om vi redan har ett NOC?

Ett traditionellt NOC reagerar på incidenter. SRE kompletterar genom att systematiskt eliminera återkommande problem via automatisering och kodifierade runbooks. Många organisationer behåller sitt NOC som first-line men lägger SRE-praktiker ovanpå för att minska incidentvolymen över tid.

Hur sätter vi meningsfulla SLO:er?

Börja med användarupplevelsen, inte infrastrukturen. Mät det slutanvändaren faktiskt upplever – sidladdningstid, API-svarstider, felfrekvens. Sätt SLO:er som speglar affärskritikalitet: en intern admin-panel behöver inte 99,99 % tillgänglighet, men ert betalflöde kanske gör det.

Vad kostar det att implementera SRE?

Kostnaden varierar kraftigt beroende på miljöns komplexitet. En intern SRE-ingenjör i Sverige kostar ofta 70 000–90 000 SEK/månad inklusive sociala avgifter. En managerad SRE-tjänst kan ge tillgång till ett helt team dygnet runt till en bråkdel av kostnaden för att bygga kompetensen internt.

Kan vi använda SRE-principer i en hybridmiljö?

Absolut. SRE är plattformsoberoende som metodik. Utmaningen i hybridmiljöer ligger i att skapa enhetlig observerbarhet över on-prem och molnresurser. Verktyg som Prometheus med Thanos, Grafana och OpenTelemetry fungerar väl i hybridscenarier.