Las 5 fallas de servidor más comunes y cómo diagnosticarlas

1. ¿Por qué tu servidor falla cuando más lo necesitas?

Nada hiere tanto la confianza de un cliente (o de tu propio equipo) como un downtime sorpresa. Con más de una década apagando incendios en centros de datos —desde racks on-premises hasta nubes públicas en México— he visto un patrón: la mayoría de los “misterios” de estabilidad se resuelven con observabilidad bien diseñada y disciplina de cambios, pero solemos atacarlos cuando ya es tarde.

En cada post-mortem aparece la misma lista corta de culpables:

• Disco/RAID degradado silenciosamente.

• Calor y flujo de aire deficiente en el rack.

• Agotamiento de recursos (RAM, I/O, descriptores) que enciende al OOM-killer o provoca timeouts.

• Cambios mal orquestados (parches, drivers, despliegues sin canary).

• Redes caprichosas: DNS, MTU y routing asimétrico.

A continuación, te cuento, con ejemplos reales y métricas concretas, cómo las anticipo antes de que exploten.

2. Panorama rápido de las 5 fallas más comunes

Disco y RAID al borde del colapso

En mi práctica, las fallas de disco son la causa #1 de derribos de servicio. Los sectores reasignados y la degradación silenciosa apenas susurran en los logs SMART. Para cazarlos vigilo la latencia por operación y el conteo de Reallocation_Event_Count. Cuando esa cifra sube de golpe, programo sustitución inmediata y re-sincronización en una ventana controlada. Redundancia real implica RAID acorde al perfil de I/O, discos de repuesto a mano y un contrato de reemplazo 4 h si tu SLA lo exige.

El enemigo silencioso: calor y flujo de aire

Nada mata hardware tan rápido como el calor. He visto racks sin placas ciegas convertirse en hornos: discos a 60 °C, DIMMs tostados y fuentes apagándose por thermal shutdown. Prevengo el desastre con sensores SNMP bien ubicados (uso APC NetBotz o Vertiv Geist), ventiladores y PSUs en configuración N + 1, y alertas cuando la temperatura sube 5 °C sobre la línea base nocturna.

Cuando la RAM se agota y el OOM-killer ataca

Muchos culpan al “bug” pero el diagnóstico revela memory pressure: aumenta el page-reclaim, sube la latencia de disco por swap-in/out y las colas de socket crecen. El sistema entra en thrashing y tu servicio se arrastra aunque la CPU esté ociosa. La receta: capacity planning basado en percentiles, cgroupv2 para limitar consumo, y SLOs ligados a presupuesto de error en lugar de alertas por cada pico.

Cambios mal orquestados que apagan tu negocio

Los patch Tuesdays improvisados generan tantos incidentes críticos como el hardware. Mi mantra: inventario vivo de firmware, runbooks de reversión y despliegues escalonados. Cada parche pasa por un lote canario del 5 %. Si falla, hago rollback antes de que alcance al resto.

Redes caprichosas: DNS, MTU y rutas asimétricas

He perdido tardes tras un MTU mal negociado o un DNS intermitente. Mis alertas se basan en experiencia directa: pérdida sostenida de paquetes por encima del 1 % durante 5 min, jitter sobre 30 ms y el p95 del RTT al doble de la línea base diaria. Si el traceroute revela saltos asimétricos, sospecho de firewalls o balanceadores ocultos.

3. Señales tempranas y métricas que delatan un desastre

Escuchar al servidor antes de que grite exige monitorear:

1. SMART: crecimiento repentino en Current_Pending_Sector.

2. Temperatura: > 38 °C en entrada del rack o > 55 °C dentro del disco.

3. RAM: p99 de uso al 90 % durante más de diez minutos.

4. CPU y context switches: ráfagas que indican espera por I/O.

5. Kernel logs: mensajes de “page allocation failure” que anticipan al OOM-killer.

6. Red: aumento inusual de retransmisiones TCP sin incremento de throughput.

   
   

Mantengo un dashboard con estos indicadores y calculo el presupuesto de error mensual de cada servicio; cuando se quema más del 2 %, iniciamos revisión.

4. Herramientas de diagnóstico que uso a diario

• smartctl -a, perccli o ssacli para discos SAS/SATA.

• sensors y traps SNMP para temperatura ambiental.

• sar, vmstat, perf y tracing eBPF (bcc, bpftrace) para colas del kernel.

• Estadísticas de cgroupv2 y páginas de memory pressure en contenedores.

