¿Qué es la gestión de incidentes?

La gestión de incidentes es el proceso que utilizan los equipos de desarrollo y operaciones de TI para responder a un evento o a una interrupción del servicio no planificados y restaurar el servicio a su estado operativo.

En Atlassian, un incidente es un evento que causa una interrupción del servicio o una reducción en la calidad de este y que requiere una respuesta de emergencia. Los equipos que siguen las prácticas de ITIL o ITSM pueden usar el término "incidente grave" en su lugar.

Incidents are events of any kind that disrupt or reduce the quality of service (or threaten to do so). A business application going down is an incident. A crawling-but-not-yet-dead web server can be an incident, too. It’s running slowly and interfering with productivity. Worse yet, it poses the even-greater risk of complete failure. Incidents can vary widely in severity, ranging from an entire global web service crashing to a small number of users having intermittent errors. An incident is resolved when the affected service resumes functioning in its intended state. This includes only those tasks required to mitigate impact and restore functionality.

La gestión de incidentes es uno de los procesos más críticos que una organización debe ejecutar a la perfección. Las interrupciones del servicio pueden resultar costosas para la empresa y los equipos necesitan una forma eficiente de responder ante estas incidencias y resolverlas con celeridad. Los equipos precisan un método fiable para priorizar los incidentes, resolverlos más rápido y prestar un mejor servicio a los usuarios.

Cuando los equipos se enfrentan a un incidente, necesitan un plan que les ayude a lo siguiente:

• Responder con eficacia para recuperarse rápidamente.
• Comunicarse de forma clara con sus clientes, las partes interesadas, los propietarios de servicios y otros miembros de la organización.
• Colaborar de manera eficaz para resolver la incidencia más rápido en equipo y eliminar las barreras que les impiden hacerlo.
• Mejorar continuamente para aprender de estas interrupciones y aplicar los conocimientos adquiridos para mejorar un servicio y perfeccionar su proceso de cara al futuro.

Cada clase de empresa tiende a inclinarse hacia un tipo diferente de proceso de gestión de incidentes. No hay ningún proceso que sea el mejor para todas las empresas, por lo que es probable que cada una use distintos enfoques.

Muchos equipos utilizan un proceso de gestión de incidentes más tradicional, basado en TI, como los descritos en las certificaciones ITIL. Otros equipos prefieren un proceso de gestión de incidentes basado en DevOps o la ingeniería de fiabilidad de sitios (SRE).

Un proceso de gestión de incidentes ayuda a los equipos de TI a investigar, registrar y resolver las interrupciones del servicio. El flujo de trabajo de gestión de incidentes de ITIL tiene por objetivo reducir el tiempo de inactividad y minimizar el impacto de los incidentes en la productividad de los empleados. Al usar plantillas diseñadas para gestionar incidentes, puedes crear un flujo de trabajo de gestión de incidentes repetible con el que te asegurarás de que los equipos registren, diagnostiquen y resuelvan los incidentes y mantengan un registro de sus actividades.

El marco de trabajo ITIL se utiliza principalmente en equipos de TI que gestionan servicios dentro de las empresas. Por lo general, los equipos implementan lo que necesitan del marco ITIL, que abarca casi todos los tipos de incidentes, incidencias y procesos a los que se tiene que enfrentar el departamento de TI, y descartan el resto. ITIL es excelente cuando los equipos necesitan centrarse en fomentar una cultura de resolución activa de problemas. Los procesos establecidos ayudan a los equipos a realizar un seguimiento integral de los incidentes y las acciones, lo que mejora los informes y el análisis y puede llevar a un mejor funcionamiento del servicio y a un equipo más exitoso.

Los incidentes pueden tener muchas procedencias: empleados, clientes, proveedores, sistemas de supervisión, etc. Sea cual sea el origen, los dos primeros pasos son sencillos: alguien identifica un incidente y alguien lo registra. Para registrar incidentes (o, lo que es lo mismo, para crear tickets), lo habitual es tener que introducir estos datos:

• El nombre de la persona que notifica el incidente
• La fecha y la hora en las que se notifica el incidente
• Una descripción del incidente (lo que está inactivo o no funciona correctamente)
• Un número de identificación único asignado al incidente, para el seguimiento

Asigna a cada incidente una categoría lógica e intuitiva (y una subcategoría, según sea necesario). De este modo, te será más fácil analizar los datos y buscar tendencias y patrones, algo esencial para la gestión eficaz de problemas y la prevención de incidentes futuros.

Hay que asignar una prioridad a todos los incidentes. Para empezar, evalúa su impacto en el negocio, el número de personas que se verán afectadas, los SLA aplicables y las posibles implicaciones financieras, de seguridad y de cumplimiento. Compara este incidente con todos los demás incidentes abiertos para determinar su prioridad. Como práctica recomendada, define los niveles de gravedad y prioridad antes de que el incidente llegue a ocurrir, para que los gestores de incidentes puedan determinar la prioridad de forma fácil y rápida. 

