SLA för molntjänster: tillgänglighet, support och ersättning

Vad ett SLA för molntjänster är – och varför det behövs

Ett SLA (Service Level Agreement) är en överenskommelse mellan kund och leverantör om servicenivån för en IT-tjänst – exempelvis krav på tillgänglighet, åtgärdstider och hantering av avbrott. TechSverige, som ger ut standardavtal för bland annat molntjänster, beskriver syftet med tydliga servicenivåer som att de skapar rätt förväntningar från start. Ett SLA kan riktas mot en extern kund, men kan lika gärna reglera relationen mellan IT-organisationen och den egna verksamheten.

SLA:t är sällan ett fristående dokument. Morlings beskriver det som normalt förekommande att ett SLA är en del av ett större avtal, till exempel ett molntjänst- eller driftavtal. TechSveriges SLA-bilagor är utformade för att tillämpas tillsammans med de allmänna bestämmelserna för respektive tjänstetyp – molntjänster, IT-infrastrukturtjänster, IT-underhåll och välfärdsteknik – och utgör då bilaga till det avtal parterna träffat. Ur ett svenskt avtalsrättsligt perspektiv har SLA:t enligt Morlings samma status som övriga avtalsvillkor, vilket innebär att otydliga eller motstridiga regleringar skapar osäkerhet om vad parterna egentligen har avtalat.

Otydliga villkor får konsekvenser även bortom den enskilda avtalsförhandlingen: en uppsats från DiVA om SLA-kontrakt för ökad molnsäkerhet (2022) konstaterar att mindre företag och organisationer har uttryckt ovilja att använda molntjänster på grund av otydliga säkerhetsvillkor.

Ett molntjänst-SLA behöver hantera tillgänglighet och hur den mäts, support och incidenthantering med svarstider och eskalering samt ersättning i form av krediter, prisavdrag eller viten. Löpande mätning och uppföljning avgör om avtalet går att hävda i praktiken.

Tillgänglighet: nivå, mätperiod och undantag

Det räcker sällan att bara ange en tillgänglighetsnivå i procent. Ett robust SLA bör enligt Morlings bland annat ta ställning till hur tillgänglighet mäts – vilken tidsperiod som gäller, vilka underhållsfönster som undantas och vilka övriga undantag som ska räknas bort. Inköpsrådets expert Magnus Nilsson lyfter fram samma sak under rubriken definitioner: parterna måste vara överens om vad som betraktas som ett fel och hur tillgänglighet ska beräknas.

I it-sammanhang reglerar ett SLA typiskt vilken tillgänglighet ett system ska ha. Nivån är bara meningsfull tillsammans med en entydig mätpunkt: mäts tillgängligheten mot en enskild komponent, mot en inloggningstjänst eller mot hela plattformen, och vem mäter?

Oklara mätpunkter är en av de vanligaste fallgroparna – parterna blir i efterhand oense om tillgängligheten verkligen har varit för låg. Skriv därför in i avtalet vilken period som mäts, vilka undantag som tillåts och hur resultatet dokumenteras, så att bedömningen inte behöver göras i efterhand utifrån olika uppfattningar.

Mätmetoden skiljer sig åt mellan tjänstetyper. För it-tjänster kan mätningen många gånger byggas in i system och därför göras enkelt och automatiserat – Inköpsrådet ger exemplet att det utan större problem går att mäta hur stor del av en månad en webbplats har varit tillgänglig. För tjänster som inte är it-baserade går motsvarande mätning inte att göra automatiskt, utan kräver manuella kontroller.

Servicenivåer och serviceklasser som går att ändra över tid

Servicenivåer reglerar enligt Inköpsrådet vilken nivå tjänsten ska hålla i olika delar och avseenden. Sätt därför nivåer per tjänstedel och per egenskap i stället för en enda generell siffra för hela molntjänsten: en del kan vara verksamhetskritisk medan en annan klarar en lägre nivå.

Serviceklasser gör det möjligt att ändra servicenivån under avtalstiden, till exempel att öka ett systems tillgänglighet från 98 procent till 99 procent. Mekanismen ger en förhandlad väg att höja nivån när verksamhetens behov förändras, i stället för att hela avtalet måste omförhandlas eller sägas upp.

