Runbook: Servicio caído¶

🚧 En construcción — este procedimiento se documentará cuando la infraestructura esté desplegada y el escenario pueda probarse.


Gravedad	🟡 Media a 🔴 Crítica (según el Tier del servicio)
Tiempo de respuesta	< 5 min (Tier A), < 30 min (Tier B), < 4h (Tier C)
Roles implicados	Argos (detección), Terminus (remediación), Hefesto (si requiere reconstrucción)

Síntomas¶

[ ] Confirmar que el problema es de un solo servicio (los demás funcionan)
[ ] Intentar acceder desde dentro de la red (descartar problema de VPN (red privada virtual))
[ ] Verificar el LXC (contenedor ligero de Proxmox): pct status <ID> en Proxmox
[ ] Verificar el contenedor Docker: docker ps | grep <servicio> dentro del LXC (contenedor ligero de Proxmox)
[ ] Revisar logs: docker logs <servicio> --tail 50
[ ] Comprobar si el puerto responde: curl http://<IP>:<puerto>
[ ] Verificar que Pi-hole resuelve el nombre: nslookup <servicio>.sc
[ ] Verificar que Caddy enruta correctamente

[ ] Si el LXC está parado: pct start <ID>
[ ] Si Docker está caído dentro del LXC: docker compose up -d
[ ] Si el contenedor no arranca: revisar logs, restaurar última snapshot ZFS (sistema de archivos con integridad de datos)
[ ] Si es un problema de red: verificar reglas de firewall y conectividad
[ ] Como último recurso: restaurar desde PBS (sistema de copias de seguridad de Proxmox)

Healthcheck configurado en el LXC (watchdog systemd o Docker)
Alerta en Uptime Kuma para todos los servicios
Snapshot ZFS (sistema de archivos con integridad de datos) antes de cada actualización
Plan de degradación documentado (qué apagar si faltan recursos)