El manejo de incidentes se puede implementar de manera escalada, consiguiendo cada vez una mejor gestión y reportes más exactos de los eventos. Progresar en la implementación de los siguientes escenarios permitirá seguir, de manera eficiente y en gran parte automatizada, las mejores prácticas definidas por ITIL. Además, al automatizar el proceso, eliminamos el riesgo de que la información registrada dependa de la persona que ingresó el ticket. En este post quedarán 5 escenarios, pero aún quedando bastante margen para seguir mejorando el proceso.
Escenario 1
- Usuario llama a mesa de ayuda o le envía un correo, donde el analista de service desk genera un ticket de tipo “Incidente”.
- El sistema envía un correo automático al usuario con el número de ticket creado.
- Agente revisa si ya existía un ticket de tipo “Incidente” para el reporte. Si ya existía, asocia el nuevo ticket con el ya existente.
- Resolutor (analista de primera, segunda o tercera línea) toma el o los tickets de tipo “Incidente”.
- Al resolver el ticket, se resuelven manualmente todos los tickets de tipo “Incidente” asociados y se notifica automáticamente a los usuarios.
Problemas principales:
- La mayor parte del proceso es manual, por lo que los tiempos de inicio y fin de incidente no son confiables y deben ser ajustados posteriormente en base a diversos criterios (revisando monitoreos, logs, emails, etc).
- Pueden quedar registrados múltiples tickets para un mismo incidente (varios usuarios reportando el mismo problema), lo que dificulta el cálculo de SLA por servicio.
Posibles mejoras:
- Permitir que el envío de correo a una casilla de email genere automáticamente un Reporte de Incidente.
- Dividir los tickets en dos “colas”: una para “Incidente” y otra para “Reporte de Incidente”. De esta manera cada ticket en la cola "Incidente" representará a un incidente en particular y puede tener asociados varios "Reporte de Incidente" de usuarios distintos.
Escenario 2
- Usuario envía correo a mesa de ayuda, donde se genera automáticamente un ticket de tipo “Reporte de Incidente”. Alternativamente, usuario crea el ticket de tipo “Reporte de Incidente” ingresando a la opción de autoatención del sistema. Se mantiene opción de ingresar un reporte de incidente llamando al Service Desk.
- El sistema envía un correo automático al usuario con el número de ticket creado.
- Agente revisa si ya existe un ticket de tipo “Incidente” para el reporte. Si ya existe, le asocia el nuevo ticket. Si no existe, crea un nuevo ticket de tipo “Incidente” a partir del “Reporte de Incidente”.
- Resolutor toma el ticket de tipo “Incidente”.
- Al resolver el ticket de tipo "Incidente", se resuelven automáticamente todos los tickets de tipo “Reporte de Incidente” y se notifica automáticamente a los usuarios.
Problemas principales:
- Manejo reactivo de incidentes: depende del reporte de un usuario.
- Las horas de inicio y fin del incidente no son confiables, ya que el inicio depende del reporte del usuario (o del agente que detectó el problema a través de algún monitoreo) y el fin del incidente es según lo reportado por el agente, pero sujeto a validación por parte del usuario.
- Implementar monitoreo que genere tickets de tipo Incidente automáticamente al detectar una falla en la plataforma.
Escenario 3
- Monitoreo detecta falla en un componente.
- Monitoreo genera una alerta que gatilla la generación automática de un ticket de tipo “Incidente”.
- Resolutor toma el ticket de tipo “Incidente”.
- Usuario se contacta con mesa de ayuda para generar un ticket de tipo “Reporte de Incidente” (teléfono, mail, autoatención).
- El sistema envía un correo automático al usuario con el número de ticket creado.
- Al resolver el ticket de tipo Incidente, se resuelven automáticamente todos los tickets de tipo “Incident Report” y se notifica automáticamente a los usuarios.
Problemas Principales:
- Se mezclan incidentes de infraestructura (por ejemplo, servidor caído) con incidentes de negocio (por ejemplo, página web caída). La caída de un servidor podría no implicar la caída de un servicio de negocio, por lo que se dificulta la extracción de estadísticas para SLA diferenciando entre negocio e infraestructura.
- La resolución de un incidente aún queda sujeta a validación, por lo que podría ser necesario ajustar la hora de resolución para tener estadísticas “reales”.
Posibles mejoras:
- Separar los incidentes de infraestructura y de negocio en dos “colas” distintas (o agregar campo al ticket para diferenciarlos).
- Configurar el monitoreo de manera que al limpiarse una alerta, se cierre el ticket asociado automáticamente.
Escenario 4
- Monitoreo detecta falla en un componente de infraestructura. Se genera alerta que gatilla la generación automática de un ticket de tipo “Incidente de Infraestructura”.
- Monitoreo detecta falla en un servicio de negocio. Se genera alerta que gatilla la generación automática de un ticket de tipo “Incidente de Servicio”.
- Resolutor toma el ticket de tipo “Incidente de Infraestructura”.
- Usuario se contacta con mesa de ayuda para generar un ticket de tipo “Reporte de Incidente” (teléfono, mail, autoatención) por el problema con el servicio de negocio. Es asociado al ticket de Incidente de Servicio.
- El sistema envía un correo automático al usuario con el número de ticket creado.
- Resolutor resuelve el incidente. No le cambia estado al ticket en software de Service Desk.
- Monitoreos detectan recuperación de infraestructura y servicio de negocio.
- Monitoreos gatillan el cierre de los ticket de tipo “Incidente de Servicio/Infraestructura” asociados.
- Al resolver el ticket, se resuelven automáticamente todos los tickets de tipo “Reporte de Incidente” y se notifica automáticamente a los usuarios.
- Con la información de la investigación del incidente, se deben asociar los Incidentes de Servicio y de Infraestructura correspondientes (tarea manual).
Se pueden dar situaciones en que se gatille un incidente de infraestructura sin un incidente de servicio de negocio (por ejemplo, caída de un nodo de un cluster en alta disponibilidad que no afecte al servicio) o al revés (caída de un servicio producto de un bug en el software que no provoca caída de componentes de infraestructura).
Problemas principales:
- Se pueden generar tickets duplicados si el sistema de tickets crea un ticket por cada correo de alarma que recibe y el monitoreo envía correos de alerta en períodos regulares para alarmas activas.
- Los datos del incidente (categoría, urgencia, impacto, etc) quedan sujetos al criterio del agente que ingresa el ticket, por lo que deben ser constantemente validados para velar por la confiabilidad de los datos registrados.
- No existe un método fácil de realizar seguimiento a los tickets para priorizarlos y actuar en caso de peligrar el cumplimiento del SLA.
Posibles mejoras:
- Para el problema de tickets duplicados hay dos alternativas al menos:
- Configurar monitoreo para que solo envíe un correo por cada alarma que se gatille.
- Configurar el sistema de tickets para que si recibe tickets duplicados, los descarte y solo mantenga el original.
- Configurar el sistema de tickets para que obtenga los campos del contenido del correo de alarma del sistema de monitoreo.
- Se debe configurar el software de Service Desk para manejar SLA y prioridades y escalar automáticamente en caso de ser necesario. La prioridad se debe fijar automáticamente en base a la información del punto anterior.
Escenario 5
- Monitoreo detecta falla en un componente de infraestructura. Se genera alerta que gatilla la generación automática de un ticket de tipo “Incidente de Infraestructura”. Los detalles del incidente son llenados automáticamente y con ello se fija la prioridad del ticket y su SLA.
- Monitoreo detecta falla en un servicio de negocio. Se genera alerta que gatilla la generación automática de un ticket de tipo “Incidente de Servicio”. Los detalles del incidente son llenados automáticamente y con ello se fija la prioridad del ticket y su SLA.
- Resolutor toma el ticket de tipo “Incidente de Infraestructura”.
- Usuario se contacta con mesa de ayuda para generar un ticket de tipo “Reporte de Incidente” (teléfono, mail, autoatención) por el problema con el servicio de negocio. Es asociado al ticket de Incidente de Servicio.
- El sistema envía un correo automático al usuario con el número de ticket creado.
- Si se corre riesgo de no cumplir SLA para el servicio afectado, se gatillan los escalamientos correspondientes.
- Resolutor resuelve el incidente. No le cambia estado en software de Service Desk.
- Monitoreos detectan recuperación de infraestructura y servicio de negocio.
- Monitoreos gatillan el cierre de los ticket de tipo “Incidente de Servicio/Infraestructura” asociados.
- Al resolver el ticket, se resuelven automáticamente todos los tickets de tipo “Reporte de Incidente” y se notifica automáticamente a los usuarios.
- Con la información de la investigación del incidente, se deben asociar los Incidentes de Servicio y de Infraestructura correspondientes (tarea manual).
Posibles problemas:
- Se puede dar la situación en que un usuario reporta un incidente que no fue detectado por el monitoreo, por lo que se debe registrar el “Incidente de Servicio” manualmente.
- El monitoreo puede generar alertas preventivas en caso de que alguna métrica supere un umbral (uso de disco, por ejemplo), lo que generará incidentes por eventos que no implican interrupción del servicio.
Posibles mejoras:
- Si un incidente no es detectado por el monitoreo, se debe implementar el monitor correspondiente.
- Implementar una nueva cola para tickets de eventos, donde queden registradas las alarmas preventivas. Esta cola se puede usar para todo tipo de eventos (ver documentación ITIL).
Escenario 6...
Se pueden seguir implementando mejoras al proceso, pero en este punto ya contaríamos con un sistema que nos entrega información creíble de los incidentes y la gestión que se realiza de ellos. Algunos ejemplos de mejoras:
- En paralelo a la generación del ticket se puede automatizar la actualización de una página de "estado de servicios". De esta manera, los usuarios pueden consultar esta página antes de ingresar un Reporte de Incidente. En la página de autoatención y en los correos que envía el service desk a los usuarios, se puede agregar un link a la página de estados de servicios.
- El monitoreo, al generar el ticket, completa datos de CI afectado. Para ello, se debe enganchar el Service Desk con la CMDB (o implementar la CMDB en el mismo software de Service Desk).
- Crear ticket de Problemas en base a los tickets de Incidentes. Como ya tenemos información de nuestros incidentes, además de el análisis manual de los incidentes, se pueden generar reglas que gatillen el inicio del proceso de gestión de problemas. Por ejemplo, si un CI tiene 3 incidentes en una semana, se genera automáticamente un problema.
- Integrar este proceso con la gestión del cambio. El proceso de gestión del cambio podría contar con otra cola de tickets en el mismo software de Service Desk.
- Integrar el proceso de gestión de incidentes con la base de datos de errores conocidos. La KEDB podría estar integrada en el mismo software de Service Desk.
Post Mortem
Al cerrar un incidente se debe validar que esté bien documentado: que el valor de los campos sean correctos y que esté documentada la forma de resolución. Esto se debe realizar manualmente revisando todos los tickets creados de forma manual y auditando periódicamente los tickets creados de forma automática.Es importante clasificar los incidentes para posterior categorización y extracción de estadísticas. Por ejemplo, se puede registrar:
- El riesgo estaba identificado?
- Causó interrupción del negocio?
- Causó pérdida financiera?
- Fue incidente de seguridad?
- Fue un incidente de disponibilidad?
- Fue un incidente de acceso no autorizado a información?
- Hubo exposición pública?
- Fue producto de un error de integración? (paso a producción?)
- Fue por indisponibilidad de acceso a información?
- Fue por no cumplimiento de políticas y/o procedimientos?
- Fue por evasión de políticas y/o procedimientos? (excepción autorizada).
- Severidad.
