SLA i molntjänster: så bedömer du tillgänglighet och ersättning

Vad SLA i molntjänster faktiskt reglerar

Ett SLA, Service Level Agreement, är ett avtal mellan en molnleverantör och kunden som beskriver villkoren för den tjänst som tillhandahålls. Det definierar den servicenivå kunden kan förvänta sig, inklusive prestandamätningar, tillgänglighet och support.

I it-sammanhang reglerar ett SLA vanligen vilken tillgänglighet ett system ska ha, hur lång tid det högst får gå innan felavhjälpning påbörjas, hur snabbt felet ska åtgärdas och hur många fel som får förekomma under en given period.

Bedöm ett moln-SLA via fyra delar: definitioner, servicenivåer, serviceklasser och sanktioner. Granska dem i den ordningen och koppla varje del till avtalets mätperiod och till verksamhetens kritiska flöden.

Definitioner säkerställer samsyn om vad ett fel är och hur tillgänglighet beräknas. Servicenivåer anger nivån i olika delar och avseenden.

Definitioner och servicenivåer avgör om en incident ger rätt till ersättning. Räknas planerat underhåll eller partiella fel bort, minskar antalet tillfällen som kan leda till servicekrediter.

Serviceklasser gör att nivån kan ändras under avtalstiden, exempelvis tillgänglighet från 98 procent till 99 procent. En höjning av nivån minskar utrymmet för avbrott; räkna om mot avtalets mätperiod.

Sanktioner reglerar vad som händer om avtalad servicenivå inte uppnås. Vite och prisavdrag är vanliga; i molntjänster kan servicekrediter eller andra former av kompensation bli aktuella. TechSveriges SLA-bilaga för molntjänster bygger på avtalad tillgänglighet, avtalad servicenivå för kundsupport och prisavdrag vid avtalsbrott.

Upptidsgarantin är den del som uttryckligen kopplas till servicekrediter. Prestanda- och supportgarantier beskriver förväntad kvalitet och har inte alltid egna trösklar eller sanktioner.

Ett SLA kan förutom upptid eller tillgänglighet också omfatta prestanda, återställningstid eller datahållbarhet.

Ordningen spelar roll: ett nio-tal utan definition av fel går inte att mäta, och en tröskel utan sanktion ger ingen ersättning. Läs avtalet som ett paket: vad mäts, vem mäter, vilka nivåer gäller och vad händer när de inte hålls.

Microsoft (Azure), Google (Google Cloud) och Amazon (AWS) dominerar marknaden. Utöver dessa finns även flera andra aktörer, såsom Oracle, IBM och Alibaba, som erbjuder sina egna molnlösningar. Azure integrerar med Windows Server, Active Directory, Microsoft 365 och SQL Server. Både AWS och Azure erbjuder IaaS, PaaS och SaaS, men använder delvis olika begrepp och koncept för samma funktioner.

Så tolkar du tillgänglighetsåtaganden och nio-tal

Upptidsgarantin är en av de viktigaste komponenterna i ett moln-SLA: ett åtagande om att tjänsterna ska vara tillgängliga under en viss procentandel av tiden, vanligtvis mätt i nio-tal – till exempel 99,9 procents drifttid.

Nio-talet blir användbart först när det kopplas till mätperioden. Ett 99,9-procentsåtagande säger inget om antal minuter eller timmar utan en angiven period.

En kortare incident behöver inte vara avtalsbrott. Ett avbrott på tio minuter kan ligga inom ramen om tjänsten körs kontinuerligt resten av månaden.

Nivåerna i avtalen skrivs som procentandelar: 98, 99 eller 99,9 procent tillgänglighet. Skillnaden mellan nivåerna är skillnaden i tillåtet avbrottsutrymme under mätperioden.

Räkna om avtalets nio-tal till förväntad otillgänglig tid för den mätperiod avtalet anger. Jämför med hur länge kritiska flöden kan vara nere innan intäkter eller service tappas. Gartner uppskattar att it-nedtid kostar stora företag över 1 miljon USD per timme.

