¿Qué es la gestión de incidentes?

Tipos de procesos de gestión de incidentes

Empresas de tipos distintos tienden a gravitar hacia diferentes tipos de procesos de gestión de incidentes. No existe un proceso universal, por lo que cada empresa utiliza un enfoque diferente.

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 en la ingeniería de fiabilidad de sitios (SRE).

El proceso de gestión de incidentes de TI

Tener un proceso de gestión de incidentes ayuda a los equipos de TI a investigar, registrar y resolver interrupciones del servicio. El flujo de trabajo de gestión de incidentes de ITIL tiene como objetivo reducir el tiempo de inactividad y minimizar el impacto en la productividad de los empleados debido a incidentes. Mediante plantillas diseñadas para gestionar incidentes, puedes crear un flujo de trabajo de gestión de incidentes repetible que permita a los equipos registrar, diagnosticar y resolver incidentes y, al mismo tiempo, tener 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 cubre casi todos los tipos de incidentes, incidencias y procesos a los que se tienen que enfrentar los equipos 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 de 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.

Pasos del proceso de gestión de incidentes de TI

Identifica un incidente y regístralo

Los incidentes pueden tener muchas procedencias: empleados, clientes, proveedores, sistemas de supervisión... Sea cual sea el origen del incidente, 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

Categoriza

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.

Prioriza

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, las 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.

Respuesta

• Diagnóstico inicial: lo ideal es que tu equipo de asistencia de primera línea pueda dedicarse a un incidente desde el diagnóstico hasta la resolución, pero, si no puede ser, el siguiente paso es registrar toda la información pertinente y escalar al equipo de siguiente nivel.
• Escalar: el siguiente equipo toma los datos registrados y continúa con el proceso de diagnóstico y, si este equipo no puede diagnosticar el incidente, se escala de nuevo al siguiente equipo.
• Comunicar: el equipo comparte periódicamente actualizaciones con las partes interesadas internas y externas afectadas.
• Investigación y diagnóstico: este proceso continúa hasta que se identifique el tipo de incidente. A veces los equipos invitan a recursos externos o miembros de otros departamentos para pedirles asesoramiento y ayuda con la resolución.
• Resolución y recuperación: en este paso, el equipo llega a un diagnóstico y da los pasos necesarios para resolver el incidente. La recuperación simplemente implica la cantidad de tiempo que las operaciones pueden tardar en recuperarse por completo, ya que algunas correcciones (como parches de error) pueden requerir pruebas e implementación incluso después de determinar la resolución adecuada.
• Cierre: si el incidente se había escalado, se devuelve al centro de asistencia para que se pueda cerrar. Para mantener la calidad y garantizar un proceso fluido, solo los empleados del centro de asistencia pueden cerrar incidentes. Los propietarios de cada incidente deben consultar con la persona que lo notificó para confirmar que la resolución es satisfactoria y que el incidente puede cerrarse realmente.

Incidentes, problemas y cambios: ¿cuál es la diferencia?

Existen diferentes tipos de problemas que suelen encontrar los equipos de TI, y los clasificamos para poder aplicarles las técnicas de gestión adecuadas.

• Solicitud de asistencia: una solicitud formal de un cliente para que se le proporcione algo; por ejemplo, un portátil nuevo.
• Incidente: una interrupción no planificada o una reducción de la calidad de un servicio de TI; por ejemplo, un sitio web inactivo.
• Problema: el origen de un incidente; por ejemplo, la configuración incorrecta de un servidor. Son las cosas que conviene tener en cuenta para que no surjan incidentes.
• Cambio: una acción que se lleva a cabo, que puede ser estándar, normal o una emergencia. Un cambio estándar tiene un procedimiento establecido. Un cambio normal a menudo no es trivial y tiene que pasar por un proceso de aprobación. Un cambio de emergencia se realiza inmediatamente y lo ideal es que se pruebe antes de implementarlo.

Proceso de gestión de incidentes de DevOps y SRE

Con un enfoque DevOps o SRE de gestión de incidentes, el equipo que desarrolla el servicio también se encarga de gestionarlo y repararlo si tiene problemas. Este enfoque ha aumentado tremendamente en popularidad junto con el crecimiento de los servicios en la nube siempre disponibles, las aplicaciones web a las que se puede acceder desde todo el mundo, los microservicios y el software como servicio.

Cada vez más, el software que utilizamos en el trabajo y en nuestra vida privada no se aloja en un servidor en la misma ubicación física en la que te encuentras. Es probable que sean aplicaciones a las que se accede a través de la Web y que están implementadas en un centro de datos para miles o millones de usuarios de todo el mundo. Para los equipos encargados de gestionar estos servicios, la agilidad y la velocidad son primordiales. Además, cualquier tiempo de inactividad tiene el potencial de afectar a miles de organizaciones, no solo a una.

Una ventaja del enfoque “you built it, you run it” es que ofrece la flexibilidad que necesitan los equipos que utilizan la metodología ágil, pero también puede ser más difícil determinar quién es responsable de qué y cuándo. A los equipos de DevOps pueden resultarle más cómodos (y eficaces) los procesos de desarrollo menos estructurados. No obstante, lo mejor es estandarizar un conjunto principal de procesos para la gestión de incidentes; de este modo, no habrá dudas sobre cómo responder cuando surja un incidente y se podrá hacer un seguimiento de las incidencias e informar de cómo se han resuelto.

Tres principios de los equipos de gestión de incidentes de DevOps

• Todos se turnan para estar de guardia: en lugar de tener ciertos miembros del equipo encargados de las guardias, los equipos de DevOps suelen rotar las guardias para que todos los miembros compartan la carga que supone tener que despertarse por la noche para responder a un incidente.
• El ingeniero que lo desarrolló es la persona ideal para arreglarlo: la idea central del enfoque “you built it, you run it” es que las personas más familiarizadas con el servicio (los desarrolladores) son las mejor preparadas para solucionar las interrupciones del servicio.
• Se desarrolla con rapidez, pero también con responsabilidad: cuando los ingenieros saben que ellos y sus compañeros de equipo están en el punto de mira durante las interrupciones del servicio, hay un incentivo adicional para asegurarse de que el código implementado es de calidad.

Este enfoque permite agilizar los tiempos de respuesta y el envío de feedback a los equipos que necesitan saber cómo desarrollar un servicio fiable.

En el Manual de incidentes de Atlassian describimos un enfoque de gestión de incidentes muy adecuado para DevOps.

Herramientas de gestión de incidentes

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

• Seguimiento de incidentes: es necesario hacer un seguimiento de todos los incidentes y documentarlos para poder detectar tendencias y hacer comparaciones a lo largo del tiempo.
• Sala de chat: disponer de un canal de comunicación por escrito y en tiempo real es fundamental para diagnosticar y resolver el incidente en equipo. Además, proporciona un amplio conjunto de datos que se puede utilizar más adelante para el análisis de la respuesta.
• Videollamadas: las videollamadas sirven de complemento al chat de texto para muchos incidentes. Las videollamadas en equipo resultan útiles para hablar de los hallazgos y trazar una estrategia de respuesta.
• Sistema de alertas: con herramientas como Opsgenie se gestionan las rotaciones de guardias y las escalaciones.
• Herramienta de documentación: con herramientas como Confluence se registran documentos de estados de incidentes y análisis retrospectivos.
• Statuspage: comunicar el estado a las partes internas interesadas y a los clientes mediante Statuspage ayuda a mantener a todo el mundo informado.