La planificación de las fases de la Gestión de incidentes

El tiempo de inactividad puede afectar a cualquier sistema en cualquier momento y estos incidentes suelen representar altos costes para las empresas que lo sufren. Por esta misma razón, es necesario contar con un plan de gestión de incidentes y saber cómo enfocarlo, y es precisamente de lo que hablaremos en esta publicación. Te contaremos cada paso que debe contemplar este plan y algunos consejos que deberías considerar entre las distintas fases de este tipo de gestión en entornos tecnológicos.

Una gestión eficaz de las incidentes permite que los sistemas de las empresas funcionen de forma estable y sin caídas. Ten en cuenta, en la medida que una empresa crezca y las herramientas de software irán creciendo en complejidad, y las vulnerabilidades de las herramientas serán mayores, por lo que el impacto negativo de estas caídas serán aún mayores en lo referente a las operaciones de la empresa a nivel de negocio.

Debido a la gravedad que pueden representar estos impactos, las empresas están evolucionando rápidamente en las prácticas de la gestión de incidentes para asegurarse de que cualquier eventualidad pueda ser subsanada de forma rápida y eficaz.

Al tener un enfoque más general y holístico del proceso de gestión de incidentes y comprender cómo evolucionan, permite ajustar las soluciones dependiendo de la fase del flujo de trabajo en el que se encuentre la incidencia.

Fases comúnes en el proceso de resolución de una incidencia

Aunque estas estapas varían de empresa a empresa, hemos resumido cinco fases que suelen enfrentar las empresas durante el proceso de resolución de una incididencia, y además, te ofreceremos algunos consejos a tomar en cuenta durante cada una de estas fases.

Las fases del ciclo de vida de resolución de una incidencia que hemos determinado, son: preparación, detección y alertas, contención, reparación, y análisis. Tener identificadas estas fases, permite a las empresas gestionarse de forma adecuada y evitar retrasos, y costes asociados:

1. Preparación

La preparación es esencial para todo, y en esta fase dentro de la gestión de incidentes permite al equipo explorar los distintos escenarios que podrían ocurrir, las posibles consecuencias y como consecuencia, explorar qué prácticas suelen ser las más adecuadas para abordarlos. El objetivo es crear una capacidad de respuesta que permita una reacción más rápida ante las incidencias.

Consejos:

1. Ten preparado un kit de emergencias. Este kit debe contener información de importancia preparada para que los equipos puedan responder de forma rápida. Tener esta información centralizada permite reducir los tiempos de respuesta evitando complejidades en la cadena de mando.
   
   
2. No huyas de los manuales. Los manuales son guías que delinean qué pasos deben seguir los miembros del equipo sobre un escenario específico, en especial para aquellos equipos que trabajan en horarios rotativos o dependen de un superior que no siempre está dispobible. Contar con un manual ofrece la ventaja de acelerar los tiempos de respuesta y, además, permite construir una base de conocimientos que apoya la mejora continua de las prácticas de respuesta a incidencias.
   
   
3. Acepta el caos y promueve la estabilidad. La Ingeniería del caos es la práctica que permite experimentar intorduciendo fallos de forma controlada, esto permite entender cuál puede ser el comportamiento en determinadas situaciones y, como consecuencia, permite construir sistemas más robustos. 

2. Detección y alertas

El proceso de detección de incidentes no consiste solamente descubrir cuándo algo va mal, sino también la forma en la que se notifica al equipo sobre estos incidentes, y aunque parezcan procesos separados, están muy conectados, ya que uno va seguido del otro.

Consejos:

1. Evita los falsos positivos. Muchas herramientas de supervisión de sistemas de TI ayudan a detectar posibles anomalías e incidentes, sin embargo, también pueden crear falsos positivos que complican el proceso de respuesta. Para solucionarlo, algunos equipos añaden una capa al proceso de monitorización para garantizar la calidad de estas alertas y así evitar ese aluvión de alertas o falsos positivos.
   
   
2. Piense fuera del NOC. Los Centros de operaciones de red o Network Opertation Center (NOC) históricamente han actuado como centro de supervisión y alerta de las herramientas de software de grandes empresas de los que generalmente se encuentra un ingeniero dedicado a ello. En contraparte, algunas herramientas que ayudan en la Gestión de peticiones e incidencias pueden ayudar a crear mayor independecia de esta figura, y además, automatizar flujos de trabajo, de esta forma se estará evitando errores humanos y saltar las posibles confusiones que puedan generar los cambios horario de los equipos, y a su vez, ajustándose a las políticas de escalado del software de empresa.
   
   
3. Canaliza y centra la atención de los equipos. No hay nada peor que recibir un aluvión de alertas desde distintos canales; al centralizar el flujo de las alertas a través de una única herramienta, los equipos podrán filtrar y priorizar el trabajo de forma efectiva.
   
   
4. El contexto lo es todo. Una alerta informa sobre algo que va mal, sin embargo, no siempre expresa qué, provocando retrasos innecesarios. Esto provoca que los equipos deben investigar y determinar la causa. En cambio, al asociar estas alertas con los detalles técnicos de por qué ha ocurrido, el proceso de solución avanzará de forma más rápida y sencilla.

3. Contención

Realizar un triaje sobre una incidencia informática conlleva varios pasos, primero es necesario identificar el alcance de la incidencia, después es necesario contenerla para evitar que la situación escale y empeore. El proceso de resolución es una fase posterior. Sin embargo, todas las acciones en esta fase deben centrarse en limitar y evitar que se produzcan más daños.

Consejos:

