De kleine lettertjes van de Service Level Agreement

Taai, ondoorgrondelijk en op meerdere manieren uit te leggen. Ik weet uit ervaring dat dit van toepassing is op veel Service Level Agreements. In een Service Level Agreement (SLA) staat beschreven wat je van een leverancier mag verwachten op het gebied van dienstverlening. In theorie moet zo’n SLA helderheid verschaffen over deze dienstverlening en ervoor zorgen dat je precies weet wat je kunt verwachten. Maar waar moet je nou op letten bij het afsluiten van een SLA?

Ik zet een aantal punten op een rij:

1. Start met inventariseren
Welke applicaties en omgevingen zijn bedrijfskritisch voor jouw organisatie? Wat móét er werken zodat jouw organisatie gewoon kan doordraaien? En waar sluit je dus precies een SLA op af? Vaak worden SLA’s alleen afgesloten op productieomgevingen van applicaties. Je kunt er voor kiezen om dit uit te breiden naar de ontwikkelomgeving. Je ontwikkelaars kunnen immers niet werken als deze omgeving eruit ligt. Ga dus goed na wat belangrijk is voor jouw bedrijf.

2. Wie is waarvoor verantwoordelijk?
Bepaal verder: waarvoor ben je als organisatie zelf verantwoordelijk en waarvoor is de leverancier verantwoordelijk? In eenvoudige, heldere en meetbare Kritieke Prestatie Indicatoren (KPI’s) leg je vast wat je van de leverancier mag verwachten met betrekking tot de taken waarvoor hij verantwoordelijk is. Definieer de KPI’s zorgvuldig, zodat hier geen discussie over kan ontstaan.

3. Technische en functionele beschikbaarheid
Als je een gehoste omgeving afneemt, is het heel belangrijk dat de leverancier aangeeft wat de beschikbaarheid is van deze omgeving. Stel je voor: je koopt een laptop en het scherm werkt, dan is deze laptop technisch beschikbaar. Kun je er echter verder niks mee, dan is de laptop dus niet functioneel beschikbaar. Let er daarom op dat de leverancier niet alleen maar praat over de technische beschikbaarheid, maar ook over de functionele beschikbaarheid van de omgeving.

Ook de omstandigheden waaronder een leverancier beschikbaarheid aanbiedt zijn belangrijk. Is het afgegeven percentage realistisch? Wordt dit percentage per kwartaal afgegeven of per jaar? En geldt dit enkel voor de infrastructuur of ook voor andere elementen zoals het netwerk? Deze zijn immers afhankelijk van elkaar. Een voorbeeld: een leverancier geeft een beschikbaarheid af van 99,99% op de infrastructuur. Dat betekent dat hij 365 dagen x 24 uur x 0,01% = 53 minuten per jaar ongeplande downtime mag hebben. Dit is een uitdagende garantie. Vaak zie je dan dat de leverancier zich indekt tegen allerlei rampscenario’s, onvoorziene omstandigheden en tussenkomst van derde partijen of aangeeft dat hij een dubbel uitgevoerde infrastructuur heeft. Vraag dan eens hoeveel overcapaciteit ze enkel en alleen voor jouw omgeving hebben gereserveerd. Vaak zie je dat ze wel een beetje overcapaciteit hebben, maar dat deze in hetzelfde datacenter staat of dat ze wel twee datacenters hebben, maar dat ze bij uitval van een datacenter bij lange na niet al hun klanten op de andere locatie kunnen laten draaien.

4. Check je back-ups
Er kan altijd een calamiteit optreden waardoor er iets met jouw omgeving gebeurt. Maak daarom goede afspraken over je Recovery Point Objective (RPO) en Recovery Time Objective (RTO). RPO houdt in: tot wanneer kun je terug in de tijd, dus tot wanneer is het opgeslagen? Kies je bijvoorbeeld voor een back-upcyclus met één back-up per dag, ben je in dat geval maximaal 24 uur aan data kwijt. De RTO houdt in: wanneer kun je weer aan het werk? En hoelang doet de leverancier er dus over om je weer up-and-running te krijgen.

Dit zijn een aantal punten waar je op moet letten bij het afsluiten van een SLA. Maar we zijn er nog niet… Denk bijvoorbeeld aan het bepalen van het juiste service window, uitsluitingen van de SLA, afspraken over performance en de gebruikersbeleving in IT-projecten (XLA). Binnenkort kom ik hier op terug in deel 2 van mijn blog.