GLAD: la metodología de 4 pasos que arregla el 99% de errores Linux

Cuando un servidor falla, la red se cae, o tu laptop se niega a arrancar, el impulso es correr el primer comando que se te ocurra. Mala idea. GLAD (Gather, Look, Analyze, Document) es una metodología sistemática que te lleva de “algo está mal” a “sé qué es, sé por qué pasó y sé cómo evitarlo”. Funciona desde hace décadas en soporte de producción y es lo que separa a alguien que reza de un sysadmin que resuelve.

Por qué necesitas una metodología (y por qué Google no basta)

El problema típico: ves un error, lo pegas en Google, alguien en StackOverflow dice “yo tuve eso, fue X”. Pruebas X, no funciona. Pruebas Y, tampoco. Pasas una hora saltando entre posts y al final aplicas tres cosas que no entiendes y que probablemente rompieron otra cosa.

Lo que no hiciste fue entender el problema. GLAD es el marco para hacer eso en orden, sin importar qué tan oscuro sea el síntoma:

• Gather (recopilar pistas y definir el problema)
• Look (mirar el estado del sistema)
• Analyze (analizar hallazgos y formar hipótesis)
• Document (documentar causa raíz, solución y prevención)

Si haces esos 4 pasos en serio, la mayoría de los problemas Linux se resuelven en minutos, no horas. Y lo mejor: te queda registro de qué pasó para no repetirlo.

Paso 1: Gather — recopila pistas y define el problema

Antes de tocar nada, contesta estas preguntas. Escríbelas (sí, en serio):

• ¿Qué pasó exactamente? Describe el síntoma en una frase. “El sitio web no carga”, “el servidor SSH rechaza mi clave”, “la laptop no bootea desde ayer”.
• ¿Cuándo empezó? Timestamp exacto si lo tienes. “Cuando reinicié a las 14:30”, “después de aplicar parches de seguridad”, “de la nada a las 3 AM”.
• ¿Qué cambió recientemente? Updates, cambios de config, nueva instalación, swap de hardware, cambio de DNS. El 80% de los problemas vienen de un cambio que no recordabas.
• ¿A quién afecta? A todos, a un usuario, a una IP específica, a un servicio puntual. Esto te dice si es global o local.
• ¿Hay mensajes de error exactos? Cópialos textuales. “Permission denied” significa algo distinto a “Connection refused”.

Un truco: si atiendes a un usuario, no te quedes con su descripción. Pídele que te mande lo que ve, tal cual, con captura si es GUI. La traducción humano→técnico pierde precisión.

Una vez tengas respuestas, redacta el problema en una línea clara:

“Desde 2026-08-04 14:30 UTC, el servicio nginx en srv-prod-01 rechaza conexiones al puerto 443 con ‘Connection refused’. Antes funcionaba. Reinicié nginx, sigue igual. Logs de las últimas 24h adjuntos.”

Eso ya es 10 veces más útil que “el nginx no anda”.

Paso 2: Look — mira el estado del sistema

Ahora sí, comandos. Pero no a lo loco: comandos que revelan estado, no que cambian estado. Lee primero, modifica después.

Estado del servicio afectado

# Estado del servicio (systemd moderno)
sudo systemctl status nginx.service --no-pager --lines=100
# ¿Está corriendo realmente?
ps aux | grep -E '[n]ginx'
# ¿En qué puerto escucha?
sudo ss -tlnp | grep -E ':80|:443'
# Logs del servicio, últimas 100 líneas sin paginar
sudo journalctl -u nginx.service --since "2 hours ago" --no-pager
# Logs tradicionales si los hay
sudo tail -100 /var/log/nginx/error.log

Estado del sistema en general

# ¿Hay espacio en disco? (causa #1 de fallos silenciosos)
df -h
# ¿Algún filesystem al 100%? Si es /, todo se rompe
# Memoria y swap
free -h
# ¿Swap lleno? El sistema recurre a OOM killer
# Carga del sistema
uptime
top -bn1 | head -20
# load average > número de CPUs = saturado
# Procesos zombi o con estados raros
ps aux | awk '$8 ~ /Z/ {print}'  # zombis