Mätperioden avgör hur mycket otillgänglig tid som ryms inom nio-talet; en kortare period gör att en enskild incident väger tyngre. För it-tjänster kan mätningen byggas in i systemen, till exempel hur stor del av en månad en webbplats har varit tillgänglig.

Tre frågor avgör vad nio-talet är värt. Vad räknas som fel – ingår planerat underhåll, partiella fel och långsamma svar där tjänsten tekniskt svarar? Vilken mätperiod används, och beräknas tillgängligheten per tjänst, per region eller för hela plattformen?

Definitioner som säkerställer samsyn kring detta är en av SLA:ets viktigaste delar; annars hamnar otydligheten i varje tvist.

Googles definitioner skiljer sig mellan tjänster. Cloud Scheduler räknar nedtid först vid mer än 10 procents felkvot, mätt på serversidan, och en nedtidsperiod måste vara minst fem sammanhängande minuter. Google Workspace räknar i stället en period då användargränssnittet har mer än fem procents felfrekvens.

Konkreta nivåer: Google Workspace lovar minst 99,9 procents månadsupptid per kalendermånad. Google Cloud Storage har 99,95 procent för multi-regional lagringsklass, 99,9 procent för regional och 99,0 procent för Nearline, Coldline och Durable Reduced Availability. Cloud Scheduler har 99,5 procent.

Oracle SaaS lovar typiskt 99,9 procent eller högre, vilket motsvarar mindre än 8,7 timmars oplanerad nedtid per år. AWS anger upptidsgarantin i nio-tal, till exempel 99,9 procent drifttid. Vilken tjänst och mätperiod som omfattas framgår av avtalet.

Upptidsprocenten gäller inte enhetligt: ett 99,9-procentsåtagande garanterar inte att tjänsten alltid är tillgänglig.

Knyt nivån till verksamhetens kritiska flöden, inte till ett allmänt intryck. Några sekunders avbrott kan vara obetydligt för mejl men affärskritiskt för kundtjänst, butik eller fjärrsupport.

Garanterar avtalet bara plattformsnivå medan ert kritiska flöde passerar flera tjänster, säger nio-talet lite om er faktiska risk. Kontrollera vilka tjänster och regioner åtagandet omfattar innan du jämför nio-tal.

Upptidsgarantin är tröskeln för ersättning, inte ett betyg. Under tröskeln kan servicekrediter eller andra former av kompensation aktiveras; över tröskeln ger avtalet ingen kompensation för långsamma svar eller partiella fel, om de inte definieras som fel.

Prestanda och supporttider – dolda delar av moln-SLA

AWS SLA:er innehåller vanligtvis prestandagarantier för hastighet och respons, till exempel latens för nätverksanslutningar eller bearbetningshastighet för virtuella maskiner. Garantierna ska försäkra att applikationerna fungerar som förväntat på plattformen.

Svarstider för support ingår också ofta, med garantier om en maximal tid. En upptidsgaranti säger inget om hur snabbt ni får hjälp när något går fel.

Svarstidsgarantierna anger en maximal tid för supporten och gäller vid sidan av upptidsgarantin. De säger inget om hur länge en tjänst är otillgänglig.

Kontrollera om svars- och åtgärdstider gäller dygnet runt eller bara kontorstid, och om de skiljer sig mellan allvarlighetsgrader. Kräv en matris: allvarlighetsgrad, svarstid, åtgärdstid och täckning.

Prestanda märks oftare i användarupplevelsen än i driftstatistiken. I Microsoft Teams påverkas samtalskvaliteten av roundtrip time, jitter och paketförlust, vilket syns i samtalshälsan.

Jitter – variationen i svarstid – syns som hack i ljud och bild trots att hastigheten ser okej ut. Paketförlust slår hårt mot telefoni, video, kassasystem och vissa VPN-flöden. Saknar avtalet nivåer för det som påverkar användaren, täcker det inte det som gör ont.

