Es usual que surjan estos términos en la conversación cuando estoy dictando algún curso de ITSM o durante una simulación o en algún proyecto y que además, haya mucha confusión con el significado de cada uno y la forma como se relacionan. En este artículo voy a intentar dar una perspectiva clara para cada uno de ellos.
La falla es lo que sucede física o lógicamente en un componente de la infraestructura y que impide que el componente funcione como se espera. La falla puede interrumpir o degradar la operación del componente.
La alerta (o alarma) es el llamado de atención sobre algo que está sucediendo en la infraestructura y la generan los mecanismos o sistemas de monitoreo (activo o pasivo) que cuenten con esa funcionalidad. Así, cuando a través del monitoreo se detecta alguna condición preestablecida, se genera una alerta. Esta condición puede ser que se sobrepasó o se bajó de un valor específico, usualmente llamado valor umbral (por ejemplo, el disco llegó a un 80% de ocupación o solo queda un 10% disponible de ancho de banda) o que ocurrió algo que merece atención (por ejemplo, no hay conexión con un servidor, se terminó de realizar el respaldo o se bloqueó la tarjeta de un router). La alerta puede ser visual y/o auditiva y usualmente es una notificación electrónica que se despliega en una pantalla o que se recibe en algún dispositivo (por ejemplo, un email en el celular, un banner en una consola o un mensaje en una pantalla en la sala de monitoreo). Entre otras cosas, las alertas nos notifican sobre las fallas.
El evento es el cambio de estado que es importante para la gestión de un componente o de un servicio. De acuerdo con ITIL®, eventos y monitoreo trabajan de manera conjunta para detectar los cambios de estado que se considerarán eventos. Así, las capacidades de alerta del monitoreo también se pueden utilizar para avisarnos cuando ocurre uno de esos cambios que son considerados eventos. Hay que tener en cuenta que alerta no es lo mismo que evento, que no todas las alertas nos notifican sobre eventos y que no todos los eventos se notifican por alertas (ejemplo de esto último, el no recibir alertas puede ser un indicativo de que tenemos un evento con el sistema de monitoreo o con un dispositivo que se automonitorea - monitoreo pasivo). Un aspecto importante de los eventos es que cada organización decidirá qué considerará un evento y qué hará con cada uno de ellos (no actuar y simplemente almacenarlos, es una opción viable para la gestión de eventos). Y como los eventos son parte importante de la operación y se generan en gran cantidad al día (usualmente en el orden de los cientos o miles), se recomienda utilizar sistemas de gestión de eventos que permitan crear y mantener registros de los eventos, automatizar acciones sobre estos y generar reportes para, entre otras cosas, analizar tendencias, identificar patrones y tener una mejor comprensión de la operación.
El incidente es la interrupción no planificada o la degradación de la calidad de un servicio. Todos los incidentes tienen la potencialidad de afectar al usuario del servicio y poner en riesgo el cumplimento de los compromisos que el proveedor de servicios estableció con sus clientes (documentados en Acuerdos de Nivel de Servicio), por tanto, el proveedor de servicios tiene que trabajar en solucionar el incidente (restablecer el servicio) lo más rápido posible para minimizar el impacto que el incidente tiene en el cliente. Ante los incidentes importa la velocidad, mientras más rápido se atiendan y resuelvan, mejor para todos los involucrados, es por ello que durante la resolución de incidentes no importa ni conocer el por qué del incidente (la causa raíz) ni resolver ese por qué; centrarse en esto retrasaría el restablecimiento del servicio e incrementaría el impacto del incidente en el cliente.
Incidentes y eventos son cosas diferentes. Aunque ambos pueden ser atendidos por los mismos equipos operativos y derivarse de la misma falla, se atienden de forma diferente, usualmente por prácticas o procesos diferentes y nunca un evento se transforma en un incidente (spoiler alert: los incidentes tampoco se transforman en problemas). Entre los aspectos que diferencian a los incidentes de los eventos, tenemos:
Las organizaciones no pueden definir qué será considerado un incidente. Cualquier interrupción no planificada o reducción de la calidad del servicio es un incidente.
Hacer nada ante un incidente es una opción viable bajo muy raras circunstancias. Generalmente todos los incidentes deben ser registrados y resueltos en el menor tiempo posible y dentro de los compromisos de tiempo establecidos con los clientes. Entre esas raras circunstancias están los incidentes que se “resuelven solos” antes de que los equipos encargados de resolverlos puedan actuar (por ejemplo, cuando se genera un incidente a partir de un cambio fallido y se regresa el cambio removiendo lo que generó el incidente) o cuando el servicio se va a retirar de operación antes de la fecha tope para resolver el incidente o cuando, por alguna razón fuera del alcance de la operación, el proveedor de servicios decide que no se deba actuar sobre el incidente (por ejemplo, hay un proyecto o una negociación en curso con el cliente que removerá la necesidad del servicio y por tanto la necesidad de resolver el incidente).
El problema es la causa real o potencial de uno o varios incidentes. Usualmente los problemas son desconocidos y sólo se identifican cuando ocurren incidentes y se decide investigar qué los está causando (el problema). A diferencia de los incidentes que deben ser resueltos lo más rápido posible, los problemas requieren de análisis e investigación y pueden permanecer sin resolución indefinidamente. En cuanto a prioridad, usualmente las tareas para resolver problemas tienen menos prioridad que las tareas para resolver incidentes, aún cuando resolver problemas podría ayudar a resolver incidentes abiertos, a reducir la cantidad y frecuencia de incidentes o a reducir el impacto de los incidentes. Como los problemas causan los incidentes, los incidentes no se transforman en problemas.
El error conocido es un problema que ha sido analizado pero que no ha sido resuelto. “Error conocido” es un estado del problema y nos indica que ya sabemos qué es lo que está causando el incidente. Las organizaciones pueden vivir con errores conocidos y proveer soluciones temporales para minimizar el impacto de los incidentes que se generen a causa de estos, resolver incidentes abiertos o prevenir la aparición de incidentes; también pueden intentar remover estos errores y eliminar la posibilidad (o el riesgo) de que sigan causando incidentes. Esto último sería la solución del problema. La decisión de si se remueve o no el error dependerá del contexto de cada organización y usualmente depende de factores de riesgo (apetito y tolerancia al riesgo; al final, un error conocido es un riesgo), financieros (relación costo-beneficio de remover el error), humanos (disponibilidad de habilidades y competencias), técnicos (limitaciones en la infraestructura, arquitectura del sistema, etc) y/o de negocio (impacto en el negocio y probabilidad de generación de incidentes a partir del error).
Resumiendo las relaciones (ojo! no es una lista exhaustiva):
La falla se puede detectar a través del monitoreo y notificarse a través de una alerta.
La falla puede generar un cambio de estado que la organización reconozca como un evento.
Si la falla ocurre en un componente de un servicio, puede llegar a afectar el servicio dando origen a un incidente.
La aparición del incidente indica la presencia de un problema.
El análisis del problema nos lleva a conocer la causa del incidente: el error conocido.
El error puede generar la falla.
Bien, este es mi punto de vista. Si tienes alguna duda, comentario o aclaratoria, déjala en los comentarios. Y mientras estás acá, si te interesa profundizar en estos temas, date una pasadita por la sección de cursos y eventos que probablemente tengamos un curso en calendario que te pueda servir.