Exemple de rapport public
Comprenez ce que les mesures des workloads permettent de conclure.
Exemple de démarche — ce n’est pas un cas client.
Cet exemple public utilise des données fictives VMware, Proxmox, KVM et Kubernetes pour montrer le format de preuve : allocation, signaux observés, données manquantes, risques et notes de décision. Les lignes représentent des workloads distincts, donc cette page n’invente pas une fausse paire avant/après.
Données de démonstration uniquement. Aucune infrastructure client ni aucun système réel n’est connecté.
Vue d’ensemble de l’infrastructure
Workloads fictifs: 4
Période d’observation: Non disponible
ND signifie non disponible, pas zéro. La présence d’un champ ne prouve pas une couverture temporelle représentative.
Allocation et utilisation observée
| Workload | Plateforme | vCPU alloués | RAM allouée (Gio) | Instantané CPU | Instantané RAM | Complétude du signal |
|---|---|---|---|---|---|---|
| prod-payments-api-01 | VMware | 4 | 8 | 18,4 % | 61,2 % | Partielle |
| prod-erp-db | Proxmox | 8 | 16 | 34 % | 75 % | Partielle |
| prod-web-02 | KVM/libvirt | 2 | 4 | ND | 48,5 % | Limitée |
| prod/payments-api-7f8cc9d78b-x42pz | Kubernetes | 0,6 | 0,875 | ND | ND | Limitée |
La complétude reflète les champs CPU/RAM disponibles dans le rapport. Elle ne constitue pas un niveau de confiance pour un dimensionnement final. Les allocations Kubernetes sont des demandes de ressources, pas une consommation mesurée.
Couverture, risques et prérequis
Ces données fictives ne comportent ni période d’observation ni séries temporelles. Les p95, p99 CPU/RAM, les pics et la couverture des cycles métier sont indisponibles. Une mesure courte ne garantit jamais le bon dimensionnement de la cible.
La mémoire invitée observée par VMware et la comptabilisation mémoire Proxmox n’ont pas le même sens. La pression d’un datastore VMware diffère aussi de l’utilisation disque d’un workload. Une même étiquette en pourcentage ne rend pas ces mesures comparables.
Avant un pilote, confirmez le responsable applicatif, les dépendances, les sauvegardes, les critères d’acceptation, la fenêtre de maintenance et le plan de retour arrière avec l’équipe responsable du changement.
Entrées/sorties disque, débit réseau, énergie, performance applicative et historique d’anomalies : ND. Aucune économie ni réduction énergétique n’est calculée.
Décision : examen complémentaire nécessaire
Ces éléments permettent de cadrer la prochaine observation et l’examen technique. Ils ne valident ni une configuration cible ni un changement en production.
Comment la validation avant/après est livrée aujourd’hui
Sur un projet réel, InfraWatts capture le périmètre convenu avant le changement, répète l’observation après la migration et le partenaire revoit la correspondance des workloads avant finalisation du rapport d’écarts. Le matching cross-platform n’est pas encore totalement automatique.
Cadrons une validation avant/après pour votre migration.
Indiquez la plateforme source, la cible, le nombre approximatif de workloads et la fenêtre de migration. Nous définissons la baseline avant, l’observation après et la méthode de correspondance avant tout traitement en production.
Étudier un cas de migration