Prestandagarantier omfattar latens för nätverksanslutningar och bearbetningshastighet för virtuella maskiner. Upptidsgarantin är den del som uttryckligen kopplas till servicekrediter. Kontrollera om prestanda- och supportgarantier har egna trösklar och sanktioner.

För supportdelen letar du efter svarstid och åtgärdstid per allvarlighetsgrad. Finns ingen matris beskriver garantin bara förväntad kvalitet.

Mät det som märks i verksamheten, inte bara hastighet

Ett speedtest kan avslöja ren kapacitetsbrist men förklarar sällan varför Teams fryser klockan 09.05, varför softphonen låter burkig eller varför VPN tappar precis när ekonomiavdelningen skickar stora filer. Ett enstaka test visar mest hur det såg ut just då, mot just den servern.

För uppföljning som håller i felanmälan och SLA-dialog behöver ni mäta det som märks i verksamheten. Mätmetoden bygger på fyra storheter: latency (fördröjning), jitter (variation i svarstid), paketförlust (tappade datapaket) och tillgänglighet.

Börja med målbilden. Skriv ner tre till fem situationer som måste fungera i vardagen, till exempel videomöten utan avbrott, softphone utan robotljud, kassasystem som håller sessionen, VPN som inte bryts och rimlig svarstid i de viktigaste SaaS-tjänsterna.

Välj tre fasta mätpunkter som används varje gång: den egna brandväggen eller routern, en närliggande extern punkt som fångar sista milen och en affärskritisk målpunkt nära de mest använda tjänsterna.

Mät samma fyra storheter mot samma mätpunkter varje gång. Då går avvikelser att koppla till avtalets definition av fel och till tröskeln för servicekrediter.

Tillgänglighet fångar kortare avbrott och dippar som knappt syns i ett speedtest men märks direkt i drift.

Samtalshälsan i Microsoft Teams visar svarstid, jitter och tappade paket. Använd den för att koppla avvikelser till incidenter.

Mätningen ska matcha avtalets mätperiod och definition av fel. Annars kan avvikelsen inte kopplas till tröskeln för servicekrediter.

Bygg en enkel mät- och loggrutin

Skapa en baslinje genom att mäta i 5 till 10 arbetsdagar och spara historiken. Rutinen behöver inte vara ett mini-NOC; värdet ligger i att den är konsekvent och att historiken bevaras.

Flera mätpunkter gör att ni kan skilja lokala problem, accessproblem och störningar längre ut i kedjan. Utan den uppdelningen går det inte att avgöra om felet ligger i ert eget nät, i förbindelsen in till leverantören eller hos en tjänst längre bort – och därmed inte heller vems åtagande som är relevant.

Baslinjen blir bevis för avvikelser. Utan historik är det svårt att visa att en incident inträffat och därmed begära servicekrediter.

Spara loggen med tidsstämpel, mätpunkt, avvikelsetyp och effekt i verksamheten. Avtalet kan kräva ansökan inom en viss frist och med viss dokumentation, så historiken måste vara komplett.

Fristerna varierar och varje leverantör sätter sin egen frist. Google Workspace kräver att kunden begär servicekredit via ett supportärende inom 30 dagar från det att rätten uppstod; annars förfaller den. Underlaget bör omfatta tidsstämplar, felloggar, bevis på omförsök och konfigurationsdetaljer.

Från dipp till dokumenterad incident

Loggad data blir underlag först när den kopplas till tid, mätpunkt, avvikelsetyp och verksamhetspåverkan. Ett användbart ärende kan formuleras så här: det lokala nätet ser friskt ut, men fördröjning och paketförlust börjar utanför accessen mellan 08.55 och 09.15. Det är skarpare än att säga att internet känns instabilt och pekar ut var felsökningen ska börja.

Målbilden definierar vilka situationer som är affärskritiska. Samma avbrott kan beskrivas i verksamhetstermer: sessionen i kassasystemet tappades, samtalet bröts eller fjärrsupporten kunde inte arbeta.

