¿VPS muerto? El cangrejo escribió el ticket al proveedor
Un VPS de producción se quedó completamente muerto de red (sin ping, sin SSH, sin HTTPS) mientras el panel del proveedor seguía diciendo “en ejecución”. El cangrejo del perfil de operaciones de Alexey trabajó el incidente de principio a fin: confirmó la caída desde dos puntos de observación independientes, manejó la propia API del proveedor desde la shell, desenterró su nueva API de energía v2 del repositorio de documentación y sacó la prueba definitiva: el propio panel del proveedor no podía alcanzar el nodo del hipervisor Proxmox. Después, análisis forense del lado del guest tras la recuperación, y un ticket de escalado listo para pegar en el idioma del proveedor.
Incidente real, 2026-09-06. n8n, Postgres, unos 20 contenedores en un solo VDS. Caído hacia las 05:30 UTC desde dos redes independientes mientras el panel afirmaba “en ejecución” y dos reinicios desde el panel no hacían nada. El cangrejo tomó el relevo:
- Verificación desde dos puntos: confirmó que era inalcanzable desde dos redes distintas, descartando el enrutamiento local antes de tocar nada
- Manejó la API del proveedor desde la shell: usando un script de CLI que había escrito e integrado en el repo de infraestructura días antes, con la clave de API guardada fuera de git
- Encontró la API de energía v2 del proveedor en su repositorio de documentación y dejó de usar los endpoints antiguos, lo que reveló la prueba definitiva: el propio panel del proveedor no podía alcanzar el nodo del hipervisor Proxmox (
connect ETIMEDOUTen el puerto de gestión del nodo), el estado de energía estaba desactualizado y ninguno de los cuatro reinicios en cola (2 del panel + 2 de la API) se había ejecutado - Dejó de lanzar reinicios en el momento en que las pruebas apuntaron al nodo anfitrión: ninguna acción a ciegas cuando quedó claro que ninguna llamada a la API podía ayudar hasta que interviniera el proveedor
- Análisis forense del guest tras la recuperación: la primera conexión saliente fallida a las 05:30:02 y la recuperación a las 08:51:59 quedaron fijadas a partir de los logs de health check de los contenedores; uptime continuo, cero eventos de caída de enlace de la NIC y syslog sin interrupciones durante todo el apagón, prueba de que el guest era inocente
- Tabla de impacto por contenedor: qué servicios registraron tormentas de reintentos, cuáles no se vieron afectados y el único contenedor que sufrió un OOM como efecto colateral
- El entregable: un informe de escalado listo para pegar al soporte del proveedor, escrito en el idioma del proveedor, con las cadenas de error exactas de su propia API como evidencia
Veredicto: bloqueo del datapath del hipervisor, el guest era inocente. Segunda firma idéntica en cuatro días, marcada como patrón de incidente repetido con una recomendación de migración. Todo el conocimiento del diagnóstico (las rarezas de la API del proveedor, la ley de “comprobar el estado de energía antes de lanzar reinicios”) quedó guardado en los archivos de cerebro del cangrejo, y el hilo de investigación sobrevivió unas 5 horas y varias compactaciones de contexto sin perder el hilo.