Hoe lees ik een cloud SLA en waar moet ik op letten?
Een SLA omschrijft welk dienstenniveau men minimaal van een aanbieder mag verwachten, maar is bovendien een prima indicator van het vertrouwen dat de dienstverlener in de eigen dienstverlening heeft. Waar moet u aan denken bij het lezen van zo’n document en wat doet u met uw conclusies?
De afkorting SLA wordt veel toegepast door dienstverlenende organisaties, waaronder dus ook hosting- en cloudaanbieders. Het staat voor ‘Service Level Agreement’ en hoewel hier ook een Nederlandstalig alternatief voor bestaat (SNO, ofwel ‘Service Niveau Overeenkomst’), blijft de Engelse term breed gebezigd.
Primair beschrijft een SLA het minimale serviceniveau dat de afnemer mag verwachten, meestal onder vermelding van de (geld)straf die de dienstverlener verschuldigd zal zijn als hij dat niveau niet zou behalen. Daaruit volgt meteen dat een SLA dus ook de wederzijdse verplichtingen en rechten omschrijft die de voorwaarden vormen waaronder het beloofde serviceniveau geldig is. Specifiek in de hosting- en cloudindustrie is vooral de parameter ‘beschikbaarheid van de geboden platformdiensten’ een populair onderwerp.
De garanties in sommige Service Level Agreements lijken soms te mooi om waar te zijn en dat geldt al helemaal voor garanties rondom infrastructuren. Hoe serieus kunt u die precies nemen? Iedere Service Level Agreement rondom infrastructuurdiensten zou natuurlijk rekening moeten houden met het simpele gegeven dat de infrastructuur, mensen en processen weleens kunnen falen… En soms falen er meerdere tegelijk. Toch lijken veel SLA’s beloftes af te geven die wel degelijk 100 procent of ‘99,99999’ beloven. Het onderbuikgevoel zegt het u al; hier is iets niet in de haak. Maar waar wringt dan de schoen dan precies?
Serviceproviders zijn vrijwel altijd commerciële organisaties die dus ook zoveel mogelijk marktaandeel willen winnen. In hun streven om dat te bereiken, passen ze allerhande ‘tekstuele gymnastiek’ toe in hun SLA’s om maar zo dicht mogelijk bij die 100 procent te komen. Het loont dan ook de moeite om de Service Level Agreement van een potentiële toeleverancier grondig door te nemen. Daar komt nogal wat bij kijken voor wie dat serieus wil aanvliegen.
Hoe een SLA te doorgronden
Een Service Level Agreement heeft natuurlijk betrekking op technische onderwerpen. Bij het opstellen ervan, waren vrijwel altijd juristen plus technici betrokken. U, als individuele lezer, staat direct 2-0 achter, nog voordat u het document inziet, want u bezit waarschijnlijk geen grondige kennis van beide gebieden. Erger nog: hoogstwaarschijnlijk is er een tekstuele virtuoos bij betrokken geweest om de minder florissante onderwerpen te verbergen of te verbloemen. U staat dan 3-0 achter.
Dat betekent dat u bij het doorgronden van zo’n tekst dus dezelfde disciplines moet inzetten om de eventuele valkuilen en struikelblokken te vinden. Het is daarbij niet genoeg als de technicus en de jurist ieder voor zich de tekst doornemen, omdat de twee kennisgebieden door elkaar heen lopen. Jurist en technicus moeten deze exercitie samen verrichten en ieder onderwerp telkens met elkaar bespreken om de daadwerkelijke implicaties vanuit beide opzichten te evalueren.
Breng tenslotte ook een tekstueel onderlegd persoon in stelling die de tekstopbouw helpt ontleden en uw kansen om valkuilen te onderkennen, nemen ingrijpend toe. Het loont de moeite om in uw offerteaanvraag of RFP uitdrukkelijk naar deze onderwerpen te vragen en uw technici te laten rondleiden door de hostingfaciliteit.
Een maatregel die die zéker bevorderlijk is voor uw netto ‘uptime’, is het aanhouden van reservevoorraden. Sommige aanbieders bieden dat, soms zelfs al in de rekken gemonteerd om uitgevallen hardware razendsnel te vervangen (Disaster Recovery-voorraad). U wilt weten of dit het geval is, hoe snel uw systeem maximaal zal worden vervangen, hoeveel aanspraak u kunt maken op die voorraden na een grootschalige outage – en hoeveel dat gaat kosten.
De SLA van serviceproviders is primair de set afspraken over het minimale serviceniveau; bij hosting is daarbij de belangrijkste parameter meestal uw minimale beschikbaarheid. Bovendien is het voor een team van een gedreven jurist, een schrijver en een technicus een document dat zij kunnen ‘reverse-engineeren’ om de valkuilen bloot te leggen waar uw organisatie potentieel had gestapt. Sterker nog; wie diep graaft, kan zélfs uitvinden waar de aanbieder in kwestie het meeste angst voor heeft. Hij heeft getracht zich daartegen te beschermen – maar daardoor weet u precies over welke onderwerpen u moet doorvragen.
Waarop te letten bij het evalueren van een Service Level Agreement
- Zijn er verborgen kosten?
Moet u over drie jaar de hardware, in het geval van dedicated omgevingen (bijvoorbeeld Private Cloud), vervangen of zijn er bijvoorbeeld kosten verbonden aan reparaties en beheer? Dat vindt u meestal terug in de SLA. - Wat is de meetperiode van ‘downtime?
Niet alleen het percentage beschikbaarheid, maar ook het meetvenster bepaalt hoe lang een onderbreking mag duren voordat uw beschikbaarheid onder het gegarandeerde niveau zakt. Meet uw leverancier op maandbasis dan is 0,5 procent niet lang, maar er zijn legio partijen die op jaarbasis meten, waardoor de onderbreking dus 12 x langer kan duren dan u wellicht had aangenomen. - Hersteltijd of reactietijd?
Garandeert de SLA alleen een reactietijd en weet u dus niet hoelang het serviceherstel echt zal duren, of garandeert uw aanbieder ook de hersteltijd? Er zijn tekstuele trucs om de ware aard van de overeenkomst te verhullen; leest u de tekst eens alsof ú de schrijver was. Een prima idee is ook om in de eigenlijke tekst stelselmatig de naam van de definitie te vervangen door de definitie. “100 procent Netwerkbeschikbaarheid per maand” ziet er prachtig uit, tenzij in de definitie 5 uur per maand is uitgesloten van die maand. Het staat er wel, maar het staat er niet! - Vanaf welk moment telt downtime als ‘onbeschikbaarheid’ voor de SLA?
Het zal u misschien verrassen maar er bestaan SLA’s die stellen dat de tijd pas gaat lopen wanneer u het probleem zelf heeft aanmeldt. U moet weten wanneer ‘de teller gaat lopen’, welke acties er mogelijk van u worden verwacht – en daarmee, wat de échte doorlooptijden zijn. - Een 100procent-garantie op beschikbaarheid… Hoe serieus kunt u die nemen?
Gegarandeerd 100 procent beschikbaarheid, dat klinkt wel héél erg mooi: maar waar is dat op gebaseerd? Immers: als de service ook maar 1 seconde downtime zou vertonen, is er al sprake van een ‘SLA-breuk’ en treedt het boetebeding in werking.
Laten we eerlijk zijn; 100 procent beschikbaarheid is gewoon niet mogelijk want techniek én mensen kunnen weleens falen. Het is dan dus zaak dat uw aanbieder zóveel redundanties inbouwt dat de kans op downtime sterk afneemt. Er bestaan echter ook partijen die hun SLA niet technologisch onderbouwen en 100 procent garanderen op basis van een simpele rekensom. De kosten van het uitbetalen van boetes zijn de ‘prijs’ die zo’n partij betaalt om toch maar met ‘100 procent beschikbaarheid’ te kunnen adverteren… De zogenaamde ‘marketing-SLA’.
Deel dit bericht
Plaats een reactie
Uw e-mailadres wordt niet op de site getoond
2 Reacties
Gribnau Business Development
Vergeet zoals bij elk contract ook niet te kijken naar de exit/beëindiging. Kortom, hoe kan ik er voor zorgen dat mijn data, applicaties etc op termijn soepel (liefst zonder al te veel downtime) over kunnen naar een andere partij.
Hans Reinhart
Dag Gribnau Business Development,
Een zeer terechte opmerking.
Een exit dient daarbij in het contract te worden opgenomen. Simpel gezegd; het ondersteunen (faciliteren) bij een overgang naar een andere partij (documentatie, data migratie, etc.)
Daarnaast ook de technische kant; zorg dat de service provider standaarden hanteert die een overgang mogelijk maakt (geen proprietary technologie).