Hvad skal en SLA-aftale egentlig indeholde?
En SLA, en serviceniveauaftale, fastlægger hvor hurtigt og pålideligt en leverandør skal varetage drift og vedligeholdelse. Nøgletallene er svartid, løsningstid og oppetid, fastsat efter sagens prioritet. Pointen er at matche niveauerne med forretningens faktiske behov (hvert ekstra nital i oppetiden koster uforholdsmæssigt meget) og at få måling, rapportering og bod på plads som faktisk bliver fulgt op.
En SLA, en serviceniveauaftale, er løftet om hvordan et system skal passes efter at det er bygget: hvor hurtigt fejl udbedres og hvor ofte tjenesten må være nede. Det er et af de vigtigste bilag i en driftsaftale og et af de mest misforståede. Mange kunder køber enten for lidt og står rådvilde ved et nedbrud, eller for meget og betaler for et beredskab systemet aldrig får brug for. Nøglen er at stille krav til niveauer der matcher forretningens faktiske behov.
Svartid, løsningstid og sagsprioritet
Det første der skal på plads, er hvad tiderne faktisk måler, for her blander leverandører og kunder ofte begreberne sammen.
- Svartid er hvor hurtigt leverandøren bekræfter sagen og begynder at arbejde på den. Den siger ikke meget om hvornår fejlen faktisk er væk.
- Løsningstid er hvor lang tid det må tage før problemet er løst. Det er det tal der beskytter din forretning.
En hurtig svartid uden en tydelig løsningstid er en fælde: Du får et venligt “vi kigger på det” og sidder så med systemet nede i to døgn uden at aftalen er brudt. Kræv derfor altid løsningstider, ikke kun svartider.
Begge skal desuden kobles til prioritet. Et totalstop i kernesystemet er ikke det samme som et skævt ikon. En almindelig inddeling er kritisk (forretningen står stille), høj (vigtig funktion nede, men der findes en vej udenom) og normal (generende, men ikke akut). Definér niveauerne konkret i aftalen. Ellers bliver hver sag en forhandling om hvor alvorlig den egentlig er.
Rimelige niveauer for oppetid og hvad de koster
Oppetid angives i procent, og forskellen mellem niveauerne ser lille ud, men er enorm i både tilladt nedetid og pris. Hvert ekstra nital kræver mere redundans, mere overvågning og mere vagtberedskab.
| Oppetidsniveau | Tilladt nedetid pr. måned |
|---|---|
| 99 % | Cirka 7 timer |
| 99,9 % | Cirka 43 minutter |
| 99,99 % | Cirka 4 minutter |
Skridtet fra 99,9 til 99,99 procent lyder som en bagatel, men mangedobler ofte omkostningen fordi det kræver at systemet kan tåle at dele går i stykker uden at tjenesten bliver afbrudt. Stil derfor modspørgsmålet før du stiller krav: Hvad koster en times driftsstop forretningen? For et internt værktøj er svaret ofte “irriterende, men til at leve med”, og så er 99,9 procent rigeligt. For et betalingsflow midt i julehandlen er svaret et andet.
Tilpas niveauet efter hvor kritisk tjenesten er
Den dyreste fejl er at give alle systemer det samme høje niveau. Gennemtænkt drift og vedligeholdelse deler tjenesterne op og fastsætter beredskabet efter hvor meget de faktisk betyder.
- Forretningskritisk (f.eks. webshoppens checkout): høj oppetid, kort løsningstid, vagt døgnet rundt.
- Vigtig for driften (f.eks. et internt sagssystem): god oppetid, udbedring i kontortiden, længere marginer.
- Understøttende (f.eks. et rapportværktøj): grundlæggende oppetid, længere løsningstider, ingen vagt.
Ved at inddele tjenesterne i lag betaler du kun for højt beredskab der hvor der er brug for det, i stedet for at lægge vagtomkostninger på det rapportværktøj som ingen savner en søndag nat.
Bod, måling og opfølgning der faktisk finder sted
Bod, altså fradrag når niveauerne ikke overholdes, er den del alle gerne vil forhandle om, og den der betyder mindst økonomisk. Godtgørelsen dækker sjældent dit reelle tab ved et nedbrud. Dens egentlige værdi er at den fremtvinger måling: Man kan ikke kræve bod uden at nogen måler resultatet.
Og det er dér de fleste SLA’er falder. Et scenarie: En virksomhed havde en aftale med flotte tal, 99,9 procent oppetid og bod ved mangler, men ingen måling og ingen månedsrapport. Da systemet gang på gang drillede, var der intet grundlag at pege på, og aftalen blev en papirtiger. En SLA uden måling og rapportering er kun en hensigtserklæring.
Kræv derfor tre ting ud over selve niveauerne: hvordan resultatet måles, en tilbagevendende rapport som du faktisk modtager, og en tydelig konsekvens ved gentagne brud. Så bliver aftalen et styringsværktøj i stedet for pynt.
Vil du fastsætte serviceniveauer der passer til netop jeres systemer frem for en standardskabelon, hjælper vi i Weapp gerne. Kontakt os med en beskrivelse af hvad I har i drift.
Ofte stillede spørgsmål
Hvad er forskellen på svartid og løsningstid?
Svartid er hvor hurtigt leverandøren bekræfter en sag og begynder at arbejde på den. Løsningstid er hvor lang tid det må tage før fejlen er løst. Det er løsningstiden der beskytter din forretning: En hurtig bekræftelse er værdiløs hvis løsningen trækker ud i dagevis. Fastsæt derfor tydelige løsningstider pr. prioritetsniveau, ikke kun svartider.
Hvad betyder 99,9 procents oppetid i praksis?
99,9 procent tillader omkring 43 minutters nedetid om måneden mens 99,99 procent kun tillader godt fire minutter. Hvert ekstra nital koster betydeligt mere fordi det kræver redundans og vagtordning. Spørg dig selv hvad et nedbrud faktisk koster forretningen før du betaler for fem nitaller. Mange systemer klarer sig fint med 99,9.
Skal alle systemer have samme serviceniveau?
Nej, og at give dem det er en dyr fejl. Et forretningskritisk betalingsflow retfærdiggør høj oppetid og kort løsningstid døgnet rundt mens et internt rapportværktøj klarer sig med kontortid og længere løsningstider. Del tjenesterne op efter hvor kritiske de er, og fastsæt niveauet derefter, så betaler du kun for det beredskab du har brug for.
Er bod værd at forhandle ind i aftalen?
Bod fungerer mest som styringssignal, ikke som indtægtskilde: Godtgørelsen dækker sjældent dit faktiske tab. Dens reelle værdi er at den fremtvinger måling og opfølgning og giver dig et værktøj ved gentagne mangler. En SLA uden måling og rapportering er derimod kun en hensigtserklæring uanset hvor høj en bod der står på papiret.