Incidenten dokumenteras mot den situation avtalet ska skydda, inte mot ett allmänt prestandaintryck. Koppla den till avtalets tröskel, till exempel upptidsgarantin, och ange tid, mätpunkt, avvikelsetyp och verksamhetspåverkan.

Ersättning, sanktioner och servicekrediter

Sanktioner i ett SLA reglerar vad som händer om avtalad servicenivå inte uppnås. Vanligtvis utgår vite eller prisavdrag; i molntjänster kan servicekrediter eller annan kompensation bli aktuell. Sanktionerna skiljer sig mellan leverantörer – kontrollera om de hänger på upptidsgarantin, på prestandan eller på svarstiderna.

Servicekrediter är en trappa som hänger på hur långt under tröskeln månadsupptiden hamnar. Google Workspace ger 3 dagars tjänst tillagd i avtalstiden om månadsupptiden ligger under 99,9 men minst 99,0 procent, 7 dagar vid under 99,0 men minst 95,0 procent och 15 dagar vid under 95,0 procent.

För Google Workspace ges krediten som dagar tillagda i avtalstiden, eller som en kredit motsvarande dagarnas värde på en framtida faktura. Kunden måste begära krediten via ett supportärende inom 30 dagar från det att rätten uppstod. Avtalet anger också ett tak för den sammanlagda servicekrediten.

Google Cloud Storage: multi-regional lagringsklass har 99,95 procents SLO, regional 99,9 procent och Nearline, Coldline och Durable Reduced Availability 99,0 procent. För multi-regional klass ger 99,0–<99,95 procents månadsupptid 10 procents kredit, 95,0–<99,0 procent ger 25 procent och under 95,0 procent ger 50 procent av månadsfakturan.

Cloud Scheduler har 99,5 procents SLO per projekt och kalendermånad. Kredittrappan är 10 procent vid 99,0–<99,5 procents upptid, 25 procent vid 95,0–<99,0 procent och 50 procent under 95,0 procent.

Oracle SaaS lovar typiskt 99,9 procent eller högre, vilket motsvarar mindre än 8,7 timmars oplanerad nedtid per år. AWS upptidsgaranti anger en viss procentandel av tiden, vanligtvis uttryckt i nio-tal, till exempel 99,9 procent; uppfylls den inte kan servicekrediter eller annan kompensation bli aktuell.

AWS SLA:er innehåller vanligtvis garantier om drifttid, prestanda och svarstider för support och beskriver båda parters ansvar för att upprätthålla servicenivån. Vilken tjänst och mätperiod som omfattas framgår av avtalet.

Tröskeln för ersättning är den avtalade upptidsnivån, till exempel ett nio-tal som 99,9 procent. Under den nivån kan servicekrediter aktiveras. Kontrollera om tröskeln gäller per tjänst, per region eller för hela plattformen.

Leta efter tröskel, kreditprocentsats, beräkningsformel, tak och ansökningsfrist. Finns uppgifterna inte i avtalet går ersättningen inte att beräkna eller begära. En kredit på 10 procent kan bli ett litet belopp om den månatliga kostnaden är blygsam, oavsett hur allvarlig störningen var.

En ersättning som kräver bevisning ni inte samlar in faller i praktiken bort, hur förmånlig den än ser ut i avtalstexten. Ett krav på servicekredit vilar på tre delar: en avtalad tröskel, ett underlag som visar avvikelsen och en ansökan inom avtalad frist.

Prestanda- och supportgarantier har inte alltid egna sanktioner. Kontrollera om latens, bearbetningshastighet och svarstider för support har egna trösklar eller bara beskriver förväntad kvalitet.

Kräv en supportmatris: allvarlighetsgrad, svarstid, åtgärdstid och täckning dygnet runt eller kontorstid. Utan den går supportgarantin inte att driva.

