En stor kunde vil have et oppetidstal i kontrakten, og salget vil gerne sige ja med det samme. En SLA (service level agreement, aftalen om det serviceniveau, kunden kan regne med) er et løfte, som driften skal indfri hver eneste måned, også den måned, hvor cloududbyderen har en dårlig dag. Før tallet skrives ind, skal I vide fire ting: hvad produktet faktisk har leveret, hvad I selv er afhængige af, hvad der tæller som nedetid, og hvem der rapporterer. Et lavere tal, I kan holde, er mere værd for begge parter end et højt tal, ingen har regnet på.
Start med det, I faktisk har leveret
Mange softwarehuse har aldrig målt oppetid set fra kunden. De ved, at serverne kører, men ikke om en bruger kan logge ind og gennemføre den vigtigste handling i produktet. Den forskel er afgørende. En server kan svare fint, mens login er nede.
Sæt derfor en automatisk prøve op, der udefra gennemfører det kerneflow, kunderne betaler for, med få minutters mellemrum. Lad den køre i en periode, før I lover noget. Har I allerede en driftslog, kan I gå de seneste kvartaler igennem og tælle, hvor længe kunderne reelt var berørt. Tallet er ofte en anden historie end den, teamet husker.
To spørgsmål afgør, om tallet er til at stole på:
- Måler I hele vejen, som kunden oplever det, eller kun enkelte dele af systemet?
- Tæller I perioder, hvor produktet var så langsomt, at det reelt ikke kunne bruges?
Jeres løfte kan ikke være bedre end jeres afhængigheder
Produktet står på en cloudplatform, en betalingstjeneste, en mailtjeneste, måske en login-udbyder og en sprogmodel. Hvis login-udbyderen er nede, er produktet nede for kunden, uanset hvem fejlen ligger hos.
Lav en liste over de tjenester, kerneflowet ikke kan fungere uden, og læs, hvad hver af dem selv lover. Stil derefter tre spørgsmål til hver: Hvad sker der i produktet, når tjenesten er væk? Kan funktionen køre videre i en begrænset udgave? Hvor hurtigt kan I skifte, hvis den er væk længe? Her opdager mange, at en lille hjælpetjeneste kan vælte det hele, fordi ingen har bygget en reserve.
Aftalen skal også sige, om nedbrud hos underleverandører tæller med. Det er en forhandling, og kunden vil ofte mene, at det er jeres ansvar at vælge dem. Tag spørgsmålet op, før salget har lovet noget. Formuleringen er et spørgsmål til advokat.
Vedligeholdelse og det, der ikke tæller
En oppetidsaftale er kun klar, når det står skrevet, hvad der ligger uden for målingen. De typiske poster er planlagt vedligeholdelse, fejl hos kunden selv og force majeure. Planlagte vinduer skal passe til kundernes arbejdsdag. En kunde med natarbejde vil se anderledes på en planlagt lukning søndag aften end et kontor.
Spørg også, om vinduerne overhovedet er nødvendige. Kræver hver opdatering, at produktet lukkes, er det et tegn på, at releaseprocessen skal have et eftersyn, se hver release er en risiko. Løfter I oppetid uden vinduer, skal arkitekturen kunne bære det, og det koster udviklingstid, der kunne være gået til noget andet.
Hvorfor det højeste tal sjældent er det rigtige
Hvert ekstra niveau af driftssikkerhed koster mere end det forrige, og Googles bog om driftsarbejde peger på, at brugerne ofte slet ikke mærker forskellen, fordi deres egen forbindelse og enhed er mere ustabil end tjenesten. Den samme kilde beskriver en nyttig tanke, som kaldes fejlbudget (error budget): det tal, I lover, fastlægger, hvor meget upålidelighed I har råd til. Er budgettet brugt, bremser I nye udgivelser og bruger tiden på stabilitet. Er der rigeligt tilbage, kan I tage større chancer.
For en ledelse er det en brugbar måde at gøre oppetid til en forretningsbeslutning. Et højere tal er et valg om at bruge mere af kapaciteten på drift og mindre på nye funktioner. Den afvejning hører til i køreplanen, og den bør træffes af ledelsen med åbne øjne, se teknisk køreplan.
Svartid og rapportering er også en del af løftet
Oppetid er ét tal. En brugbar SLA siger også, hvornår I reagerer på en fejl, hvordan fejl inddeles efter alvor, og hvilke tider supporten dækker. Lover I svar om natten, skal nogen kunne vækkes, og det kræver en vagtordning, teamet kan holde til i længden. Hvad det indebærer, står i overvågning, vagt og driftshændelser.
Læseren på den anden side af bordet sammenligner ofte jeres aftale med begreberne i SLA forklaret for ledelsen. Sikkerhedskrav, der følger med i samme kontrakt, behandles i sikkerhedskrav i kundekontrakten.
Rapporteringen er det, der gør løftet troværdigt. En kort månedlig opgørelse med målt oppetid, hændelser og opfølgning viser kunden, at I har styr på tallene. Beskriv også, hvad der sker, når løftet brydes. Kompensation er et aftalespørgsmål, men den tekniske side er enkel: I skal kunne dokumentere, hvad der skete, fra jeres egne målinger.
Tjek, før tallet går i kontrakten
- Kan I vise målt oppetid for det seneste halve år, set fra kunden?
- Er alle afhængigheder i kerneflowet listet med deres egne løfter?
- Er der en plan for hver af dem, hvis de falder ud?
- Kan vagten dække de tider, aftalen lover?
- Har den, der ejer driften, læst aftalen før underskrift?
Er svaret nej til flere af dem, kan I lægge et lavere tal ind nu og aftale et nyt, når målingerne er på plads. De fleste kunder foretrækker et ærligt svar med en plan.
Det skal I lade være med
· At lade salget fastsætte tallet uden en samtale med dem, der driver produktet.
· At kopiere en konkurrents tal fra hjemmesiden.
· At måle på servere, når kunden oplever noget andet.
· At love særlige vilkår til én kunde, når alle kunder står på samme platform.
Det skal I kræve af den eksterne
- ☐ Et målt udgangspunkt for oppetid set fra kunden.
- ☐ En liste over afhængigheder i kerneflowet med en plan for udfald.
- ☐ Et forslag til SLA-niveau, der er koblet til vagt og kapacitet.
- ☐ En skabelon til den månedlige rapport til kunderne.
- ☐ En klar forklaring til ledelsen af, hvad et højere tal koster i udviklingstid.
Kilder
- Google: Site Reliability Engineering, kapitlet Embracing Risk: fejlbudget og hvorfor fuld pålidelighed er et dårligt mål.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Hvem ejer driften? · Produktet var nede: dagen efter
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
