Método de Diagnóstico Estructurado
El Enfoque Sistemático
En informática, y especialmente en la nube, la resolución de problemas no debe ser un "trial and error" aleatorio. Un método estructurado le ahorrará tiempo y le hará más eficiente.
┌─────────────────────────────────────────────────────────────┐
│ MÉTODO DE DIAGNÓSTICO EN 5 PASOS │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. SÍNTOMA │
│ └── ¿Qué es exactamente lo que no funciona? │
│ ¡Sea preciso! "No funciona" no es un │
│ síntoma válido. │
│ │
│ 2. HIPÓTESIS │
│ └── ¿Cuáles son las posibles causas? │
│ Enumérelas por probabilidad. │
│ │
│ 3. PRUEBAS │
│ └── ¿Cómo verificar cada hipótesis? │
│ Una prueba a la vez, metódicamente. │
│ │
│ 4. CORRECTIVO │
│ └── ¿Qué acción resuelve el problema? │
│ Aplicar y validar. │
│ │
│ 5. DOCUMENTACIÓN │
│ └── Anotar la solución para referencia futura. │
│ Actualizar el runbook. │
│ │
└─────────────────────────────────────────────────────────────┘
Paso 1: Definir el Síntoma
Malos vs Buenos Síntomas
❌ MALOS SÍNTOMAS (demasiado vagos):
• "El servidor no funciona"
• "Está roto"
• "Tengo un error"
• "Antes funcionaba"
✅ BUENOS SÍNTOMAS (precisos):
• "Timeout SSH después de 30 segundos hacia IP 52.1.2.3"
• "Error 502 Bad Gateway en http://example.com"
• "La instancia i-xxx pasa a terminated después de 10 segundos"
• "La página web devuelve error 500 desde las 14:30"
Preguntas para Hacerse
┌─────────────────────────────────────────────────────────────┐
│ PREGUNTAS DE ACLARACIÓN │
├─────────────────────────────────────────────────────────────┤
│ │
│ ¿QUÉ? │
│ • ¿Cuál es el mensaje de error exacto? │
│ • ¿Qué funcionalidad está afectada? │
│ • ¿Qué servicio/instancia está involucrado? │
│ │
│ ¿CUÁNDO? │
│ • ¿Cuándo comenzó el problema? │
│ • ¿El problema es constante o intermitente? │
│ • ¿Hay patrones (horas, días)? │
│ │
│ ¿DÓNDE? │
│ • ¿Qué región/AZ? │
│ • ¿Qué instancia/recurso? │
│ • ¿Desde dónde se observa el problema? │
│ │
│ ¿QUIÉN? │
│ • ¿Todos los usuarios o solo algunos? │
│ • ¿Desde ciertas redes/IPs? │
│ │
│ ¿CAMBIO? │
│ • ¿Qué ha cambiado recientemente? │
│ • ¿Despliegue? ¿Configuración? ¿AWS? │
│ │
└─────────────────────────────────────────────────────────────┘
Paso 2: Formular Hipótesis
Categorías de Problemas EC2
┌─────────────────────────────────────────────────────────────┐
│ CATEGORÍAS DE PROBLEMAS │
├─────────────────────────────────────────────────────────────┤
│ │
│ 🌐 RED │
│ ├── Security Group mal configurado │
│ ├── NACL bloqueando │
│ ├── Route Table incorrecta │
│ ├── Falta Internet Gateway │
│ └── Sin IP pública │
│ │
│ 🔐 SEGURIDAD / AUTH │
│ ├── Clave SSH incorrecta │
│ ├── Usuario incorrecto │
│ ├── Permisos del archivo .pem │
│ └── IAM (para llamadas API) │
│ │
│ 💻 INSTANCIA │
│ ├── Instancia no running │
│ ├── Status check fallido │
│ ├── Servicio no iniciado (Apache, SSH) │
│ └── Disco lleno │
│ │
│ 📦 APLICACIÓN │
│ ├── Aplicación caída │
│ ├── Configuración incorrecta │
│ ├── Dependencia faltante │
│ └── Puerto incorrecto │
│ │
│ ☁️ AWS │
│ ├── Falla regional │
│ ├── Servicio degradado │
│ └── Mantenimiento │
│ │
└─────────────────────────────────────────────────────────────┘
Priorizar las Hipótesis
Regla de oro: De lo más simple a lo más complejo
De lo más probable a lo menos probable
Ejemplo para "SSH timeout":
ALTA PROBABILIDAD (verificar primero)
1. Security Group - puerto 22 cerrado
2. Sin IP pública
3. Instancia no running
PROBABILIDAD MEDIA
4. NACL bloqueando
5. Route table sin ruta hacia IGW
6. Firewall en la instancia
BAJA PROBABILIDAD
7. Falla regional de AWS
8. Bug del cliente SSH
Paso 3: Probar las Hipótesis
Pruebas para Problemas de Red
# 1. Verificar el estado de la instancia
aws ec2 describe-instances --instance-ids i-xxx \
--query 'Reservations[].Instances[].State.Name'
# 2. Verificar la IP pública
aws ec2 describe-instances --instance-ids i-xxx \
--query 'Reservations[].Instances[].PublicIpAddress'
# 3. Verificar los Security Groups
aws ec2 describe-security-groups --group-ids sg-xxx
# 4. Probar la conectividad de red (desde su máquina)
ping IP_PUBLIQUE # ICMP (si está permitido)
telnet IP_PUBLIQUE 22 # Probar puerto SSH
nc -zv IP_PUBLIQUE 22 # Alternativa a telnet
# 5. Verificar la route table del subnet
aws ec2 describe-route-tables --filters "Name=association.subnet-id,Values=subnet-xxx"
Pruebas para Problemas de Instancia
# 1. Verificar los status checks
aws ec2 describe-instance-status --instance-ids i-xxx
# 2. Recuperar los logs del sistema (si está configurado)
aws ec2 get-console-output --instance-id i-xxx
# 3. Verificar las métricas de CloudWatch
aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-xxx \
--start-time 2024-01-01T00:00:00Z \
--end-time 2024-01-01T01:00:00Z \
--period 300 \
--statistics Average
Desde la Instancia (si es accesible)
# Verificar los servicios
systemctl status sshd
systemctl status httpd
# Verificar los puertos abiertos
netstat -tlnp
ss -tlnp
# Verificar el espacio en disco
df -h
# Verificar la memoria
free -m
# Verificar los logs
tail -100 /var/log/messages
tail -100 /var/log/secure
journalctl -xe
Paso 4: Aplicar el Correctivo
Reglas para los Correctivos
┌─────────────────────────────────────────────────────────────┐
│ REGLAS PARA APLICAR UN CORRECTIVO │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. UN CAMBIO A LA VEZ │
│ └── ¡No cambie 5 cosas al mismo tiempo! │
│ └── Si no, no sabrá qué resolvió el problema │
│ │
│ 2. DOCUMENTAR ANTES DE CAMBIAR │
│ └── Anotar el estado actual │
│ └── Poder revertir │
│ │
│ 3. PROBAR DESPUÉS DE CADA CAMBIO │
│ └── Verificar si el problema está resuelto │
│ └── Verificar que no se han creado nuevos problemas │
│ │
│ 4. VALIDAR COMPLETAMENTE │
│ └── El test rápido OK no es suficiente │
│ └── Probar todos los casos de uso afectados │
│ │
└─────────────────────────────────────────────────────────────┘
Ejemplo de Correctivo Documentado
PROBLEMA: Timeout SSH hacia la instancia i-0123456789
DIAGNÓSTICO:
- Instancia: running ✓
- IP pública: 52.1.2.3 ✓
- Security Group: sg-abc123
→ Puerto 22: FALTANTE ❌
CORRECTIVO APLICADO:
aws ec2 authorize-security-group-ingress \
--group-id sg-abc123 \
--protocol tcp \
--port 22 \
--cidr 0.0.0.0/0
VALIDACIÓN:
ssh -i mi-clave.pem ec2-user@52.1.2.3
→ Conexión exitosa ✓
FECHA: 2024-12-18 14:30
TÉCNICO: Haythem
Paso 5: Documentar
Plantilla de Documentación
# Incidente: [Título corto]
## Fecha y Duración
- Inicio: YYYY-MM-DD HH:MM
- Resolución: YYYY-MM-DD HH:MM
- Duración total: X horas
## Síntoma
[Descripción precisa del problema observado]
## Impacto
- Usuarios afectados: X
- Servicios impactados: [lista]
- Nivel de severidad: Crítico/Mayor/Menor
## Causa Raíz
[Explicación de la causa fundamental]
## Cronología
- HH:MM - Detección del problema
- HH:MM - Inicio del diagnóstico
- HH:MM - Causa identificada
- HH:MM - Correctivo aplicado
- HH:MM - Validación y cierre
## Solución Aplicada
[Descripción del correctivo]
## Acciones Preventivas
- [ ] Acción 1 para evitar que se repita
- [ ] Acción 2
- [ ] Actualización del runbook
## Lecciones Aprendidas
[Lo que se aprendió de este incidente]
Ejercicio Práctico
Escenario
Contexto:
Ha lanzado una instancia EC2 hace 5 minutos.
La instancia está en estado "running".
Intenta conectarse por SSH.
Resultado:
$ ssh -i mi-clave.pem ec2-user@52.1.2.3
ssh: connect to host 52.1.2.3 port 22: Connection timed out
¡Aplique el método de diagnóstico!
Respuesta Guiada
PASO 1: SÍNTOMA
"Timeout SSH después de 30 segundos hacia 52.1.2.3 puerto 22
desde mi equipo (IP: 203.0.113.50)"
PASO 2: HIPÓTESIS (por probabilidad)
1. Security Group - puerto 22 no abierto o IP no autorizada
2. Sin ruta hacia Internet Gateway
3. NACL bloqueando el puerto 22
4. Instancia aún no completamente iniciada
PASO 3: PRUEBAS
Prueba 1: Security Group
→ aws ec2 describe-security-groups --group-ids sg-xxx
→ Resultado: Puerto 22 abierto solo hacia 10.0.0.0/8
→ ¡Mi IP 203.0.113.50 no está autorizada!
PASO 4: CORRECTIVO
aws ec2 authorize-security-group-ingress \
--group-id sg-xxx \
--protocol tcp \
--port 22 \
--cidr 203.0.113.50/32
VALIDACIÓN:
ssh -i mi-clave.pem ec2-user@52.1.2.3
→ ¡Conexión exitosa!
PASO 5: DOCUMENTACIÓN
[Completar la plantilla anterior]
Resumen
| Paso | Acción | Duración Típica |
|---|---|---|
| 1. Síntoma | Definir con precisión | 2-5 min |
| 2. Hipótesis | Listar por probabilidad | 5-10 min |
| 3. Pruebas | Verificar metódicamente | Variable |
| 4. Correctivo | Un cambio a la vez | Variable |
| 5. Documentación | Siempre documentar | 10-15 min |
Quiz de Validación
- ¿Por qué se debe probar una hipótesis a la vez?
- ¿Cuál es la diferencia entre un síntoma vago y uno preciso?
- ¿Por dónde empezar: las causas probables o improbables?
- ¿Por qué documentar incluso los incidentes pequeños?
- ¿Qué hacer si el primer correctivo no funciona?
Próxima sección: Lab: Escenarios de Falla