Zo’n SLA, wat moet daar eigenlijk in staan?

Ieder ICT-bedrijf heeft ermee te maken: Service Level Agreements. In zo’n SLA staat welk kwalitatieve serviceniveaus een afnemer mag verwachten. En dat gaat verder dan ‘99,9 procent beschikbaarheid’. Helaas gaat er nog wel eens wat mis met deze documenten.

Door Dirkjan van Ittersum

Het belang van een SLA kunnen we het best uitleggen aan de hand van een voorbeeld. Stel, een ondernemer heeft een mooie webwinkel opgebouwd. Hij draait een aardige omzet, heeft veel vaste klanten en er zijn verschillende mensen in dienst. Plots slaat het noodlot toe: zaterdagochtend vliegen de servers eruit! Op het slechtst mogelijke moment: het weekend voor kerst. Pas na eindeloos bellen en mailen komt er een reactie van de hostingprovider en wordt het probleem zondagavond opgelost. Maar toch: de winkel is bijna het hele weekend offline geweest. De schade door misgelopen inkomsten is enorm.

Met lege handen

Bij dit soort nachtmerriescenario’s wordt de Service Level Agreement (SLA) uit de la getrokken. Daarin staat hoe lang een dienst offline mag zijn en hoe snel er een oplossing geboden moet worden. En dan blijkt dat er vaak niet goed is nagedacht over de afspraken in zo’n SLA. Want stel dat erin staat dat er een uptime van 99,5 procent per jaar is gegarandeerd? Helemaal niet ongebruikelijk, want zeg nu zelf: 99,5 procent klinkt best goed…

Maar wie het narekent, komt erachter dat de webhost in bovenstaand geval niets te verwijten valt. Volgens deze SLA mag het bedrijf namelijk bijna 1 dag en 20 uur offline zijn! De ondernemer staat met lege handen. Hij kan de schade niet verhalen op de host en is zijn inkomsten definitief misgelopen. Er wacht hem een kerstdiner met een kater. En zelfs als de dienst het volle weekend (48 uur) offline zou zijn geweest, was het niet veel beter geweest. Het is niet ongebruikelijk dat de SLA dan bepaalt dat de ondernemer die maand zijn hostingkosten niet hoeft te bepalen (of een korting daarop ontvangt). Lang niet genoeg om de schade te dekken…

Geen dure BMW

Het voorbeeld maakt duidelijk welke zaken belangrijk zijn bij het afsluiten van een SLA, namelijk:

  1. Is de beschikbaarheid van dienst gegarandeerd op de momenten die er toe doen?
  2. Hoe snel moet een dienstverlener reageren op een melding en een oplossing bieden?
  3. Wat is er afgesproken over aansprakelijkheid en schadevergoedingen?

Helaas komt het nog te vaak voor dat de afspraken in de SLA tekortschieten. “In veel contracten wordt gesproken over ‘best effort’, maar dat is geen SLA”, vertelt Bart de Ruijter van Metri Group. “In een SLA staat hoe lang een dienst offline mag zijn, terwijl in het geval van ‘best effort’ er alleen sprake is van een poging de dienst zo goed mogelijk te leveren.”

bart de ruijter, metri
Bart de Ruijter, Metri.

De Ruijter hamert erop dat een bedrijf goed moet nadenken welke afspraken noodzakelijk zijn. “Vaak is er vanuit de business van een bedrijf de vraag naar 99,9 procent beschikbaarheid, maar het is de vraag of je dat echt nodig hebt. Vergelijk het maar met een auto. Iedereen wil een dure BMW, maar heb je die echt nodig? Een voordeliger model is vanuit zakelijk oogpunt misschien verstandiger. Zo is het ook met de beschikbaarheid van een dienst.”

Om te bepalen wat je nodig hebt, stelt Metri scenario’s op in opdracht van bedrijven. “Daarin staat wat het effect is van een bepaalde uitval”, zegt De Ruijter. “Zo kom je er snel achter welke uptime je nodig hebt. Het is belangrijk om de kosten van uptime te relateren aan de business. Onderzoek wat voor financiële gevolgen uitval heeft en hoeveel je bereid bent te betalen om het risico op uitval verder te beperken. Bij tradingfloors is het vanzelfsprekend dat de uptime honderd procent moet zijn. Bij een overheidsbedrijf is minder wellicht genoeg. Als iedereen daar tussen 9 en 17 uur werkt, kun je beter afspreken dat er overdag 99,9 procent uptime moet zijn.”

 


