Un departamento de sistemas puede tener un equipo dedicado a la investigación y resolución de problemas (¡bienaventurados aquellos con el presupuesto para tenerlo!), y no es exigible al resto de empleados la resolución de los problemas. Pero la detección sí: cabe esperar de cualquier técnico o usuario que vea un posible problema, un agujero, un fallo, lo que sea, que de inmediato aviso de tal fallo.

Un “no es mi trabajo” no es aceptable: los que saben arreglar cosas, deben arreglarlas; los que no saben, deben avisar a alguien que sepa. Y después hacer un seguimiento formal mediante Gestión de Problemas de cada uno de estos problemas para que ninguno se pierda.

Finalmente, concluí la diapositiva con un sucinto “Todos los implicados con los servicios TI deben involucrarse en la detección de problemas proactivamente y debe premiarse el esfuerzo en la detección y la resolución de problemas”.

Sobre el cuándo debe abrirse un problema, fui incluso más sucinto, y sólo incluí: “siempre que sea necesario, útil y que aporte valor”.

El caso es que aún no sé si la presentación fue del gusto del cliente o no. Quizás debería ser menos idealista y ceñirme al estándar español de generar problemas sólo cuando ITIL dice que es imprescindible…

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.

• Identificar items de configuración (CI) que pueden provocar un corte de servicio
• Localizar CIs que no están redundados o que por lo menos no tienen un backup
• Evaluar el riesgo de fallo de cada CI
• Justificar la demanda de inversiones
• Colabora en la creación y mantenimiento de la CMDB.

Los 3 pasos clave para realizar el CFIA con éxito serían:

• Es este CI un punto único de fallo?
• Qué impacto tiene para el cliente/para el negocio el fallo de este CI? A cuántos usuarios afectará? Cuál será el coste para el negocio?
• Cuál es la probabilidad de fallo? Qué puede cambiarse para evitar ese impacto?
• Podría prevenirse ese impacto realizando algún cambio de diseño? Sería conveniente dotar ese CI de redundancia o hacerlo más robusto? Y en tal caso, cuánto costaría?

Realmente, es un método sencillo y muy resultón para empujar al departamento de TI a meter el pie en Gestión de la Disponibilidad, que no es uno de los procesos más populares ahora mismo; de paso, lo que me pregunto es si podría expandirse la matriz para incluir los procedimientos o instrucciones de trabajo de recuperación de fallo de esos CI, quizás añadiendolo como una fila en la parte inferior de la matriz CFIA, aunque esto requiere primero que el departamento de TI sea lo suficientemente maduro como para tener todo eso por escrito (voy a dar por hecho que sí; en caso contrario, no tiene ningún sentido plantearse ni CFIA ni disponibilidades sin tener lo más básico listo: algo de documentación).

Añadir la documentación a la matriz CFIA podría usarse para evaluar tanto la organización como la infrastructura, analizandolo con preguntas tipo:

• Cómo se responde cuando ese CI falla?
• Qué procedimientos se siguen? ¿Están documentados esos procedimientos?
• ¿Se pueden mejorar esos procedimientos? ¿Se pueden automatizar?
• ¿Se podrían mejorar los procedimientos formando al personal o usando nuevas técnicas o herramientas?
• ¿Se podría haber evitado el problema efectuando mantenimientos preventivos?

Si se logara la ejecución metódica y exhaustiva de análisis de impacto de fallo de componentes a todos los niveles (a nivel de infrastructura y de la organización), se generarán RfCs que aporten mejoras reales al negocio pero sin requerir un elevado nivel de madurez en los procesos ni derrochar en software de soporte. Tambien aporta beneficios al departamento TI, porque además de poner un primer pie en Gestión de la Disponibilidad tambien significa meter la cabeza en Gestión de la Continuidad; los datos obtenidos en la preparación de la matriz CFIA sirve como input para Gestión de la Configuración, sobretodo si se añade la documentación de recuperación, que puede aprovechar ese conocimiento para la CMDB. Y por supuesto, Gestión de Incidencias, que usará esos procedimientos de recuperación, y Gestión de Problemas, que recibirá como input el resultado de los análisis efectuados.

El informe completo (en inglés) puede leerse aquí.

Como los chicos de The Opposite of Luck, aplaudo la transparencia con la que Fisher Plaza ha manejado este incidente, sobretodo como deferencia a sus clientes, que realmente merecen una explicación; al fin y al cabo, Fisher Plaza provee servicios de housing y hosting, ese es su negocio: el cliente tiene derecho a saber por qué ese servicio ha fallado de forma tan catastrófica.

De igual forma, tus usuarios tambien se merecen una explicación cuando un servicio IT de los que prestas se cae; no tienes que redactar un informe de 12 páginas para cada problema que analices, pero lo que es inaceptable es encogerse de hombros y decirle: “estas cosas pasan…”. 

