Guide de collecte de preuves et de rédaction de tickets pour la surallocation de serveurs cloud

3 étapes pour obtenir des preuves de surallocation et rédiger un ticket efficace

Mis à jour 2026-09-05 · CloudWorth

surallocationpreuvestickettest de performanceCloudWorthSteal TimeSurvente VPSBenchmark VPS

Utilisez des journaux système + horodatages + certification par un tiers pour fixer les preuves, et visez directement la violation du SLA dans le ticket.

Comment tester la surallocation

Ne vous précipitez pas pour juger le fournisseur avec des logiciels de benchmark — s'il vous répond juste « méthode de test non standard », même les plus belles captures d'écran ne serviront à rien. La surallocation consiste à allouer des ressources physiques au-delà de leur capacité, mais ses manifestations se cachent dans deux endroits discrets : le Steal Time du CPU et l'effondrement du cache disque.

Commencez par exécuter une mesure de référence en période de faible charge : utilisez top -d 5 pour enregistrer la valeur de steal pendant 10 minutes. Un serveur cloud normal devrait afficher une valeur inférieure à 1 % ; si elle dépasse 5 % sur une période prolongée, cela signifie que des machines virtuelles voisines empiètent sur vos vCPU. Pour les E/S disque, ne vous contentez pas d'observer les pics avec fio ; regardez plutôt la courbe de débit lors d'une écriture continue de 10 Go — une fois le cache de l'hôte suralloué épuisé, les IOPS chutent brutalement, un fait qu'aucune « méthode de test » ne peut changer.

Exécutez le même test à trois moments différents (par exemple, hors pointe, heure de pointe du soir, petites heures) en conservant les sorties brutes. Si vous ne comprenez même pas le Steal Time, vous pouvez d'abord suivre les points que nous avons réunis pour dérouler le processus, ou consulter un exemple de diagnostic automatisé dans /app. Rappelez-vous : le test ne consiste pas à savoir « si c'est lent ou non », mais « si les ressources sont volées par les voisins ».

Comment consolider les preuves

L'objectif de la collecte de preuves n'est pas de prouver que les performances sont « médiocres », mais de prouver que les « engagements de ressources ne correspondent pas au SLA ». Chaque preuve doit donc comporter quatre éléments : horodatage, nom de la commande ou de l'outil, sortie brute, environnement d'exécution.

Exécutez date -u +%FT%TZ conjointement avec la commande de test pour que les journaux incluent automatiquement l'heure UTC ; puis utilisez script -a session.log pour enregistrer toute la session de terminal, afin d'éviter tout soupçon de falsification a posteriori. Les captures d'écran doivent conserver la barre de titre et l'heure système. Il est recommandé de filmer l'écran avec un téléphone et de lire l'heure actuelle à voix haute au début de la vidéo — c'est l'ancrage temporel tiers le plus élémentaire. Pour les captures d'écran de la chute brutale du cache disque, accompagnez-les d'un enregistrement continu avec iostat -dx 5, sauvegardé en CSV, plus convaincant qu'une simple image.

N'oubliez pas la « validation croisée » : les deux séries de tests doivent être espacées d'au moins 6 heures, de préférence à cheval sur le « cycle de renouvellement » ou le « pic d'activité du locataire voisin ». Si vous ne testez qu'une seule fois, l'autre partie peut se défausser ; mais si vous obtenez des résultats répétés à différentes dates et sous différentes charges, la chaîne de preuves est bouclée.

Les plus astucieux en tireront une courbe de rapport qualité-prix : à prix égal, votre part de CPU allouable est-elle inférieure de 30 % à celle des références du cloud public ? Bien que cela ne prouve pas directement la surréservation, cela permet d'élever la « controverse technique » en « perte de prime FinOps », transformant le ticket de « vous mentez » en « je perds de l'argent ».

Comment rédiger un ticket

La règle d'or d'un ticket est de ne rapporter que des faits, pas des jugements. Ne dites pas « vous avez surréservé », dites « observation d'un CPU steal moyen de 12 %, et 4 chutes brutales du cache disque » ; ne dites pas « les performances sont insuffisantes », dites « conformément à l'engagement de performances CPU de votre SLA, les performances actuelles s'écartent de la ligne de base ».

Structure recommandée :

