Cloudserver-oververkoop: bewijswijzer en ticketgids

Bewijs oververkoop in 3 stappen, zo schrijf je een effectief ticket

Bijgewerkt 2026-09-05 · CloudWorth

oververkoopbewijsticketprestatietestCloudWorthSteal TimeVPS oversellingVPS benchmark

Verzamel bewijs met systeemlogs + tijdstempels + extern notariaat, en verwijs in het ticket rechtstreeks naar de SLA-schending.

Hoe detecteer je overboeking?

Haast je niet om met benchmarksoftware een oordeel over de provider te vellen — als de provider gewoon terugzegt “de testmethode is niet representatief”, stellen je mooie screenshots niets voor. Overboeking wil zeggen dat fysieke resources boven hun limiet worden toegewezen, maar dat zie je alleen op twee onopvallende plaatsen: de CPU-Steal Time en de disk-cache-afgrond.

Draai eerst een nulmeting op een rustig moment: noteer met top -d 5 tien minuten lang de steal-waarden. Bij normale cloudservers blijft dat onder 1%; blijft het langdurig boven de 5%, dan pikken aangrenzende virtuele machines je vCPU's in. Kijk bij schijf-IO niet alleen met fio naar pieken, maar naar de doorvoercurve bij het continu schrijven van 10 GB — zodra de cache van de overboekte host uitgeput is, vallen de IOPS van een klif. Dat is een feit dat geen enkele “testmethode” kan veranderen.

Voer dezelfde test uit op drie tijdstippen (bijv. buiten de piek, tijdens de avondpiek en vroeg in de ochtend) en bewaar elke keer de ruwe output. Als je zelfs Steal Time niet begrijpt, kun je eerst de door ons opgestelde punten doorlopen; je kunt ook op /app een voorbeeld van automatische diagnose bekijken. Onthoud: je meet niet of iets “traag” is, maar of je resources door je buren worden gestolen.

Hoe leg je bewijs vast

Het doel van bewijsverzameling is niet om aan te tonen dat de 'prestaties slecht zijn', maar om aan te tonen dat de 'resourcebelofte niet overeenkomt met de SLA'. Daarom moet elk bewijsstuk vier elementen bevatten: tijdstempel, naam van het commando of de tool, ruwe uitvoer en de uitvoeromgeving.

Voer date -u +%FT%TZ samen met de testopdracht uit, zodat het logboek automatisch voorzien is van UTC-tijd. Gebruik vervolgens script -a session.log om de volledige terminalsessie vast te leggen, om verdenking van achteraf vervalsen te voorkomen. Bij screenshots moeten de titelbalk en de systeemtijd behouden blijven; het wordt aanbevolen om met een telefoon het scherm op te nemen en aan het begin van de video de huidige tijd hardop te noemen — dit is het meest basale externe tijdsanker. Voor de plotselinge daling van de diskcache kun je het beste iostat -dx 5 continu laten registreren en de uitvoer opslaan als CSV; dat is overtuigender dan een enkele afbeelding.

Vergeet ook de 'kruisvalidatie': de twee testrondes moeten meer dan 6 uur uit elkaar liggen, bij voorkeur over een 'verlengingscyclus' of 'piekbelasting van aangrenzende tenants'. Als je maar één keer test, kan de andere partij het ontkennen; maar als je op verschillende datums en onder verschillende belastingen herhaalde resultaten krijgt, is de bewijs keten gesloten.

Wie slimmer is, leidt uit hetzelfde bewijs een prijs-prestatiecurve af: is jouw toegewezen CPU-aandeel bij eenzelfde prijsklasse 30% lager dan de benchmark van de publieke cloud? Dit bewijst niet direct oververkoop, maar het kan een 'technisch geschil' verheffen tot 'FinOps-premieverlies', waardoor het ticket verandert van 'jij liegt' naar 'ik verlies'.

Hoe schrijf je een ticket

De ijzeren regel voor tickets is: alleen feiten, geen oordelen. Zeg niet “jullie overboeken”, maar “we hebben een gemiddelde CPU-steal van 12% waargenomen en vier keer een disk-cache die plotseling kelderde”; zeg niet “de prestaties zijn niet goed”, maar “volgens de CPU-prestatietoezegging in jullie SLA wijkt de huidige prestatie af van de basislijn”.

Aanbevolen structuur:

1. Omgevingsbeschrijving: instantieconfiguratie, besturingssysteem, tijdbereik.
2. Testmethode: voeg reproductiecommando's toe (gebruik algemene commando's, geen BaoTa of benchmarktools van derden).
3. Ruwe data: drie sets steal-logs, disk-CSV, screenshot met tijdstempel; verpak en voeg ze als bijlage toe.
4. Impactbeschrijving: beschrijf concreet hoe de bedrijfsvoering is beïnvloed (bijv. API-respons van 80 ms naar 2 s).
5. Verzoek: vraag de officiële instantie om de belastingstoestand van de hostmachine opnieuw te controleren en een toelichting op de resourcetoewijzing te geven.

Een sjabloon kan als volgt beginnen:

