En serviceaftale, ofte kaldet SLA, siger, hvad udbyderen lover om tilgængelighed, ydelse og support, og hvad I får, hvis løftet brydes. Tallet for oppetid betyder kun noget, når I ved, hvad der tæller med, over hvilken periode det måles, og hvad kompensationen er, og det gælder lige meget, om udbyderen er europæisk.
Artiklen er til den driftsansvarlige, der skal læse en serviceaftale og sammenligne den med en anden. Den bygger på Europa-Kommissionens retningslinjer for standardisering af serviceaftaler i cloud fra 2014. De er vejledning og intet lovkrav, og de er skrevet til erhvervskunder.
Oppetid: hvad der tæller med
Kommissionens retningslinjer beskriver oppetid som den tid i en periode, hvor tjenesten var tilgængelig, sat i forhold til den samlede mulige tid. Tre ting afgør, hvad tallet betyder i jeres aftale.
Perioden. Retningslinjerne nævner, at perioden oftest er en faktureringsmåned. Et udfald på flere timer kan altså stadig holde sig inden for løftet, hvis resten af måneden går godt.
Planlagt vedligehold. Retningslinjerne nævner, at det er almindeligt at trække planlagt vedligehold fra, før oppetiden opgøres. Læs, hvordan vedligehold varsles, hvor ofte det må ske, og om det kan lægges i jeres åbningstid.
Hvad “tilgængelig” betyder. En tjeneste kan svare og alligevel være så langsom eller fejlbehæftet, at den ikke kan bruges. Retningslinjerne peger på, at det er nyttigt, at aftalen siger, hvad brugbar betyder. Står der intet, kan en langsom tjeneste tælle som oppe.
Et procenttal for oppetid må kun bruges med kilde i den konkrete aftale. Sammenlign aldrig to tal uden at have læst de tre punkter for begge.
Hvad oppetiden dækker i en infrastruktur
En serviceaftale gælder for bestemte tjenester. Hos en udbyder af infrastruktur kan der være forskellige løfter for virtuelle servere, lager, netværk og kontrolpanelet, og nogle tjenester kan stå uden løfte. Læs, hvilke tjenester der er omfattet, og om løftet gælder den enkelte server eller tjenesten som helhed i en region.
For jer er det samlede system det, der tæller. Et system, der bruger servere, lager og en lastbalancer, er nede, hvis én af dem er nede. Det er vores vurdering, at systemets reelle tilgængelighed derfor skal vurderes ud fra alle de tjenester, det afhænger af, og ud fra jeres egen arkitektur med reserver og flere zoner.
Svartid og ydelse
Retningslinjerne nævner, at svartid afhænger af, hvor målingen starter og slutter, og om netværket på vejen er med. Et løfte om svartid inde i udbyderens datacenter siger intet om svartiden for jeres brugere. Læs, hvor der måles, og mål selv fra de steder, jeres brugere sidder.
Support er sine egne tal
Supporttider, svartid og løsningstid er forskellige mål. Med svartid menes tiden, til udbyderen har bekræftet at have modtaget sagen. Løsningstid er tiden, til fejlen er rettet. Retningslinjerne skelner mellem dem og nævner, at de typisk varierer med sagens alvor. En kort svartid siger intet om, hvornår systemet kører igen. Hvem der tager telefonen, står i Support: hvem tager telefonen, på hvilket sprog og hvornår?
Kompensationen
Retningslinjerne nævner, at kompensation kan have forskellige former, fx tilbagebetaling af gebyrer, ekstra ydelser eller anden kompensation. Læs, om kompensationen kommer af sig selv, eller om I skal kræve den inden for en frist, og hvad den højst kan udgøre. En kredit på næste regning står ikke nødvendigvis i forhold til, hvad et udfald koster forretningen. Den er et økonomisk signal til udbyderen. Beredskabet ligger i jeres egen arkitektur.
Ophør hører også med
Retningslinjerne medtager ophør som en del af serviceaftalen: en periode til at hente data, opbevaring af sikkerhedskopier under ophøret og en beskrivelse af data, der bliver tilbage bagefter. Det forbinder serviceaftalen med muligheden for at komme videre. Mere om punkterne i aftalen står i Hostingaftalen: punkterne, en driftsansvarlig skal læse.
Der findes en international standard for rammer for serviceaftaler i cloud, ISO/IEC 19086, som retningslinjerne henviser til. Vi har ikke kunnet læse den, og den er ikke brugt her.
Hvad det kræver, og hvad det koster at lade være
Læsningen af en serviceaftale efter punkterne ovenfor tager en driftsperson et par timer pr. udbyder. Hertil kommer en opgørelse af, hvilke tjenester jeres vigtigste systemer afhænger af, og hvad et udfald koster forretningen pr. time i jeres egne tal. Den opgørelse kan genbruges i beredskabsplanen.
Lader I være, sammenligner I tal, der ikke måler det samme. Et højere tal kan dække en kortere liste af tjenester eller en bredere undtagelse for vedligehold. Og når udfaldet kommer, viser det sig, at kompensationen er en kredit, der skal søges om, og at den ikke står i forhold til tabet.
Det skal I lade være med
- At sammenligne oppetid uden at læse definitionen · periode, vedligehold og “tilgængelig” ændrer tallet.
- At blande svartid og løsningstid sammen · en kvittering er endnu ingen reparation.
- At regne kompensation som beredskab · den står ikke nødvendigvis i forhold til tabet.
Det skal valget kunne vise
- ☐ Oppetid med periode, undtagelser og definition af tilgængelig, pr. tjeneste.
- ☐ Hvor svartid måles, og jeres egne målinger fra brugernes side.
- ☐ Svartid og løsningstid pr. alvorsgrad.
- ☐ Kompensationens form, frist og loft.
Kilder
- Europa-Kommissionen, Cloud Service Level Agreement Standardisation Guidelines, 24. juni 2014: afsnit 1 og 3. Vejledning, ikke regel.
Senest gennemgået: november 2026.
Næste skridt
Find serviceaftalen for den tjeneste, jeres vigtigste system kører på, og læs de tre punkter om oppetid.
Læs også: To datacentre, to regioner, to udbydere · Ansvarsdeling på en europæisk platform
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
