Acercamiento a la resolución de incidencias de red

jogofus
29 mar
5 Min. de lectura

Actualizado: 27 jul

Estás tan tranquilo en tu mesa/despacho/oficina. De repente, alguien aparece por la puerta o te llaman por teléfono:

-Hola, ¿departamento de IT?

+Dígame, ¿en qué puedo ayudarle?

-Estoy intentando conectarme al servidor X y no consigo acceder

+¿Ha probado a reiniciar? -No, esto es coña. Quien haya visto la serie The IT Crowd lo entenderá-

Sabes que tienes que resolver una incidencia, pero, ¿de qué?

Como administradores de sistemas y redes, debemos saber qué buscar, pero también dónde buscar. En la entrada de hoy voy a resumir lo que para mí, es esencial en lo que llamo el arte del troubleshooting.

¿Qué es el troubleshooting?

No, no es una palabra que me acabo de inventar. Pero como en casi todo, nos gusta apropiarnos de palabras anglosajonas, y esta no iba a ser menos.

El troubleshooting es la resolución de incidencias, ya sean de sistemas, de redes, de BBDD... El caso es que hay algo que solucionar.

En palabras de Cisco, es el proceso que conduce al diagnóstico y, si es posible, resolución del problema.

La gran mayoría de veces viene motivado porque un usuario reporta un problema con la red, pero en redes más modernas, en las que podemos montar sistemas de monitorización (¿cómo, aún no te has leído mi entrada sobre monitorización? Aquí te la dejo: monitorización, la necesitas, ¿lo sabías? ) nos permiten adelantarnos al problema y resolverlo antes de que el usuario se de cuenta o afecte a la producción.

Una cosa que hay que tener clara es que se debe diferenciar entre lo que el usuario llama problema (que en realidad son los síntomas del problema) de la verdadera causa del problema.

El troubleshooting, o resolución de incidencias, comienza con la definción del problema, después se diagnostica recogiendo información (muchas veces, a raíz de la recolección de información ya se empiezan a generar hipótesis), se analiza la información, eliminando información innecesaria y se proponen hipótesis.

En ocasiones, la solución no se puede implementar en el momento y hay que preparar lo que se conoce como un workaround (solución alternativa) La diferencia es que la solución resuelve el problema y el workaround es temporal y resuelve solo los síntomas.

Fases del troubleshooting

Recoger información:
Ocurre justo después de que un problema haya sido reportado por un usuario o por los sistemas de monitorización. Esta fase incluye "entrevistar" a todas las partes que intervienen en el proceso (usuarios), además de recoger cualquier otra información, como logs de dispositivos, preguntar al equipo si han habido cambios en configuraciones o topología de red... Como consejo, generalmente, la información aportada por el usuario es muy pobre y no tiene suficientes datos, por lo que deberemos hacer una recolección de datos bastante exhaustiva.
Analizar la información:
Después de recoger la información, se debe analizar y comparar los síntomas con su conocimiento, conocimiento del sistema, entorno, procesos y demás para poder diferenciar un comportamiento normal de uno anómalo. Y, ¿qué es obligatorio para esto, aparte de conocimientos técnicos, obviamente? DOCUMENTACIÓN. Y lo pongo en grande, porque a mucha gente se le olvida que la documentación es necesaria. Puede que sepas mucho, pero quizá no te acuerdes de como montaste ese servidor hace 5 años y necesites recurrir a la documentación. Por favor, documenta.
Eliminar posibles causas:
Tras comprobar el comportamiento actual con el real, se puede eliminar ciertas posibles causas. Como dice Sherlock Holmes:

"Cuando eliminas lo imposible, lo que queda, por improbable que parezca, es la verdad

Formular hipótesis:
Después de los pasos anteriores, múltiples posibles causas aparecerán. Deberemos seleccionar minuciosamente las hipótesis que vamos a realizar.
Probar las hipótesis:
Las hipótesis deben ser probadas para confirmar o denegar si es la causa actual del problema. Para ello se proponen soluciones basadas en esas hipótesis.

Aquí debemos tener cuidado. Todos quieren la solución para ya (y sobretodo los jefes). Cada uno de los pasos descritos anteriormente tienen unos méritos y requieren esfuerzo y tiempo.

Si no tienes un enfoque correcto para realizar el troubleshooting y lo realizas "a lo loco", en ocasiones funcionará, pero será ineficiente y -te garantizo- que con el tiempo volverá a fallar, a veces incluso con consecuencias peores.

Los distintos enfoques para el troubleshooting

Antes de enumerar los distintos enfoques que existen, me gustaría hacer mención a uno en concreto. Es conocido como el shoot-from-the-hip, o disparo desde la cadera, y es llevado a cabo por los administradores de red más avezados, aunque en ocasiones, por inexperiencia, también por los más nuevos.

Esto significa que en la fase de recoger información, el sysadmin hace unos pequeños cambios para ver si corrige el problema.

Aunque parezca un método random, no lo es. Se basa en la amplia experiencia y conocimiento, tanto técnico como de la infraestructura y de como debería funcionar. SÍ, LA EXPERIENCIA ES UN GRADO.

A continuación detallo los distintos enfoques estructurados para la resolución de problemas.

The top-down:

Se empieza trabajando desde la capa superior del modelo OSI. Una característica importante del modelo OSI es que cada capa depende de la inferior. Esto implica que si una capa funciona, las inferiores también lo hacen.

The bottom-up:

Se empieza por la capa inferior del modelo OSI, es decir, por la capa física. Aunque es algo muy obvio, hay gente que pasa por alto esta capa, dando por hecho que los cables no fallan nunca. (Ay, si supierais la de problemas que he resuelto simplemente cambiando un cable...).

Divide y vencerás:

El principio de este enfoque es empezar en las capas intermedias del modelo OSI, generalmente en la capa 3, la capa de red, y según los resultados, ir hacia arriba del modelo o hacia abajo.

Una de las pruebas más comunes es hacer un ping o un traceroute.

-Que levante la mano quien no ha hecho esto siempre que ha tenido un problema de red.

Follow-the-path:

Es un complemento de las anteriores. Primero se descubre la ruta seguida y se elimina de la ecuación todos aquellos dispositivos de red que no entren en juego y son irrelevantes. Una vez determinados cuales son, se revisa la configuración y demás menesteres en cada uno.

Existen otros enfoques, como por ejemplo:

Encuentra las diferencias y mueve el problema. El primero se basa en comprobar cambios de configuración en los dispositivos, tanto en el cliente final, como servidor (en caso de que sea nuestro) como de los dispositivos de red. El segundo nos dice que cambiemos el equipo por otro para comprobar como se desencadena el problema con otro dispositivo.

Consideraciones finales

Muchos os estaréis preguntando:

-Entonces, ¿cuál es el enfoque correcto?

No hay un enfoque correcto o incorrecto, depende de la situación y del tipo de problema. Lo que si que hay que tener claro es que hay que recopilar toda la información posible para poder abordar el problema de la mejor forma.

Y para finalizar...

Me gustaría dedicar estas líneas para poder ayudar en una causa necesaria. Estamos recaudando fondos para ayudar a, Ellie una niña de 8 años con TEA, que necesita un perro de asistencia de la Asociación DogPoint.

Podéis colaborar dede el siguiente enlace: https://www.migranodearena.org/reto/un-amigo-para-ellie

Además, os podéis desgravar el 80% de lo que aportéis.

Animaros y colaborad por una buena causa.