En vanlig fallgrop är ett SLA som inte uppdateras när tjänsten utvecklas, så att nya funktioner saknar servicenivåer. Rutinen för tjänsteändringar bör därför omfatta SLA:t: nya moduler, integrationer eller tjänstedelar tilldelas nivåer när de tas i drift, inte i efterhand.

Ett fungerande SLA är enligt itsoftware.se relaterat till en definierad tjänst som finns i organisationens tjänstekatalog, fokuserar på tydligt definierade resultat snarare än enbart operationella mätvärden som hastighet eller antal hanterade ärenden, och är skrivet på ett enkelt språk som är lätt att förstå för alla involverade parter. Morlings pekar också på otillräcklig koppling till kundens verksamhetskritiska processer som ett typiskt problem – nivåerna bör gå att härleda till vad verksamheten faktiskt förlorar när tjänsten står still.

Support och incidenthantering: svarstider, åtgärdstider och eskalering

Ett SLA behöver ta ställning till hur incidenter klassificeras och vilka svarstider som gäller för varje nivå, samt vilka åtgärdstider som gäller vid allvarliga driftstörningar. Det är två separata åtaganden: svarstiden mäts från det att ärendet registreras, åtgärdstiden fram till dess att felet är avhjälpt.

Inköpsrådet beskriver de mått ett it-SLA vanligtvis reglerar: vilken tillgänglighet ett system ska ha, hur lång tid det högst får gå innan felavhjälpning ska påbörjas, hur snabbt felet ska vara åtgärdat och hur många gånger ett fel får förekomma under en given tidsperiod. Den sista parametern fångar upp återkommande fel som var för sig klarar svarstiderna men sammantaget gör tjänsten opålitlig.

Incidentprocesser som inte följs i praktiken är enligt Morlings en återkommande orsak till att ett SLA inte fungerar, och problemet sitter ofta i otydliga rapporteringsvägar och kontaktvägar. Det räcker alltså inte att tiderna är satta – det måste framgå var en incident anmäls, vem som klassificerar den och hur den rapporteras tillbaka.

Frågor att ställa till leverantören inför avtalet: Vilka kontaktvägar finns för att anmäla en incident, och är de bemannade dygnet runt eller bara under kontorstid? Vilka prioritetsnivåer finns, vem sätter prioriteten och kan kunden begära omklassificering? Vilken svarstid och åtgärdstid gäller per nivå? Hur eskalerar en incident som inte blir löst inom utlovad tid, och till vem? Vilka tider och dagar räknas klockan under – dygnet runt eller kontorstid? Hur dokumenteras och rapporteras incidenter till kunden?

Planerade driftavbrott och avisering

Ett SLA behöver ta ställning till vilka planerade driftavbrott som är tillåtna och hur de ska aviseras. Det hänger direkt ihop med tillgänglighetsmätningen, eftersom underhållsfönster och undantag är en av de faktorer som avgör hur tillgängligheten beräknas och därmed vad siffran i avtalet betyder.

Om planerade avbrott räknas bort från mätperioden påverkar de inte den redovisade tillgängligheten; om de inte räknas bort belastar de leverantörens resultat. Gränsdragningen behöver vara explicit: vilka fönster som får användas, hur långt i förväg de ska aviseras, under vilka tider på dygnet de får läggas, vilka delar av tjänsten som får påverkas och på vilket sätt kunden informeras.

Poängen med att reglera detta är att skilja avbrott som leverantören råder över från oplanerade störningar, så att gränsdragningen inte blir en tvistefråga i efterhand. En incident som leverantören själv har aviserat som planerat underhåll bör inte kunna beskrivas som en oplanerad störning – eller tvärtom.

Ersättning när servicenivån inte nås: krediter, prisavdrag och viten

Sanktioner reglerar vad som händer om avtalad servicenivå inte uppnås. Vanligtvis utgår då någon form av vite eller så sker ett prisavdrag, enligt Inköpsrådet. Morlings formulerar kravet på regleringen som att SLA:t ska ta ställning till om och hur tjänstekrediter eller prisavdrag ska beräknas vid uppfyllandet av tillgänglighet.

