Forside · Gennemgået oktober 2026 · Af John Nielsen
Et SLA-tal som 99,9 procent oppetid er ikke en måling, men resultatet af en beregning, der bygger på en række valg: hvor der måles fra, hvor ofte, hvad der tæller som nede, hvilke perioder der trækkes fra, og hvordan resultaterne lægges sammen. Når to parter når frem til forskellige tal for den samme måned, skyldes det næsten altid forskelle i disse valg og ikke, at én af dem lyver. En teknisk efterregning starter derfor med at fastlægge metoden og de rå data og regner derefter tallet igen på en dokumenteret måde.
Hvad SLA-aftalen typisk definerer, og hvordan tvisten forløber juridisk, er beskrevet i SaaS-tvister: oppetid, SLA og logdata. Hvordan virksomheden selv kan måle løbende, står i Leverandøren overholder ikke SLA. Her handler det om selve beregningen.
Grundformlen
Oppetid beregnes typisk som den målte periode minus nedetid, divideret med den målte periode. Bag formlen gemmer sig tre definitioner, der hver kan flytte resultatet:
- Den målte periode: hele kalendermåneden, kun åbningstid, eller kun tid uden for planlagt vedligehold?
- Nedetid: fra hvornår til hvornår, og efter hvilken definition af nede?
- Undtagelser: hvilke hændelser er undtaget, fx force majeure, kundens egne fejl eller tredjepartstjenester?
For at give en fornemmelse af størrelserne: 99,9 procent af en måned med 30 dage svarer til ca. 43 minutters tilladt nedetid. Små forskelle i metoden kan derfor betyde, at en måned går fra opfyldt til ikke opfyldt.
Målepunktet
Hvor der måles fra, er afgørende:
- Intern overvågning i leverandørens eget netværk kan vise, at tjenesten svarer, selv om kunderne ikke kan nå den på grund af et netværks- eller DNS-problem.
- Ekstern syntetisk overvågning fra en eller flere lokationer på internettet måler brugerens vej, men kan registrere fejl, der skyldes måleudstyrets egen forbindelse.
- Komponentmåling af enkelte servere eller tjenester siger ikke nødvendigvis noget om, om den samlede løsning virkede for brugeren.
- Reelle brugerdata, fx fejlrater i webserverlogs, viser den faktiske oplevelse, men kun når der var brugere.
Webserver- og applikationslogs er ofte den bedste uafhængige kontrol af en syntetisk måling. Se Webserverlogs.
Samplingsinterval og tærskler
Syntetisk overvågning tester typisk med et fast interval, fx hvert minut eller hvert femte minut. Det har to konsekvenser:
- Opløsningen. Et nedbrud kan begynde og slutte mellem to målinger. Ved et interval på fem minutter kan et nedbrud på fire minutter forsvinde helt, og et nedbrud på seks minutter kan registreres som fem eller ti.
- Tærskler. Mange værktøjer kræver flere fejlede målinger i træk, før de registrerer nedetid, for at undgå falske alarmer. Det betyder, at korte nedbrud systematisk ikke tæller med, og at starttidspunktet forskydes.
Efterregningen skal angive intervallet og tærsklerne og vurdere, hvor stor usikkerhed de giver i det samlede tal.
Hvad er “nede”?
Definitionen af nede er ofte mindre præcis i aftalen end i måleværktøjet:
- Svarer serveren med en fejlkode, eller svarer den slet ikke?
- Tæller en svartid over en bestemt grænse som nede?
- Tæller delvis nedetid, fx at én funktion ikke virker, eller at kun nogle kunder er ramt?
- Tæller en side, der svarer korrekt, men med forkert indhold?
Måleværktøjet har sin egen definition, typisk en HTTP-statuskode og eventuelt et forventet tekststykke på siden. Den skal sammenholdes med aftalens definition. Afviger de, skal efterregningen enten bruge aftalens definition på de rå data eller beskrive, hvorfor det ikke kan lade sig gøre.
Planlagt vedligehold og undtagelser
Planlagt nedetid trækkes typisk fra, men betingelserne varierer: varsling i forvejen, bestemte tidsvinduer og et loft over den samlede mængde. Kontrollér for hver periode, der er trukket fra, om den var varslet som krævet, og om vedligeholdet faktisk lå inden for det varslede vindue. Varslingsmails, statussider og ændringstickets er kilderne. Se Ticket-systemer: ændringshistorik.
Måleudstyrets egne huller
Overvågningen kan selv være nede. Når måleværktøjet ikke har data for en periode, skal det besluttes, om perioden tæller som oppe, nede eller udelades. Mange værktøjer udelader den, hvilket hæver oppetiden. Find hullerne i de rå data, og vis, hvordan de er behandlet. Overvågningsdata som kilde er beskrevet i Monitoreringsdata som bevis.
Sammenlægning
Når der måles fra flere steder eller på flere komponenter, skal resultaterne lægges sammen. Et gennemsnit på tværs af målepunkter kan skjule, at én region var nede i timevis. Tæller tjenesten som nede, hvis ét målepunkt fejler, hvis et flertal fejler, eller kun hvis alle fejler? Valget kan ændre resultatet markant og skal fremgå.
For svartider gælder det samme. Et gennemsnit skjuler de langsomme forespørgsler. Percentiler, fx den 95. eller 99. percentil, giver et mere retvisende billede, men aftalen kan være formuleret med gennemsnit.
Tid og tidszoner
Månedens grænser afhænger af tidszonen. Et nedbrud kl. 00.30 dansk tid den 1. i måneden ligger i den foregående måned i UTC. Sommertidsskiftet giver en måned med en time mere eller mindre. Se Sommertid og tidszoner i rapporten. Svar- og løsningstider på supportsager har egne regler for åbningstid og pauser og beregnes af ticket-systemet ud fra dem.
Leverandørens månedsrapport
Leverandørens SLA-rapport er typisk genereret automatisk af overvågnings- eller ticket-systemet og viser et samlet tal pr. måned. Den er en sammenfatning, ikke en kilde. Bed om de rå målinger bag rapporten og om konfigurationen af den måling, der producerede den. Kontrollér også, om rapportens beregning er ændret undervejs i aftaleperioden, fx ved et skift af overvågningsværktøj eller en ny definition af planlagt vedligehold. Et skift midt i perioden kan forklare, hvorfor tallene pludselig ser bedre ud, uden at driften er blevet det.
Efterregning i praksis
- Fastlæg aftalens definitioner: periode, nedetid, undtagelser og sammenlægning.
- Hent de rå data: hver enkelt måling med tidspunkt, målepunkt, resultat og svartid, ikke kun månedsrapporten.
- Beskriv måleværktøjets konfiguration: interval, tærskler, kontrolkriterier og målepunkter, med eventuelle ændringer i perioden.
- Find huller i måledata og beslut, hvordan de behandles.
- Beregn med aftalens definitioner, og beregn derefter med de alternative fortolkninger, der er i spil.
- Kontrollér mod uafhængige kilder som webserverlogs, fejlrater og supportsager.
Præsenter resultatet som en tabel med en kolonne pr. fortolkning, så forskellen mellem parternes tal kan føres tilbage til konkrete valg. En graf over målingerne i tid kan gøre det tydeligt, hvor afvigelserne ligger, se Visualiseringer i forensiske rapporter.
Hvad efterregningen kan vise
En efterregning kan vise, hvad SLA-tallet bliver med en bestemt metode på bestemte data, og præcist hvor parternes tal adskiller sig. Den kan ikke afgøre, hvilken fortolkning af aftalen der er den rigtige. Det er et juridisk spørgsmål. Men ved at gøre forskellene konkrete og regnbare kan den reducere tvisten til de få valg, der faktisk betyder noget.
Kilder og versioner
- RFC 9110: HTTP-semantik og statuskoder
- RFC 3339: tidsstempler på internettet
- Google SRE: serviceniveaumål og målemetoder
Senest gennemgået: oktober 2026.
Næste skridt
Læs også: Wiki og kravdokumenter: sidehistorik og kravændringer · Monitoreringsdata som bevis: overvågning, APM og opbevaring
→ Uvildig IT-sagkyndig med forensic-baggrund · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