• Diagnóstico inicial: lo ideal es que tu equipo de soporte de primera línea pueda ver un incidente desde el diagnóstico hasta el cierre, pero si no puede, habrá que registrar toda la información pertinente y derivarlo al equipo del siguiente nivel.
• Derivación: el equipo del siguiente nivel toma los datos registrados y continúa con el proceso de diagnóstico. Si no puede diagnosticar el incidente, se deriva al siguiente equipo.
• Comunicación: el equipo comparte actualizaciones con las partes interesadas internas y externas afectadas de forma periódica.
• Investigación y diagnóstico: este proceso se extiende hasta que se identifique la naturaleza del incidente. A veces, los equipos incorporan recursos externos o miembros de otros departamentos para consultarles y que les ayuden en la resolución.
• Resolución y recuperación: en este paso, el equipo llega a un diagnóstico y toma las medidas necesarias para resolver el incidente. La recuperación no es más que la cantidad de tiempo que pueden tardar las operaciones en restaurarse por completo, ya que para algunas correcciones (como parches de errores, etc.) puede resultar necesario realizar pruebas e implementaciones incluso después de que se haya identificado la solución adecuada.
• Cierre: si el incidente se ha derivado, una vez resuelto se vuelve a enviar al centro de asistencia para que lo cierre. A fin de mantener la calidad y garantizar un proceso fluido, solo los empleados del centro de asistencia pueden cerrar los incidentes, y el propietario del incidente debe ponerse en contacto con la persona que lo notificó para confirmar que se ha resuelto correctamente y puede cerrarse.

Con un enfoque de DevOps o SRE para la gestión de incidentes, el equipo que crea el servicio también lo ejecuta y soluciona los posibles problemas que puedan surgir. Este enfoque ha adquirido una gran popularidad junto con el crecimiento de los servicios en la nube siempre disponibles, las aplicaciones web de acceso global, los microservicios y el software como servicio.

Cada vez es menos habitual que el software que utilizas en tu vida personal y profesional se aloje en un servidor situado en tu misma ubicación física. Es probable que se trate de una aplicación a la que se accede desde la web implementada en un centro de datos para miles o millones de usuarios de todo el mundo. Para los equipos encargados de ejecutar estos servicios, la agilidad y la velocidad son primordiales. Cada vez que se produce un tiempo de inactividad, puede afectar a miles de organizaciones, no solo a una.

Una ventaja del enfoque "tú lo creas, tú lo gestionas" es que ofrece la flexibilidad que necesitan los equipos de metodología ágil, pero también puede provocar que se desconozca de qué tarea debe encargarse cada persona y cuándo debe hacerlo. Los equipos de DevOps pueden sentirse cómodos (y tener éxito) con procesos de desarrollo menos estructurados. Pero lo mejor es estandarizar un conjunto básico de procesos para la gestión de incidentes a fin de que no haya dudas sobre cómo responder en caso de que se produzca un incidente y poder así hacer un seguimiento de las incidencias e informar sobre cómo se han resuelto.

• Dividir las guardias por turnos: para que no sean siempre los mismos miembros del equipo quienes estén de guardia, los equipos de DevOps suelen rotar según una planificación de guardia en la que todos los miembros pueden recibir un aviso nocturno para responder a un incidente.
• El ingeniero que lo desarrolló es la persona idónea para solucionarlo: la idea central del lema "tú lo creas, tú lo gestionas" es que las personas más familiarizadas con el servicio (quienes lo desarrollaron) son las que están mejor preparadas para solucionar una interrupción.
• Generar con rapidez, pero con asunción de responsabilidades: cuando los ingenieros saben que tanto ellos como sus compañeros de equipo están en la cuerda floja durante las interrupciones, hay un incentivo adicional para asegurarse de que se está implementando un código de calidad.

Este enfoque garantiza tiempos de respuesta rápidos y una retroalimentación agilizada para los equipos que necesitan saber cómo crear un servicio fiable.

Puedes consultar todos los detalles sobre un enfoque de gestión de incidentes idóneo para DevOps en nuestro Manual de gestión de incidentes de Atlassian.

La gestión de incidentes no se lleva a cabo con una única herramienta, sino con la combinación adecuada de herramientas, prácticas y personas. Estas son algunas de las categorías de herramientas más comunes para una gestión de incidentes eficaz:

• Seguimiento de incidentes: cada incidente debe rastrearse y documentarse para poder identificar tendencias y hacer comparaciones a lo largo del tiempo.
• Sala de chat: la comunicación por escrito en tiempo real resulta fundamental para diagnosticar y resolver incidentes en equipo. Además, brinda un gran conjunto de datos para el análisis de respuestas posterior.
• Chat de vídeo: el chat de vídeo del equipo complementa el chat por escrito para muchos incidentes, ya que facilita el análisis de los hallazgos y la elaboración de una estrategia de respuesta.
• Sistema de alerta: una herramienta como Jira Service Management se integra con tu sistema de supervisión y gestiona las rotaciones de las guardias y las derivaciones.
• Herramienta de documentación: en una herramienta como Confluence se pueden recopilar documentos sobre el estado de los incidentes y los análisis retrospectivos.
• Statuspage: comunicar el estado tanto a las partes interesadas internas como a los clientes a través de Statuspage contribuye a que todo el mundo esté al tanto de todo.