¿Por qué resulta entonces tan difícil trasladar esa habilidad al entorno laboral?

A nivel de gerencia IT, existe una cierta conciencia sobre la necesidad de integrar la gestión de problemas dentro de los procesos de gestión IT, pero con muchas reticencias a la hora de implementarla efectivamente, basándose en un puñado de motivos poco fundamentados. Es de esperar que si la dirección es resistente a la adopción de la gestión de problemas, más lo serán los técnicos implicados en ejecutarlo, por partida doble:

• El primer efecto percibido es un aumento en su carga de trabajo: cualquier organización mediana o pequeña evitará la dedicación exclusiva de ningún recurso al análisis de causa raíz porque es caro; de manera inmediata, sin entrar en cálculos de ROIs o VOIs y otros indicadores aún más etéreos, es cierto que supone un desembolso desde el inicio. Los técnicos han de compaginar en su jornada la prestación rutinaria del servicio y, además, investigar incidencias graves o recurrentes, y una vez hallada la causa raíz, proponer los cambios y mejoras necesarios para erradicarla.
• El administrador de sistemas medio no sabe por dónde empezar… pero tampoco dónde acabar.

Ese fue mi caso cuando me vi por primera vez en el brete de hacer un RCA y gestionar un problema: “¿cómo hago un análisis de causa raíz?”

Después del salto, intento arrojar algo de luz sobre esto…

El terror del registro de problema en blanco

Imaginemos: el ServiceDesk recibe un aluvión de llamadas de usuarios reportando que no les funciona el correo electrónico; se inicia el proceso de Incidente Grave, se desencadena el plan de acción, llega a Sistemas y un administrador lo resuelve; actualiza el registro de incidencia con la información de la resolución y se comunica a los usuarios el restablecimiento del servicio.

En una organización que haya iniciado la adopción de ITIL, un incidente grave requiere la apertura de una investigación de problema; y ante la extensión inmaculada del registro de problema recién abierto se encuentra el administrador de sistemas encargado de completarlo. ¿Por dónde empezar?

Lo primero: identificar el servicio y sus componentes afectados por el incidente, algo que ya no es trivial en un departamento que no haya adoptado la Gestión de la Configuración y que tenga un catálogo de servicios incompleto, con poca sustancia, en resumen: más bien flojo. Tener que hacer el ejercicio de determinar los componentes de un servicio afectados por un incidente durante la investigación de problema tiene una ventaja: puede convertir esa información generada en input para la Gestión del Catálogo de Servicios para enriquecerlo y así hacerlo más preciso y útil.

Lo siguiente es saber cómo documentar un registro de problema; requiere que contenga una descripción fiel y detallada del desarrollo de los acontecimientos desde la primera notificación del incidente hasta su resolución. La forma más clara: contarlo como si fuera una crónica periodística, en la que se establece primero el marco del suceso (fecha, hora y lugar) y después se detalla la secuencia cronológica de eventos. Una vez realizada esta crónica, comienza el análisis; para realizar esa parte, es conveniente disponer de un cuerpo de preguntas que:

• vertebre la investigación
• prevenga el dejar cabos sueltos o áreas de responsabilidad vacías
• nos ayude a identificar y formalizar las mejoras que conformarán la solución permanente al problema, y que es, en definitiva, el producto principal que debe extraerse de la gestión de problemas.

Exponiendo los hechos: la verdad, toda la verdad y nada más que la verdad

Un registro típico de problema podría empezar con algo como:

“A las 10:15 am, el usuario Joaquín Báñez contactó al Service Desk por teléfono y reportó que al abrir MS Outlook para acceder al correo se producía el siguiente mensaje de error…”

El primer paso en la investigación es, por tanto, recopilar todos los registros de incidencias relacionados con el problema que tratamos; el primero de ellos, se convertirá en el cabo del ovillo del que iremos tirando para responder a una colección de preguntas similar a:

• cuándo fue detectado el incidente?
• cómo se detectó?
• ¿qué se hizo para resolverlo?
• ¿qué impacto causó a los usuarios?
• ¿ha pasado antes? ¿es un problema recurrente?
• ¿se pudo de alguna manera detectar antes este problema?
• ¿se pudo de alguna manera resolver antes este problema?
• ¿existía documentación sobre esta incidencia en la base de datos de conocimiento? En tal caso, la instrucción de trabajo era adecuada para la resolución?
• ¿Debe algún otro equipo o proveedor estar involucrado en la investigación del problema?

En siguientes entradas, daré más detalles sobre cómo documentar, argumentar y contestar, de manera metódica y estructurada (y, sobretodo, documentada), todas estas preguntas.