Definitie: Een SLA (Service Level Agreement) is een overeenkomst tussen een leverancier en een klant waarin meetbaar wordt vastgelegd welk niveau van dienstverlening de leverancier levert, zoals beschikbaarheid, reactietijd en oplostijd. Ook staat erin wat er gebeurt als die afspraken niet worden nagekomen.

In het kort

  • Een SLA maakt dienstverlening meetbaar met afspraken als 99,9 procent beschikbaarheid of een reactie binnen vier uur bij een storing.
  • Belangrijke onderdelen zijn de dienstomschrijving, servicetijden, prioriteiten, reactie- en oplostijden, rapportage en gevolgen bij het niet halen van de afspraken.
  • Bij software gaat een SLA vaak over hosting, onderhoud, support en het oplossen van storingen.
  • Een SLA is zo goed als de meetbaarheid van de afspraken; vage beloftes zonder meetmethode bieden weinig houvast.

Wat is een SLA?

Een SLA is een contract, of een bijlage bij een contract, waarin staat wat je als klant mag verwachten van een dienst. Waar een algemene overeenkomst beschrijft wat er wordt geleverd, beschrijft de SLA hoe goed en hoe snel. Denk aan vragen als: hoeveel procent van de tijd is het systeem beschikbaar? Hoe snel reageert de leverancier op een melding? Binnen welke tijd moet een kritieke storing zijn opgelost? Wanneer is de supportafdeling bereikbaar?

Een SLA is ook nuttig voor de leverancier. Hij weet precies wat er van hem wordt verwacht en kan zijn planning, bezetting en infrastructuur daarop afstemmen. Daarmee voorkomt een SLA teleurstelling aan beide kanten. SLA’s komen voor bij allerlei diensten: hosting, clouddiensten, IT-beheer, softwareonderhoud, telecom, maar ook bij logistiek en facilitaire dienstverlening. Bij software en webapplicaties gaat het meestal over beschikbaarheid, support en het oplossen van fouten.

Wat staat er in een SLA?

Onderdeel Wat je vastlegt
Dienstomschrijving Welke dienst valt onder de SLA, en wat niet
Servicetijden Wanneer de leverancier bereikbaar is en werkt aan meldingen, bijvoorbeeld werkdagen van 9 tot 17 uur
Beschikbaarheid Het percentage van de tijd dat de dienst moet werken
Prioriteiten Indeling van meldingen naar ernst, zoals kritiek, hoog, normaal en laag
Reactietijd Binnen welke tijd de leverancier op een melding reageert
Oplostijd Binnen welke tijd een probleem is opgelost of omzeild
Gepland onderhoud Wanneer onderhoud plaatsvindt en hoe dat wordt aangekondigd
Rapportage Hoe en hoe vaak de leverancier rapporteert over de prestaties
Gevolgen Wat er gebeurt als de afspraken niet worden gehaald, zoals een korting of boete
Uitsluitingen Situaties die buiten de SLA vallen, zoals storingen door derden of overmacht
Looptijd en evaluatie Hoe lang de SLA geldt en wanneer hij wordt herzien

Reactietijd en oplostijd

Twee begrippen worden vaak door elkaar gehaald:

  • Reactietijd is de tijd tot de leverancier de melding heeft opgepakt en een eerste reactie geeft.
  • Oplostijd is de tijd tot het probleem is verholpen, of er een tijdelijke oplossing is.

Een snelle reactietijd zegt dus nog niets over hoe snel een storing is opgelost. Een goede SLA bevat beide, per prioriteit.

Prioriteit Voorbeeld Voorbeeld reactietijd Voorbeeld oplostijd
Kritiek Het systeem is voor iedereen onbereikbaar Binnen 1 uur Binnen 4 uur
Hoog Een belangrijk onderdeel werkt niet Binnen 4 uur Binnen 1 werkdag
Normaal Een functie werkt niet goed, er is een omweg Binnen 1 werkdag Binnen 5 werkdagen
Laag Een cosmetische fout of vraag Binnen 2 werkdagen In een volgende release

Dit zijn voorbeeldwaarden om de opbouw te laten zien, geen norm. Welke tijden passen, hangt af van hoe kritisch het systeem is en wat de dienstverlening kost.

Wat betekent een beschikbaarheidspercentage?

Beschikbaarheid wordt vaak uitgedrukt in een percentage. Kleine verschillen in het percentage maken in de praktijk veel uit:

Beschikbaarheid Maximale uitval per maand (30 dagen) Maximale uitval per jaar
99% Ongeveer 7 uur en 12 minuten Ongeveer 3,65 dagen
99,5% Ongeveer 3 uur en 36 minuten Ongeveer 1,8 dagen
99,9% Ongeveer 43 minuten Ongeveer 8 uur en 46 minuten
99,99% Ongeveer 4 minuten Ongeveer 53 minuten

Let op hoe beschikbaarheid wordt gemeten. Telt gepland onderhoud mee? Wordt gemeten over een maand of een jaar? Gaat het om het hele systeem of om onderdelen? En wie meet het: de leverancier zelf of een onafhankelijke monitoringdienst?

SLA bij software en webapplicaties

Bij een webapplicatie die voor je is gebouwd, gaat een SLA vaak over meerdere lagen:

  • Hosting en infrastructuur. De servers, de database en het netwerk, vaak bij een hostingpartij of cloudaanbieder met een eigen SLA.
  • Applicatiebeheer. Updates, beveiligingspatches, back-ups en monitoring van de applicatie zelf.
  • Support. Het beantwoorden van vragen en het oplossen van fouten.
  • Doorontwikkeling. Nieuwe functies en aanpassingen, die meestal buiten de SLA vallen en apart worden afgesproken.

Belangrijk is dat de afspraken van de verschillende partijen op elkaar aansluiten. Een leverancier kan geen hogere beschikbaarheid beloven dan de hostingpartij waarvan hij afhankelijk is.

Servicecredits en boetes

Wat gebeurt er als de leverancier de afspraken niet haalt? Veel SLA’s werken met servicecredits: een korting op de maandelijkse vergoeding, oplopend naarmate de afspraak verder wordt gemist. Bijvoorbeeld een kleine korting als de beschikbaarheid onder de afgesproken norm zakt, en een grotere korting als hij nog verder daalt. Sommige SLA’s bevatten een boeteclausule met een vast bedrag. Bij herhaaldelijk of ernstig tekortschieten kan een SLA ook het recht geven om de overeenkomst te beëindigen.

Servicecredits zijn zelden bedoeld om de werkelijke schade van een storing te vergoeden. Ze zijn vooral een prikkel voor de leverancier en een signaal dat de afspraken serieus zijn. Als uitval voor jouw bedrijf grote gevolgen heeft, is het belangrijker om te investeren in betrouwbaarheid, back-ups en een herstelplan dan in hogere boetes.

Wat kost een SLA?

Een SLA zelf kost niets; de afspraken erin wel. Hoe hoger de beschikbaarheid, hoe ruimer de servicetijden en hoe korter de reactietijden, hoe meer de leverancier moet investeren in infrastructuur, monitoring en bereikbaarheid. Een SLA met bereikbaarheid buiten kantoortijden vraagt bijvoorbeeld om een bereikbaarheidsdienst. Vergelijk daarom niet alleen de prijs, maar ook wat je daarvoor krijgt, en kies het niveau dat past bij de impact van een storing voor jouw bedrijf.

Voorbeelden van heldere SLA-afspraken

  • “Een melding met prioriteit kritiek wordt op werkdagen tussen 8.00 en 18.00 uur binnen één uur in behandeling genomen.”
  • “De beschikbaarheid van de applicatie wordt per kalendermaand gemeten door een externe monitoringdienst. Aangekondigd onderhoud buiten kantoortijden telt niet mee.”
  • “Back-ups worden dagelijks gemaakt en dertig dagen bewaard. Een herstel van de back-up van de vorige dag is binnen vier uur na het verzoek uitgevoerd.”
  • “De leverancier levert elk kwartaal een rapportage met beschikbaarheid, aantal meldingen per prioriteit en de gemiddelde reactie- en oplostijden.”

Zulke afspraken zijn concreet, meetbaar en laten weinig ruimte voor uiteenlopende interpretaties.

SLA, OLA en UC

In IT-beheer kom je naast de SLA soms ook deze termen tegen:

  • OLA (Operational Level Agreement): interne afspraken tussen teams binnen dezelfde organisatie, die nodig zijn om de SLA naar de klant waar te maken.
  • UC (Underpinning Contract): het contract met een externe partij, zoals een hosting- of softwareleverancier, waarop de dienstverlening steunt.

Samen zorgen ze ervoor dat de beloftes naar de klant ook intern en bij toeleveranciers zijn afgedekt.

Back-ups en herstel in een SLA

Naast beschikbaarheid en support is het verstandig om afspraken te maken over back-ups en herstel. Twee begrippen zijn daarbij nuttig:

  • RPO (Recovery Point Objective): hoeveel gegevens je maximaal mag verliezen bij een calamiteit. Een RPO van 24 uur betekent dat je in het slechtste geval de gegevens van één dag kwijt bent.
  • RTO (Recovery Time Objective): hoe snel het systeem na een calamiteit weer moet werken.

Spreek ook af hoe vaak een herstel wordt getest. Een back-up die nooit is teruggezet, biedt minder zekerheid dan je denkt.

Zo stel je een goede SLA op

  1. Begin bij de impact. Wat betekent uitval van het systeem voor je bedrijf, per uur en per dag?
  2. Bepaal wat echt kritiek is. Niet elk onderdeel heeft dezelfde beschikbaarheid nodig.
  3. Maak afspraken meetbaar, met duidelijke definities en een meetmethode.
  4. Leg prioriteiten vast met voorbeelden, zodat beide partijen hetzelfde verstaan onder kritiek of laag.
  5. Kies realistische tijden. Hogere beschikbaarheid en snellere reactietijden kosten meer.
  6. Spreek rapportage af, zodat je kunt zien of de afspraken worden gehaald.
  7. Regel de gevolgen, zoals een servicekorting bij het niet halen van de afspraken.
  8. Evalueer periodiek, bijvoorbeeld jaarlijks, en pas de SLA aan als het gebruik verandert.

Veelgemaakte fouten

  • Vage afspraken. “De leverancier lost storingen zo snel mogelijk op” is geen meetbare afspraak.
  • Alleen reactietijd. Een snelle reactie zonder afspraak over de oplostijd biedt weinig zekerheid.
  • Geen definitie van een storing. Wat is kritiek en wat niet? Zonder definitie ontstaat discussie.
  • Te hoge eisen. 99,99 procent beschikbaarheid klinkt goed, maar is voor de meeste zakelijke applicaties onnodig duur.
  • Geen rapportage. Afspraken zonder meting zijn niet te controleren.
  • Afhankelijkheden vergeten. Hosting, koppelingen en externe diensten bepalen mee wat haalbaar is.

Wat betekent dit voor jouw project?

Beheer en verbetering zijn in mijn werkwijze een vaste stap na de eerste versie. Welke afspraken daarbij passen, hangt af van hoe kritisch de applicatie is voor je werk. Een interne tool die een team ondersteunt, vraagt om andere afspraken dan een klantportaal waar klanten dag en nacht op rekenen.

Ik vind het belangrijk om afspraken na te komen, en daarom ook om alleen afspraken te maken die realistisch zijn. Het gesprek over beheer begint bij de vraag wat uitval of een fout voor jouw bedrijf betekent.

Wil je weten welke afspraken over beheer en support passen bij je applicatie? Stuur me wat de applicatie doet, wie ermee werkt en wat er gebeurt als hij niet beschikbaar is. Dan bepalen we samen de logische eerste stap.

Veelgestelde vragen over een SLA

Wat is een SLA?

Een SLA (Service Level Agreement) is een overeenkomst tussen leverancier en klant waarin meetbaar wordt vastgelegd welk niveau van dienstverlening wordt geleverd, zoals beschikbaarheid, reactietijd en oplostijd, en wat er gebeurt als dat niet wordt gehaald.

Wat staat er in een SLA voor softwareonderhoud?

Een SLA voor softwareonderhoud bevat meestal de dienstomschrijving, servicetijden, prioriteiten van meldingen, reactie- en oplostijden, afspraken over updates en back-ups, rapportage en de gevolgen bij het niet halen van de afspraken.

Wat betekent 99,9 procent beschikbaarheid?

Bij 99,9 procent beschikbaarheid mag een dienst maximaal ongeveer 43 minuten per maand of bijna 9 uur per jaar onbeschikbaar zijn. Of gepland onderhoud meetelt, hangt af van de afspraken in de SLA.

Verwante termen

Doorontwikkeling en onderhoud · Fixed price vs nacalculatie · Vendor lock-in · Broncode · Webapplicatie

← Terug naar de kennisbank