Tu servidor está caído, ¿estás preparado para repararlo? Guía práctica de diagnóstico, recuperación y prevención

Cuando un servidor cae, el reloj suena más fuerte. No necesitas magia: necesitas método. En esta guía te comparto el proceso que uso en el día a día para volver a estar en línea sin romper nada por el camino.

Diagnóstico rápido (15 minutos): ¿red, DNS o servidor?

Comprobaciones básicas (ping/mtr, acceso SSH/RDP, IPMI)

1. ¿Responde a la red?

2. ping y mtr/traceroute hacia la IP del servidor. Si hay pérdida de paquetes o rutas inestables, lo trato como incidente de red antes de tocar servicios.

3. Revisa DNS: ¿el dominio apunta a la IP correcta? ¿Cambios recientes con TTL alto? Un A/AAAA mal apuntado se siente igual que un servidor muerto.

4. ¿Puedo entrar?

5. Linux: ssh usuario@ip y journalctl -p err -n 100 o dmesg | tail.

6. Windows: RDP/WinRM.

7. Si no hay acceso por red pero sí por consola fuera de banda (IPMI/iDRAC/iLO/KVM-over-IP), el problema no es el S.O., es red o firewall.

8. ¿El balanceador/CDN tapa el síntoma?

9. Despublica temporalmente el nodo en el balanceador (drain) o by-passea CDN para ver la verdad.

10. Si usas WAF/rate limiting, verifica que no estés bloqueando “a los tuyos”.
    

En mi caso, si el servidor responde por consola pero no por red, no toco servicios: coordino con red/DNS. Si responde a ping pero no a HTTP/SSH, busco firewall/iptables/security groups antes de reiniciar nada.

Señales en logs y métricas (CPU, iowait, errores 5xx)

• CPU y RAM: top, htop, free -m, vmstat 1. Si la CPU está al 100 % con iowait alto, la raíz suele ser disco.

• Disco: df -h, iostat -xz 1, smartctl -a /dev/sdX. I/O saturado o sectores reasignados = bomba de tiempo.

• Red: ss -lntp/netstat -plant, ethtool, ip a, iptables -S o reglas en el firewall del cloud.

• Aplicación/Web: logs de Nginx/Apache, php-fpm -t, pm2 status/systemctl status. Un pico de 5xx con 200 OK en salud interna indica backend lento o DB ahogada.
  

Cuando detecto RAID degradado, priorizo integridad de datos antes de cualquier reinicio “para ver si se arregla”. Los reinicios con discos enfermos empeoran el daño.

Acciones inmediatas (60–180 minutos) para volver a estar en línea

Web/App: reinicios seguros, caché/CDN y rollback

• Congela cambios: detén despliegues automáticos.

• Reinicios de proceso, no de máquina: systemctl restart nginx php-fpm o pm2 reload. Revisa error logs antes y después.

• Caché/CDN: si la app sirve contenido estático, apóyate en CDN para ganar aire. Purga selectivamente.

• Rollback: si el incidente sigue a un deploy, vuelve a la versión estable (tag/commit anterior) con un cambio a la vez.

• WordPress: desactiva plugins problemáticos por SFTP/SSH renombrando la carpeta; habilita modo mantenimiento solo durante ventanas cortas.
  

Base de datos: integridad, réplicas y failover

• Salud: mysqladmin processlist, SHOW ENGINE INNODB STATUS\G, pg_stat_activity, tiempos de checkpoints.

• Bloqueos: identifica queries largas y corta con bisturí (no a lo loco).

• Réplicas: si hay réplica sana, promuévela y redirige lectura/escritura.

• Backups: si hay corrupción, restaura en nuevo host y apunta la app por variables de entorno.

• Índices y conexiones: un pool mal configurado provoca caídas “fantasma” en horas pico.

SMTP: pruebas, reintentos y conexión de respaldo

• Prueba básica: telnet smtp.tu-dominio 587 o openssl s_client -starttls smtp -connect host:587 para validar banner/TLS.

• Colas: Postfix mailq, Exim exim -bp. Depura mensajes atascados por dominios específicos.

• Fallback SMTP: configura un servidor de respaldo (otro proveedor/IP) para que las notificaciones críticas no se pierdan.

• Registros: SPF/DKIM/DMARC vigentes; errores 550 frecuentes = reputación o autenticación.

• 
  

En incidentes de correo, habilito logs detallados y reenvío masivo hacia un servicio de respaldo. El cliente recibe sus alertas y yo gano tiempo para arreglar el origen.

Runbooks por tipo de caída

Caída parcial vs. total: cómo priorizar servicios

• Parcial (solo web o solo DB): aísla el componente roto, sirve estático o modo degradado.

• Total (host inalcanzable): activa plan B: VM espejo, snapshot reciente, o contenedores en otro nodo.