99,9 procent, hoeveel is dat eigenlijk?

Op internet is een handige SLA-uptimecalculator te vinden. Daaruit blijken de volgende (toch wel verrassende) cijfers over hoe lang een dienst per jaar maximaal uit de lucht mag zijn:

  • 99% uptime p.j. = maximaal 3 dagen 15 uur 30 seconden offline
  • 99,5% uptime p.j. = maximaal 1 dag 19 uur 45 seconden offline
  • 99,8% uptime p.j. = maximaal 17 uur 31 minuten 54 seconden offline
  • 99,9% uptime p.j. = maximaal 8 uur 45 minuten 57 seconden offline
  • 99,99% uptime p.j. = maximaal 52 minuten 36 seconden offline
  • 99,999% uptime p.j. = maximaal 5 minuten 16 seconden offline
  • 99,9999% uptime p.j. = maximaal 31 seconden offline

Zelf rekenen? De site is te vinden op http://uptime.is.


 

 

Streeftijden?

Ook jurist Jeroen van der Lee van advocatenkantoor Bird & Bird houdt zich regelmatig bezig met SLA’s. “Het is een dagelijks onderdeel van ons werk. Ook nu weer ligt er een stapeltje SLA’s waaraan we werken. Wat me opvalt zijn de verschillen in ‘look and feel’ tussen de documenten. In sommige gevallen zijn het korte documenten van twee A4’tjes, maar andere SLA’s zijn enorme boekwerken waarin ieder detail tot achter de komma is geregeld.”

Overigens wil Van der Lee niet zeggen dat het een beter is dan het ander. “De uitgebreide SLA’s worden opgesteld door bedrijven die zich bijvoorbeeld richten op banken of het verzekeringswezen. Daar kunnen ze niet met twee A4’tjes aankomen.” Van der Lee komt ook SLA’s tegen die in de loop der tijd telkens zijn uitgebreid. Die zijn veelal van mindere kwaliteit. “Het zijn documenten waar steeds wat aan is toegevoegd, bijvoorbeeld in reactie op vragen van klanten. Het zijn documenten die niet uitblinken in consistentie en helderheid”, zegt Van der Lee met gevoel voor understatement.

Jeroen van der Lee, Bird&Bird.
Jeroen van der Lee, Bird&Bird.

Van der Lee geeft een voorbeeld van een slecht geformuleerde SLA: “Soms staat er dat de dienst 24x7x365 wordt gegarandeerd. Impliciet garandeer je een uptime van honderd procent, maar waarschijnlijk wordt dat niet bedoeld. Ook komen we soms contracten tegen waarin staat dat alles op basis van best effort is, terwijl in de bijlage ‘harde’ respons- of oplostijden worden genoemd. Zijn deze respons- en oplostijden nu gegarandeerd of slechts ‘streeftijden’?

Wel acceptabel

SLA’s zijn ook niet altijd even helder over de responstijden in geval van problemen. “Daarbij kun je je opnieuw afvragen of dat altijd even snel moet”, zegt De Ruijter. “Overdag gelden er andere eisen dan ’s nachts. Mensen die ’s nachts werken hebben vaak te maken met kritieke situaties, waardoor ze dan juist een snelle respons willen – ook al kost het misschien wat meer. Denk ook na over hoe je kunt voorkomen dat er hulpvragen komen. Maak bijvoorbeeld afspraken met de leverancier om gezamenlijk het aantal calls terug te brengen.”

Volgens Van der Lee realiseren bedrijven zich het belang van responstijden niet voldoende. “Een gebrekkige helpdesk wordt regelmatig genoemd als reden om versneld over te willen stappen naar een andere leverancier. Maar als we dan de SLA erbij pakken, blijkt zo’n bedrijf gewoon te voldoen aan de afspraken en is er geen reden om het contract voortijdig te ontbinden. Als de helpdesk zo belangrijk is, waarom was dat dan geen belangrijk onderdeel van de afspraken?”, vraagt Van der Lee zich hardop af.

