VPS mort ? Le crabe a écrit le ticket au fournisseur
Un VPS de production est devenu totalement injoignable au niveau réseau, pas de ping, pas de SSH, pas de HTTPS, alors que le panneau de l’hébergeur affichait toujours « running ». Le crabe du profil ops d’Alexey a traité l’incident de bout en bout : panne confirmée depuis deux points de vue indépendants, pilotage de l’API du fournisseur depuis le shell, déterrage de leur nouvelle API power v2 dans le repo de doc, et récupération de la preuve décisive, le panneau du fournisseur lui-même n’arrivait pas à joindre le nœud hyperviseur Proxmox. Puis de la forensique côté guest après le rétablissement, et un ticket d’escalade prêt à coller, dans la langue du fournisseur.
Vrai incident, 2026-09-06. n8n, Postgres, ~20 conteneurs sur un seul VDS. Tombé vers 05:30 UTC depuis deux réseaux indépendants alors que le panneau affirmait « running » et que deux redémarrages depuis le panneau n’ont rien changé. Le crabe a pris le relais :
- Vérification depuis deux points de vue : injoignable confirmé depuis deux réseaux différents, ce qui écarte le routage local avant de toucher à quoi que ce soit
- L’API du fournisseur pilotée depuis le shell : via un script CLI qu’il avait écrit et commité dans le repo infra quelques jours plus tôt, avec la clé d’API stockée hors de git
- L’API power v2 du fournisseur trouvée dans leur repo de doc, et bascule hors des endpoints legacy, ce qui a révélé la preuve décisive : le panneau du fournisseur lui-même n’arrivait pas à joindre le nœud hyperviseur Proxmox (
connect ETIMEDOUTsur le port de management du nœud), état d’alimentation périmé, et les quatre redémarrages en file (2 panneau + 2 API) n’avaient jamais été exécutés - Arrêté de tirer des redémarrages au moment où les preuves pointaient vers le nœud hôte, aucune action aveugle une fois qu’il était clair qu’aucun appel API ne pouvait aider avant l’intervention du fournisseur
- Forensique côté guest après le rétablissement : première connexion sortante échouée à 05:30:02 et rétablissement à 08:51:59, épinglés depuis les logs de health-check des conteneurs ; uptime continu, zéro événement de link-down sur la NIC et syslog ininterrompu pendant toute la coupure, la preuve que le guest était innocent
- Tableau d’impact par conteneur : quels services ont loggé des tempêtes de retry, lesquels n’ont pas été touchés, et le seul conteneur qui a OOM comme effet de bord
- Le livrable : un rapport d’escalade prêt à coller pour le support du fournisseur, rédigé dans la langue du fournisseur, avec les chaînes d’erreur exactes de leur propre API comme preuve
Verdict : wedge du datapath de l’hyperviseur, guest innocent. Deuxième signature identique en quatre jours, signalée comme un schéma d’incident récurrent avec une recommandation de migration. Toute la connaissance du diagnostic (les particularités de l’API du fournisseur, la loi « vérifier l’état d’alimentation avant de tirer des redémarrages ») persistée dans les brain files du crabe, et le fil d’investigation a survécu à ~5 heures et à plusieurs compactions de contexte sans perdre le fil.