Identificación y análisis de las distintas fases del proceso de resolución de incidencias

Se debe realizar una buena gestión de incidencias para que la resolución sea más eficiente y menos costosa en la medida de la capacidad que esta gestión aporta.

Definición del problema

La notificación de la Incidencia se puede realizar por distintas vías, por mail, por teléfono, etc., y puede proceder de distintas personas: cliente, administrador de red, etc. Si se sigue una metodología como ITIL, la recepción de la primera notificación, si esta es por parte del cliente o usuario, es por parte de un técnico de primer nivel. Es posible que este no tenga grandes conocimientos de redes. Por lo tanto, debe tener un cuestionario mínimo de preguntas para poder conocer el problema y que, cuando se escale, se tenga la mayor cantidad de datos posible.

Recordemos! En la metodología ITIL, existe el llamado Service Oes/r(SD),que es el primer nivel de atención al usuario y a los posibles incidentes o problemas.

Una vez en el departamento adecuado, se debe tratar de definir el problema en un principio. Así, para acotarlo, se deben definir esencialmente dentro de la red los siguientes aspectos:

• Servicios afectados.
• Tiempo de falta o merma de servicio.
• Repercusión dentro de la empresa que trabaja con la red.
• Coste económico a esta empresa.
• Cumplimiento de SLA.

Estos serían los datos principales que se deben tener en cualquier tipo de red, pero después se debería estudiar cada tipo de red, porque habrá parámetros más concretos de los que sea necesario conocer más.

Una vez conocido esto, se debe hacer una descripción exhaustiva dei problema.

Descripción del problema

Cuando ya se conoce a qué ha afectado la Incidencia y se clasifica según el SLA que se tenga acordado con el cliente, se debe realizar la descripción del problema. Para esto, es posible que se deba hablar con la persona que ha detectado la Incidencia, ya que es muy probable que pueda aportar muchos más datos. La descripción del problema depende mucho de cada caso, porque cada uno es diferente y aquí entra en juego el buen hacer del administrador o gestor de redes. Así, si el problema ya se ha dado en alguna ocasión anterior y está documentado, se resolverá inmediatamente, pero, si no, se deberá realizar y documentar qué ocurre exactamente y cómo afecta. Así, se pueden considerar parámetros importantes y generales en la descripción del problema:

• Cómo ha sido detectado.
• Qué lo ha causado.
• Qué servicios están afectados y qué servicios no.
• Cuándo ha ocurrido.

Estos son los datos principales, pero, dependiendo de la casuística de cada red, se deberán concretar ciertas cosas más o menos.

Otra cosa a tener en cuenta es si realmente esos servicios que se están demandando como perdidos son realmente servicios que se han ofrecido o no, es decir, es posible que el cliente crea que le falta un cierto servicio, pero en realidad sea un servicio que no se ha implementado en su momento porque no estaba en el acuerdo, pero es algo que puede no conocerse por parte del usuario de la red, ya que pueden ser necesidades que se crean posteriormente.

Ejemplo:

Un usuario compra un teléfono móvil para realizar llamadas y se lo lleva. Cuando está haciendo uso de él, quiere empezar a usar una aplicación de mensajería instantánea, pero no le funciona. Va a la tienda explicando que tiene un problema porque el teléfono no hace todas las funcionalidades que este usuario quería. Lo que el usuario no sabe es que no ha contratado la tarifa de datos en el teléfono, solo pidió en su momento poder hablar por teléfono, por lo que le aplicaron la tarifa de voz y, por tanto, no puede tener aplicaciones de mensajería, ni ninguna de las que requieran el uso de Internet. Así, se descarta como Incidencia, ya que no es un servicio contratado en un principio.

Dentro de la descripción, también se debe tener en cuenta el SLA y se especifica si se cumple y qué plazos se tienen para resolver el problema, según el acuerdo.

Recordemos! El ANS o SLA (Acuerdo de Nivel de Servicio o Service Level Agreement) es un Documento o acuerdo en el que se especifican los requisitos mínimos que debe cumplir el servicio contratado entre cliente y proveedor. Debe garantizar la Calidad mínima de los servicios contratados necesaria para el cliente.

Establecimiento de las posibles causas

Para poder empezar con la resolución del problema, se deben establecer las posibles causas. En este caso, puede haber muchas o quizá sea necesario investigar para poder llegar a la causa principal, porque sea una causa no conocida o nueva.

Normalmente, lo primero que se debe intentar es comprobar en la base de datos si el problema ya se ha dado y así se pueden establecer las causas más fácilmente o si se ha dado uno similar. En otro caso, se hará un estudio exhaustivo para determinar estas causas. Para este trabajo, son realmente interesantes los diagramas de causa/efecto que se estudian en el siguiente epígrafe.

Se realizarán una serie de pruebas y estudios para llegar a las causas más probables.

Las causas más probables, sacadas de puestas en común de distintos administradores de redes, son:

• Respecto al nivel físico, de cobre, fibra o inalámbrico.-

-Cableado o terminaciones dañadas o sucias

-Atenuación excesiva de la señal

-Insuficiente ancho de banda para el cableado

-Interferencia inalámbrica.

• Respecto a la configuración software del nivel de red, Ethernet e IP:

-Dispositivos de red dañados.

-Configuraciones de dispositivo incorrectas o no óptimas

-Problemas de autenticación y asociación

-Ancho de banda de red insuficiente.

• Respecto a los sistemas switches, routers y VLAN:

-Uso excesivo

-Demasiados errores.

-Inscripción de VLAN asignada incorrectamente

-Problemas de prioridad del tráfico (cos/qos).

Aplicación práctica

Imagine que está en una empresa que da soporte a la red de un hospital. Llega una Incidencia en la que se describe una caída del servidor en el que está la base de datos de los pacientes. Se llega hasta los servidores anteriores de acceso, pero, al introducir los datos, no funciona la aplicación. Por lo que se describe, sí se llega al servidor anterior, pero no al que alberga la base de datos. ¿Qué tipo de Incidencia descartaría primero (softwareo hardware)?. ¿Cuáles cree que serían las causas más probables, según lo visto?

Solución:

En principio, parece ser algo de hardware, ya que se llega a un servidor anterior, así que descartaría el caso software en un principio (esto no quita que pueda ser otro tipo de problema, es el estudio primero). Así, las causas más probables son:

1.    Cableado o terminaciones dañadas o sucias.

2.    Atenuación excesiva de la señal.

3.    Insuficiente ancho de banda para el cableado.

4.    Interferencia inalámbrica.

Prueba de las causas más probables

Una vez que se consiguen aislar las causas que se consideran más probables de todas las posibles, utilizando los diagramas causa/efecto, es necesario realizar las pruebas o los estudios correspondientes para poder averiguar la causa real de lo que está ocurriendo, porque si no sería imposible llegar a una resolución del problema. Para esto, se tomará un listado de las causas más probables y, haciendo uso de las herramientas hardware y software de las que se dispone para la administración y la gestión de incidencias, se llegará a la causa del problema.

Verificación de la causa real

Una vez concretada la causa que provoca la Incidencia, después de haber hallado las causas más probables por el diagrama de causa/efecto y habiendo hecho las pruebas con las herramientas que se van a estudiar se llegará a la causa del problema.

na vez que se considera que una causa es la responsable de la Incidencia, se ha de verificar que es así, ya que puede haber errores en las mediciones, en las herramientas de diagnósticos y en los juicios de las personas responsables de la red y que manejan estas herramientas. Para ello, se realizan una serie de pruebas.

Puede ocurrir que vuelva a haber servicio en la red porque la causa que provoca la falta o la merma de servicio en la red sea temporal y las condiciones vuelvan a ser propicias para que la red vuelva a su funcionamiento normal.

En este caso, si no se pudiese verificar la causa, sería conveniente forzar la Incidencia. Para hacer esto, se debe hacer un estudio sobre en qué momento se debe realizar una prueba, porque sea menos perjudicial y menos costoso tanto para el cliente como para la empresa gestora de las incidencias.

Entonces se provocaría el problema y se determinaría la causa, verificando que es la que se ha considerado. Esto es importante hacerlo porque el estado de esta Incidencia se queda en modo inestable, ya que no se le ha dado una solución real, ha sido un cambio de estado, así que se debe estudiar la causa y darle una solución definitiva.

Ejemplo:

Se tiene una falta de servicio de un servidor por la tarde. El cliente llama y avisa de esta falta de servicio. No se intenta resolver porque en la SLA no se encuentra el acuerdo de que se resuelva a cualquier hora. A la mañana siguiente, cuando llega el administrador de la red, se encuentra que el servicio está de nuevo en funcionamiento. A pesar de que las circunstancias han cambiado, es conveniente estudiar la causa del problema y ver si se puede volver a dar. En este ejemplo, es porque el sistema de ficheros del servidor se ha llenado, lo que provoca que los servicios no estén funcionando. Por la noche, hay programada una rotación de estas trazas, que se comprimen y se mueven a otro sitio. Esto provoca que se libere el sistema de ficheros y el servidor pueda volver a tener un uso normal. Así, por la mañana, el administrador se encuentra que todo funciona correctamente. Pero es algo que se debe estudiar, porque es un problema inestable, ya que se puede dar el caso, y es muy probable que se dé, de que vuelva a haber una falta de servicio. Cuando se haya llegado a la conclusión de que esta es la causa, se debe intentar simular.

Planificación de las intervenciones

