Méthode en quatre étapes pour réduire et remplacer la configuration du serveur cloud : comment abaisser en toute sécurité une configuration élevée inutilisée

Identifiez le « gros cheval qui tire une petite charrette », puis réduisez la configuration sans réduire les performances.

Mis à jour 2026-08-09 · CloudWorth

Réduction de configuration cloudGros cheval pour petite charretteAlternative abordableFinOpsBenchmark réelCloudWorthSteal TimeSurvente VPSBenchmark VPS

Utilisez le benchmark réel et Steal Time pour vérifier, afin de réduire la configuration en toute sécurité et d'économiser la moitié du budget.

Comment détecter un “cheval de trait pour une petite charrette”

Ne vous précipitez pas pour réduire la configuration. D'abord, vérifiez si votre serveur cloud est vraiment un cas de “cheval de trait pour une petite charrette” – CPU constamment sous 10 %, mémoire utilisée à moins de la moitié, I/O disque presque inactif, mais la facture mensuelle est celle d'une configuration haut de gamme. Ce scénario est très typique : on achète un 8C16G pour une “future expansion”, et après six mois d'exploitation, on n'utilise que 2C4G.

Ma méthode ne consiste pas à regarder les courbes CPU de la console, mais à utiliser CloudWorth pour extraire trois ensembles de données : benchmark réel, Steal Time, et performance du cache disque.

• Benchmark réel vs configuration annoncée : pour un même serveur cloud, le nombre de vCPU annoncé ne correspond pas forcément à la puissance de calcul réellement obtenue. Lancez sysbench pendant 30 minutes et comparez le score avec celui d'autres fournisseurs au même prix. Si l'écart dépasse 30 %, vous payez une prime pour une “configuration papier” – c'est exactement le “piège du rapport qualité-prix” typique en FinOps.

• Le Steal Time, miroir de la survente : sous Linux, regardez directement le champ steal de /proc/stat, ou %st dans top. S'il dépasse 5 % sur une longue période, cela signifie que des voisins vous volent du CPU, et votre configuration haut de gamme est peut-être “faussement costaude”. Dans ce cas, avant de réduire la configuration, vérifiez en changeant d'abord de machine, sinon vous risquez d'obtenir un serveur encore plus lent.

• Test du gouffre de cache disque : avec dd, écrivez un fichier de 2 Go ; les 200 premiers Mo atteignent 1,2 Go/s, puis la vitesse chute à 150 Mo/s – c'est la courbe typique d'un cache vidé. Lors de la réduction de configuration, comparez l'I/O stable des anciens et nouveaux forfaits, ne vous laissez pas berner par la “rapidité des premières secondes”.

En un mot : d'abord les preuves, ensuite la réduction. Parlez avec le benchmark réel et le Steal Time, afin d'éviter l'illusion du “cheval de trait pour une petite charrette”, et les économies réalisées seront réellement dans votre poche.

Performances réelles vs configuration annoncée

Acheter un serveur cloud en se basant sur le nombre de cœurs CPU, la mémoire et la bande passante annoncés, c'est comme regarder un CV avec la mention « diplômé d'une grande école » — ça sonne bien, mais il faut encore passer un entretien pour voir si ça tient la route. J'ai l'habitude de sortir sysbench, Geekbench et Steal Time pour les faire courir, surtout quand vous soupçonnez d'avoir un « gros cheval tirant une petite charrette ».

Commençons par un piège : j'ai vu une instance 8C16G avec un score monocœur seulement 1,2 fois supérieur à la référence, et un Steal Time constamment supérieur à 20 %. En apparence, c'est une haute configuration inutilisée, mais en réalité c'est une sur-vente du voisinage, la puissance de calcul réelle n'atteignant même pas une 2C4G. Ce « gros cheval tirant une petite charrette » est une illusion — ce n'est pas que le travail est petit, c'est que la machine est faible. Donc avant de réduire la configuration, il faut d'abord rassembler des preuves : utiliser des benchmarks réels pour mettre à nu l'ancienne instance, examiner les scores CPU, l'écriture aléatoire 4K du disque, et voir si le cache chute brutalement.

Un autre point de croisement est le taux de prime FinOps. Beaucoup d'instances « à haute rapport qualité-prix » ont un prix bas et des spécifications annoncées correctes, mais après épuisement du cache disque, elles retombent à la vitesse du disque nu, c'est un faux bas prix. Pour une véritable alternative économique, il faut regarder simultanément la stabilité des performances sur 30 minutes et le Steal Time, lancer un cycle avec CloudWorth, et dresser un tableau « annoncé → mesuré → prime ». Ce n'est que si les valeurs sont correctes que la réduction de configuration ne revient pas à remplacer un grand cheval par un cheval maigre.

La méthode en quatre étapes pour une réduction de configuration sans risque

Réduire la configuration n'est pas une décision à prendre à la légère. Voici une méthode en quatre étapes, chacune visant à éviter le piège classique : passer d'une machine surdimensionnée et surbookée à une machine plus modeste mais normale, pour finalement obtenir de moins bons résultats qu'avant.

