Proceso de Resolución de Problemas

El objetivo de esta etapa es verificar que existe un problema y luego definir correctamente cuál es el problema. Los problemas generalmente se identifican por un síntoma (por ejemplo, la red es lenta o ha dejado de funcionar). Los síntomas pueden aparecer de distintas maneras, que incluyen alertas del sistema de administración de red, mensajes de la consola y quejas de los usuarios.

Mientras se recolectan los síntomas, es importante que el administrador de red realice preguntas e investigue el problema para restringirlo a una variedad de posibilidades más reducida. Por ejemplo, ¿el problema se limita a un único dispositivo, un grupo de dispositivos, una subred completa o una red de dispositivos?

En una organización, los problemas suelen asignarse a los técnicos de red mediante tickets de problemas. Estos tickets se crean utilizando software de tickets de problemas que permiten realizar un seguimiento del progreso de cada ticket. El software de creación de tickets de problemas también puede incluir un portal de usuario de autoservicio para enviar tickets, acceso a una base de conocimientos de tickets de problemas, los cuales se pueda buscar, brinda capacidades de control remoto para resolver problemas de los usuarios finales, y mucho más.

En este paso, se deben identificar los dispositivos que se van a investigar, se debe obtener acceso a los dispositivos y se debe recopilar información. En esta etapa, el administrador de red puede recopilar y registrar más síntomas, según las características que se identifiquen.

Si el problema está fuera del límite de control de la organización (por ejemplo, pérdida de conectividad a Internet fuera del sistema autónomo), comuníquese con un administrador del sistema externo antes de recolectar más síntomas de la red.

Las posibles causas deben ser identificadas. La información recopilada se interpreta y analiza utilizando documentación de red, líneas de base de red, búsquedas en bases de conocimiento organizacionales, búsquedas en Internet y conversaciones con otros técnicos.

Si se identifican múltiples causas, entonces la lista debe reducirse eliminando progresivamente las causas posibles, para finalmente identificar la causa más probable La experiencia es extremadamente valiosa para eliminar rápidamente las causas e identificar la causa más probable.

Cuando se ha identificado la causa más probable, se debe formular una solución. En esta etapa, la experiencia de solución de problemas es muy valiosa a la hora de proponer un plan.

Antes de probar la solución, es importante evaluar el impacto y la urgencia del problema. Por ejemplo, ¿podría la solución tener un efecto adverso en otros sistemas o procesos? La gravedad del problema se debe contrastar con el impacto de la solución. Por ejemplo, si un servidor o un router fundamentales deben permanecer sin conexión durante una cantidad significativa de tiempo, tal vez sea mejor esperar hasta el final del día de trabajo para implementar la solución. A veces, se puede crear una solución alternativa hasta que se resuelva el problema real.

Crea un plan de respaldo que identifique cómo invertir rápidamente una solución. Esto puede resultar necesario si la solución falla.

Implementar la solución y verificar que haya resuelto el problema. A veces, una solución introduce un problema inesperado. Por lo tanto, es importante que una solución se verifique a fondo antes de pasar al siguiente paso.

Si la solución falla, se documenta la solución intentada y se eliminan los cambios. Ahora, el técnico debe volver al paso de "recopilar información y eliminar posibles causas".

Comunica a los usuarios y a todos los involucrados en el proceso de resolución que el problema ya está resuelto. La solución se debe informar a los otros miembros del equipo de TI. La documentación adecuada acerca de la causa y la solución ayudan a otros técnicos de soporte a prevenir y resolver problemas similares en el futuro.

En la resolución de problemas ascendente, se comienza por los componentes físicos de la red y se atraviesan las capas del modelo OSI de manera ascendente hasta que se identifica la causa del problema, como se muestra en la figura.

La resolución de problemas ascendente es un buen método para usar cuando se sospecha que el problema es físico. La mayoría de los problemas de red residen en los niveles inferiores, de modo que, con frecuencia, la implementación del método ascendente es eficaz.