Cuando ya se ha cerrado cuál es la causa del problema y se ha hecho un estudio de cuál puede ser la posible reparación y cómo debe ser esta, se debe realizar una planificación. En este caso, se deben tener muy en cuenta los acuerdos llegados según el SLA. Para esto, se debe tener esta documentación accesible y disponible, porque es muy importante para la planificación. Esto repercute sobre todo en los tiempos de contratación de servicio. No es lo mismo un servicio en el que se tiene contratada una asistencia técnica de 24 hs. con una actuación dentro de un plazo mínimo, que si se tiene acordado un servicio en horario laboral solamente. Según esto, se planificaran las actuaciones de una manera u otra.

Independientemente de esto, lo que siempre se tiene que intentar es reactivar los servicios que ofrece la red en el mínimo tiempo posible y con la menor repercusión negativa para la empresa.

También se debe planificar la actuación técnica para estar seguro de que lo que se está haciendo no va a repercutir negativamente en otros servicios.

Por lo tanto, se debe realizar, y por supuesto documentar, una planificación exhaustiva de todas las tareas que se van a realizar para resolver la Incidencia, teniendo en cuenta los tiempos y también la repercusión. Son datos importantes a tener en cuenta a la hora de la planificación:

• Tiempo que se permite que esté el servicio en concreto caído o mermado.
• Importancia de esa falta de servicio.
• Estudio de la repercusión de esa falta de servicio en la empresa a la que da servicio la red.
• Estudio de la repercusión de la posible resolución a los demás servicios que da la misma red.
• Tiempos en los que es mejor realizar la intervención, según el acuerdo del SLA.
• Planificación técnica de cómo realizar la intervención según los sistemas implicados.

Dependiendo de cada Incidencia en concreto, se deberá realizar otra posible documentación.

Ejemplo:

En una red que da servicio a un soporte bancario sobre sus sucursales, se deben parametrizar todos los datos importantes dados hasta ahora, pero también se debe tener en cuenta, a la hora de realizar una posible intervención, la fecha del mes en la que se podría realizar, ya que, por lo general, los bancos, a finales y a principios de mes, tienen mucho más tráfico y operaciones. Por lo tanto, este dato, en este caso en concreto, también se debe considerar.

Comprobación de la reparación

Según la documentación que se va teniendo, se va realizando un seguimiento del problema. Es muy importante realizar un posterior seguimiento de la Incidencia. Esto está contemplado en todas las metodologías y manuales de buenas prácticas, ya que es importante, pues pueden ocurrir una serie de cosas no previstas en la resolución, como por ejemplo:

• Que no se hayan contemplado todas las posibles causas y problemas que hayan ocurrido.
• Que la solución no sea suficiente porque necesite de alguna reparación más.
• Que la solución sea temporal.
• Que no se restauren correctamente todos los servicios.
• Que no se cumpla el acuerdo SLA.

Además, se debe hacer un seguimiento posterior a la resolución de la Incidencia, porque es importante para la documentación que se debe llevar sobre todo el proceso. En la documentación debe aparecer también, cuando se realiza la resolución, cómo evoluciona en el tiempo la restauración o renovación del servicio dado.

Documentación

Como se especifica en la gestión de incidentes, es muy importante llevar una documentación sobre todo el proceso. Todos los manuales de buenas prácticas y metodologías reflejan la importancia de esta documentación, para que se facilite la resolución de otros posibles problemas posteriores y para que todas las personas implicadas en el proceso de la resolución de incidencias puedan tener acceso a cada paso que se da para resolver esta Incidencia, desde la recepción del problema hasta la solución definitiva.

Recordemos! La [def]CMDB[/def] (Configuration Management Data Base o Base de Datos de Gestión de Configuración) es la base de datos que contiene cada elemento de configuración de cualquier ítem de las TI con todos sus detalles relevantes. Esencial en metodología ITIL.

Para manejar Hita documentación, se suelen llevar una o varias bases de datos, donde habrá una serie de campos para rellenar ya prefijados. Habrá campos que se repitan en cualquier tipo de incidencias, campos de datos que se repitan en incidencias de redes, y campos personalizados para ciertas redes concretas. Seguidamente, se ofrece un ejemplo de los campos que se pueden poner en la base de datos. Aunque estos son genéricos y deben estar en todas las bases de datos, normalmente se les añadirán más, según cada casuística:

• Hora del incidente.
• Hora de la detección.
• Falta o reducción del nivel de servicio causado.
• Tiempo total desde la caída del servicio a la restauración parcial.
• Tiempo total desde la caída del servicio a la restauración completa (a veces coincide con la anterior).
• Recursos utilizados.
• Posibles causas.
• Descripción completa de la solución parcial.
• Descripción completa de la solución total.

EJEMPLO DE OBJETIVOS DE SEGUIMIENTO Y ENUMERACIÓN DE ALGUNOS DE LOS CAMPOS DE LA BASE DE DATOS

Hora del incidente

Hora de la detección

Falta o reducción del nivel de servicio

Tiempo total de la caída a solución parcial

Tiempo total de la caída a solución total

Recursos utilizados

Posibles causas

Descripción solución parcial

Descripción solución total