• kdump/netdump ante kernel panic (“Kernel panic – not syncing …” suele señalar initramfs corrupto o MCE en DIMMs).

• Wireshark, TCPdump y mtr para latencia y rutas de red.

• Tracing distribuido para enlazar síntoma y causa hasta la capa de aplicación.

Cada herramienta vive en un runbook con comandos, umbrales y pasos de reversión si el fix empeora la situación.

5. Cómo prevenir cada falla con arquitectura y disciplina de cambios

“Redundancia real, health checks a nivel transacción, backups probados con restore drills, parches canary, límites de sistema y SLOs basados en presupuesto de error.”

Hardware

• PSU y ventiladores en N + 1, RAID 10 para bases de datos exigentes.

• Contrato de piezas en 4 h o repuestos on-site.

Software y Cambios

• Blue-green o canario en micro-lotes.

• Feature flags para desactivar con un clic.

Capacidad y Recursos

• Planeación trimestral basada en p95 y p99, no promedios.

• Límites (memory.high, memory.max) alineados al working set.

Backups y DR

• Backups completos o forever-incremental + pruebas de restauración mensuales.

• Snapshots no sustituyen un backup aislado/multisitio.

Red y Alta Disponibilidad

• Activo-activo siempre que la aplicación sea idempotente.

• Multi-zona, y si el presupuesto lo permite, multi-región.

  
  

Diagnóstico de Servidores

6. Caso real: de la alerta al post-mortem en 15 min

03:17 a. m., el p95 de la API pasa de 120 ms a 900 ms. Correlaciono métricas: pico en DiskAwait y pgpgout/s. SMART incrementó Current_Pending_Sector en 24 unidades desde ayer. Dreno tráfico al nodo sano —gracias al activo-activo—, pongo en offline el disco sospechoso y la latencia cae a 130 ms. Técnico Dell llega en menos de cuatro horas, disco nuevo, RAID reconstruido. Post-mortem: el umbral de alerta SMART era demasiado generoso; lo ajusto y descuento 0.5 % del presupuesto de error.

7. Buenas prácticas de monitoreo y alertas accionables

• Alertar por SLO, no por cada pico.

• Reducir ruido: un evento de 30 s no amerita un pager si no quema presupuesto.

• Contexto rico en cada alerta: playbook, última causa conocida y enlaces a dashboards.

• Pruebas sintéticas a nivel transacción, no solo ping.

• Observabilidad unificada: métricas, tracing y logs en la misma consola.
  

Mis alertas estrella de red usan tres líneas rojas: pérdida sostenida > 1 %, jitter > 30 ms y p95 RTT al doble de la línea base.

8. Preguntas frecuentes de operaciones

¿Cómo diferencio un agotamiento de recursos de un crash por bug?Si es falta de recursos, verás escalada: p99, luego p999, luego timeouts, y finalmente OOM-killer. Un bug lanza SIGSEGV o kernel panic de golpe; los dumps y dmesg lo confirman.

¿Qué sensores de temperatura SNMP compro en México?APC NetBotz, Vertiv Geist y AKCP sensorProbe son mis elecciones habituales; todos envían traps que Zabbix entiende.

¿Sirve ApacheBench o uso JMeter?AB es genial para humo en un solo endpoint; JMeter modela usuarios reales, ramp-ups y piensa en percentiles. Para reproducir experiencia, JMeter gana.

¿Activo-activo o activo-pasivo para bases de datos?Si tu motor soporta réplicas multi-writer, activo-activo minimiza el MTTR. Si no, activo-pasivo simplifica y abarata.

¿Qué SLA obtengo hoy en México?Azure Querétaro ofrece 99.99 % con dos VM en zonas distintas; Google Cloud México queda en 99.95 %. De cualquier modo, la arquitectura pesa más que la marca.

Conclusión

Dos convicciones que me sostienen a las 03:17 a. m.:

1. Observabilidad y disciplina de cambios vencen al azar. Telemetría exhaustiva y runbooks claros detectan incidentes antes de que salgan en Twitter.

2. La alta disponibilidad se diseña; no se compra. Activo-activo, multi-zona y backups probados valen más que cualquier logo de proveedor.
   

Si quieres una lista de verificación adaptada a tu entorno —sensores, métricas, alertas y runbooks— avísame. En TBS iT, podemos convertir estos aprendizajes en un plan que mantenga tus servicios de pie, incluso en la madrugada más crítica.