Seguimiento y administración dinámica de incidencias

Las acciones de prediagnosis, cruce con información anterior y determinación concreta de las causas reciben una atención especial. Como es habitual, la efi- cacia aumenta cuanto más automatizado sea el proceso, enlazando dinámica- mente con el resto de las etapas del área o subsistemas de las demás.

La interrelación con el subsistema de gestión de incidencias del área de confi- guración resulta obvio y esencial. Las principales tareas conectan con muchos de sus procesos, y proporcionan y recogen información respectiva.

La segunda de las etapas de la cadena de proceso de fallos se encarga de la coordinación de todas las tareas que hay que desarrollar, una vez que el fallo ha sido confirmado por la gestión de alarmas anterior.

Algunas de las tareas más significativas dentro del marco de la dinámica de in- cidencias son las que mencionamos a continuación:

• Apertura de los partes de incidencia.

• Asignación de recursos humanos a las tareas de diagnosis, contención y re- solución: control de perfiles y responsabilidades, aplicadas al personal in- terno especialista y generalista, y a los recursos y organizaciones internas. • Control y seguimiento de los estados y flujos: pruebas de diagnosis. • Control de la información histórica: información de los históricos puros,

contenida en los partes de problemas cerrados, y de las fuentes de informa- ción que pueden completar los sistemas de ayuda a la diagnosis.

Uno de los principales objetivos de la gestión de fallos es reducir el tiempo de resolución y restauración de las condiciones estables. Un factor importante será el de decidir qué recursos y qué perfiles se asignan a los problemas, según la complejidad, criticidad o disponibilidad de medios.

Los niveles de problemas mencionados cumplen unas características determi- nadas, que mencionamos a continuación:

1) Características del primer nivel

• Gestionado por las herramientas dehelp desk de usuario final y sus operadores.

• Los problemas normalmente no son de origen técnico, sino que están rela- cionados con tratamientos y manipulaciones de usuario.

• En una organización bien soportada representan entre el 80% y el 85% de las incidencias que se producen.

• Diagnosis rápida. En la mayoría la resolución puede ser remota, y buena parte de éstas se abren, analizan, diagnostican y resuelven durante una sola llamada.

2) Características del segundo nivel

• Gestionado por los operadores de red y de sistemas específicos.

• El problema tiene un carácter técnico sencillo, pero no puede ser resuelto por la unidad de help desk.

Como norma general, se han establecido cinco niveles de clasificación de los problemas, según los recursos que se asignan para su resolución, la proporción que representan, el área o componentes en los que gene- ralmente se originan y el esfuerzo de detección y resolución.

Ejemplos de problemas de primer nivel

La pérdida de configuración de una impresora o el fallo en un

loginen un servidor son casos de problemas de primer nivel.

Ejemplos de problemas de segundo nivel

Algunos casos de problemas de segundo nivel pueden ser, por ejemplo, la desconfigura- ción y bloqueo de un encamina- dor (router) o la inestabilidad de un enlace.

• Representan entre un 5% y un 10% de las incidencias que se producen. • Diagnosis considerable, que implica algún análisis más profundo en remo-

to o la consulta de información histórica. 3) Características del tercer nivel

• Gestionado por especialistas de redes, telecomunicaciones, sistemas o apli- caciones relacionadas.

• Problemas críticos y complejos, pero que se detectan sin dificultad. • Representan entre un 2% y un 5% de las incidencias que se producen y que

con frecuencia se relacionan con la complejidad tecnológica y las solucio- nes multivendedor.

• Diagnosis muy considerable, que implica siempre la utilización de recursos humanos de altos conocimientos y herramientas de análisis complejas. 4) Características del cuarto nivel

• Gestionado por especialistas de aplicación.

• Son problemas muy variados, localizados o extensos, normalmente impu- tables al diseño, desarrollo o mantenimiento de aplicaciones.

• Representan entre un 1% y un 5% de las incidencias producidas.

• No son fácilmente identificables y, en ocasiones, la detección puede pasar mucho tiempo después de que hayan sucedido. El seguimiento y la repro- ducción controlada del fallo puede no ser posible.

5) Características del quinto nivel

• Gestionados únicamente por los constructores y desarrolladores de siste- mas,softwarede base y grandes aplicaciones.

• De entrada los problemas son muy concretos, porque si no serían intratables. • Representan entre un 1% y un 2% de las incidencias totales que se producen. • Diagnosis muy pesada, basada normalmente en la comparación de efectos similares en muchas instalaciones con características comunes. Según la gravedad se pueden resolver a un corto plazo, pero a veces se retrasan a nuevas actualizaciones o cambio de versiones. Son las más involucradas en procesos de rediseño.

Ejemplos de problemas de tercer nivel

La caída de la red troncal de voz y datos por problemas de sincro- nización y configuración de los conmutadores ATM, o la inesta- bilidad de un servidor al asumir muchos procesos son casos de problemas de tercer nivel.

Ejemplos de problemas de cuarto nivel

La degradación de la integridad de tablas de la base de datos de gestión financiera, o la pérdida de saldos consolidados en dife- rentes cuentas y procedimientos de un banco representan casos de problemas de cuarto nivel.

Ejemplos de problemas de quinto nivel

Algunos casos de problemas de quinto nivel son, por ejem- plo,bugsen módulos del siste- ma operativo de los servidores cuando se utilizan en escena- rios como el nuestro o incom- patibilidad de coexistencia de dos entornos de aplicación corporativos.