“Onze instantie heeft op 2025-06-01 om 02:00, 08:00 en 20:00 drie keer dezelfde test uitgevoerd; de samples zijn bijgevoegd. De CPU-steal lag daarbij elke keer boven de 8%, en na het instorten van de disk-cache daalde de IOPS tot minder dan 20% van de nominale waarde. Aangezien jullie service level agreement een basislijn voor CPU- en IO-prestaties belooft, verzoek ik het technische team om de huidige allocatieverhouding en de belasting van de buurmachines op de fysieke host te controleren.”

Let op: gebruik in de hoofdtekst geen woorden als “klacht”, “overboeking” of “fraude”; die kun je bewaren totdat de klantenservice het ticket escaleert. De waarde van het ticket is dat de andere partij het niet kan weerleggen met “de tool is niet nauwkeurig”, dus elk gegeven moet corresponderen met een volledige logregel. Als de andere partij antwoordt: “gebruik onze testtool”, kun je antwoorden: “We hebben al opnieuw getest volgens de methode in jullie documentatie; zie bijlage, dataset 3.” Zo speel je de bal netjes terug.

Wat als de provider het niet erkent?

Als de tegenpartij reageert met “de testmethode is problematisch” of “de hostbelasting is normaal”, ga dan niet meteen in discussie. Vraag eerst om hostmonitorlogs van dezelfde periode — vaak kunnen ze die niet overleggen, of hooguit een uitgeklede versie. Inmiddels heb je twee harde bewijzen: de regel-voor-regel logs waaruit blijkt dat de CPU-steal hoger is dan 8%, en de curve die laat zien dat de IOPS, nadat de schijfcache volledig is leeggelopen, zijn gedaald tot 20% van de opgegeven waarde. Zet deze twee gegevensreeksen om in een in tijd uitgelijnde vergelijkingstabel en wijs erop: als de scherpe daling van de schijfcache precies samenvalt met een piek in de steal, betekent dit dat de CPU- en opslagcapaciteit van de host tegelijkertijd worden ingepikt door de buren. Dit is geen incidentele testfluctuatie, maar een typische vorm van overboeking in de resourcepool.

Blijft de tegenpartij volhouden dat “de tool onnauwkeurig is”, dan kun je antwoorden: “Lever alstublieft het door uw bedrijf officieel aanbevolen testscript en de parameters. Ik voer de test opnieuw uit volgens uw documentatie, en laat een onafhankelijke derde partij het proces vastleggen.” De waarde van deze stap is dat de bewijslast terug bij de provider wordt gelegd. Voer daarnaast op verschillende dagen nog twee onafhankelijke tests uit (bijvoorbeeld in de vroege ochtend en tijdens de avondspits), voor kruisvalidatie. Wanneer drie monsters naar dezelfde conclusie wijzen, kan de tegenpartij het niet langer afdoen als “incidenteel”. Bewaar van elke test de originele logs, systeemtijd, NTP-synchronisatiegegevens en de tijdstempels van de screenshots — deze vormen het materiaal voor een eventuele klacht bij een hoger kanaal.

Klachten escaleren en restitutie

Als de directe klantenservice weigert te escaleren, start dan kanaalescalatie: stuur ten eerste een e-mail naar het op de officiële website van de provider vermelde abuse-/klachtenadres, met als onderwerp “SLA-schendingsbewijs bijlage nummer”; dien ten tweede materiaal in bij de telecommunicatieregulator in het rechtsgebied van de cloudprovider of bij het 12321-meldpunt voor netwerk- en spamklachten. Vermeld bij het indienen niet de testconclusies, maar alleen een feitenlijst: op welke dag, op welke instantie, welke test is uitgevoerd, wat de resultaatwaarden waren en op welke SLA-clausule deze betrekking hebben.

Restitutieverzoeken moeten in twee stappen worden gedaan. Vraag eerst volgens de restitutieregels van de provider een restitutie aan voor niet-gebruikte duur, en vermeld dat bedrijfsschade is ontstaan door onvoldoende resources, en eis aanvullende compensatie — gebruik hierbij een FinOps-perspectief om een berekening te maken: je hebt een premie betaald voor een vermeende 8-core 16G, maar de feitelijke beschikbare rekenkracht is slechts gelijk aan 3 cores, dus de prijs-prestatieverhouding is al lang uit balans. Als de tegenpartij alleen een deel van de kosten wil terugbetalen, sta er dan op dat ze een toewijzingsverklaring van resources afgeven, en vermeld daarin of deze instantie een host deelt met goedkope high-density VPS’s. De meeste providers zijn bang dat je deze verklaring gebruikt om overbezetting te melden en zullen een compromis voorstellen.

Tot slot een herinnering: voer alle communicatie via tickets of e-mail en bewaar screenshots. Als je restitutie aanvraagt, onthoud dan om eerst schijfgegevens te exporteren voordat je de machine verwijdert — na restitutie wordt de instantie gewist en moeten je forensische logs ten minste 180 dagen worden bewaard voor eventuele arbitrage of juridische stappen. Zelfs als restitutie succesvol is, wordt aanbevolen om deze forensische methode bij de volgende provider te gebruiken: verifieer grondig voordat je betaalt, om herhaling te voorkomen.