Red

# ¿Llegas al host?
ping -c 3 srv-prod-01
# ¿El puerto responde desde acá mismo?
curl -v http://localhost:80
curl -v https://localhost:443
# ¿Y desde otra máquina de la red?
nc -zv srv-prod-01 443
# DNS resuelve bien?
dig srv-prod-01
nslookup srv-prod-01

Recursos y logs

# ¿Qué dice dmesg? (mensajes del kernel, drivers, hardware)
sudo dmesg --since "1 hour ago" | tail -50
# ¿Errores recientes en syslog?
sudo journalctl -p err --since "1 hour ago" --no-pager
# Logs específicos por servicio
sudo journalctl -u sshd.service --since "1 hour ago"
sudo journalctl -u NetworkManager.service --since "1 hour ago"

La regla: tras Gather+Look deberías tener 3-5 pistas concretas (ej: “disco /var al 100%”, “no hay errores en nginx pero sí ‘address already in use’ en el log”, “el puerto 443 está LISTEN pero solo en 127.0.0.1”).

Paso 3: Analyze — forma hipótesis y valida

Aquí es donde el problema se resuelve o se complica. La clave es no enamorarte de la primera hipótesis.

Framework de hipótesis

Con las pistas que tienes, escribe 2-3 hipótesis ordenadas por probabilidad:

1. “El servicio falló porque el disco /var está lleno” — explicar por qué: nginx no puede escribir logs/access → crashea
2. “Otro proceso se apropió del puerto 443” — explicar por qué: cambié config de Apache ayer
3. “La configuración nueva tiene un error de sintaxis” — explicar por qué: hice nginx -t y falló

Ahora valida o descarta cada una. Cada hipótesis necesita UNA prueba específica:

Hipótesis	Prueba
Disco lleno	df -h /var y du -sh /var/log/*
Puerto apropiado	sudo ss -tlnp | grep 443 y sudo lsof -i :443
Error de sintaxis	sudo nginx -t

Errores comunes de análisis

• Confirmation bias: ves evidencia de tu hipótesis e ignoras la que la contradice. Fuerza a mirar TODO el output del comando, no solo lo que esperabas.
• Causalidad vs correlación: el servicio cayó A LA MISMA HORA que un update. ¿Fue el update o algo que pasó 5 minutos antes y todavía no había hecho efecto?
• Solución sintomática: reiniciaste el servicio y volvió a la vida, pero no entendiste por qué. Mañana se cae otra vez. No marques el ticket como “resuelto” hasta tener causa raíz.
• Múltiples causas: a veces hay 2-3 problemas a la vez. Disco lleno + config rota + DNS roto. Resuelve uno a la vez y verifica que el sistema siga funcionando entre cambios.

Comando clave: el “minimum reproducible state”

Si puedes, reproduce el problema en un entorno controlado:

# Snapshot antes de tocar (para rollback)
sudo systemctl stop nginx
sudo cp -r /etc/nginx /tmp/nginx.backup.$(date +%Y%m%d_%H%M)
# Aplica el cambio mínimo
# (edita un archivo, reinicia, etc.)
# Verifica resultado
sudo nginx -t
sudo systemctl start nginx
curl -v http://localhost

Si en el sandbox funciona pero en producción no, el problema es del entorno, no del código.

Paso 4: Document — registra qué pasó y por qué

La parte que casi nadie hace y que te ahorra horas el próximo incidente. Documenta incluso si es “trivial”.

Plantilla mínima:

## Incidente: srv-prod-01 - nginx 443 caído (2026-08-04)
**Síntoma**: nginx rechazaba conexiones HTTPS
**Inicio**: 2026-08-04 14:30 UTC
**Detectado por**: alerta Pingdom
**Resuelto en**: 25 minutos
**Causa raíz**: certificado SSL expirado + config de nginx con `ssl_certificate` apuntando al cert viejo
### Timeline
- 14:30 — alerta Pingdom
- 14:35 — verificado: curl localhost:443 = "Connection refused"
- 14:42 — `nginx -t` reveló "SSL_CTX_load_verify_location" failed
- 14:48 — identificado cert expirado en /etc/letsencrypt
- 15:00 — renovado con certbot, nginx recargado, verificado
### Solución aplicada
sudo certbot renew --nginx
sudo systemctl reload nginx
### Prevención
- Agregar cert al monitoring con check 30 días antes de expirar
- Configurar certbot timer (ya estaba, pero no había alerting)
- Documentar en runbook: "si ves Connection refused en 443, revisar cert primero"

Guárdalo donde tu equipo lo encuentre: wiki, ticket de Jira, comentario en Slack, lo que sea. El valor de la documentación aparece el segundo incidente similar, no el primero.

Errores comunes de Linux resueltos con GLAD

“Permission denied” en todo

Gather: usuario X no puede escribir en /var/www Look:

ls -la /var/www
id usuario_x
mount | grep /var

Analyze: ¿el dir es de root y no tiene ACL? ¿el filesystem está montado read-only? ¿SELinux/AppArmor bloqueando? Document: “usuario X no tenía grupo www-data. Agregado con usermod -aG www-data usuario_x && newgrp“.

“No space left on device” pero df muestra espacio

Gather: app falla al escribir, df -h dice 30% usado Look:

df -h        # espacio en filesystem
df -i        # inodes usados

Analyze: si df -i muestra 100%, te quedaste sin inodes (millones de archivos chiquitos: sesiones PHP, mails, logs). Fix:

# Encontrar dirs con más archivos
sudo find / -xdev -type f | cut -d/ -f1-2 | sort | uniq -c | sort -rn | head

“Service won’t start” silencioso

Gather: systemctl start dice “failed” sin más detalle Look:

sudo systemctl status miproblema.service --no-pager --lines=100
sudo journalctl -xeu miproblema.service --no-pager

Analyze: el -l muestra líneas completas sin truncar. -xe agrega contexto extra. El 90% de las veces el error real está ahí, solo que el status por defecto lo esconde.

“Internet no anda” en una máquina específica

Gather: solo esa máquina, otras sí Look:

ip a           # ¿tiene IP?
ip route       # ¿tiene gateway?
cat /etc/resolv.conf   # ¿tiene DNS?
ping 8.8.8.8  # ¿llega a Internet por IP?
ping google.com  # ¿resuelve DNS?

Analyze: por dónde se rompe (IP/ruta/DNS) y aplicas fix específico.

Sistema lento sin razón aparente

Gather: “todo va lento desde hace 1 hora” Look:

uptime              # load average
top -bn1            # procesos por CPU
free -h             # memoria
iostat -x 1 5       # I/O disco
sudo iotop          # quién está haciendo I/O

Analyze: si load > CPUs y no hay CPU user alta, hay I/O wait. Mira iotop, probablemente un backup o una query mal escrita.

Herramientas que hacen GLAD más rápido

• journalctl con --since y -u: tu primer aliado para cualquier servicio systemd
• ss -tlnp: reemplaza al viejo netstat, más rápido y muestra el PID dueño
• lsof -i: qué proceso usa qué puerto/archivo
• strace: trazar syscalls de un proceso que falla misteriosamente
• tcpdump: capturar tráfico cuando la red “no anda” pero no sabes por qué
• bpftrace / bpftool: observabilidad moderna desde el kernel (programas pequeños tipo awk sobre eventos del kernel, requieren kernel ≥ 5.x)
• htop / btop: reemplazos visuales para top con más info
• glances: dashboard completo con web UI opcional

Cuándo NO usar GLAD

• Emergencias que requieren acción inmediata: si el cluster está quemando y los servicios críticos están abajo, no documentes paso por paso — levanta lo urgente y documenta después. La metodología es para resolver bien, no para obstaculizar.
• Cambios triviales: reiniciar un servicio colgado no necesita GLAD. Documenta la recurrencia si pasa 3 veces.
• Hardware muerto: si el disco hace clic clic clic, no hay metodología que valga. Reemplazo físico.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux