Wat is een service level agreement SLA

1. Inleiding

Alle leveranciers die zorgdragen voor aspecten van beheer, zowel op het gebied van hardware, databases, besturingssystemen en netwerken als van applicaties zouden de overeenkomst moeten vastleggen in de vorm van een Service Level Agreement. Het gaat daarbij niet alleen om het oplossen van plotseling optredende problemen, maar zeker ook om  het pro-actief beheren (controleren en signaleren) van de situatie bij de klant. Deze vorm van service verlening kan op locatie of op afstand via een inbelverbinding worden verleend. De klant bepaalt zelf welke vorm voor de onderneming de meest geschikte is. In overleg tussen klant en leverancier wordt bepaald welk niveau van dienstverlening voor de diverse aspecten van de ICT-omgeving gewenst is.
Op basis daarvan wordt een Service Level Agreement opgesteld, waarin helder, overzichtelijk en meetbaar ICT wordt gedefinieerd en welke afspraken ten aanzien van de dienstverlening zijn gemaakt Periodiek ontvangt de afnemer van de leverancier een rapportage over de uitvoering van de Service Level Agreement, zodat hij inzicht krijgt in de verrichte werkzaamheden.

2. Wat is een Service Level Agreement?

Een Service Level Agreement is een contract tussen klant en leverancier over het te leveren niveau en type service. Vervolgens wordt bijgehouden of de klant ook daadwerkelijk krijgt waar hij voor betaalt. Een SLA wordt onder andere opgesteld voor een organisatie die een deel van de automatisering wil uitbesteden aan een leverancier. Ook kunnen SLA’s worden opgezet voor de verschillende afdelingen binnen een organisatie. De kosten worden dan per afdeling afgestemd en het gebruik wordt per afdeling verrekend. Zo worden de kosten van de automatisering beheersbaar en controleerbaar gehouden.

2.1 Ontwikkelingen

De ontwikkelingen binnen de computerwereld volgen elkaar snel op. Na het mainframe, deed de LAN zijn intrede en nu zijn het Web georiënteerde applicaties die de markt veroveren. Omdat deze ontwikkelingen niet betekenen dat alle “oude” technologie bij het straatvuil wordt gezet, is de automatisering er niet gemakkelijker op geworden. Mainframes, WAN systemen en Webtechnologie worden met elkaar geïntegreerd, wat inhoudt dat laag op laag wordt gebouwd.
Simpele centrale capaciteitsplanning, zoals we die kennen uit het oude mainframe tijdperk is er daarom niet meer bij. Een mainframe is één centraal systeem waarvan de capaciteit en het aantal gebruikers bekend zijn. Een Service Level Agreement is hiervoor goed te maken, omdat capaciteit en gebruik eenvoudig zijn vast te leggen. Als een klant bijvoorbeeld 30% van de processortijd van een mainframe gebruikt, dan is daar gemakkelijk een prijsje aan te verbinden, omdat alles centraal wordt geregistreerd.
Tegenwoordig hebben we te maken met een veelheid aan systemen, die vaak op ondoorzichtige wijze aan elkaar gekoppeld zijn. Van het aantal gebruikers kan vaak slechts een schatting worden gemaakt. Hoewel het gedistribueerde systeem een groot aantal voordelen kent, is het opstellen van een goede Service Level Agreement een lastig karwei. Hierbij moeten lange ketens van subsystemen, waaruit het totale systeem bestaat, onder de loep genomen worden.

2.2 Meetbaarheid

Een leverancier moet toch een prijskaartje hangen aan het gebruik van zijn voorzieningen. Om een SLA op te stellen, moet hij weten welke capaciteit nodig is om het gewenste serviceniveau te kunnen leveren.

Om iets te kunnen zeggen over de capaciteit zijn de oude methoden ontoereikend, omdat er te veel schakeringen zijn die beperkingen kunnen opleggen aan het systeem. Nieuwe methoden en tools zijn ontwikkeld om toch iets te kunnen zeggen over de capaciteitsplanning. Tools worden ingezet om de aanwezige systemen op de voet te volgen. De meeste tools geven informatie over 3 kwaliteitsattributen: beschikbaarheid, betrouwbaarheid en responstijd.

2.2.1 Beschikbaarheid

Geeft aan hoeveel procent van de tijd het systeem beschikbaar is.

2.2.2 Betrouwbaarheid

Geeft aan in hoeveel procent van de gevallen de informatiebronnen juist en up-to-date zijn.

2.2.3 Responsetijd

