Gestión de problemas: hila fino en los detonadores y descubre a tu mayor enemigo

Por Joaquín Báñez  Martín.

A la hora de establecer el proceso de Gestión de Problemas en una organización merece la pena dedicar cierto esfuerzo a definir los detonadores que se considerarán para la creación de registros de problemas.

El detonador es aquello que ha provocado que se desencadene el problema, lo que hace que aflore; tener una colección de detonadores bien tipificados y que elegir un detonador sea obligatorio en cada registro de problema gestionado, ayuda a:

• Identificar cuál es el factor que más frecuentemente desencadena problemas
• Tener una visión numérica de los factores de riesgo que amenazan nuestros servicios
• Detectar las malas prácticas que pueden ocasionar problemas
• Y hacer algo útil con todo esa información después…

“Detonador” no tiene nada que ver con causa raíz; el detonador va a hacer explotar un problema , va a hacer que se manifieste y que aflore; la causa raíz es el error o circunstancia que hace que, al darse ese detonador, el problema se dispare. Es decir, al final, la meta ha de ser erradicar la causa raíz: es lo que realmente evitará la recurrencia del problema; pero el control de los detonadores es importante y como parte del plan de acción que se diseña para solucionar un problema se deben incluir acciones encaminadas al control de los detonadores.

Ejemplos de detonadores que se me ocurren: uso válido. Es el más frecuente y, en realidad, el que más nos debe preocupar si aparece demasiado a menudo. Un ejemplo: que se te llene el disco de sistema porque una aplicación ha agotado el espacio disponible con los logs generados no es un fallo de aplicación, sino que es su comportamiento normal.

El problema que te ha generado es que se ha agotado el espacio en disco; posiblemente esa aplicación se ha detenido, y tambien es probable que todo el sistema que aloja dicha aplicación se detenga. Te has quedado sin servicio.

La causa raíz no es “los logs de la aplicación han agotado todo el espacio en disco”; la aplicación genera logs cuando funciona normalmente. Fue diseñada así. Es correcto. Y ese funcionamiento correcto según la norma ha sido el detonador. ¿Cuál sería la causa raíz? Que ese funcionamiento normal no se tuvo en cuenta en la fase de diseño; no se consideraron adecuadamente los requerimientos del servicio, en este caso de espacio en disco para logs, o no se aplicó una política de rotación de logs correcta o la que se aplicó se dimensionó incorrectamente. La raíz de causapodría caer en una categoría como  ”Diseño / fallo de capacidad”, si el problema fue que el volumen de datos de registros fue inesperado, o en el caso de que la política de rotación de logs fuera inadecuada o no se aplicara, algo como “Política inadecuada”, en el sentido de que las políticas para la adopción de servicios quizás no estén correctamente definidas para entregar al negocio servicios resistentes a los detonadores (pero esto,  las clasificaciones de causa raíz, lo hablamos otro día).

Otros posibles detonadores que podrían incluirse:

• Fallo de un componente: fácil, el servidor se rompió, el switch se quedó lelo… un componente del servicio, simplemente, falló.
• Fallo de infrastructura: como podrían ser problemas de alimentación eléctrica en el CPD (o que se te inunde, o que se incendie…)
• Error humano: este es otro que aparece frecuentemente; un error de operación te la puede liar, y gorda.
• Terceros (y aquí cabrían muchas subclasificaciones): bugs de software desarrollado por otros, fallos en comunicaciones, tu ISP…
• Acto deliberado: que un empleado cabreado te rompa algo es algo que puede pasar… y un atentado terrorista tambien

Cuando ya los tengo clasificados… ¿qué hago?

Cuando tras un periodo gestionando problemas tienes una muestra significativa de problemas analizados y resueltos, estudia la distribución porcentual de detonadores y elabora planes de acción para acotar su impacto actual y futuro; la gestión de problemas no sólo sirve para reducir el número de incidencias sino también el número de fallos de la plataforma tecnológica, y aquí incluyo todo lo que tenga que ver con el departamento TI: hardware, software y gente. A saber:

• Si tu detonador principal es “Uso válido”: revisa a fondo tus procesos de diseño y cambio, porque se están entregando al negocio servicios poco fiables, mal diseñados, mal dimensionados…
• Si es fallo de componente: revisa la disponibilidad de tus servicios y la capacidad de tu plataforma;  si tus componentes críticos no están redundados, sientate con la dirección y analiza si el negocio lo necesita; puedes usar esto para empezar el análisis
• Si el error humano encabeza la lista: forma al personal, mejora tus procedimientos  e instrucciones de trabajo, introduce el uso de checklists para las tareas rutinarias, e idealmente, automatizalas.

Y así con todos; y tambien sería importante delegar en los procesos de Mejora Contínua el perfilar esta lista de detonadores hasta ajustarla a las necesidades del servicio prestado. Cada organización va a necesitar considerar una colección de detonadores que represente de forma fidedigna qué hace estallar un problema en su negocio; por ejemplo, para un proveedor ISP móvil puede ser interesante incluir “Meteorología” como detonador mientras que a un proveedor web no le sirve de nada incluir tal categoría.

Pero así es todo; al fin y al cabo, ITIL no es un modelo pret-a-porter, sino una guía de estilo; no te vende el traje hecho, pero sí te deja bien claro que no combines nunca negro con azul.