Étape 1 : Prouver qu'il s'agit vraiment d'un "gros cheval pour une petite charrette"
Ne vous fiez pas aux quelques cœurs et quelques Go affichés dans la console. Commencez par extraire les courbes d'utilisation CPU, mémoire, I/O disque et réseau sur une semaine. Si le CPU reste durablement sous les 10 % et que les lectures/écritures disque sont quasi inexistantes, c'est que vous gaspillez des ressources. Mais attention : vérifiez avec de vrais benchmarks, ne vous laissez pas berner par les spécifications annoncées. Lancez YABS et sysbench, comparez avec les données de Steal Time de CloudWorth. Si le Steal Time de la machine haut de gamme dépasse 10 % sur une longue période, ses "performances" sont peut-être factices, et une réduction de configuration pourrait même être plus stable.

Étape 2 : Choisir l'offre cible selon le rapport qualité/prix, pas uniquement le prix unitaire
Divisez le coût mensuel des anciennes et nouvelles offres par le score de benchmark réel (par exemple le score single-core de Geekbench) pour obtenir les performances obtenues pour chaque centime dépensé. C'est en fait la logique du "taux de prime" dans le FinOps : ne payez pas pour de la redondance inutile, et ne choisissez pas non plus un "roi du surbooking" dont le score s'effondre juste pour économiser de l'argent. Comparez surtout les performances du cache disque : utilisez dd pour lire en continu 1 Go et 10 Go, et observez si le débit chute brutalement après les premières secondes. Si le cache est normal sur la machine réduite, l'expérience est souvent plus fluide.

Étape 3 : Vérifier immédiatement le Steal Time après la migration
Après avoir réduit la configuration, ne supprimez pas immédiatement l'ancienne machine. Lancez d'abord stress pendant 30 minutes tout en surveillant la colonne st avec vmstat. Si le Steal Time de la nouvelle instance est supérieur à 15 %, cela signifie que le voisin est trop bruyant. Changez immédiatement de région ou de fournisseur. Cette étape est le plancher de sécurité de toute réduction de configuration.

Étape 4 : Observer pendant deux semaines et prévoir un plan de rollback
Conservez un instantané de l'ancienne machine et observez au moins deux cycles de pic d'activité. Si le trafic augmente, remontez la configuration, ne subissez pas. Mon expérience personnelle : en suivant ce processus, ma facture mensuelle est passée de 40 $ à 18 $, et le score de benchmark a même augmenté de 12 % — car je me suis débarrassé du "faux poids" de la machine haut de gamme surbookée.

En résumé : L'essentiel de la réduction de configuration n'est pas de rogner sur le budget, mais de prouver avec des données que vous utilisez un "petit cheval pour une petite charrette", puis de remplacer ce cheval par un autre non surbooké qui tire la même charrette.

Comment vérifier la surallocation après une réduction de configuration

Après une réduction de configuration, la plus grande crainte n'est pas la baisse de performance, mais d'avoir payé pour obtenir de moins bonnes performances — ce qui n'est généralement pas dû à la réduction elle-même, mais au fait que la nouvelle instance souffre de surallocation. La méthode de CloudWorth est la suivante : ne vous fiez pas à la configuration annoncée, faites d'abord un test réel de 30 minutes.

Commencez par le Steal Time. Sur l'instance, lancez un échantillonnage continu :

vmstat 5 60 | awk '$22'  # 第22列是st，采样5秒一次，共60次

Si la moyenne de st dépasse 5 %, cela signifie que les voisins de l'hôte physique utilisent le CPU de manière intensive, et il y a une forte suspicion de surallocation. Si elle dépasse 15 % sur une longue période, il est recommandé de changer de fournisseur ou de forfait.

Examinez ensuite les scores réels et la courbe de cache disque. Avant la réduction, les scores ont peut-être été « pénalisés » par la concurrence pour les ressources de la machine virtuelle de haute configuration ; après la réduction, ils peuvent au contraire être plus rapides — ce qui valide à l'envers que votre configuration précédente était typiquement « un cheval de trait tirant une petite charrette ». Utilisez le même ensemble de scripts (comme sysbench + fio) pour comparer l'ancien et le nouveau, en vous concentrant sur :

• Les variations des scores mono-cœur et multi-cœurs, plutôt que le score total
• Les lectures/écritures en cache du disque sur les 10 premières secondes par rapport aux écritures aléatoires une fois stabilisées
• Si la bande passante mémoire atteint la fréquence annoncée

Si l'écart entre le score de la nouvelle instance et la « configuration annoncée » dépasse 30 %, méfiez-vous de la surallocation ; s'il est inférieur à 20 %, cela signifie que le rapport qualité-prix de cette gamme de prix est déjà bon.

Ajoutons ici une perspective FinOps : appelons le rapport performance réelle / coût mensuel après réduction le « ratio de rentabilité ». Par exemple, l'ancienne machine coûte 200 yuans par mois et obtient un score de 8000, soit un ratio de 40 ; la nouvelle machine coûte 100 yuans par mois et obtient un score de 6000, soit un ratio de 60 — bien que le score ait baissé de 25 %, la performance par unité de coût a augmenté de 50 %, c'est là la zone idéale de la réduction avec remplacement.

Enfin, n'oubliez pas de redémarrer pour vérifier. De nombreuses opérations de réduction sont des « modifications à chaud » ; après le redémarrage, le quota CPU et la limitation de vitesse du disque sont rechargés. Redémarrez puis relancez un cycle de vmstat et fio pour confirmer que le Steal et les IOPS ne chutent pas brutalement. C'est seulement à ce moment-là que la réduction est réellement réussie.