Geeft aan in hoeveel tijd een percentage van het aantal gevraagde services is afgehandeld. Bijvoorbeeld: 95% van de serviceaanvragen is in maximaal 120 seconden afgehandeld.
Hoewel beschikbaarheid belangrijk is, prevaleert de betrouwbaarheid als sleuteleenheid, omdat betrouwbaarheid nauw verbonden is met beschikbaarheid. Is een systeem 90% beschikbaar, dan lijkt dat een mooi cijfer. Maar als dit betekent dat 10% van de gegevens niet aanwezig is, dan duidt dat op een lage betrouwbaarheid.
De gebruiker merkt het meest van de responsetijd. Hoge responsetijd maakt het werken met het systeem tot een langdurige bezigheid en vormt daarom een bedreiging voor de productiviteit van de gebruikers.

2.3 Behoefteplanning

Hoeveel gebruikers kan deze server aan? Kan ik de database SQL applicatie en een Exchange applicatie op één machine draaien? Hoeveel gebruikers kan ik gelijktijdig afhandelen met deze Exchange server? Capaciteitsplanning binnen de Windows wereld is vaak puur gokwerk. Het is niet altijd even duidelijk welke hardware benodigd is om de gestelde eisen te halen. Om daar toch wat meer over te kunnen zeggen zijn er speciale tools ontwikkeld. Deze tools belasten de gehele infrastructuur met echte serviceaanvragen. Zo kan worden nagegaan welke belasting de gevraagde services op de aanwezige voorzieningen legt. Deze gegevens kunnen vervolgens worden gebruikt om na te gaan welke capaciteit nodig is. Ook kan de leverancier nu de kosten bepalen die het gewenste serviceniveau met zich meebrengt.

3. SLA opstellen

Een SLA opstellen betekent in feite het koppelen van het businessmodel aan het technische model. De onderhandelingen tussen leverancier en de klant moeten niet gaan over cpu tijd en hoeveelheden gebruikt geheugen, maar over eenheden die begrijpelijk en meetbaar zijn voor de klant, zoals het aantal transacties per uur of het aantal mailtjes per dag. Het beste is een tabel op te stellen waarin aan de linkerkant de zakelijke doelen staan vermeld en aan de rechterkant de technische doelen. In het artikel ‘Checklist Service Level Agreement SLA’ vind je een checklist die je van dienst kan zijn bij het opstellen van een SLA.
Voorbeeld van een zakelijk doel: verminder de “downtime” en het technische doel zou dan installatie van een pro-actief netwerk managementsysteem kunnen zijn. Een ander zakelijk doel: het verbeteren van de concurrentiepositie. Het technische doel is dan bijvoorbeeld een versimpelde toegang tot het extranet voor de klant.
In de SLA wordt de link gelegd tussen de zakelijke verwachtingen van de klant en de benodigde technologie. Hoewel het moeite en energie kost om een SLA op te stellen en zich hier aan te houden, levert het wel degelijk wat op: de leverancier kan laten zien dat hij de gewenste service levert, op een manier die begrijpelijk is voor de klant, conform vooraf gedefinieerde meetpunten en gerealiseerde resultaten. Bovendien weet de leverancier precies wat er van hem verwacht wordt. En de klant ziet zijn zakelijke verwachtingen gerealiseerd worden, zonder dat hij met onverwachte tegenvallers te kampen heeft.

3.1 Een SLA-model

Om een SLA op te stellen zijn verschillende modellen beschikbaar. In de volgende paragraaf wordt een veel gebruikt model besproken.
De leverancier verplicht zichzelf in een SLA een prestatiegarantie te geven. Hij is hierin wel afhankelijk van zijn toeleveranciers en van de systeemontwikkelaars. Zo ontstaat er een driehoeksverhouding tussen de partijen die in de onderstaande opstelling staan weergegeven.
De contractuele relaties vormen gezamenlijk de SLA. Zo valt de SLA dus uiteen in vier onderdelen:

• SLA/1: prestatie-eisen;
• SLA/2: afspraken over maximale belasting door de gebruikers;
• SLA/3: eisen die de leverancier stelt aan de systeemontwikkel- en onderhoudsorganisatie;
• SLA/4: eisen die de leverancier stelt aan derden (hardwareleveranciers etc.).

De opzet van deze SLA’s worden in de volgende paragrafen besproken.

3.1.1 SLA/1 prestatie-eisen

In dit gedeelte van de SLA worden de prestaties vastgelegd, die de klant verwacht van de leverancier. De volgende kwaliteitsattributen worden vastgelegd:

3.1.1.1. Betrouwbaarheid

• juistheid en volledigheid:
  De leverancier garandeert dat de juiste versie van de programmatuur en de bestanden wordt verwerkt en dat de verwerking aantoonbaar volledig wordt afgerond.
• veiligheid:
  De leverancier garandeert dat slechts toegang tot de verwerking en de gegevens wordt verleend aan diegenen, die daarvoor door de functioneel beheerders geautoriseerd zijn.