1. Foco en lo importante. La atención debe centrarse en las acciones a corto plazo que estabilicen la evolución de una incidencia. Es el primer objetivo en esta fase (aislar una red, rehacer un código, reiniciar servidores, etc.) y permitirá que los sistemas vuelvan a funcionar. Si los esfuerzos de gestión de incidentes se centran en la reparación, y no en la contención, la resolución de una incidencia sobre una interrupción se prolongara innecesariamente.
   
   
2. En equipo todo es mejor. Colaborar en la resolución de las incidencias en equipo, permite resolverlas de forma más rápida, por lo que en esta fase las herramientas de chat y videollamadas se convierten en elementos esenciales en la gestión de incidentes, ya que permite la colaboración en tiempo real de equipos remotos. Imagina las posibilidades si tu herramienta de gestión de alertas e incidencias tiene capacidades de integración con herramientas de comunicación.
   
   
3. La transparencia es clave, siempre. Si los usuarios de tus productos o servicios llegan a enfrentar interrupciones en el producto/servicio, es habitual que el incidente se haga público en poco tiempo, para adelantarse a estas situaciones, es necesario que los equipos tengan un plan de comunicación de incidentes a mano con el objetivo de generar confianza, reconociendo públicamente la interrupción, asegurando que se están tomando las medidas para resolverla. Integrar herramientas como Twitter, StatusPage y los foros de usuarios especializados son clave para comunicarlo.

4. Reparación

La reparación está estrechamente vinculada a la fase de contención. En esta fase se implementan las soluciones que van a perdurar en el tiempo y que garantizan que el incidente se ha abordado de forma completa y eficaz, cerrando su ciclo. A diferencia de la fase de contención, el objetivo aquí es el de comprender la causa del problema y corregirlo para evitar que incidentes similares se produzcan en el futuro.

Consejos:

1. El marco de trabajo Cynefin. Es un marco de toma de decisiones que ofrece una forma estructurada de abordar los problemas y ayuda a los responsables de la respuesta a incidencias a determinar el mejor curso de acción en función de la naturaleza del propio problema (La Matriz de priorización es otra). Dependiendo del tipo de incidente (simple, complejo, complicado, caótico), se puede definir un enfoque para resolverlo respondiendo las siguientes preguntas:
   1. ¿La incidencia tiene una causa y solución conocidas?
   2. ¿Es necesario involucrar a otras personas para resolver la incidencia?
   3. ¿Hay tiempo suficiente para identificar la mejor respuesta posible, o la situación requiere una acción inmediata?
      
      
2. La automatización es clave. Las herramientas de chat han ayudado a mejorar la comunicación y la colaboración en las empresas, ofreciendo soluciones que van más allá del envío y recepción de mensajes. Por ejemplo, el equipo de desarrollo de software de GitHub implementó Hubot, un bot que permite activar acciones y scripts directamente desde un chat, esto ha permitido al equipo de resolución de incidentes a ahorrar tiempo, y en este caso, sentar un precedente para simplificar operaciones utilizando bots

5. Análisis

Una vez que se ha alcanzado la resolución definitiva de una incidencia, no significa que se ha llegado al final del ciclo de vida de la misma, ya que la realización de un análisis "postmortem" permite comprender las causas que han generado el problema y qué pasos han permitido ofrecer una respuesta adecuada. A partir de aquí, se identificarán oportunidades de mejora y así desarrollar nuevos flujos de trabajo que permitan ofrecer un sistema más robusto y procesos de respuesta más veloces.

Consejos:

1. Aprender de los fallos. Aprender de todo tipo de errores, desde los más sencillos a los más importantes puede tener un impacto considerable en la mejora del rendimiento de los sistemas y en el servicio de respuesta a las incidencias. Si bien es cierto que en algunas situaciones no sea necesario crear un informe postmortem, siempre debería hacerse una breve revisión de lo que ha ocurrido, de este modo, se evitará que el problema persista en el futuro, además, se alimentará la base de conocimientos y favorecerá a la mejora continua del equipo.
   
   
2. No existe una única causa raíz. Nombrar una única causa raíz de un incidente suele ser poco común, y si es así, según el modelo Cynefin, entraría en una categoría de un incidente simple. A menudo los sistemas son demasiado complejos y estás muy conectados entre sí, por lo que es difícil definir una única causa.
   
   
3. No culpar a nadie. El objetivo de llevar a cabo estos análisis es el de entender qué ha ido mal y cómo evitarlos en el futuro. Es importante evitar señalar a las personas para omitir las emociones de la ecuación, lo que puede entorpecer realizar un análisis objetivo de lo ocurrido.

Como puedes ver, la gestión de incidentes, desde el punto de vista del equipo de TI, va más allá de simples respuestas antes cualquier problema de informática que un usuario pueda estar visualizando, por lo que es importante tener un plan a seguir que soporte esta forma de actuar, y mejor aún, de mejorar en la medida que el tiempo avance. 

Si estás buscando una solución que reúna cada una de estas características y que se integre de forma sencilla con la solución de software que de ITSM que utilices, deberías conocer un poco más sobre Opsgenie, una herramienta de Atlassian que ayuda a los equipos a gestionar los incidentes de forma efectiva. Como una empresa certifiicada ITSM por Atlassian, tenemos el conocimiento de causa que nos permite aconsejarte sobre las mejores prácticas en el ámbito de la Gestión de servicios, de todo tipo, y para cualquier equipo. Además, si estás buscando mayor orientación, no dudes en acercarte a nosotros, te podemos guiar a encontrar la solución que mejor se adapte a tus necesidades y presupuesto.