• Prioridades: 1) datos, 2) autenticación, 3) transacciones, 4) ornamental. Documenta cada cambio (hora, comando, resultado).

Hardware/hipervisor: RAID, memoria, migración en virtualización

• Discos: reemplaza el fallido, reconstruye RAID fuera de horario de pico si es posible.

• Memoria: memtest si hay kernel panics o OOM; revisa errores ECC.

• Hipervisor: migra la VM a otro host si hay señales de hardware inestable. En hiperconvergencia, la movilidad te da minutos de oro.

• Energía: UPS y pruebas; muchos “misterios” son picos eléctricos.

Seguridad: DDoS, WAF y contención

• DDoS: limita tasa, activa protección del proveedor, filtra a nivel edge.

• Exploit activo: aísla el servidor, saca imagen forense, restaura a infraestructura limpia y rota credenciales.

• WAF: no lo desactives “por probar”. Ajusta reglas y crea excepciones temporales con vigencia.

He visto que un failover bien ensayado (no solo documentado) reduce el pánico. Ensayar dos veces al año cambia el juego.

Comunicación de incidentes y post-mortem sin drama

• Dentro de los 15 min: reconoce el incidente, severidad y alcance (“afecta a web de clientes X-Y”).

• Cada 30–60 min: actualiza estado, próxima ETA y acciones en curso.

• Transparencia útil: no digas “fue el proveedor”, explica: “desviamos tráfico al nodo B mientras reparamos el RAID”.

• Post-mortem (24–72 h): línea de tiempo, causa raíz, acciones correctivas, aprendizajes y dueños de cada tarea.

En mi equipo, seguimos prácticas ITIL: ticket desde el minuto uno, estados claros y un runbook visible para todos. Menos ruido, más foco.

Prevención: arquitectura de alta disponibilidad y backups probados

RTO/RPO realistas y pruebas de restauración

• Define RTO (tiempo objetivo de recuperación) y RPO (pérdida de datos aceptable). Que sean números medidos, no deseos.

• Pruebas trimestrales: restaura en entorno aislado, mide tiempos y documenta cuellos de botella.

• Estrategia de backups: 3-2-1 (tres copias, dos medios, una offsite). Encripta, etiqueta y rota.

Cuando probamos restores trimestrales, siempre aparece el “detalle” que en papel nadie vio: permisos rotos, claves olvidadas, scripts que no escalan.

Monitoreo proactivo 24/7 y alertas multicanal

• Monitorea host, red y aplicación (métricas + logs + traces).

• Alertas accionables: CPU sostenida, iowait, 5xx por minuto, latencia DB, espacio en disco, salud RAID, colas SMTP.

• Integra alertas a correo, SMS y chat; y define guardias.

• Hardening básico: MFA, rotación de claves, mínimos privilegios, parches periódicos.

Yo uso stack de Nagios/Zabbix/Prometheus+Grafana o servicios gestionados (CloudWatch/Cloud Monitoring) según el entorno. Lo clave no es la marca, es configurarlo y mantenerlo.

Checklist de respuesta ante caídas

Incidente P1 (servicio crítico caído)

• Congelar despliegues y abrir ticket/severidad.

• Árbol de decisión: red/DNS → host → servicios.

• Despublicar del balanceador y servir modo degradado/estático.

• Revisar logs y métricas antes de reiniciar.

• Decidir rollback o promoción de réplica.

• Comunicar cada 30–60 min.

• Si hardware: migrar VM o activar nodo de reemplazo.

Incidente P2 (degradación severa)

• Ajustar límites de recursos/autoescalado.

• Purga selectiva de cachés, expandir pool de conexiones.

• Afinar WAF/rate limiting, observar.

• Programar ventana para fix definitivo.

Conclusión

Un servidor caído es un problema técnico… y de proceso. Con un diagnóstico ordenado, acciones de bajo riesgo y una prevención que se prueba, pasas del caos a la confianza. No busques la receta perfecta: busca un método que practiques hasta que te salga natural.

FAQs rápidas

¿Cómo distingo caída del servidor vs. problema de red/DNS?Si hay consola pero no red, es red/DNS. Si ni consola responde, sospecha host/energía. Si solo falla la web, es servicio/aplicación.

¿Qué reviso primero si la web no carga pero hay ping?Firewall, puertos abiertos, estado de Nginx/Apache/PHP-FPM o del runtime (Node, Python), y logs de error.

¿Backups locales o en la nube?Ambos: local para rapidez, nube para resiliencia. Lo crítico es probarlos de forma periódica.

¿Cómo monto un SMTP de respaldo?Configura un relay secundario con credenciales separadas y reglas de conmutación. Registra los cambios en SPF/DKIM/DMARC.

Reparación de servidores