Machines de service et instances de test

Parfois, une machine est attribuée non pas via une commande payante classique, mais pour une tâche interne : vérifier une image système, reproduire le problème d'un client, tester une configuration avant de la déployer. Techniquement, c'est la même machine avec le même accès root ; seuls la raison de son attribution et les règles de manipulation diffèrent.

En quoi elle diffère d'une machine classique

• Le tier et l'OS sont choisis pour la tâche, pas pour le confort : reproduire le problème d'un client exige exactement le tier et l'OS où le problème a été observé.
• Sa durée de vie est courte et connue à l'avance. La machine est créée pour une vérification et supprimée une fois celle-ci terminée.
• Les données qu'elle contient sont considérées comme jetables. Rien de précieux ou d'unique ne doit y être stocké.

Tout le reste est identique : le panneau /hosting/vds/m/<id> avec les mêmes onglets, deux types de console, le disque de récupération SystemRescue, la réinstallation de l'OS et le DNS inversé pour l'adresse.

Règles d'utilisation

1. Créez la machine pour une seule tâche. Un banc de test qui fait aussi tourner trois autres expériences « à côté » cesse d'être reproductible.
2. Notez ce que vous avez testé et sur quel tier. Un résultat du type « lent sur VDS-1 » est inutile sans la précision que le goulot d'étranglement était la limite d'écriture de 60 Mo/s.
3. Ne laissez pas de clés et de jetons actifs ayant accès aux services de production sur la machine de test. La machine sera supprimée, mais une clé tombée entre de mauvaises mains avant cela fonctionnera toujours.
4. Terminé — supprimez-la. Une machine occupée retient des cœurs CPU, de la mémoire et une adresse IPv4 publique dont d'autres ont besoin.

Le disque d'une machine supprimée ne peut pas être récupéré. Si quelque chose dont vous avez besoin est apparu pendant la vérification — un log, une configuration, un dump — copiez le fichier de votre côté avant la suppression : scp root@<address>:/root/report.txt .

Scénarios internes typiques

Vérification d'une image système. Commandez une machine avec la distribution requise, puis vérifiez qu'elle a démarré, que le réseau fonctionne et que l'agent invité est en place :

systemctl status qemu-guest-agent
ip -brief address
df -h /

Si l'agent est absent, le panneau n'affichera pas l'utilisation du disque et un redémarrage à chaud ne fonctionnera pas — le panneau propose lui-même la commande d'installation.

Reproduction du problème d'un client. Prenez le même tier et le même OS, répétez les étapes, capturez la sortie des commandes. Le diagnostic section par section est traité dans Le réseau est tombé sur la machine et Le service ne démarre pas : un parcours systemd.

Test d'une configuration avant la machine de production. Utile lorsque les changements touchent au réseau ou au démarrage : casser la machine de test et la restaurer via le disque de récupération coûte moins cher que de s'occuper de celle de production.

Après le test

Cochez la liste : résultats consignés, fichiers nécessaires copiés, aucun enregistrement DNS pointant encore vers l'adresse de la machine, clés avec accès externe révoquées. Libérez ensuite la machine — il n'y a pas de bouton de suppression dans le panneau ; la procédure et ses conséquences sont décrites dans Suppression d'une machine et période de rachat.