Att SLA:t innehåller sanktioner gäller framför allt i relationen till externa kunder. Leverantörernas egna SLA-bilagor kan se ut på liknande sätt: i Unit4:s SLA-bilaga för globala molntjänster anges att om leverantören inte uppnår och upprätthåller de KPI:er som anges i SLA:t kan kunden vara berättigad till kompensation enligt vad som anges där.

Beräkningen behöver vara entydig för att sanktionen ska fungera. Bestäm vad krediten beräknas på – månadsavgiften för den berörda tjänstedelen eller hela avtalet – vilket tröskelvärde som ska vara passerat, hur krediten trappas upp vid större avvikelser, om det finns ett tak per månad och om kunden måste begära krediten inom en viss tid. Krediter som aldrig efterfrågas eller som kräver en komplicerad utredning får ingen praktisk effekt.

Relationen mellan SLA-regleringen och övrigt skadeståndsansvar i avtalet måste framgå. En återkommande fallgrop, enligt Morlings, är att SLA:t inför begränsningar av kundens rättigheter – exempelvis genom att hänvisa till tjänstekrediter som påföljd – utan att det tydligt framgår i huvudavtalet. Det kan i sin tur leda till oklarheter om hur svensk dispositiv rätt, exempelvis regler om fel och påföljder, ska tillämpas i förhållande till SLA:t. Formulera därför uttryckligen om krediten är den enda påföljden vid avtalsbrott mot servicenivåerna eller om den kompletterar övriga påföljder enligt huvudavtalet.

Mätning, uppföljning och bevisning under avtalstiden

För it-tjänster kan mätningen av hur väl ett SLA upprätthålls många gånger byggas in i system och göras på ett enkelt och automatiserat sätt. Uppföljningen blir då en fråga om att komma överens om vilka mätetal och rapporter som tas fram, hur ofta de redovisas och hur avvikelser hanteras mellan parterna. Nilex beskriver i det sammanhanget KPI:er och mätetal för en modern servicedesk och hur de kan användas för att driva förbättring snarare än bara för att mäta.

Det är viktigt att redan när ett SLA skrivs – i många fall under kravarbetet vid en upphandling – försäkra sig om att det är möjligt att göra de kontroller som krävs, på ett sätt som säkerställer att de avtalade tjänstenivåerna upprätthålls kontinuerligt under hela avtalstiden. Kravställning och avtalsuppföljning hänger ihop: ett mätetal som inte går att ta fram i tid, eller som bara kan tas fram manuellt och sällan, är svårt att hävda när nivån väl har missats.

Bevisningen är en egen fråga att reglera. Inga regler om bevisning leder enligt Morlings till svårigheter att visa hur länge en störning faktiskt pågick. Bestäm därför i förväg vilka loggar och tidstämplar som ska finnas, hur parterna dokumenterar när en störning började och slutade, vem som äger underlaget och hur länge det sparas.

Uppföljningen behöver också ha en form: regelbundna genomgångar av utfallet mot avtalade nivåer, en fast rapportstruktur och en rutin för vad som händer när en nivå har missats flera perioder i rad. Annars stannar SLA:t vid ett dokument som ingen part agerar på förrän relationen redan är skadad.

Vanliga fallgropar – och en checklista inför förhandlingen

De typiska problemen med otydliga SLA-villkor är enligt Morlings oklara mätpunkter, där parterna är oense om tillgängligheten verkligen har varit för låg; inga regler om bevisning, vilket gör det svårt att visa hur länge en störning faktiskt pågick; incidentprocesser som inte följs i praktiken, med otydliga rapporteringsvägar och kontaktvägar; ett SLA som inte uppdateras när tjänsten utvecklas, så att nya funktioner saknar servicenivåer; och en otillräcklig koppling till kundens verksamhetskritiska processer. För företag med kritiska IT-tjänster kan bristerna få stora konsekvenser – en längre driftstörning kan leda till avtalsbrott mot kundens egna kunder, regulatoriska risker eller skada på varumärket.

Checklista inför förhandlingen:

Checklista inför SLA-förhandling – kritiska punkter