Défense contre la survente de serveurs cloud : processus complet de collecte de preuves par ticket + PDF de benchmark

Gagnez les litiges de remboursement avec des preuves de données, pas avec des disputes.

Mis à jour 2026-08-11 · CloudWorth

Défense contre la surventePreuve par ticketCPU Steal TimePDF de benchmarkLitige de remboursementCloudWorthSteal TimeSurvente VPSBenchmark VPS

Utilisez Steal Time, la chute de disque et le benchmark pour générer un package de preuves PDF ; la communication par ticket peut efficacement obtenir un remboursement.

Comment identifier la survente

Identifier la survente ne repose pas uniquement sur une « impression de lenteur ». Utilisez le diagnostic de performance de CloudWorth pour générer un rapport complet, en vous concentrant sur trois indicateurs clés : CPU Steal Time (au-delà de 5 %, un voisin accapare le CPU), chute du cache disque (dans le test fio, l'écriture aléatoire 4K chute du cache haute vitesse à quelques Mo/s), variance des résultats de benchmarks successifs (le score total YABS des VPS de même spécification fluctue). Si ces trois signaux apparaissent simultanément, c'est pratiquement confirmé.

Mais ne vous précipitez pas pour ouvrir un ticket — transformer les résultats en preuves est essentiel. Prenez des captures d'écran de l'horodatage de chaque test, de la charge système et du champ steal dans /proc/stat, puis utilisez la fonction d'export de CloudWorth pour générer un rapport PDF avec métadonnées. Ce PDF constitue le « package de preuves irréfutables » mentionné dans le tutoriel PDF sur la réclamation pour survente de serveur cloud et la collecte de preuves pour ticket. En l'envoyant au service client, joignez les données de tests répétés sur 3 jours consécutifs à la même heure, ce qui est dix fois plus efficace que de simplement dire « c'est très lent ».

Méthode de collecte de preuves en trois étapes

Pour défendre vos droits en cas de survente, il ne suffit pas de ressentir un lag. Pour constituer un dossier de preuves de niveau tutoriel PDF pour un ticket de réclamation de survente de serveur cloud, vous devez utiliser trois outils : Steal Time, la chute du cache disque et les benchmarks réels. Commençons par les données :

# 查看 CPU steal time（持续采集10秒）
top -b -d 2 -n 5 | grep steal
# 或 mpstat
mpstat -P ALL 2 5

# 测磁盘缓存掉速：连续读8次，观察第一次 vs 后续
dd if=/tmp/test of=/dev/null bs=1M count=1024 2>&1 | tail -1
for i in {1..7}; do dd if=/tmp/test of=/dev/null bs=1M count=1024 2>&1 | tail -1; done

Si le Steal Time dépasse 10 % de manière continue, cela signifie que le CPU est volé par l'hôte physique ; si le cache disque chute à un tiers après la première exécution, c'est que le cache est saturé par d'autres. Ensuite, lancez un benchmark avec YABS ou sysbench, puis enregistrez les résultats avec l'horodatage du ticket en PDF — n'utilisez pas de captures d'écran, car le PDF conserve les métadonnées, et le support ne pourra pas dire « l'image n'est pas claire ». Ces trois éléments combinés constituent une preuve de survente de serveur cloud, à joindre directement au ticket pour demander un remboursement conformément au SLA.

Comment créer un dossier de preuves PDF

Après avoir effectué les benchmarks, il ne suffit pas d'envoyer des captures d'écran au support client ; il faut compiler un dossier de preuves PDF — c'est la preuve tangible d'une surallocation du serveur cloud. Cette étape détermine directement si le ticket sera « discuté » ou « conflictuel ».

Mon approche se décline en trois parties (correspondant au rapport test CloudWorth) :

1. Graphique de la timeline Steal Time : Extrayez la courbe de 24 heures avec mpstat -P ALL 1 ou la surveillance intégrée de CloudWorth, et capturez principalement les périodes où le steal CPU est durablement supérieur à 10 %. Le titre du graphique doit indiquer « Steal CPU des processus continus (%, dépassant le seuil de 10 %) ».
2. Preuve de l'effondrement du cache disque : Lancez fio --name=randwrite --rw=randwrite --bs=4k --size=1G --numjobs=4, et enregistrez les courbes IOPS de trois exécutions consécutives. Sur une machine surallouée, la première exécution donne généralement 5k IOPS, la troisième chute en dessous de 500. Utilisez l'instantané IOPS de CloudWorth pour capturer cette « falaise », et notez à côté : « Même disque, baisse de 90 %. »
3. Récapitulatif du benchmark YABS : Exécutez le YABS complet, placez sur la même page les scores mono-cœur / multi-cœurs, la vitesse iozone et la latence réseau, en ajoutant le modèle de la machine et les informations de l'hôte (le nom du modèle dans cat /proc/cpuinfo).

Générez le PDF avec l'option d'impression du navigateur « sans en-têtes ni pieds de page », nommez-le overselling_evidence_YYYYMMDD.pdf, et ajoutez les numéros de page et l'heure du test en bas de chaque page. Dans le ticket, écrivez :

Ci-joint le dossier de preuves PDF du 2025-06-01 au 2025-06-03 (contenant la courbe Steal Time, la comparaison des trois exécutions consécutives de fio IOPS, et le benchmark YABS). Le steal CPU moyen est de 27 %, la baisse disque de 90 %, ce qui s'écarte des performances de référence de la même configuration. Veuillez vérifier et proposer un remboursement ou une solution de migration.

Ainsi, le support ne peut pas parler de « fluctuations occasionnelles », car les données sont continues et reproductibles. Le message clé est : « Ce n'est pas un voisin bruyant, c'est une surallocation systématique par rapport aux spécifications du même modèle. » Si le premier ticket est rejeté, utilisez les mêmes données du PDF, ouvrez un nouveau ticket sous l'angle de la « violation de SLA », et mentionnez les clauses relatives à cloud server overselling evidence for dispute.

Discours de réclamation par ticket

Une fois que vous avez obtenu le package de preuves PDF contenant le Steal Time, la chute brutale du cache disque et les résultats de benchmark, ne vous énervez pas. L'essentiel de la communication par ticket est de « dialoguer avec les données », pas de se plaindre. J'écris généralement ceci :

Lors des tests yabs et fio sur mon instance, le CPU steal a dépassé 30 % en continu, et les écritures du cache disque ont chuté brutalement, avec des performances bien inférieures aux vCPU et IOPS promis. C'est clairement une contention de ressources causée par la surréservation, et non des fluctuations occasionnelles d'un voisin bruyant. Veuillez vérifier le rapport de benchmark complet et les captures d'écran en pièce jointe.

Il y a trois points clés dans le discours :

1. Citez des chiffres précis : par exemple steal 35 %, la latence d'écriture aléatoire 4k de fio est passée de 0,2 ms à 8 ms, afin que le support ne puisse pas se défausser avec des « fluctuations normales ».
2. Comparez avec les conditions de service : si les CGU ou le SLA du fournisseur promettent des ressources exclusives, soulignez directement que « cela constitue une violation de contrat, et non une utilisation raisonnable de ressources partagées ». La plupart des agents de support reculent devant le mot violation.
3. Exprimez clairement votre demande : dès le début, dites « je veux soit un remboursement, soit une migration vers un nœud non surréservé », sans détour.

Si la première réponse du support est « nous enquêtons » et qu'aucune nouvelle n'arrive après trois jours, n'attendez pas. Ajoutez directement des données et une chronologie au ticket d'origine :

J'ai effectué trois tests les 1er, 3 et 5 juillet, et le steal est toujours resté au-dessus de 25 %. Veuillez fournir une explication technique. Si aucune solution concrète n'est apportée sous 48 heures, j'ouvrirai une contestation auprès du prestataire de paiement.

Cette astuce fonctionne particulièrement bien avec les fournisseurs étrangers : ils craignent les chargebacks. Tout au long du processus, le package de preuves PDF est votre arme, et le discours de ticket est vos munitions. Rappelez-vous : vous faites une réclamation technique, pas une dispute. Transformez chaque chiffre en fait irréfutable, et votre taux de succès de remboursement peut doubler.

Si vous voulez d'abord vérifier que le package de preuves est complet, reportez-vous à la section 3 de ce guide ; s'il est rejeté, passez à la section 5 pour voir les voies de recours.

Que faire si votre remboursement est refusé

Rejeté par le chat du service client avec un « les fluctuations des ressources partagées sont normales » ? Ne vous précipitez pas pour abandonner. Tout d'abord, examinez attentivement votre dossier de preuves PDF : Steal Time dépasse-t-il 20 % en continu, le cache disque chute-t-il brutalement, et la comparaison des benchmarks est-elle accompagnée d'horodatages et de l'ID de l'instance ? Ce ne sont pas des « impressions de lenteur », mais des indicateurs quantitatifs vérifiables qui peuvent directement contrer le discours du « voisin bruyant ».

Action clé : copiez les raisons de refus du service client dans le ticket et comparez-les point par point avec vos preuves. Par exemple, si l'on vous dit que « les fluctuations de performances sont conformes au SLA », demandez en retour : le SLA inclut-il une limite supérieure pour le CPU steal time ? La chute à zéro du cache disque est-elle couverte par les conditions convenues ?

L'étape suivante est la voie d'escalade :

• Si aucune réponse satisfaisante n'est reçue sous 24 heures, répondez au ticket pour demander le transfert au support avancé ou à un chargé de litige ;
• Soumettez également un dossier de preuves PDF (5 à 10 pages recommandées), avec en première page un tableau récapitulatif : « indicateur de surallocation — temps — commande de test — résultat » ;
• Citez les clauses du contrat ou des conditions de service concernant les « ressources dédiées », et soulignez que la surallocation constitue une violation des termes du service, et non un simple problème de performance ;
• Enfin, indiquez clairement votre demande : un remboursement au prorata du temps restant, ou une migration vers une instance non surallouée en payant la différence.

# 生成最终证据包时，记得把每个测试命令的 log 一并转存为 PDF
# 用 printf 拼接简单的投诉时间线，作为工单附件

Si vous êtes toujours refusé à ce stade, demandez au fournisseur de fournir un rapport d'audit prouvant la « non-surallocation ». La plupart des fournisseurs, lorsque la chaîne de preuves est complète, acceptent le remboursement comme solution pour limiter les pertes. Rappelez-vous : la leçon la plus importante de ce tutoriel PDF sur la collecte de preuves pour les réclamations de surallocation de serveurs cloud est de transformer la dispute en examen des données.

Litiges courants et pièges à éviter

Lorsqu'on défend ses droits face à l'overselling de serveurs cloud (étape centrale du tutoriel sur les preuves PDF par tickets), le plus difficile n'est pas la détection, mais le fait que le support client vous esquive avec des arguments comme « voisins bruyants ». Mon expérience : ne paniquez pas, sortez les données. Voici les points de litige les plus courants lors d'une réclamation ; les anticiper vous évitera bien des discussions.

Litige 1 : les benchmarks ne sont pas reconnus comme fiables par le support. Si vous fournissez simplement une capture d'écran de YABS, on vous répondra que « les ressources partagées fluctuent naturellement ». La solution est d'ajouter les données de Steal Time — si dans top ou vmstat le steal dépasse 30 % en continu, cela signifie que le temps CPU est accaparé par l'hôte, ce que les « voisins » ne peuvent pas expliquer.

Litige 2 : les performances disque ressemblent à des montagnes russes. Quand le cache est normal, fio affiche de belles performances, mais dès que le cache chute, les performances s'effondrent. Une capture d'écran ne montre qu'« un instant », il faut donc exécuter iostat -x 1 pendant 10 minutes, puis exporter les courbes d'utilisation du disque et du taux de hit du cache, ainsi que les journaux de fio, dans un PDF.

Piège à éviter : les captures d'écran peuvent être accusées de falsification ; en revanche, les horodatages, les sorties de commandes et les chaînes de journaux dans un PDF sont irréfutables.

Ensuite, un litige courant est : « que faire si le remboursement est refusé ? » Il est normal que le premier ticket soit refusé ; l'essentiel est de faire escalader : citez les clauses du SLA (par exemple, un dépassement du steal time CPU constitue une violation de performance), joignez un PDF de rapport de benchmarks sur 7 jours consécutifs, et demandez enfin à être transféré au service de facturation. La plupart des fournisseurs accepteront un remboursement, car l'arbitrage pour violation du SLA est plus compliqué.

Liste des pièges à éviter :

• N'insultez pas dans les tickets, contentez-vous de lister les données.
• Le dossier de preuves doit contenir : les journaux de Steal Time, l'effondrement du cache disque, et des PDF de benchmarks provenant de trois outils différents.
• Conservez toutes les réponses des tickets, sauvegardez les captures d'écran en PDF, pour empêcher le support de les modifier ou supprimer.

Rappelez-vous : défendre ses droits en cas d'overselling n'est pas une dispute, c'est une communication avec un dossier de preuves PDF vérifiables. Si vous faites cela correctement, vos chances d'obtenir un remboursement doublent.