Troubleshooting de Sistemas: El Triángulo de Triaje que te ahorra tiempo

En esta segunda entrada quiero hablar de una herramienta que no se instala, no se parchea y no tiene licencia. Es una herramienta mental. Me refiero al método que aplicamos en el departamento para no volvernos locos cuando todo arde: el aislamiento de variables.

La Psicología del Pánico: Por qué fallamos

Son las 09:05 de un lunes. Te entra una llamada directa, ni siquiera un ticket.
— "El IFS no va. Nadie puede entrar."

En ese preciso instante, tu cerebro reptiliano toma el mando. El cortisol se dispara. Sientes la presión de una fábrica parada en tu nuca.

En este estado, el 90% de los técnicos comete el error del novato: el Efecto Túnel. Te lanzas a mirar el último log del servicio que tocaste ayer, o asumes que es culpa de esa actualización de Windows de la que leíste en Twitter. Empiezas a aplicar la "Depuración de Escopeta": reinicias un servicio por si acaso, limpias una caché DNS, pides al usuario que reinicie... todo a la vez.

Si tienes suerte, algo funcionará. Y ese es el problema: la suerte no escala ni dura para siempre.

Si se arregla, no sabrás qué fue. Si no se arregla, habrás introducido tres variables nuevas en la ecuación y ahora tendrás un sistema en un estado indeterminado. Eso no es ingeniería, es superstición.

Para evitar esto, necesitas un ancla. Un protocolo rígido que te obligue a pensar despacio cuando todo el mundo te pide que corras. En mi caso, para el aislamiento de variables, uso El Triángulo de Triaje.

El Arsenal: Construyendo la Atalaya

Antes de explicar el método, hablemos del equipo. No puedes hacer diagnósticos precisos con herramientas sucias.

El concepto central del Triángulo de Triaje es la comparación. Para comparar, necesitas un estándar de oro, una referencia inmutable. Necesitas lo que en ciencia llaman un "Grupo de Control", pero en la trinchera llamamos tu Máquina de Soporte.

Tu equipo de soporte no es "tu portátil". Tu equipo de soporte es un instrumento de medida calibrado. Para que sea válido, debe cumplir dos reglas sagradas:

1. Independencia de Red Total: No me vale que te conectes a la Wi-Fi de invitados del cliente. Necesitas una red completa separada. Si tu herramienta de diagnóstico depende de la infraestructura que estás diagnosticando, estás ciego. Si el firewall del cliente bloquea todo, y tú estás detrás de ese mismo firewall, nunca sabrás si el servidor está caído o si es el firewall que te está bloqueando.
2. Higiene de Software:
   • Limpieza de Cachés: Tu navegador no debe tener cookies antiguas. Usa siempre modo Incógnito o perfiles limpios.
   • Sin GPOs Corporativas: Si tu máquina tiene las mismas restricciones de seguridad (proxies, antivirus gestionados) que las máquinas de los usuarios, heredarás sus mismos problemas y darás falsos negativos.
   • Herramientas de Precisión:
     • curl: El bisturí. Los navegadores mienten y cachean; curl -v te dice la verdad de las cabeceras HTTP.
     • nc (Netcat): El martillo. Para saber si un puerto TCP está abierto, sin protocolos de capa 7.
     • Manifiestos Limpios (Caso IFS): Si das soporte a IFS Applications versiones 8, 9 o 10, ten a mano un script para limpiar la caché de ClickOnce.

La Teoría: Tres Redes, Tres Verdades

La topología lógica de cualquier incidencia, sea un ERP on-premise, una web en Azure o un SaaS, es siempre la misma:

1. Red del Cliente (La Variable): El entorno hostil. La oficina del usuario, su Wi-Fi saturada, su portátil con el antivirus caducado. Aquí es donde se reporta el fallo, pero no siempre es donde está la causa raíz real.
2. Red de Servidores (La Fuente): Es la "zona cero" del dato. Donde vive el servicio. Puede ser un rack en el sótano del cliente, una instancia en AWS o el cloud de Microsoft 365. Lo que nos importa aquí es una pregunta: ¿El servicio funciona si estoy "sentado" encima de él?
3. Red de Soporte (El Juez): Esta es tu herramienta más valiosa. Es una red separada y limpia.
   • Si eres soporte interno, puede ser una VLAN de gestión o incluso salir por datos móviles 4G saltándote el firewall corporativo.
   • Si eres soporte externo, es tu propia oficina o tu casa.
   • Repito: La clave es que su configuración sea distinta e independiente a la del usuario final.

El juego consiste en triangular. Nunca confíes en lo que dice el cliente ("he reiniciado y sigue igual"). Nunca confíes en lo que dice el servidor ("estoy en verde"). Confía en la diferencia de comportamiento entre los vértices del triángulo.

Escenarios de Trinchera: Deep Dive

Las herramientas cambian, pero la autopsia es la misma. Vamos a ver cómo se comporta el triángulo en el barro: un caso rígido de empresa y uno flexible de servidor web.

Caso 1: El Fantasma Local (Cliente vs. Soporte)

Síntoma: El usuario reporta: "Abro el IFS Enterprise Explorer y no hace nada, o sale un error raro de .NET"
Pánico: ¿Se ha caído el servidor? ¿La base de datos está bloqueada?

El Procedimiento:

1. Disparo desde Soporte: Pruebas a abrir el Enterprise explorer desde la red de soporte.
   • Resultado: Se descarga el manifiesto, se valida la firma y se abre la ventana de login.
2. Análisis:
   • Si a ti te abre y a él no, PROHIBIDO TOCAR EL SERVIDOR.
   • No mires logs de Oracle. No reinicies el Middleware Server.
   • El problema es puramente local.

El Diagnóstico Técnico:
Lo más probable es que la caché de ClickOnce del usuario esté corrupta, que una actualización de Windows/Antivirus esté bloqueando la descarga del .application o que haya un problema de comunicaciones en la red del cliente.

La Solución:
En lugar de detener la producción, te conectas al PC del usuario y vas directo al grano:

• Borrar caché ClickOnce.
• Revisar logs del Antivirus local.
• Probar estabilidad de comunicaciones con el servidor.

Has resuelto la incidencia en 5 minutos sin molestar a nadie más.

Caso 2: La Mentira del Proxy (Soporte vs. Servidor)

Síntoma: El usuario dice: "La web se queda pensando y da error".
Tu Prueba: Pruebas desde tu red externa (Soporte) y te da un 502 Bad Gateway o un 503 Service Unavailable.

El Procedimiento:

Aquí es donde el novato dice: "Se ha caído el servidor". El veterano dice: "Vamos a ver quién está muerto".
Un error 500 significa que alguien está respondiendo. El servidor (la máquina) está viva.

1. Disparo con Bisturí (curl):

curl -I -v https://ivananta.com

Si ves Server: nginx, significa que el Reverse Proxy (Nginx) está vivo, pero no puede hablar con el backend.

2. Incursión a la Red de Servidores:
   Te conectas por Escritorio Remoto o SSH al servidor.

• Prueba Local: curl http://localhost:puerto_interno
• Si en local funciona, es el Nginx/el-reverse-proxy-de-turno el que está mal configurado.
• Si en local falla, entonces sí, el servicio de backend está muerto.

La Diferencia:
Saber distinguir entre "Nginx no conecta" (problema de config/red interna) y "el servicio está caído" (problema de Ghost) te ahorra horas de leer logs equivocados.

Caso 3: El Agujero Negro (Muerte de Red)

Síntoma: Nadie entra. Ni el usuario, ni tú desde fuera. Timeout absoluto. El navegador dice ERR_CONNECTION_TIMED_OUT.

El Procedimiento:

No pierdas tiempo intentando loguearte. Si da timeout, no hay nadie al otro lado del teléfono.

1. Traza la Ruta (traceroute / tracert):
   Lanza un tracert ivananta.com desde tu máquina externa.
   • Si muere en el salto 1 o 2: Tu internet falla.
   • Si muere en el salto 12 (justo antes del destino): El Firewall perimetral de la empresa está tirando los paquetes o el ISP tiene una incidencia.
   • Si llega al destino pero no responde: El servidor tiene el cable quitado o el firewall del sistema operativo ha decidido bloquear el puerto 443.

Acción:
En este caso, si es un problema de red, tenemos culpables casi claros. Si llega a destino pero no responde, podría ser el firewall o el servicio podría estar caído. En ambos casos, tenemos a los culpables acotados.

Protocolo de Comunicación: La Capa 8

Mientras haces todo esto, tienes al usuario (Capa 8 del modelo OSI) preguntando "¿Ya está?". Gestionar la ansiedad humana es tan importante como gestionar los paquetes TCP.

1. El Comando "Alto el Fuego":
   Lo primero que debes decir es: "Estoy triangulando el fallo. Por favor, NO intentes entrar ni reinicies nada hasta que yo te avise."
   Si el usuario sigue intentando entrar compulsivamente, generará ruido en los logs que te confundirá.
2. Valida, no confíes:
   Usuarios: "Me sale un error."
   Tú: "¿Qué error?"
   Usuarios: "Uno rojo."
   Jamás confíes en un pantallazo recortado. Pide el texto completo o conéctate para verlo.
   Tampoco confíes en el "A mi compañero sí le funciona". A veces lo dicen para meter presión. Verifícalo tú mismo.

¡Ojo! Todos podemos ser en algún momento Capa 8, tómese esto con humor, no sería la primera vez que acabo notificando yo mismo un error de algo sin todo el contexto y convirtiéndome, de facto, en la capa 8 descrita.

Trampas Comunes y Falsos Positivos

Para cerrar, cuidado con las piedras en el camino:

• "En mi máquina funciona" (El Falso Positivo): Si pruebas desde tu navegador habitual, puedes estar entrando gracias a una caché antigua o una cookie de sesión válida, mientras el servicio de autenticación está caído para los nuevos logins. Usa siempre Modo Incógnito.
• Culpar al Firewall por defecto: Es la excusa del cobarde o del ignorante. "Será el firewall". El 90% de las veces es un DNS mal apuntado o un servicio detenido. El firewall no se cambia solo de la noche a la mañana; los servicios sí se cuelgan. Culpa al firewall solo cuando un telnet o nc te confirme que el puerto está cerrado (Connection refused vs Timeout).

Conclusión

Al final del día, tu trabajo no es saberlo todo. Nadie conoce de memoria todos los códigos de error de Oracle ni todas las excepciones de .NET. Tu trabajo es saber descartar lo que NO es.

El Triángulo de Triaje te permite entrar en una "sala en llamas", mirar alrededor con calma y decir: "No es el edificio, es solo una vela encendida". Y eso, amigo mío, es la diferencia entre un apagafuegos y un bombero profesional.

Nos leemos en el siguiente post.