La desventaja del método de resolución de problemas ascendente es que requiere que revise cada dispositivo e interfaz en la red hasta que detecte la posible causa del problema. Recuerda que se debe registrar cada conclusión y cada posibilidad, de modo que es posible que haya mucho papeleo asociado a este enfoque. Otro desafío es determinar qué dispositivos se deben examinar primero.

Ver también

CCNA 3

Licencias del IOS Cisco: Activación y Verificación

En la figura, la resolución de problemas descendente comienza por las aplicaciones de usuario final y atraviesa las capas del modelo OSI de manera descendente hasta que se identifica la causa del problema.

Antes de abordar las partes más específicas de la red, se prueban las aplicaciones de usuario final. Usa este método para los problemas más simples o cuando creas que el problema está en un software.

La desventaja del enfoque descendente es que requiere que se revises cada aplicación de red hasta que se detecte la posible causa del problema. Se debe registrar cada conclusión y cada posibilidad. El desafío es determinar qué aplicación se debe examinar primero.

En la figura, se muestra el enfoque divide y vencerás para resolver un problema de red.

El administrador de red selecciona una capa y hace pruebas en ambos sentidos desde esa capa.

En el método de resolución de problemas divide y vencerás, comienza por reunir las experiencias que el usuario tiene del problema, documenta los síntomas y, después, con esa información, hace una deducción fundamentada sobre la capa del modelo OSI en la que se debe comenzar la investigación. Cuando se verifica que una capa funciona correctamente, se puede suponer que las capas por debajo de ella funcionan. El administrador puede trabajar en las capas del modelo OSI en sentido ascendente. Si una capa de OSI no funciona correctamente, el administrador puede descender las capas de OSI.

Por ejemplo, si los usuarios no pueden acceder al servidor web, pero pueden hacer ping al servidor, entonces el problema se encuentra por encima de la capa 3. Si el ping al servidor falla, es probable que el problema esté en una capa inferior del modelo OSI.

Esta es una de las técnicas de solución de problemas más básicas. El enfoque descubre primero la ruta de tráfico real desde el origen hasta el destino. El alcance de la solución de problemas se reduce solo a los enlaces y dispositivos que se encuentran en la ruta de reenvío. El objetivo es eliminar los enlaces y dispositivos que son irrelevantes para la tarea de resolución de problemas. Este enfoque generalmente complementa uno de los otros enfoques.

Este enfoque también se denomina intercambio del componente (swap-the-component) porque se cambia físicamente el dispositivo problemático por uno conocido y funcional. Si se corrige el problema, el administrador de red sabe que el problema está en el dispositivo que quitó. Si el problema permanece, la causa puede estar en cualquier otro lugar.

En situaciones específicas, este puede ser un método ideal para la resolución rápida de un problema, por ejemplo, cuando queda inactivo un único punto de error crítico. Por ejemplo, un router de borde que falla. En vez de resolver el problema, puede resultar más beneficioso reemplazar el dispositivo y restaurar el servicio.

Si el problema se encuentra en varios dispositivos, es posible que no sea posible aislar correctamente el problema.

Este enfoque también se denomina Encontrar las diferencias (spot-the-differences) e intenta resolver el problema modificando los elementos que no funcionan, para que sean coherentes con los que si funcionan. Puedes comparar configuraciones, versiones de software, hardware u otras propiedades de dispositivos, enlaces o procesos entre situaciones que funcionan y no funcionan y detectar diferencias significativas entre ellas.

Si bien este método puede proporcionar una solución que funcione, no revela con claridad la causa del problema.

Este enfoque también se denomina enfoque de resolución de problemas de disparo desde la cadera (shoot-from-the-hip). Este es un método de solución de problemas menos estructurado que utiliza una conjetura educada basada en los síntomas del problema. El éxito de este método varía en función de tu experiencia y capacidad de solución de problemas. Los técnicos experimentados tienen más éxito porque pueden confiar en su amplio conocimiento y experiencia para aislar y resolver problemas de red de manera decisiva. En el caso de un administrador de red menos experimentado, es muy posible que este método sea más parecido a una resolución de problemas al azar.