1. Description de l'environnement : configuration de l'instance, système d'exploitation, plage horaire.
2. Méthode de test : joindre les commandes de reproduction (utiliser des commandes génériques, pas le panneau BaoTa ni d'outils de benchmark tiers).
3. Données brutes : trois jeux de journaux steal, CSV disque, captures d'écran horodatées, le tout compressé en pièce jointe.
4. Description de l'impact : précisez les effets concrets sur le service (par exemple, les réponses API passent de 80 ms à 2 s).
5. Demande : demandez au fournisseur de vérifier l'état de charge de l'hôte physique et de fournir une explication de l'allocation des ressources.

Le modèle peut commencer ainsi :

« Notre instance a exécuté trois fois le même test le 2025-06-01 à 02:00, 08:00 et 20:00 ; les échantillons sont joints en annexe. Le CPU steal dépasse 8 % à chaque exécution, et après l'épuisement du cache disque, les IOPS chutent à moins de 20 % de la valeur nominale. Votre accord de niveau de service promet des performances de base pour le CPU et l'IO ; nous vous remercions de faire vérifier par votre équipe technique le ratio d'allocation actuel de l'hôte physique ainsi que la charge des instances voisines. »

Attention : n'utilisez pas dans le corps du texte des termes comme « plainte », « surréservation » ou « fraude » — ces mots sont à garder pour plus tard, après que le ticket aura été escaladé. La valeur d'un ticket est d'empêcher l'autre partie de répliquer avec « vos outils sont imprécis » ; chaque donnée doit donc correspondre à une ligne de journal complète. Si l'autre partie répond « utilisez notre outil de test », vous pouvez répondre : « Nous avons déjà refait le test selon la méthode documentée par vos soins ; voir le troisième jeu de données en annexe. » Ainsi, vous renvoyez la balle dans son camp.

Que faire si le fournisseur ne reconnaît pas

Quand on vous répond « la méthode de test est problématique » ou « l’hôte a une charge normale », ne vous précipitez pas pour discuter. Demandez d’abord les journaux de surveillance de l’hôte pour la même période — ils ne peuvent souvent pas les fournir, ou seulement une version tronquée. Vous disposez alors de deux preuves solides : les journaux ligne par ligne montrant un steal CPU supérieur à 8 %, et la courbe montrant que les IOPS chutent à 20 % des valeurs annoncées une fois le cache disque épuisé. Transformez ces deux ensembles de données en tableau comparatif aligné dans le temps, et soulignez que si la chute brutale du cache disque coïncide avec le pic de steal, cela indique que le processeur et les ressources de stockage de l’hôte ont été simultanément accaparés par les locataires voisins ; ce n’est pas une simple fluctuation de test, mais la forme typique de surprovisionnement du pool de ressources.

Si le fournisseur insiste en disant « l’outil n’est pas fiable », vous pouvez répondre : « Veuillez fournir le script et les paramètres de test officiellement recommandés par votre société ; je referai le test selon votre documentation et ferai enregistrer la procédure par un tiers de confiance. » Cette étape permet de transférer la charge de la preuve au fournisseur. En parallèle, effectuez deux autres tests indépendants à des dates différentes (par exemple tôt le matin et pendant le pic du soir) pour obtenir une validation croisée. Si les trois échantillons aboutissent à la même conclusion, le fournisseur ne pourra plus se retrancher derrière un « incident isolé ». Pensez à conserver les journaux bruts de chaque test, l’heure système, les enregistrements de synchronisation NTP, ainsi que les horodatages des captures d’écran — ce sont les éléments nécessaires pour une éventuelle réclamation auprès de canaux de niveau supérieur.

Escalade des plaintes et remboursement

Si le service client direct refuse de faire remonter votre demande, déclenchez l'escalade par les canaux appropriés : d'abord, envoyez un e-mail à l'adresse abuse/plainte affichée sur le site officiel du fournisseur, avec pour objet « Numéro de pièce jointe des preuves de violation de SLA » ; ensuite, soumettez les documents à l'administration des communications de la juridiction du fournisseur de cloud ou au centre de réception des signalements pour les contenus nuisibles et le spam sur Internet (12321). Lors de la soumission, ne répétez pas les conclusions des tests, listez simplement une liste des faits : à quelle date, sur quelle instance, quel test a été exécuté, quelle était la valeur du résultat, et à quelle clause de SLA elle correspond.

La demande de remboursement doit se faire en deux étapes. Tout d'abord, demandez un remboursement de la durée non utilisée conformément aux règles de remboursement du fournisseur, en indiquant clairement que le non-respect des ressources a causé des pertes commerciales et que vous demandez une compensation supplémentaire. Vous pouvez alors faire le calcul dans une perspective FinOps : vous avez payé trop cher pour une configuration annoncée de 8 cœurs et 16 Go de RAM, alors que la puissance de calcul réellement disponible ne correspond qu'à 3 cœurs, et le rapport qualité-prix est déjà déséquilibré. Si le fournisseur ne propose qu'un remboursement partiel, insistez pour obtenir une « description de l'allocation des ressources » indiquant clairement si cette instance partage un serveur hôte avec des VPS bon marché à haute densité. La plupart des fournisseurs craignent que vous utilisiez ce document pour signaler une surréservation et proposeront une solution de compromis.

Dernière remarque : toutes les communications doivent être effectuées via des tickets ou des e-mails, et conservez des captures d'écran. Si vous demandez un remboursement, pensez à exporter d'abord les données du disque avant de supprimer l'instance — après le remboursement, l'instance sera supprimée, et vos journaux d'investigation doivent être conservés pendant au moins 180 jours pour une éventuelle procédure d'arbitrage ou un procès ultérieur. Même si le remboursement aboutit, il est recommandé d'appliquer cette méthode d'investigation au prochain fournisseur, en vérifiant soigneusement avant de payer, pour éviter de retomber dans le même piège.