Identificación y análisis de las distintas fases del proceso de diagnóstico y solución de averías
Mediante la identificación y análisis de averías, o de posibles averías, se podrán anticipar Acciones preventivas, resolver con más celeridad las consideradas como críticas o disponer de todo un catálogo de procedimientos de resolución de averías para saber, si se diera el caso, cómo proceder en su localización y resolución.
Definición del problema
Se identifica un problema cuando se espera un resultado sobre una acción y se obtiene algo distinto de lo esperado. Justo este momento se identifica como problema.
Para la definición textual del problema se utilizará una frase escueta pero concisa, a modo de titular de un noticiero, por ejemplo: “Sin comunicación con la oficina central de Málaga”.
Tomando como escenario de ejemplo el de la imagen siguiente, debería de haber comunicación, pero justo en ese momento se detecta que no hay comunicación con la central, lo que origina un problema que se ha de resolver.
Descripción del problema
Identificado el problema, se describen los síntomas de la manera más ex tensa y detallada posible contestando a una serie de preguntas: ¿qué sucede?, ¿dónde sucede?, ¿cómo sucede?, ¿cuándo sucede?, ¿quién lo origina? y ¿de qué forma se ha venido solucionando?, en el caso de problemas reiterativos.
Esta descripción ha de servir para identificar el problema de forma inequívoca por sus síntomas, sin que haya posibilidad de confusión con otros problemas posibles.
Siguiendo con el problema del ejemplo anterior, “Sin comunicación con la oficina central de Málaga”, se realiza la siguiente descripción del problema:
“No se detecta comunicación de datos con la central de Málaga desde la delegación de Valencia”.
Inicialmente, los síntomas que se han detectado son:
- Al intentar la comunicación con Server0, ubicado en Málaga, desde cualquier estación de trabajo de la delegación de Valencia, devuelve el error: “Tiempo de conexión excedido”.
- La comunicación con Server1 es correcta.
- No hay acceso a la puerta de enlace, Router FC-Valencia, desde cualquier puesto de trabajo de la delegación de Valencia.
- Las comunicaciones internas funcionan correctamente en la central de Málaga.
Teniendo en cuenta estos síntomas, se observa claramente que el problema está centralizado en la delegación de Valencia sin afectar a la central de Málaga.
Aplicación práctica
Tomando como escenario el esquema de la imagen anterior, se detecta un defecto de comunicación entre Laptop1 y Server1 al acceder al servicio web. Se tiene definido un problema: “Sin comunicación HTTP entre Laptop1 y Server0”.
Cree la descripción del problema contestando a las preguntas de: ¿qué sucede?, ¿dónde sucede?, ¿cómo sucede?, ¿cuándo sucede?, ¿quién lo origina? y ¿de qué forma se ha venido solucionando?
Solución:
Contestando a la serie de preguntas, la descripción resultante quedaría:
- ¿Qué sucede?: no hay comunicación entre Laptop1 y Server0 al intentar utilizar el servicio HTTP.
- ¿Dónde sucede?: el problema sucede entre el tramo que comprende el Router inalámbrico Linksys y el switch Málaga.
- ¿Cómo sucede?: al utilizar el navegador del Laptop1.
- ¿Cuándo sucede?: pero solo ocurre al acceder desde Laptop1; desde cualquier otro puesto de trabajo funciona.
- ¿Quién lo origina?: por lo que los dispositivos que pueden originar el problema se reducen al propio Laptop1 y el Router Linksys.
- ¿De qué forma se ha venido solucionando?: En otras ocasiones se ha solucionado reiniciando el Router Linksys.
No hay comunicación entre Laptop1 y Server0 al intentar utilizar el servicio HTTP. El problema sucede entre el tramo que comprende el Router inalámbrico Linksys y el switch Málaga al utilizar el navegador del Laptop1, pero solo ocurre al acceder desde Laptop1; desde cualquier otro puesto de trabajo funciona, por lo que los dispositivos que pueden originar el problema se reducen al propio Laptop1 y el Router Linksys. En otras ocasiones se ha solucionado reiniciando el Router Linksys.
Establecimiento de las posibles causas
Observados los síntomas, se podrán establecer las posibles causas que pueden llegar a originar el problema. Se creará una lista y se establecerá un orden de prioridad consensuado.
Continuando con el escenario de ejemplo de la imagen, se establece una lista de las posibles causas y subcausas que pueden originar el fallo de comunicación entre los puestos de trabajo y la central. Al haber comunicación con Server1, la lista de causas disminuye:
- Por causa del suministro eléctrico.
-Fallo de alimentación eléctrica del switch PT-Valencia.
-Fallo de alimentación eléctrica del Router FC-Valencia.
- Por causa del dispositivo:
-Fallo en el dispositivo PT-Valencia.
-Fallo en el dispositivo switch 2950T-24 Valencia
-Fallo en el dispositivo FC-Valencia.
- Por causa del cableado:
-Error de conexión del enlace entre FC-Valencia y PT-Valencia.
-Error de conexión del enlace entre PT-Valencia y switch 2950T-24 Valencia.
- Por causa de la configuración:
-Error de configuración en Router FC-Valencia.
Prueba de las causas más probables
Tomando como punto de partida la lista de las posibles causas del problema, se procederá a la determinación y realización de pruebas específicas de cada causa, que ayudarán a valorar la causa más probable del problema.
Valorando el resultado de cada prueba, se irán descartando aquellas cuestiones que arrojen resultados negativos a la causa del problema. Por ejemplo, para las causas de error de conexión (cableado) se realizarán las siguientes pruebas:
- Comprobar que los conectores estén en el lugar correcto.
- Comprobar que el enlace se encuentra en buen estado.
- Comprobar que se tiene señal de enlace (LINK) en los dispositivos en ambos extremos.
De igual forma, se procederá con las demás causas posibles del origen del problema, que en este ejemplo son: suministro eléctrico, dispositivo y configuración.
Verificación de la causa real
En casos más obvios no se necesitará la realización de todas y cada una de las pruebas de verificación de la causa. Utilizando el sentido común, se podría determinar qué verificaciones merecerían ser descartadas, centrando la búsqueda, a priori, en las más lógicas.
En el caso del ejemplo, se podría realizar una prueba que no se menciona en las verificaciones de las posibles causas por no relacionarse directamente con los elementos afectados, que en función del resultado acotaría en gran medida la causa real del problema.
Esta prueba consiste en realizar una prueba de comunicación mediante un simple comando ping lanzado desde Server0 a la interfaz de comunicación del Router FC-Valencia del lado de la delegación, es decir, sobre la puerta de enlace de los puestos de trabajo de la delegación de Valencia; descartando del problema al dispositivo Router FC-Valencia en caso de que la comunicación fuese efectiva, y, por ende, las pruebas a realizar sobre este.
Utilizando la plantilla y continuando con el ejemplo anterior, y realizando las pruebas descritas del apartado anterior, se observa que entre la conexión de origen Valencia y destino switch Valencia, el testigo luminoso de LINK informa que el enlace no se realiza correctamente, según se observa a continuación.
Planificación de las intervenciones
Si para la resolución del problema es necesaria una intervención que pueda llegar a detener la actividad laboral o la interrupción del servicio afectado durante un tiempo prolongado, se ha de plantear la posibilidad de planificar esta, anunciando con anterioridad a los actores afectados el día y la hora del inicio de la intervención y la duración aproximada de la misma, así como los servicios que se verán afectados.
Para una correcta planificación se deberá tener en cuenta todos los medios materiales, de software y de personal que sean necesarios. También se deberá coordinar con terceros, como proveedores de servicios de conexión a Internet, telefonía, suministro eléctrico, climatización, etc., si se vieran o pudieran verse afectados estos servicios en la resolución del problema.
En el ejemplo anterior, no sería necesaria una planificación previa por ser un problema que origina una avería franca de origen físico, la cual mantiene paralizada la comunicación entre delegación y central. Por lo tanto, la intervención se realizaría inmediatamente. Aún así, se debería de comunicar, mediante el aviso correspondiente, de la intención y alcance de la intervención.
Aplicación práctica
Le informan que el servidor de correo ha incrementado el número de usuarios y que por el aumento de tráfico se le ha de incorporar otra tarjeta de red para que trabaje en paralelo con la actual, lo que conlleva para el servidor insertar la nueva tarjeta, conectar mediante un latiguillo la nueva tarjeta al conmutador, realizar la configuración requerida y poner nuevamente en servicio.
Planifique la intervención: cree un check list de tareas y de materiales a utilizar. Asegúrese de informar a terceros que se vean implicados, redactando y enviando un correo electrónico indicando el motivo, el día y la hora y la duración prevista de la intervención.
Solución (Propuesta):
Para la realización de esta intervención, se creará un check list, previo, especificando todas las tareas que se crea que se van a realizar, para que una vez en faena no se deje nada por hacer y por comprobar. El resultado de este check list es el siguiente:
Una intervención de este tipo puede durar, como mucho, dos horas entre que se apaga el servidor, se realiza la intervención y vuelve a arrancar el servidor.
Si se pretende empezar sobre las 04:00 AM, se terminará sobre las 06:00 AM. Esta es una franja horaria donde el tráfico de mensajes es el más bajo por estadísticas y esto es lo que se informará a nuestros usuarios de correo en el mensaje enviado días antes a la intervención.
Comprobación de la reparación
Tras la reparación efectiva del problema, se deberá realizar una serie de comprobaciones específicas para cada efecto, a modo de check list (lista de chequeo), que contendrá una tabla con la lista de las pruebas a realizar, el resultado de la misma y una columna, a modo de casilla de verificación, donde se marcará si se ha realizado o no.
Continuando con el ejemplo, se observa que el acceso al servidor central se ha comprobado como correcto, indicado así en la ficha de comprobaciones do operatividad. Este hecho refleja que se ha restablecido la comunicación y que, por consiguiente, se ha reparado el problema. En el Rack de la delegación do Valencia (imagen siguiente) se puede apreciar cómo la luz del testigo de enlace (LINK) se enciende con normalidad, a la vez que se observa que se ha procedido a la sustitución del latiguillo de conexión por uno cruzado (de color naranja).
En el esquema topológico se ve reflejado el cambio del latiguillo, motivo del problema, por uno de conexión cruzada, al igual que se utiliza en la central de Málaga para la interconexión de los dos conmutadores (siguiente imagen). También se puede apreciar que el sistema funciona con normalidad: la prueba realizada de ICMP (ping) desde PCO a Server0 da como último estado el valor de Exitoso.
Documentación
La documentación necesaria en la resolución de problemas, o su análisis, depende en gran medida del nivel de Registro con el que se quieran llevar las Acciones efectuadas, o si se realizan estadísticas o informes en base a planes de actuación en caso de avería, si existe mantenimiento preventivo o correctivo, etc.
Importante! La documentación de las averías y su solución forma parte de la historia de la instalación.
De forma general, la documentación se compone de procedimientos específicos, diagramas de flujo, partes de trabajo, check list como los expuestos en apartados anteriores y memorias.
