0% del curso completado
Metodología estructurada de troubleshooting
📋 En esta lección
Has diagnosticado cable (2.4), VLANs (5.11), IP (4.6), IPv6 (6.5) y WiFi (9.5). Aquí extraes el método común y lo conviertes en un procedimiento que funciona con cualquier avería — incluidas las que no has visto nunca. Es la lección que separa a quien resuelve problemas conocidos de quien resuelve problemas.
Por qué el método gana a la intuición
El técnico experimentado parece adivinar la causa. No adivina: reconoce patrones porque ha visto el mismo síntoma cien veces. Esa intuición es valiosa y tiene dos fallos graves — es inútil ante lo desconocido, y falla en silencio: te lleva con confianza absoluta por el camino equivocado.
El método estructurado no es más lento; es más lento al principio y mucho más rápido en el caso que importa: el que no encaja en ningún patrón previo. Además es transferible (se enseña, se documenta, se audita) y acumulativo (cada avería resuelta con método deja conocimiento; cada una resuelta por corazonada deja una anécdota).
El ciclo: siete pasos
1. DEFINIR el problema → ¿qué falla exactamente?
2. RECOGER información → datos, no opiniones
3. ANALIZAR y acotar → ¿qué queda dentro del dominio del fallo?
4. HIPÓTESIS → la causa más probable, formulada como afirmación
5. PROBAR la hipótesis → un cambio / una comprobación cada vez
6. RESOLVER y verificar → ¿ha vuelto el servicio? ¿y todo lo demás?
7. DOCUMENTAR → causa raíz, solución y prevención
Si la prueba del paso 5 refuta la hipótesis, se vuelve al 4 con lo aprendido — no al 1. Ese bucle estrecha el cerco en cada vuelta.
1. Definir el problema
"No funciona la red" no es un problema: es una queja. Convertirla en un problema definido significa responder:
- ¿Qué falla exactamente? ¿No abre una web, no resuelve nombres, no imprime, va lento?
- ¿Quién está afectado? Un usuario, un departamento, una planta, toda la sede. La pregunta más informativa de todas: define de inmediato el alcance y, con él, la lista de sospechosos.
- ¿Desde cuándo? ¿Nunca funcionó (problema de configuración inicial) o dejó de funcionar (algo cambió)?
- ¿Es constante o intermitente? Lo intermitente huele a dúplex (2.2), a IP duplicada (4.6), a roaming (9.4) o a saturación puntual.
- ¿Qué cambió? — la pregunta reina, más abajo.
2. Recoger información
Datos verificables, no interpretaciones. Tus fuentes, por este orden de coste: los logs (show logging — 8-5: el equipo suele llevar horas contándote lo que pasó), el estado (show interfaces, show ip interface brief, show vlan brief, show ip route), y las pruebas activas (ping por escalones, extended ping con origen forzado, traceroute — 5-11).
⚡ "¿Qué cambió?" — la pregunta que resuelve la mitad de las averías
Las redes estables no se rompen solas. Si algo funcionaba ayer y hoy no, algo cambió: una configuración, un cable, una actualización, una licencia que caducó, un certificado, una contraseña rotada, una obra en el edificio. Pregúntalo siempre — y desconfía del "no hemos tocado nada": casi nunca es mentira deliberada, casi siempre es que quien lo dice no conectó su cambio con tu síntoma. Los logs (
%SYS-5-CONFIG_I— 8-5) y el historial de tu sistema de versiones (11.2) responden sin depender de la memoria de nadie.
3. Analizar y acotar: el dominio del fallo
El corazón del método: convertir "algo en la red" en una región concreta. La herramienta es la comparación sistemática:
| Comparación | Qué acota |
|---|---|
| ¿A quién le pasa y a quién no? | La frontera entre lo que funciona y lo que no |
| ¿Qué tienen en común los afectados? | Su VLAN, su switch, su AP, su subred, su sistema operativo |
| ¿Hacia dónde falla? | ¿Solo a Internet, solo a un servidor, a todo? |
| ¿Funciona el mismo puesto con otro dispositivo? | Separa host de infraestructura |
| ¿Funciona el mismo dispositivo en otro puesto? | Separa infraestructura de host |
Cada comparación elimina medio mapa. Dos o tres bien elegidas convierten una red entera en un puñado de candidatos.
Los cinco enfoques clásicos
El orden en que recorres las capas OSI (1.4) también es una decisión:
- Bottom-up (de física hacia arriba): el más fiable ante problemas de conectividad total. Es el que has usado todo el curso — cable, enlace, VLAN, IP, servicio. Lento si el problema está arriba.
- Top-down (de aplicación hacia abajo): eficaz cuando la red "va bien" y falla una aplicación concreta.
- Divide y vencerás: empieza en una capa intermedia (típicamente IP: un ping al gateway) y, según el resultado, sube o baja. El más eficiente en general y el que usan los experimentados.
- Seguir el camino (follow the path): recorre físicamente la ruta del tráfico salto a salto — host, switch de acceso, distribución, router, firewall. Insuperable cuando conoces la topología.
- Comparar con lo que funciona: pon lado a lado la configuración del puerto roto y la de uno idéntico que funciona. En redes con plantillas (5.10), la diferencia es la causa.
4. Hipótesis
Una hipótesis es una afirmación falsable, no una sensación: "el puerto está en la VLAN equivocada", no "parece cosa del switch". Debe explicar todos los síntomas observados; si explica el 80%, probablemente es incorrecta o incompleta.
5. Probar: un cambio cada vez
La regla que atraviesa el curso (4.6, 5.11): una modificación, una verificación. Tres cambios simultáneos que funcionan no te dicen cuál era el problema — y el problema volverá. Dos disciplinas que lo acompañan:
- Prefiere pruebas no destructivas primero: un
showantes que un cambio; un cambio reversible antes que uno irreversible. - Deshaz lo que no funcionó antes de probar lo siguiente, o acabarás con una configuración llena de sedimentos de intentos fallidos — la causa de la siguiente avería.
⚠️ ⚠️ El sesgo de confirmación
Cuando tienes una hipótesis, tu cerebro empieza a buscar datos que la confirmen y a descartar los que la contradicen. Es el fallo cognitivo que más horas cuesta en salas de crisis. El antídoto es explícito: pregúntate "¿qué observación demostraría que me equivoco?" y ve a buscarla. Si el dato que te contradice existe y lo estabas rodeando, lo encontrarás en un minuto — y te ahorrarás tres horas.
6. Resolver y verificar
Verificar no es que el usuario diga "ya va". Es comprobar que el servicio funciona (la prueba concreta que fallaba), que no has roto nada más (el resto de la VLAN, el otro extremo del trunk, el tráfico que pasaba por ahí), y que la solución es estable — especialmente si tocaste algo que sobrevive a un reinicio: write memory (3.3), o el cambio se evapora en el próximo corte de luz.
7. Documentar: causa raíz, no síntoma
La diferencia entre resolver y apagar un fuego:
- Síntoma: "el usuario no tenía red; reiniciamos el switch y volvió."
- Causa raíz: "un bucle en la sala de reuniones (dos rosetas unidas con un latiguillo) provocó una tormenta de broadcast; el reinicio la cortó temporalmente. Se ha aplicado BPDU guard con PortFast en todos los puertos de acceso de la planta (5.9)."
La primera versión garantiza que vuelva a pasar. La segunda lo previene y, además, enseña a toda la organización. Documenta siempre: síntoma, alcance, causa raíz, solución aplicada y medida preventiva.
Cuándo escalar
Escalar a tiempo es criterio profesional, no rendición. Hazlo cuando: el tiempo consumido supera el impacto tolerable (un servicio crítico caído no admite tu curva de aprendizaje), el problema excede tu ámbito (es del ISP, del proveedor de aplicación, del fabricante), o necesitas permisos o conocimiento que no tienes.
Y escala con el trabajo hecho: síntoma definido, alcance medido, qué has descartado y con qué evidencia. Un escalado con contexto ahorra horas; un "no funciona nada, mira tú" las multiplica.
Relación con otros conceptos
- Este método es el esqueleto común de los diagnósticos del curso: cableado (2.4), L2/L3 (5.11), IPv4 (4.6), IPv6 (6.5), WiFi (9.5).
- Sus herramientas son las de siempre: logs y
show(3.2, 8.5), extended ping y traceroute (5.11), SPAN cuando hace falta ver la trama (5.11). - "¿Qué cambió?" se responde con NTP + syslog centralizado (8.4, 8.5) y con el historial de configuración versionada (11.2, 11.4).
- Evaluar lo que propone un agente de IA (11.7) es aplicar este mismo rigor a una hipótesis que no has formulado tú.
Resumen
Siete pasos: definir (qué falla, a quién, desde cuándo, constante o intermitente, qué cambió), recoger datos (logs primero — el equipo ya te lo contó —, luego estado, luego pruebas activas), acotar el dominio del fallo comparando lo que funciona con lo que no, formular una hipótesis falsable que explique todos los síntomas, probarla con un cambio cada vez (no destructivo primero, deshaciendo lo que falle), resolver y verificar de verdad (servicio restaurado, nada más roto, cambio guardado) y documentar la causa raíz, no el síntoma. Elige el enfoque según el caso: bottom-up para conectividad total, top-down para una aplicación, divide y vencerás como estrategia general, seguir el camino cuando conoces la topología, y comparar con un elemento que funcione cuando hay plantillas. Vigila el sesgo de confirmación preguntándote qué dato te demostraría que te equivocas — y escala a tiempo, con el trabajo hecho.