12.11. Gestión de eventos.



Visión general.

Una vez que el servicio está operando es necesario monitorizar todos los sucesos importantes que se produzcan para poder anticiparse a los problemas, resolverlos o incluso prevenirlos. Esta función representa una tarea en sí misma y por tanto constituye un proceso independiente dentro del ciclo de vida: la Gestión de Eventos.

A efectos de la operación del servicio, se denomina evento a todo suceso detectable que tiene importancia para la estructura de la organización TI, para la prestación de un servicio o para la evaluación del mismo. Ejemplos típicos de eventos son las notificaciones creadas por los servicios, los elementos de configuración o las herramientas de monitorización y control.

Un aspecto clave en la Gestión de Eventos es, como resulta evidente, una buena monitorización y unos efectivos sistemas de control. Encontramos dos tipos:

 

• Herramientas de monitorización activa. Se comprueban los CIs uno a uno para verificar su estado y disponibilidad. Si detecta excepciones, la herramienta de monitorización genera una alerta y la envía al equipo o mecanismo de control asignado.

• Herramientas de monitorización pasiva. Detectan y correlacionan alertas operacionales generadas por los propios CIs.

Los eventos no tienen por qué ser siempre negativos o extraordinarios, también pueden ser rutinarios. De hecho, podemos distinguir varios tipos de eventos dependiendo de su impacto:

 

• Eventos que indican que el servicio está operando con normalidad.

• Eventos que indican una excepción.

• Eventos que indican una operación inusual pero no excepcional, y que requieren una monitorización exhaustiva.

La Gestión de Eventos, además de detectar y notificar los sucesos, se encarga de clasificarlos y dimensionar su impacto en el servicio. Llegado el caso, se ocupa también de documentar el evento y derivarlo al proceso correspondiente para que tome medidas:


 

• A la Gestión de Incidencias, en caso de que el evento suponga una interrupción no planificada del servicio o fallos en uno o más CIs.

• A la Gestión de Problemas, si una incidencia se repite a menudo y no se conoce la causa que la provoca.

Y también envía a la Gestión de Cambios, a través de la Mejora Continua del Servicio, nuevas solicitudes de cambio basadas en la correlación de eventos.

 

El principal objetivo de la Gestión de Eventos, en su función de monitorizar todos los sucesos importantes, consiste en detectar y escalar condiciones de excepción para así contribuir a una operación normal del servicio:

 

• Proporcionando puntos de entrada para varios procesos de la fase de Operación (p. ej. Gestión de Incidencias).

• Posibilitando la comparación entre el rendimiento real del servicio con los estándares de diseño y los SLAs.

• Contribuyendo a la Mejora Continua del Servicio mediante informes de mejora.

Algunas de las ventajas que una correcta Gestión de Eventos aporta a la organización TI son:

 

• Ayuda a la detección temprana de incidentes, llegando incluso a evitar que éstos se manifiesten a los usuarios.

• Además, la coordinación directa con otros procesos hace posible que éstos reaccionen con mayor rapidez, resultando en una mayor eficiencia de toda la organización TI.

• Posibilita la monitorización automatizada de determinadas actividades. Es más barata que una monitorización en tiempo real y disminuye considerablemente el periodo de inactividad del servicio que media entre la aparición del incidente y su resolución definitiva.

• Proporciona la base para las operaciones automatizadas, que incrementan la eficiencia y descargan de trabajo a los recursos humanos que, así, pueden ser empleados en otras tareas como diseñar nuevas funcionalidades, etc.

Entre los principales desafíos que pueden obstaculizar la labor de la Gestión de Eventos encontramos:


 

• Dificultades en la obtención de fondos para contratar las herramientas necesarias y el esfuerzo necesario para configurarlas y explotar sus beneficios.

• Los niveles de filtrado no son adecuados, bien por exceso (se gestionan eventos sin impacto real en el servicio) o por defecto (algunos eventos de importancia no se detectan hasta que es demasiado tarde).

• No existe suficiente compromiso con la Gestión de Eventos en otros procesos del ciclo de vida, ocasionando retrasos en la repuesta a los eventos.

• Adquirir las habilidades necesarias exige tiempo y dinero.

Las actividades de la Gestión de Eventos son:

 

• Aparición de eventos. El proceso se inicia cuando ocurre el suceso, ya sea detectado o no.

• Notificación de eventos. El evento es notificado al equipo o responsable de gestión.

• Detección y filtrado de eventos. La notificación llega a un agente o herramienta de gestión que la lee e interpreta el suceso con el fin de determinar si merece mayor atención o no.

• Clasificación de eventos. Se le asigna una categoría y un nivel de prioridad.

• Correlación. Se analiza si existen eventos similares, así como la importancia del evento en sí mismo y se decide si es necesario tomar medidas.

• Disparadores. Se ponen en marcha los mecanismos necesarios para dar respuesta al evento.

• Opciones de respuesta. Se eligen las soluciones a adoptar.

• Revisión de acciones y cierre. Se revisan las excepciones o eventos importantes para determinar si se han tratado correctamente. Se cierra el proceso de Gestión de Eventos.

El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Eventos:




























Aparición de eventos.

 

El flujo de trabajo del proceso de Gestión de Eventos se inicia cuando aparece un evento. Los eventos ocurren continuamente, pero no todos son detectados o registrados.

Por ello, es importante que todos los implicados en el diseño, desarrollo, gestión y soporte de los servicios IT y la infraestructura IT comprendan cuáles son los eventos que es preciso detectar.


 

Notificación de eventos.

 

La mayoría de los elementos de configuración (CIs) son diseñados para comunicar información sobre sí mismos de las siguientes formas:

 

• Una herramienta de gestión demanda periódicamente determinados datos a un dispositivo del CI.

• El propio CI genera un informe al darse unas determinadas condiciones definidas previamente.

Las notificaciones de eventos pueden estar registradas en un formato propietario, aunque la mayoría de los CIs emplean el estándar SNMP (Simple Network Management Protocol).

En general, cuanta más información acerca del evento quede recogida en la notificación, y cuanto mejor se determine el destinatario de dicha información, más fácil resultará tomar decisiones respecto al mismo. A menudo, se registran mensajes de error codificados y el personal encargado de resolver los problemas no alcanza a comprender su significado completo.

Si los roles y responsabilidades no han sido bien definidos desde la fase de Diseño, es muy probable que cuando se presente un evento que requiera una respuesta, nadie sepa quién está haciendo qué. En tal caso, hay que redactar una RFC.

Detección y filtrado de eventos.

Una vez generada la notificación, ésta llega a su destinatario, que puede ser un agente que trabaje sobre el sistema o bien una herramienta de gestión diseñada específicamente para recibir los datos relacionados con el evento e interpretarlos.

El filtrado consiste en decidir si el suceso merece una consideración en profundidad por parte de otra unidad de gestión o si por el contrario, una vez leído puede ser ignorado. Por ejemplo, cuando se trata de un grupo de notificaciones relacionadas que se emiten de forma seriada, es habitual optar por transmitir sólo la primera.

En otros CIs, en cambio, todos los eventos son significativos y se trasladan directamente a un sistema de correlación automatizado, incluso aunque la notificación esté duplicada.

Clasificación de eventos.

No todos los eventos son iguales ya que no tienen la misma importancia para el servicio ni la infraestructura TI y por tanto, no deben tratarse de la misma manera.

La mejor manera de asignar distintas prioridades a cada evento, pero que al mismo tiempo guarden cierta coherencia, es confeccionar una clasificación de eventos. Lo más habitual es que cada organización TI disponga de su propia categorización, ya que es lo más eficaz. Sin embargo, existen tres categorías que no pueden faltar:

 

• Informativo. Se asigna a aquellos eventos que no requieren, en principio, ninguna respuesta y que por tanto no representan una excepción.

• Alerta. Se asigna a aquellos eventos que indican que el servicio se aproxima a un umbral. Su objetivo es notificar a las personas, herramientas o procesos apropiados para que revisen la situación y tomen las medidas necesarias para evitar que se produzca una excepción.

• Excepción. Se asigna a los eventos cuando indican que el servicio está operando de manera irregular: los SLAs y OLAs se han incumplido, etc. Las excepciones pueden representar un fallo total, un cese en una funcionalidad o una disminución del rendimiento. Sin embargo, no tienen por qué ser errores.

Correlación.

La Correlación consiste en dimensionar la importancia del evento y, si se diera el caso, establecer conexiones con otros eventos relacionados para ahorrar tiempo. La importancia y significado del evento en sí mismo depende de los siguientes factores:

 

• Número de eventos similares registrados con anterioridad.

• Número de elementos de configuración (CIs) que generan eventos similares.

• Si existe alguna acción asociada al evento.

• Si el evento representa una excepción.

• Comparación de la cantidad de información utilizada en el evento respecto a un estándar.

• Si se requieren datos adicionales para investigar el evento con posterioridad o incluso datos procedentes de otros sistemas de información.

• Categorización asignada al evento.

• Nivel de prioridad asignado al evento.

Disparadores.

Una vez que la Correlación ha reconocido la importancia de un evento, es preciso poner en marcha los mecanismos pertinentes para que se produzca una respuesta desde dentro de la organización TI. A este mecanismo, que sirve como desencadenante de una tarea o serie de tareas, lo denominamos “disparador”.

Existen varios tipos de disparadores:

 

• Disparadores de Incidentes. Crean un registro en el Sistema de Gestión de Incidencias, generando un input para este proceso de la fase de Operación.

• Disparadores de Cambios. Generan una solicitud de cambio (RFC) y enviándola a la Gestión de Cambios, en la fase de Transición.

• Disparadores procedentes de una RFC aprobada o desautorizada. Se envía toda la información relacionada para que la Gestión de Cambios investigue lo ocurrido.

• Scripts automatizados que ejecutan acciones específicas (p. ej. reiniciar un equipo).

• Notificaciones por teléfono móvil.

• Disparadores de base de datos, que restringen el acceso de un usuario a determinados registros o campos, o que crean/eliminan entradas en la base de datos.

Opciones de respuesta.

Existen numerosas respuestas posibles a la hora de actuar frente a un evento. Entre las más comunes están:

 

• Registro de eventos. Independientemente de las acciones que se lleven a cabo, se documenta lo ocurrido.

• Respuesta automática. En algunos casos, se pueden programar respuestas automáticas a determinados eventos que la organización TI conoce en profundidad. Por ejemplo: reiniciar un dispositivo, cambiar un parámetro, bloquear una aplicación para evitar accesos no autorizados, etc.

• Alerta e intervención humana. La alerta tiene como objeto advertir e informar a la persona más cualificada para que desempeñe una acción específica, probablemente en un tiempo determinado y en un dispositivo concreto.

• Emisión de una solicitud de cambio (RFC). Las solicitudes de cambio pueden crearse en cuanto ocurre la excepción o en el momento en que la actividad de Correlación concluye que es necesario hacer cambios.

• Apertura de un registro de incidencia. Al igual que con la RFC, el registro de incidencias puede efectuarse en cuanto se detecta la excepción o cuando la Correlación lo considera necesario.

• Apertura de un vínculo a un registro de problema. Los problemas suelen estar asociados a uno o más incidentes. Esto ayuda al equipo encargado de la Gestión de Problemas para determinar el impacto y la severidad del problema.

Estas respuestas no tienen por qué darse de manera aislada, es decir, que la organización puede combinar dos o más de ellas para ofrecer una solución más completa al evento.

Puede presentarse el caso de un evento que representa una excepción pero que no tiene un impacto directo en el servicio. Se trata de incidentes especiales en los que el registro debe hacerse de acuerdo a un Modelo de Incidentes, pero que no tienen ninguna influencia en el rendimiento al no ocasionar interrupciones del servicio.

Revisión de acciones y cierre.

Antes de dar por terminado el proceso de Gestión de Eventos, es preciso revisar todas las excepciones o eventos importantes para garantizar que se han tratado correctamente.

Control del proceso.

A la hora de evaluar la eficiencia y efectividad del proceso de Gestión de Eventos deben verificarse los siguientes indicadores:


 

• Número de eventos, por categorías.

• Número de eventos, por importancia.

• Número y porcentaje de eventos que requirieron de intervención humana y cómo fue esa intervención.

• Número y porcentaje de eventos que desembocaron en el registro de una nueva incidencia o solicitud de cambio.

• Número y porcentaje de eventos ocasionados por problemas ya existentes o errores conocidos.

• Número y porcentaje de eventos repetidos o duplicados. Esto es relevante para optimizar la función de Correlación.

• Número y porcentaje de eventos relacionados con problemas de rendimiento.

• Número y porcentaje de eventos que indican futuros problemas de disponibilidad.

• Número y porcentaje de cada tipo de evento, por plataforma o aplicación.

• Número y ratio de eventos por comparación al número de incidentes.