SLA-monitoring: hoe u uptime meet en bewijst tegen een SLA
SLA-monitoring is de praktijk van het onafhankelijk controleren van de beschikbaarheid van een dienst, zodat u tijdgestempeld bewijs heeft of het uptimepercentage dat een service level agreement belooft, ook werd gehaald. Dat bewijs telt het zwaarst in een geschil, aangezien het eigen dashboard van een provider geen neutrale getuige is van zijn eigen downtime.
Wat is SLA-monitoring?
Een SLA (service level agreement) is een contract dat een specifiek beschikbaarheidsdoel benoemt, meestal een maandelijks uptimepercentage zoals 99,9%, en vastlegt wat er gebeurt als de provider dat mist: doorgaans een servicekrediet, soms een recht om op te zeggen. SLA-monitoring is het doorlopende meetwerk onder dat contract: het beloofde endpoint controleren van buiten het eigen netwerk van de provider, elke storing loggen met een tijdstempel, en het resultaat oprollen tot het percentage waar het contract om draait. Zonder dat onafhankelijke record komt het antwoord op de vraag of een SLA is gehaald neer op wiens cijfers u vertrouwt.
Beide kanten hebben er een reden voor. Een klant wil bewijs voordat hij een kredietclaim indient. Een provider wil een eigen eerlijk cijfer voordat de monitoring van een klant een probleem als eerste opmerkt.
SLA versus SLO versus SLI
De drie termen worden losjes door elkaar gebruikt, maar ze beschrijven drie verschillende dingen, in deze volgorde: meting, doel, belofte.
| Term | Wat het is | Voorbeeld |
|---|---|---|
| SLI (Service Level Indicator) | De daadwerkelijke meting, een getal berekend uit echte controles | Uptime gemeten vanaf externe controlepunten over de laatste 30 dagen |
| SLO (Service Level Objective) | Een interne doelstelling voor die indicator, zonder contractueel gevolg | "We streven dit kwartaal naar 99,95% uptime" |
| SLA (Service Level Agreement) | Een contractuele belofte gebouwd op een of meer SLO's, met een vastgelegd gevolg bij niet-halen | "99,9% maandelijkse uptime, of een pro rata servicekrediet" |
De praktische toets: als het missen van het getal nergens een vastgelegd gevolg heeft, is het een SLO, geen SLA.
Wat een uptime-SLA werkelijk toestaat
Elke tiende procentpunt telt zwaarder dan het lijkt. Hieronder staat wat elk gangbaar SLA-niveau toestaat voordat het wordt geschonden, voor een doorlopende maand van 30 dagen en een jaar van 365 dagen:
| SLA-doel | Toegestane downtime per maand (30 dagen) | Toegestane downtime per jaar |
|---|---|---|
| 99% | 7 u 12 min | 3 dagen 15 u 36 min |
| 99,5% | 3 u 36 min | 1 dag 19 u 48 min |
| 99,9% | 43 min 12 sec | 8 u 45 min 36 sec |
| 99,95% | 21 min 36 sec | 4 u 22 min 48 sec |
| 99,99% | ~4 min 19 sec | ~52 min 34 sec |
De sprong van 99,9% naar 99,99% snijdt de toegestane downtime met 90%, van ongeveer 43 minuten per maand naar ongeveer 4 minuten. Zie hoe u uptime berekent voor de onderliggende formule en de redenering achter elk niveau.
Wat u moet meten zodat het getal een geschil overleeft
- Controleer van buiten het netwerk van de provider, en vanaf meer dan één locatie. Een controle die begint en eindigt op de infrastructuur die wordt getest, kan een storing op netwerkniveau die die infrastructuur van het internet isoleert niet zien.
- Stem het controle-interval af op het SLA-niveau. Een interval van 5 minuten kan een doel van 99,99% niet betrouwbaar bewijzen of weerleggen, omdat de hele maandelijkse marge kleiner is dan één controlecyclus.
- Vereis bevestiging vanaf een tweede locatie voordat downtime wordt geteld. Een netwerkstoringetje op één locatie is niet de storing van de provider; een incident dat pas opent zodra meerdere locaties het eens zijn, houdt die ruis buiten het getal.
- Sluit alleen de onderhoudsvensters uit die de SLA daadwerkelijk documenteert. Niet-aangekondigd onderhoud telt nog steeds als downtime; een venster waar beide partijen vooraf mee instemden, niet.
- Meet precies het endpoint dat het contract noemt, niet een health-checkpad dat 200 antwoordt ongeacht of de echte dienst werkt.
- Pas de responstijddrempel van de SLA toe, als die er een heeft. Sommige overeenkomsten definiëren "plat" als trager dan een vastgelegde responstijd, niet alleen als onbereikbaar.
- Bewaar het ruwe controlelog, niet alleen het opgerolde percentage. Een geschil heeft tijdstempels, responscodes en duurtijden nodig, niet één getal uit een spreadsheet.
SLA-monitoring stap voor stap opzetten
- Noteer het exacte endpoint, de metriek (uptime, responstijd, of beide) en het meetvenster dat de SLA voorschrijft. Een controle op de verkeerde URL of de verkeerde tijdzone levert een getal op dat niemand kan gebruiken.
- Stel het controle-interval kort genoeg in voor het niveau dat u bewijst. Als vuistregel: houd het ruim onder de kleinste storing die het doel toestaat, dus een doel van 99,9% heeft een interval nodig dat in minuten wordt gemeten, niet in tientallen minuten.
- Voer de controles uit vanaf meerdere onafhankelijke locaties buiten de eigen infrastructuur van de provider, verspreid over de regio's die ertoe doen. HostTracker controleert vanaf meer dan 300 controlepunten in 158 steden, zodat u locaties kunt kiezen dicht bij waar uw echte gebruikers zitten.
- Zet een herhalings- of bevestigingsregel aan, zodat de storing van één locatie eerst door andere moet worden bevestigd voordat die als downtime telt.
- Als de SLA een responstijddrempel stelt, configureer die dan als een faalvoorwaarde, niet alleen als een traag-maar-geslaagd resultaat.
- Voeg de onderhoudsvensters waar beide partijen mee instemden toe aan de monitoringconfiguratie, zodat ze automatisch worden uitgesloten van het uptimecijfer in plaats van handmatig op het moment van rapporteren.
- Plan een terugkerend uptimerapport in op hetzelfde ritme waarop de SLA wordt gemeten, wekelijks of maandelijks, zodat het getal nooit voor het eerst wordt samengesteld tijdens een geschil.
Hoe u rapporteert over een SLA
Een gepland rapport sluit de lus tussen meten en bewijzen. Een wekelijks of maandelijks uptimerapport, automatisch verstuurd naar wie de relatie aan beide kanten beheert, zet het ruwe controlelog om in het getal waar de SLA tegen is geschreven, nog voordat iemand erom hoeft te vragen. Een publieke statuspagina doet hetzelfde werk voor iedereen buiten die verzendlijst: een gedeeld, tijdgestempeld record van uptime en incidenten waarbij geen van beide partijen de ander op zijn woord hoeft te geloven. Zie wat een statuspagina eigenlijk laat zien als u er nog geen heeft ingesteld. Zodra u de controleresultaten van een periode heeft, geeft ze door een uptimecalculator halen het percentage zonder dat u het handmatig hoeft uit te rekenen.
Veelgemaakte fouten
- Meten vanuit uw eigen netwerk. Een controle die begint en eindigt op infrastructuur die u beheert, kan een storing die alleen invloed heeft op hoe de buitenwereld u bereikt niet zien.
- Uptime middelen over meerdere diensten of regio's. Eén gemengd getal kan een dienst verbergen die zijn SLA schond terwijl andere het gemiddelde weer omhoog trokken.
- Alleen volledige storingen tellen. Als de SLA een responstijdclausule heeft, is een dienst die wel antwoordt maar veel trager is dan de drempel ook in overtreding, ook al is hij nooit volledig plat gegaan.
- Een controle-interval van 5 minuten draaien tegen een doel van 99,99%. De wiskunde klopt niet: 99,99% staat ongeveer 4 minuten downtime per maand toe, minder dan één controlecyclus, dus het interval kan niet vaststellen of het doel is gehaald.
Veelgestelde vragen
Hoe wordt SLA-uptime berekend?
Op dezelfde manier als elk uptimepercentage wordt berekend: (totale tijd min downtime) gedeeld door totale tijd, keer 100. Het SLA-specifieke deel is welke downtime telt: alleen storingen tegen het exacte endpoint en venster die het contract noemt, met overeengekomen onderhoud uitgesloten. Zie hoe u uptime berekent voor de volledige formule en uitgewerkte voorbeelden.
Telt onderhoud mee tegen een SLA?
Alleen als het niet vooraf is overeengekomen. De meeste SLA's sluiten gepland onderhoud uit dat beide partijen vooraf hebben vastgelegd, maar downtime door een niet-aangekondigde wijziging, of een noodreparatie die achteraf "onderhoud" wordt genoemd, telt nog steeds mee. De uitsluiting geldt voor het bekendgemaakte venster, niet voor het woord zelf.
Wat is een goede uptime-SLA?
99,9% is een gangbare ondergrens voor een commerciële dienst, goed voor ongeveer 43 minuten downtime per maand. 99,95% is een redelijke toezegging in het middensegment, en 99,99% is een serieuze toezegging die maar enkele minuten per maand overlaat, lastig te halen zonder redundante infrastructuur en gedisciplineerd onderhoud. Behandel elke belofte van 100% als een marketingclaim in plaats van een technische; de tabel hierboven laat zien waarom.
Hoe claim ik SLA-kredieten?
De algemene vorm is vergelijkbaar bij verschillende providers: verzamel uw eigen monitoringbewijs voor de getroffen periode (tijdstempels, het gecontroleerde endpoint, de bevestigde downtime), vergelijk dat met de eigen statuspagina of het incidentrecord van de provider, en dien een claim in via het supportkanaal van de provider binnen het venster dat het contract stelt, vaak een vastgesteld aantal dagen na het incident. Controleer het eigen SLA-document van de specifieke provider voor de exacte deadline en het vereiste bewijs, want deze details verschillen en kunnen snel verlopen.
Kan één monitoringlocatie SLA-naleving op zichzelf bewijzen?
Niet betrouwbaar. Eén locatie kan een echte storing niet onderscheiden van een probleem in het eigen netwerkpad naar de provider, en dat is precies het soort valse positief dat een SLA-geschil niet overleeft. Bevestiging vanaf meer dan één onafhankelijke locatie voordat een storing wordt geteld, is wat het resulterende getal verdedigbaar maakt.