Servicekrediter hanteras i faktureringen. Molnfakturering genererar fakturor från resursanvändningsdata och kan omfatta automatiserad fakturering, integrerad betalningshantering och detaljerad finansiell rapportering. Globala marknadsvärdet för molnfakturering väntas öka från 3,9 miljarder USD 2021 till 15,8 miljarder USD 2031. Begär att underlaget för en kredit kan kopplas till rätt tjänst och mätperiod.

Serviceklasser används för att ändra nivån under avtalstiden, till exempel från 98 procent till 99 procents tillgänglighet. En högre nivå är i praktiken en annan tjänst och bör följas upp och värderas därefter.

Checklista innan du signerar eller förlänger moln-SLA

Definitioner: är parterna överens om vad som är ett fel, hur tillgänglighet beräknas, vilken mätperiod som gäller och om planerat underhåll eller partiella fel räknas bort?

Servicenivåer och serviceklasser: vilka nivåer gäller för tillgänglighet, prestanda (till exempel latens och bearbetningshastighet) och svarstider för support – och kan nivån ändras under avtalstiden?

Sanktioner: vad händer om nivån inte uppnås – vite, prisavdrag eller servicekrediter – vid vilken tröskel, med vilket tak och vilka krav på er ansökan och dokumentation?

Servicekrediter: kräv att procentsats, beräkningsformel, tak, ansökningsfrist och dokumentationskrav framgår. Jämför med kända trappor: Google Workspace 3, 7 och 15 dagar; Google Cloud Storage och Cloud Scheduler 10, 25 och 50 procent av månadsfakturan vid stigande avvikelse.

Mätbarhet: för it-tjänster kan mätningen byggas in i system och göras enkelt och automatiserat, till exempel hur stor del av en månad en webbplats varit tillgänglig. Säkerställ redan när avtalet skrivs att de avtalade nivåerna kan kontrolleras kontinuerligt under hela avtalstiden.

Supporttider: omfattar svars- och åtgärdstider dygnet runt eller bara kontorstid, och skiljer de sig mellan olika allvarlighetsgrader?

Uppföljning: bestäm tre till fem affärskritiska situationer, tre fasta mätpunkter och mät de fyra storheterna mot samma punkter. Bygg en baslinje över 5 till 10 arbetsdagar. Logga avvikelser löpande med tidsstämpel, mätpunkt, avvikelsetyp och effekt i verksamheten.

Konkreta nivåer att jämföra mot: AWS anger upptidsgarantin i nio-tal, till exempel 99,9 procent drifttid. Google Workspace lovar 99,9 procents månadsupptid; Google Cloud Storage 99,95 procent för multi-regional, 99,9 procent regional och 99,0 procent för Nearline, Coldline och Durable Reduced Availability; Cloud Scheduler 99,5 procent. Oracle SaaS lovar typiskt 99,9 procent eller högre.

Räkna om avtalets nio-tal till förväntad otillgänglig tid för er mätperiod. Jämför med verksamhetens kritiska flöden.

Ställ tre frågor om upptidsgarantin: vad räknas som fel, vilken mätperiod gäller och omfattar åtagandet er tjänst och er region?

Skriv in avtalets nio-tal och mätperiod på samma rad som verksamhetens kritiska flöden. Då syns det var avbrottsutrymmet tar slut, och vilken incident som är värd att driva mot tröskeln.

Mätverktyg: använd Microsoft Teams samtalshälsa för att följa samtalskvaliteten. Speedtest kan avslöja kapacitetsbrist men inte förklara verksamhetsstörningar.

SLA-dokument: läs leverantörens SLA. Granska definitioner, servicenivåer, serviceklasser och sanktioner. Jämför mot era kritiska flöden.

Kort svar: definitioner avgör om en incident ger ersättning; servicenivåerna täcker vanligen drifttid, prestanda och svarstider för support; sanktionen är vanligen vite eller prisavdrag, och i molntjänster kan servicekrediter bli aktuella; tröskeln är upptidsgarantin, till exempel 99,9 procent.

Saknas tröskel, kreditprocent, tak och ansökningsfrist i avtalet är servicekrediten inte bedömbar.