3.1.1.2. Continuïteit

• bedrijfszekerheid:
  De leverancier garandeert een bepaalde MTBF (Mean Time Between Failure).
• veerkracht en herstelbaarheid:
  De leverancier garandeert een bepaalde MTTR (Mean Time To Repair/Recover).
• uitwijkmogelijkheid:
  De leverancier kan afspraken maken over de tijd waarbinnen een noodvoorziening operationeel wordt na calamiteiten. Deze twee kwaliteitsaspecten worden vaak vastgelegd met behulp van een calamiteitenplan, waarin stap voor stap staat beschreven wat er staat te gebeuren als er dan toch problemen ontstaan.

3.1.1.3. Snelheid

De leverancier garandeert bepaalde gemiddelde en maximale responsetijden voor een aantal interactieve toepassingen en een bepaalde batch-turnaround-tijd voor de achtergrondtoepassingen.

3.1.1.4. Beschikbaarheid

De leverancier garandeert een bepaald percentage beschikbaarheid (bijvoorbeeld 95%) gedurende de tijden dat de geautomatiseerde informatievoorziening gebruikt wordt (bijvoorbeeld op werkdagen van 9-17 uur). Daarnaast garandeert de leverancier voor dat gedeelte van het netwerk dat hij zelf beheert, dat de informatievoorziening op alle afgesproken plaatsen toegankelijk is. (Garanties voor de beschikbaarheid van publieke netwerken zijn afhankelijk van de afspraken die de leverancier met de desbetreffende beheerders kan maken, zie SLA/4.)
In een goede SLA komen al deze kwaliteitsattributen voor.

3.1.2 SLA/2 maximale gebruikersbelasting

Wanneer de klant garanties wenst voor het prestatieniveau, dan hoort daar ook bij dat hij de maximale gebruiksbelasting aangeeft, waarbij dat kwaliteitsniveau nog gehaald moet worden. De maximale gebruiksbelasting wordt aangegeven in termen als:

• het maximum aantal werkstations dat tegelijk aanvragen doet op een server;
• de afstand van de werkstations tot de leverancier (zijn er alleen lokale werkstations, zijn ze verspreid over het land, of zelfs internationaal verspreid);
• het maximum aantal transacties per tijdseenheid (uitgesplitst naar soorten transactie, met indicatie van bijzondere piekbelastingen);
• de hoeveelheid gegevens die op de voorgrond aanwezig moet zijn;
• de hoeveelheid gegevens die dagelijks op de achtergrond in de batch verwerkt moet worden.

3.1.3 SLA/3 Eisen die de leverancier aan de systeemontwikkel- en onderhoudsorganisatie stelt

Het gaat hierbij om twee zaken:

3.1.3.1 Eisen aan het onderhoudsproces

De leverancier maakt afspraken over een snelle procedure voor correctief onderhoud door de onderhoudsorganisatie. Wanneer bijvoorbeeld de continuïteit van de informatievoorziening door fouten in de applicatieprogrammatuur in gevaar komt, moet zeer snel onderhoud gepleegd kunnen worden. De leverancier kan zelf de coördinatie van dit onderhoud in handen houden via de helpdesk.

3.1.3.2 Acceptatiecriteria voor de producten van de systeemontwikkel- en onderhoudsorganisatie

De leverancier stelt criteria op voor de acceptatie van de applicaties die de systeemontwikkel- en onderhoudsorganisatie in productie wil geven. Het hanteren van acceptatiecriteria betekent in ieder geval dat de leverancier die applicaties aan een eigen acceptatietest onderwerpt. Soms echter zal de leverancier ook inspraak eisen in de ontwikkeling van die applicaties. In het algemeen is een vroegtijdige betrokkenheid van de leverancier bij het ontwikkelproces sterk aan te bevelen. De te stellen eisen hebben met name betrekking op de volgende kwaliteitsattributen:

• Onderhoudbaarheid:
  Bij fouten in de applicaties die tot storingen in de geautomatiseerde gegevensverwerking leiden, moet snel correctief onderhoud mogelijk zijn, ook zonder dat men in de programmatuur is ingewijd.
• Geschiktheid van de infrastructuur:
  De applicatie moet geschikt zijn voor de technische infrastructuur waarover de leverancier beschikt.
• Betrouwbaarheid:
  De applicatie mag nagenoeg geen ’technische fouten’ meer bevatten. Hieronder verstaan wij fouten die leiden tot afbreking van de verwerking, fouten die de bestanden beschadigen etc.
• Zuinigheid:
  De applicatie moet economisch omspringen met de resources (machinecyclus, opslagcapaciteit) waarover de leverancier beschikt. Men kan dit uitwerken tot normen voor het aantal I/O-accessen van kritische transacties. De applicatie moet ook zuinig omspringen met het personeel van de leverancier. Men kan bijvoorbeeld als norm stellen dat gegevensverwerkingen in principe zonder tussenkomst van operateurs worden afgehandeld.

