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

Vad SLA i molntjänster faktiskt reglerar

SLA står för Service Level Agreement och anger vilken kvalitetsnivå en leverans ska hålla. Metoden kommer från it-området, men kan även reglera andra tjänsteleveranser. I it-sammanhang regleras 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 gånger ett fel får förekomma under en given period.

Fyra delar är centrala. Definitioner ska säkerställa att parterna är överens om vad som är ett fel och hur tillgänglighet beräknas. Servicenivåer anger nivån i olika delar och avseenden. Serviceklasser gör att nivån kan ändras under avtalstiden, exempelvis tillgänglighet från 98 procent till 99 procent. Sanktioner reglerar vad som händer om avtalad servicenivå inte uppnås.

I molntjänster handlar avtalet inte bara om driftstid. AWS SLA:er innehåller vanligtvis garantier om drifttid, prestanda och svarstider för support, och beskriver båda parters ansvar för att hålla servicenivån. 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.

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

I AWS SLA är upptidsgarantin en av de viktigaste komponenterna: 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. Procentsatsen säger inget förrän den kopplas till mätperioden. Räkna i stället om procentsatsen till förväntad otillgänglig tid för den mätperiod avtalet anger och jämför med hur länge kritiska flöden kan vara nere innan intäkter eller service tappas.

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 hur 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.

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. Garantierar avtalet bara plattformsnivå medan ert kritiska flöde passerar flera tjänster, säger nio-talet lite om er faktiska risk.

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. Genom att specificera prestanda i avtalet försäkrar leverantören att applikationerna ska fungera som förväntat på plattformen.

Svarstider för support ingår också ofta i AWS SLA:er, med garantier om en maximal tid. Skillnaden mot tillgänglighet är avgörande: en upptidsgaranti säger inget om hur snabbt ni får hjälp när något går fel. Kontrollera om svars- och åtgärdstider gäller dygnet runt eller bara kontorstid, och om de skiljer sig mellan allvarlighetsgrader.

Prestanda märks oftare i användarupplevelsen än i driftstatistiken. Teams samtalskvalitet påverkas av roundtrip time, jitter och packet loss, vilket syns i samtalshälsan enligt Microsoft Support. Hög latency märks i molntjänster, fjärrskrivbord och samtal. 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.

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.

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. Med tydlig målbild blir det lättare att avgöra vad som är en incident i avtalets mening.

Välj tre fasta mätpunkter som används varje gång. En bra start är 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 fyra storheter mot dem: latency (fördröjning i trafiken), jitter (variation i svarstid), paketförlust (tappade datapaket) och tillgänglighet. Den sista fångar kortare avbrott och dippar som knappt syns i ett speedtest men märks direkt i drift.

Bygg en enkel mät- och loggrutin

Skapa en baslinje genom att mäta i 5 till 10 arbetsdagar och spara historiken. Logga samma fyra storheter – latency, jitter, paketförlust och tillgänglighet – mot samma mätpunkter varje gång. 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.

Från dipp till dokumenterad incident

Loggad data blir underlag först när den kopplas till tidpunkt, mätpunkt, typ av avvikelse 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.

Eftersom målbilden definierar vilka situationer som är affärskritiska kan samma avbrott beskrivas i verksamhetstermer: sessionen i kassasystemet tappades, samtalet bröts eller fjärrsupporten kunde inte arbeta. Incidenten dokumenteras då mot den situation avtalet ska skydda, inte mot ett allmänt prestandaintryck – vilket är den typ av underlag en SLA-dialog eller ersättningsbegäran kräver.

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 är servicekrediter en vanlig variant: om AWS inte uppfyller sin upptidsgaranti kan kunderna ha rätt till servicekrediter eller annan kompensation.

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

Kontrollera trösklarna före signering. Vid vilken nivå inträder ersättningen, hur beräknas den och finns ett tak? Vad krävs av er som kund – måste ni ansöka, inom vilken tid och med vilken dokumentation av felet? 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. Notera också vad sanktionen täcker: vite, prisavdrag eller servicekrediter kompenserar en del av avgiften, inte verksamhetens förlorade intäkter.

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?

Mätbarhet: för it-tjänster kan mätningen ofta 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 latency, jitter, paketförlust och tillgänglighet mot samma punkter. Bygg en baslinje över 5 till 10 arbetsdagar och logga avvikelser löpande med tidpunkt, mätpunkt, typ av avvikelse och verksamhetspåverkan.