Te lage vergoeding

Als we het hebben over aansprakelijkheid en schadevergoedingen, dan bepaalt de SLA vaak dat de ondernemer een korting (of service credit) krijgt als de SLA niet wordt gehaald. “Een goede optie”, vindt Van der Lee. “Het voorkomt getouwtrek over schadevergoedingen waarbij het bedrijf moet bewijzen dat er daadwerkelijk schade is geleden. Juridisch gezien is dat niet altijd even makkelijk. Het geven van een service credit geeft helderheid. Voor de IT-dienstverlener is het ook gunstig: het voorkomt onverwacht hoge schadevergoedingen, want je kunt met zo’n bepaling verdere aansprakelijkheid uitsluiten. Zeker als er wordt gesproken van een ‘sole and exclusive remedy’.”

Ook De Ruijter vindt een korting bij het niet nakomen van de SLA reëel, maar plaatst een kanttekening: “De korting moet wel in verhouding staan tot de schade. Als je veel orders misloopt omdat de dienst er een paar dagen uitligt, is een maand geen hosting betalen niet genoeg. Dat is een veel te lage vergoeding. Maar denk ook aan een stimulans als de SLA overtroffen wordt; ik mis vaak de positieve gedachte in contracten.”

 


Valkuilen van een SLA

Hoeveel uptime is écht gegarandeerd?

Als een uptime van 99,9 procent per jaar wordt gegarandeerd, mag een site er per jaar een ruime werkdag achterelkaar uit liggen. Als dit percentage per maand wordt berekend, is het slechts 43 minuten. Een flink verschil!

Respons- of reparatietijd?

Als de bepaling luidt dat er binnen x minuten op een melding wordt gereageerd, betekent dat alleen maar dat het probleem zo snel wordt genoteerd. Maar hoe lang duurt het voordat er een oplossing wordt geleverd?

Valt gepland onderhoud binnen uptime?

In sommige SLA’s wordt gepland onderhoud niet meegerekend bij downtime. Maak ook afspraken over de momenten dat onderhoud gepland mag worden. ‘s Avonds of ‘s nachts bijvoorbeeld.

Zijn er verborgen kosten?

Af en toe zijn er contracten waarin er extra kosten zijn verbonden aan beheer, reparaties of onderhoud. Breng dit vooraf in kaart, zodat u achteraf niet voor verrassingen komt te staan.


 

Gaat niet goed

Bij het afspreken van uptime in SLA’s ligt de zogeheten back-to-backproblematiek op de loer. “Veel IT-leveranciers hebben de neiging beloftes te doen”, zegt Van der Lee, “maar vergeten dat ze afhankelijk zijn van andere partijen. Stel dat het bedrijf een applicatie heeft draaien bij een hostingbedrijf dat 99,5 procent uptime garandeert. Als het bedrijf vervolgens aan klanten 99,9 procent uptime belooft, gaat het niet goed. Dat komen we nogal eens tegen.”

Om dit soort problemen te voorkomen, is het belangrijk de SLA af en toe te controleren. “Je moet zo’n document onderhouden”, zegt Van der Lee. “Wacht niet tot het misgaat, maar onderneem actie als je zo’n fout erin ziet staan. Het is natuurlijk leuker om zakelijke deals met klanten af te sluiten. Maar bedenk dat als het een keer misgaat het flink wat geld kan kosten als je de schade van meerdere klanten moet vergoeden door zo’n fout.”

 


Afspraken over recovery

Behalve uptime bepaalt de SLA ook hoe snel er wordt gereageerd op een storing. Daarbij horen de termen RTO (Recovery Time Objective) en RPO (Recovery Point Objective). Beide termijn zijn onderdeel van een Business Impact Analyse die beschrijft welke schade een bedrijf kan lijden door storingen. RTO is de tijd waarbinnen het systeem weer actief moet zijn, bijvoorbeeld binnen een uur. De RPO is het maximale verlies aan data, bijvoorbeeld maximaal een half uur aan data. Middels een Business Impact Analyse wordt duidelijk waar de RTO en RPO aan moeten voldoen.


 

Dirkjan van Ittersum is freelance journalist.