3.1.4 SLA/4 Eisen van de leverancier aan derden

De hardwareleveranciers en de beheerders van publieke netwerken kunnen een zodanige invloed uitoefenen op de totale kwaliteit, dat zij in de afspraken betrokken moeten worden, zoals hierna is aangegeven.

3.1.4.1 Eisen aan leveranciers

De leverancier maakt met de leveranciers van hardware, basisprogrammatuur enzovoort afspraken over snelle reparatie van programmatuurfouten en vervanging van defecte onderdelen.

3.1.4.2. Afspraken met netwerkbeheerders

De leverancier maakt afspraken met de beheerders van publieke netwerken, zoals bijvoorbeeld de KPN, over de beschikbaarheid van (voldoende capaciteit van) dat netwerk.

4. Controle: de rapportage over het service level

Het sluitstuk van het Service Level Management wordt gevormd door rapportages over de uitvoering van de diverse onderdelen van de Service Level Agreement. Deze rapportages dienen ervoor om op de korte termijn te verifiëren of de gemaakte afspraken worden nagekomen, en om ze waar nodig bij te sturen. Daarnaast vormen zij op de lange termijn een belangrijk instrument voor verdere kwaliteitsverbetering, doordat zij aangeven op welke punten de service levels hoger gesteld kunnen worden.

4.1 Rapportage over het prestatieniveau

Alhoewel het merkwaardig aandoet, zal alleen de leverancier in staat zijn om een statistiek te maken over de kwaliteit van zijn eigen functioneren, om op basis daarvan te rapporteren over de bereikte prestatieniveaus. Aan de betrouwbaarheid van deze rapportage kan bijvoorbeeld in een third-partymededeling aandacht worden geschonken. Er dient vastgelegd te worden over welke periode telkens gerapporteerd wordt. Het is van groot belang om vergelijkbare periodes te kiezen, zodat de ontwikkeling in het dienstverleningsniveau blijkt. Dagen, weken of kwartalen voldoen als eenheid beter dan maanden. Bij kritische applicaties dient over een kortere periode gerapporteerd te worden. Afhankelijk van het type applicatie mogelijk ook nog naar tijdsperiode per dag: kantooruren, piek- en daltijden, enzovoort. Verder is het nuttig om vast te leggen dat ad hoc meer gedetailleerde informatie over het prestatieniveau kan worden gevraagd, om het gedrag van bepaalde onderdelen van de informatievoorziening onder de loep te kunnen nemen.

4.2 Rapportage over het gebruik

Ook de statistieken over het feitelijk gebruik van de geautomatiseerde informatievoorziening worden geproduceerd door de leverancier, als context voor en in samenhang met de rapportage over het prestatieniveau.

4.3 Rapportage over de kwaliteit van het onderhoud

Wanneer het spoedonderhoud wordt gecoördineerd door een helpdesk, kan deze helpdesk ook de rapportage over de uitvoering verzorgen. Deze rapportage zal statistisch van aard zijn, en bijvoorbeeld vermelden hoeveel urgente problemen binnen een uur werden opgelost, hoeveel binnen twee uur, enzovoort.

4.4 Acceptatierapport van de leverancier over de applicatie

Wanneer de leverancier de applicaties van de systeemontwikkel- en onderhoudsorganisatie telkens test voordat ze (opnieuw) in productie worden genomen, ligt het voor de hand om ook acceptatietestrapporten op te stellen, waarin de testresultaten worden vergeleken met de acceptatiecriteria.

4.5 Rapportage over de bijdragen van derden

Afhankelijk van welke bijdragen van derden betrokken worden in het Service Level Agreement, kan men hiervoor diverse rapportagevormen afspreken.

5. Conclusie

Resumerend kunnen we dus stellen dat een goede SLA een juiste vastlegging van alle technische en organisatorische afspraken bevat, die direct gekoppeld zijn aan het afgenomen dienstenpakket.
Hierbij dient nog vermeld te worden dat de financiële vergoeding veelal gekoppeld is aan het realiseren van het afgesproken dienstenniveau. Hierbij kan de hoogte van de financiële vergoeding gekoppeld worden aan de beschikbaarheid van een software applicatie. Anderzijds is het mogelijk om te werken met boetes indien het overeengekomen dienstenniveau niet gerealiseerd wordt.
Indien u nog weinig ervaring hebt met het opstellen van Service Level Agreements, kunt u zich uiteraard laten begeleiden door een externe partij. Deze partij dient te beschikken over  checklists en ervaring om dit proces snel uit te voeren, waardoor u per saldo geld bespaart.