De fem grundpelarna i ett användbart SLR

Ett SLR som faktiskt driver kvalitet innehåller tydligt definierade krav inom åtminstone dessa fem områden:

Tillgänglighet – den mest missförstådda siffran

"99,9 % upptid" låter bra tills du räknar ut att det innebär nästan 9 timmar nertid per år. För affärskritiska system i molnet räcker det sällan. Å andra sidan kostar varje extra nia exponentiellt mer i redundans och komplexitet.

Vi ser ofta att organisationer sätter tillgänglighetskrav utan att förstå vad de faktiskt kostar. Ett SLR på 99,99 % kräver multi-AZ-arkitektur, automatiserad failover och rigorös testning – det är inte något man bara skriver in i ett avtal.

Tumregel från Opsios NOC: Börja med att kartlägga verksamhetspåverkan per timme nertid. Om kostnaden för en timmes avbrott understiger kostnaden för den extra infrastrukturen, sänk kravet och investera pengarna i bättre incidentrespons istället.

Prestanda – mät rätt, inte mycket

P95-latens (den svarstid som 95 % av anropen klarar) är ett mer meningsfullt mätetal än genomsnittlig svarstid. Genomsnittet döljer extremvärden som drabbar riktiga användare. I ett SLR bör du specificera latenskrav per tjänstekomponent, inte som ett samlat genomsnitt.

Vanliga misstag när organisationer sätter SLR

Efter att ha hjälpt dussintals svenska organisationer med molntjänster ser vi samma misstag upprepas:

1. SLR skrivs av IT – utan verksamhetsförankring

Tekniker sätter krav som är tekniskt korrekta men inte speglar vad verksamheten behöver. Resultatet? SLA:er som uppfylls på pappret medan användarna fortfarande är missnöjda.

Lösning: Workshop med representanter från både IT och verksamhet. Ställ frågan: "Vad händer om den här tjänsten ligger nere i en timme under arbetstid?" Svaret styr kravet.

2. Krav sätts en gång och glöms bort

SLR som skrevs 2023 reflekterar inte den arbetsbelastning organisationen har 2026. Molnarkitekturer förändras, användarantal växer, och nya regelverk som NIS2 ställer hårdare krav på incidentrapportering.

Lösning: Kvartalsvisa SLR-revisioner kopplade till kapacitetsplanering och incidentdata.

3. Mätetal utan konsekvenser

Om ingen reagerar när ett SLR-mål bryts, är det inte ett krav – det är en önskelista. Effektiva SLR behöver kopplas till tydliga eskaleringsvägar och, i externa relationer, ekonomiska konsekvenser.

4. Alltför komplexa kravdokument

Vi har sett SLR-dokument på 80+ sidor som ingen läser. Ett SLR bör rymma kärnkraven på en till två sidor med hänvisning till detaljerade bilagor. Om ingen i organisationen kan sammanfatta kraven utan att slå upp dokumentet, är det för komplext.

Från SLR till SLA: så bygger du avtalet

När SLR:et är definierat och förankrat är steget till SLA relativt rakt. Strukturen bör innehålla:

• Tjänstebeskrivning – Exakt vilka tjänster som omfattas
• Mätetal och tröskelvärden – Direkt från SLR, med specificerad mätmetod
• Rapporteringsfrekvens – Månadsvis är minimum; veckovis för kritiska tjänster
• Eskaleringsprocess – Vem kontaktas vid vilken avvikelsenivå
• Undantag – Planerade underhållsfönster, force majeure
• Ekonomiska konsekvenser – Servicekrediter vid brott mot SLA

OLA – det interna smörjmedlet

Operational Level Agreements är interna avtal mellan team. Om SLA:et lovar 15 minuters responstid på P1-incidenter måste OLA:et specificera att NOC kvitterar larmet inom 5 minuter och att eskalering till nästa nivå sker inom 10 minuter. Utan dessa interna åtaganden finns ingen mekanism att uppfylla det externa löftet.

På Opsio använder vi OLA:er mellan vårt SOC i Karlstad, NOC i Bangalore och respektive kundteam. Dygnet-runt-bemanningen kräver att överlämningar är exakta och dokumenterade. Molnsäkerhet

UC – underleverantörsavtalen som ofta glöms bort

Om din infrastruktur kör i AWS eu-north-1 (Stockholm) eller Azure Sweden Central är molnleverantörens SLA en underpinning contract. AWS garanterar exempelvis 99,99 % tillgänglighet för EC2 inom en region med multi-AZ-deployment. Om ditt SLR kräver 99,99 % men din arkitektur bara nyttjar en enda availability zone, har du en gap som inget avtal i världen kan täcka.

Mätning och övervakning – SLR i drift

SLR som inte mäts kontinuerligt är retorik. Effektiv övervakning kräver:

Teknisk stack:

• Observerbarhetsplattform (Datadog, Grafana, CloudWatch) med dashboards per SLR-mål
• Automatiserade larm vid tröskelvärdesbrott med rätt eskaleringsnivå
• Syntetiska tester som simulerar användarupplevelsen, inte bara infrastrukturpulsar

Organisatorisk process:

• Månatlig SLR-rapport till verksamheten med trendanalys
• Incidentgenomgångar som kopplar rotorsak till SLR-påverkan
• Kvartalsvis kapacitetsplanering baserad på SLR-marginaler

Enligt ITIL 4 bör Service Level Management-praktiken inkludera regelbundna "service reviews" där mätdata jämförs med SLR och där åtgärder definieras för avvikelser. Opsios managerad DevOps-tjänst integrerar denna mätning direkt i CI/CD-pipelinen, så att prestanda mot SLR-mål syns redan i staging-miljön.

SLR och FinOps – kostnaden för varje nia

Det finns ett direkt samband mellan SLR-ambition och molnkostnad. Flexeras State of the Cloud har konsekvent visat att kostnadshantering är den största utmaningen för molnanvändare. Aggressiva SLR-mål utan kostnadsanalys är en av anledningarna.

Cloud FinOps handlar inte om att skära kostnader – det handlar om att investera rätt i förhållande till verksamhetens faktiska krav. Ett SLR som kräver 99,99 % för ett internt testsystem slösar pengar. Ett SLR på 99,0 % för betalningsflödet kostar i förlorade intäkter.

SLR vid molnmigrering

Vid molnmigrering är SLR-arbetet särskilt kritiskt. Befintliga on-prem-krav översätts inte automatiskt till molnarkitektur. Nätverkslatens, delade resurser och molnleverantörens egen SLA-struktur förändrar förutsättningarna.

Praktiskt tillvägagångssätt:

1. Dokumentera nuvarande SLR – Vad levererar ni faktiskt idag? Inte vad som står i gamla avtal, utan mätt verklighet.

2. Identifiera gap – Var överträffar ni kraven (och betalar för mycket)? Var underleverar ni?

3. Designa molnarkitektur mot SLR – Inte tvärtom. Arkitekturen ska uppfylla kraven, inte definiera dem.

4. Validera med belastningstester – Innan produktionssättning, verifiera att SLR-målen nås i den nya miljön.

Regulatoriska krav som påverkar SLR

NIS2-direktivet, som gäller i Sverige sedan 2024, ställer krav på incidentrapportering inom 24 timmar för väsentliga entiteter. Detta måste återspeglas i SLR:et – om ditt mätetal för incidentdetektering är 4 timmar och rapporteringsprocessen tar ytterligare 8 timmar, har du redan ett regulatoriskt problem.

GDPR ställer krav på datahantering som påverkar RPO (Recovery Point Objective) – hur mycket data du har råd att förlora. IMY har i sina tillsynsbeslut betonat vikten av dokumenterade tekniska och organisatoriska åtgärder, och ett väldefinierat SLR är en central del av den dokumentationen.

Vanliga frågor

Vad är skillnaden mellan SLR och SLA?

SLR är kravspecifikationen – vad verksamheten behöver av en IT-tjänst. SLA är det formella avtalet som baseras på dessa krav. SLR kommer alltid först: utan väl genomarbetade krav blir avtalet meningslöst. Tänk på SLR som ritningen och SLA som kontraktet med byggfirman.

Vilka mätetal bör ingå i ett SLR?

Tillgänglighet (exempelvis 99,9 % upptid), svarstid (p95-latens), MTTR (genomsnittlig återställningstid), supporttider och eskaleringsprocedurer. Välj mätetal som speglar verksamhetens faktiska behov, inte tekniska fåfängor. Undvik att mäta allt – fokusera på det som driver verksamhetsvärde.

Hur ofta bör SLR revideras?

Minst kvartalsvis, och alltid vid större förändringar i infrastruktur, verksamhetskrav eller leverantörsbyten. På Opsio kopplar vi SLR-revisioner till kapacitetsplanering och incidenttrender från vår NOC. En revision behöver inte vara stor – det viktiga är att den sker regelbundet.

Behöver vi SLR även för interna IT-tjänster?

Absolut. Interna SLR – formaliserade som OLA:er – ger tydlighet kring vad driftteamet åtar sig gentemot verksamheten. Utan dem uppstår oundvikligen konflikter om prioriteringar vid incidenter. Formella interna krav skapar dessutom en kultur av ansvarstagande.

Hur hänger SLR ihop med ITIL?

I ITIL 4 ingår SLR i praktiken Service Level Management. Processen börjar med att fånga verksamhetskrav (SLR), formalisera dem i avtal (SLA/OLA/UC) och sedan mäta, rapportera och förbättra löpande. ITIL betonar att SLR bör vara levande dokument som utvecklas med verksamheten.