Guía completa sobre la gestión de incidentes mayores de TI

Es lunes por la mañana y las cosas son bastante normales en su mesa de servicio. De repente, recibe un ticket de alerta indicando que un servicio crítico no está funcionando y dentro de los próximos 15 minutos comienza a recibir un montón de tickets que reportan el mismo problema. Puede ser que su sitio web esté caído, que su software de punto de venta haya dejado de funcionar, o algo aún más trascendente, como la caída de la bolsa de valores o el aterrizaje de aviones. Si su negocio se ve gravemente afectado por un problema de TI que causa la pérdida de ingresos o reputación, entonces se trata de un incidente mayor.

La forma como reaccione ante un incidente mayor marca la diferencia en cuanto a la reducción del impacto del incidente y el restablecimiento de los servicios. Como dicen, el tiempo es dinero, y en este caso, no podría ser más cierto. Si su organización cuenta con un proceso de gestión de incidentes mayores (MIM), puede responder rápidamente y resolver los incidentes mayores. Si no tiene tal proceso, es hora de elaborar un plan de respuesta a emergencias, también conocido como un proceso de respuesta a incidentes mayores.

Los riesgos de un incidente mayor son más altos que nunca, y según un estudio de Information Technology Intelligence Consulting, el 98 por ciento de las organizaciones pierden al menos $100.000 por cada hora de inactividad. Esto refuerza la importancia de establecer un proceso de MIM que pueda abordar de manera efectiva y eficiente los incidentes mayores.

Cada organización tiene como objetivo eliminar los incidentes mayores, pero el hecho es que los incidentes mayores no se pueden prever completamente y lo único que puede hacer es estar preparado.

En esta guía, veremos cómo establecer un proceso de MIM efectivo, cuáles son los errores comunes que pueden afectar la MIM de su organización y cuáles son las mejores prácticas para mejorar su proceso de MIM.

Pero primero, ¿qué hace que un incidente se considere un incidente mayor?

Un incidente mayor es un problema urgente de alto impacto que generalmente afecta a toda la organización o a gran parte de ella. Un incidente mayor casi siempre afecta la disponibilidad de los servicios de una organización, lo que a su vez afecta el negocio de la organización y, en última instancia, afecta su posición financiera. Existen dos formas en que un incidente mayor puede afectar los servicios de una organización:

• Evitar que los clientes accedan a los servicios de la organización. La interrupción de Cloudflare en julio de 2019 es un ejemplo de cómo los clientes se ven afectados por un incidente mayor. Esta interrupción mayor afectó a casi la mitad de Internet y dejó a millones de usuarios de Internet sin poder acceder a varios servicios.
• Afectar la capacidad de los empleados para completar su trabajo a tiempo, lo que lleva a una interrupción del negocio. La interrupción de IndiGo en noviembre de 2019 afectó el proceso de check-in de la aerolínea, lo que provocó largas demoras y afectó a miles de pasajeros.

Una mesa de servicio bien preparada debe estar equipada para evaluar los incidentes mayores y encontrar soluciones o soluciones alternativas para reducir y controlar el impacto de un incidente mayor.

Las organizaciones deben tener un proceso de MIM, ya que les ayuda a minimizar el impacto comercial que causa un incidente mayor. El proceso de MIM consiste principalmente en los siguientes pasos:

Etapa 1: Identificación

Declarar el incidente mayor:

El primer paso es identificar los posibles incidentes mayores. Es importante que las organizaciones establezcan varios métodos para identificar las amenazas. Los técnicos pueden marcar los incidentes mayores cuando reciban tickets inusuales, o pueden ser detectados por otras soluciones como las herramientas de monitoreo de red que pueden marcar automáticamente un problema de red y crear un ticket para alertar a la mesa de servicio. Las organizaciones también pueden establecer una línea directa dedicada para que el personal de la mesa de servicio marque los posibles incidentes importantes.

Informar a las partes interesadas:

Una vez que se ha identificado un incidente mayor, se debe comunicar a todas las partes interesadas clave. Hay cuatro grupos principales a los que se debe informar sobre los incidentes mayores:

• Equipo técnico: Es importante informar al equipo técnico de inmediato para que pueda comenzar a elaborar un plan para solucionar el problema.
• Directivos: Mantener a los directivos, como el CIO, informados sobre los incidentes mayores facilita la aprobación. Las organizaciones también deben mantener informada a la gerencia sobre todas las medidas adoptadas para solucionar los incidentes mayores.
• Interesados clave: Los directores de departamento y el personal de gestión empresarial de nivel de servicio también deben ser informados sobre los incidentes importantes y recibir actualizaciones periódicas del estado.
• Usuarios: Los usuarios necesitan saber qué servicios no están disponibles debido a un incidente mayor.

Etapa 2: Contención

Formar un equipo de incidentes mayores

Un equipo de incidentes mayores, o MIT para abreviar, está conformado por técnicos, directores de gestión de nivel de servicio y otras partes interesadas clave; a veces se contrata personal externo altamente calificado para solucionar un incidente mayor. El MIT trabaja en conjunto para encontrar una solución para el incidente mayor y restablecer las operaciones.

Establecer un puente de conferencia

Un puente de conferencia, más comúnmente conocido como una llamada de conferencia, ayuda a garantizar una resolución de problemas efectiva y una comunicación centralizada. Actúa como un canal de comunicación claro y rápido entre los miembros del MIT.

Preparar una sala de operaciones designada

Tener una sala de operaciones designada permite que todos los miembros del MIT se reúnan y resuelvan el incidente. Esto aumenta los esfuerzos de colaboración, ayudando al MIT a encontrar una solución más rápido.

Crear un ticket de problema para identificar los problemas subyacentes

Se puede crear un ticket de problema para descubrir y comprender la causa raíz del incidente mayor. Esto puede ayudar a prevenir que ocurran incidentes mayores similares en el futuro al abordar las causas del incidente mayor.

Etapa 4: Mantenimiento

Realizar una revisión post-implementación

Es importante evaluar el incidente durante un período de tiempo para asegurarse de que realmente esté resuelto. Si no se solucionan los problemas subyacentes, podrían generar otro incidente mayor.

Producir documentación clara

Documentar todo el proceso de resolución del incidente mayor ayuda a la organización a prepararse para afrontar incidentes similares en el futuro. Con la debida documentación sobre le incidentes anteriores, la organización puede implementar la solución aprobada inmediatamente cuando se enfrente a otro incidente mayor similar, reduciendo su impacto.

Medir las métricas

Medir el rendimiento de la mesa de servicio ayuda a medir la efectividad de la mesa de servicio y el proceso de MIM. Algunas métricas importantes que se deben medir son el tiempo medio para confirmar (MTTA), el tiempo medio para resolver (MTTR), el número total de incidentes mayores y el tiempo promedio de inactividad para los incidentes mayores.

Un incidente importante requiere un grupo de personal especializado para abordar el incidente y resolverlo. Los roles de MIM incluyen:

Técnicos de la mesa de servicio

Los técnicos de la mesa de servicio son la primera línea de defensa contra los incidentes mayores. Analizan los tickets de incidentes y los escalan al gestor de incidentes. Los técnicos de la mesa de servicio también participan en la implementación de las resoluciones.

Gestor de incidentes mayores

El gestor de incidentes mayores es el propietario del incidente mayor. Su función incluye declarar el incidente como un incidente mayor y garantizar que se siga el proceso de MIM y que el incidente se resuelva lo antes posible. Actúa como el principal punto de contacto para cualquier información sobre el incidente mayor y gestiona el MIT.

MIT

Un MIT es un equipo especializado que es responsable de analizar el incidente mayor y elaborar un plan de acción para manejar la amenaza. El MIT se compone idealmente de técnicos de la mesa de servicio, personal de gestión de nivel de servicio, personal técnico, otras partes interesadas relevantes y consultores externos si la situación lo amerita.

Personal técnico

El personal especializado responsable de mantener la infraestructura y las operaciones, incluidos los administradores de sistema, los administradores de redes y el personal de seguridad de la información, que conforman el personal técnico de una organización. El personal técnico ayuda a solucionar el incidente mayor y es el principal responsable de implementar la resolución del incidente mayor

Gestor del cambio

El gestor de cambios es el propietario del cambio creado para implementar la solución para el incidente mayor. El gestor de cambios asume toda la responsabilidad y propiedad del ticket de cambio.

Gestor de problemas

Si se crea un problema en respuesta al incidente mayor, el gestor de problemas será el propietario del ticket de problema. El gestor de problemas intenta determinar la causa raíz del incidente y asegurarse de que no vuelva a ocurrir, o que al menos la organización esté preparada para la próxima vez que ocurra el incidente

Consultores externos o proveedores externos

En algunos casos, el incidente mayor puede requerir personal altamente especializado que ayude a comprender y solucionar el incidente. El gestor de incidentes mayores identifica al personal requerido y lo incorpora al MIT para ayudar a reducir el impacto del incidente mayor.

Estos son 5 errores comunes que pueden dificultar su proceso de MIM:

1. Escalamiento y comunicación manual

   El mayor desafío para la MIM es la comunicación. Si ocurre un incidente mayor, varios interesados deben ser informados sobre el estado del incidente, su gravedad y las medidas adoptadas para solucionar el problema. Es muy difícil comunicar todo esto de forma manual y podrían haber inconsistencias en la comunicación, lo que solo empeora las cosas. Al automatizar el proceso, se notifica a las partes interesadas clave durante todo el ciclo de vida del ticket, y el gestor de incidentes mayores puede centrar toda su atención en solucionar el problema.

2. Canales ineficientes para reportar los incidentes mayores

   Cada mesa de servicio recibe decenas o incluso cientos de tickets por día, desde problemas con computadoras portátiles hasta solicitudes de servicio. Entre esta montaña de tickets, podría haber algunos incidentes mayores. No establecer un canal separado para reportar los incidentes mayores demora la identificación de los incidentes mayores

3. Duplicación de esfuerzos

   Si no se delegan las tareas de manera organizada, se pueden duplicar los esfuerzos dentro del MIT. Es importante asignar tareas y mantener informado al MIT sobre la tarea de cada miembro.

4. Documentación insuficiente

   La falta de documentación adecuada obligará al MIT a comenzar desde cero cada vez que ocurra un incidente mayor similar, lo que provocará demoras en la resolución de los incidentes mayores y generará un tiempo de inactividad innecesario.

5. Falta de análisis de causa raíz

   Similar a la gestión de incidentes, la MIM puede tener un corto alcance, ya que se enfoca en solucionar el problema y restablecer los servicios en el menor tiempo posible. Si no se combina con la gestión de problemas para identificar los problemas subyacentes, la causa subyacente de un incidente mayor continuará haciendo que la organización sea vulnerable a los incidentes mayores.

Estas son las mejores formas de abordar el proceso de MIM

1. Establecer varios canales para reportar los incidentes mayores

   Cuando se trata de manejar incidentes mayores, el tiempo es esencial. Las organizaciones deben identificar y clasificar los incidentes mayores tan pronto como los detecten. Ofrecer a los usuarios varias formas de reportar los incidentes hará que todo el proceso sea más rápido y más accesible. Puede permitir la creación de tickets a través del correo electrónico o un portal web, o incluso establecer una línea directa dedicada para reportar los posibles incidentes mayores. Configurar un software de monitoreo de red para detectar las anomalías puede ayudarlo a lidiar proactivamente con los incidentes mayores.

2. Automatizar los procesos de la mesa de servicio

   La velocidad y la eficiencia juegan un papel fundamental en el control del impacto de un incidente mayor, y la automatización de varios procesos de la mesa de servicio justamente ayuda a lograr esto ya que permite liberar a sus técnicos de las tareas repetitivas como notificar a las partes interesadas. Automatizar el sistema de notificación y establecer flujos de trabajo para los incidentes mayores son dos formas eficientes de automatizar los procesos de la mesa de servicio para mejorar el tiempo de resolución y estructurar el proceso de MIM.

3. Esforzarse por lograr una comunicación rápida y relevante

   Es importante mantener informados a los directivos y a las partes interesadas de su organización sobre cada incidente mayor. Mantener informada a la gerencia lo ayudará a obtener las aprobaciones y permisos necesarios para solucionar el incidente mayor. Una comunicación rápida garantiza que todo el personal de incidentes principales esté en sintonía y permite una colaboración fluida y efectiva. También mantiene a los usuarios finales informados sobre cualquier posible tiempo de inactividad para que puedan prepararse.

4. Crear documentación clara

   Una documentación clara ayuda al gestor de incidentes mayores a registrar todo el trabajo realizado para solucionar el incidente mayor, su impacto, los servicios afectados y otra información clave sobre el incidente mayor. Esta documentación permite demostrar a la gerencia el beneficio de tener un proceso de MIM, incluido su ROI. La documentación clara también ayudará a solucionar cualquier incidente mayor similar en el futuro.

5. Utilizar integraciones profundas con el software de ITOM

   Las sólidas integraciones con el software de ITOM permiten al departamento de TI manejar proactivamente los incidentes mayores. La identificación reactiva de incidentes mayores se basa en tener una gran afluencia de tickets para saber que hay un incidente mayor en progreso. Por otro lado, un proceso de MIM proactivo que utiliza las integraciones de ITOM cuenta con sistemas para monitorear las redes y los servicios, y puede detectar automáticamente las anomalías que podrían ser posibles incidentes mayores.

Es importante recordar que no todos los incidentes de alta prioridad son incidentes mayores. Dado que el proceso de MIM implica un gran compromiso de recursos (como implementar un MIT separado), es importante clasificar cuidadosamente los incidentes mayores.

Fuente : https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/

La interrupción de Cloudflare en el 2019 es un muy buen ejemplo de lo que significa un incidente mayor. En este caso, un procedimiento operativo estándar para actualizar una regla gestionada para el firewall de aplicaciones web (WAF) aumentó a casi el 100 por ciento el uso de las CPU dedicadas a servir el tráfico HTTP/HTTPS a través de los servidores de la red de Cloudflare. La interrupción causada resultó en una reducción del 80 por ciento del tráfico de Cloudflare y afectó a millones de usuarios de Internet en todo el mundo.

Impacto: alto

La interrupción provocó que los clientes de Cloudflare (y sus clientes) vieran una página de error 502 al visitar cualquier dominio de Cloudflare. Los errores 502 fueron generados por los servidores web de front-end de Cloudflare que todavía tenían núcleos de CPU disponibles pero no podían acceder a los procesos que servían el tráfico HTTP / HTTPS. Se estima que al menos la mitad de todo el Internet era inaccesible durante los veintisiete minutos de inactividad.

Urgencia: alta

Todos los sitios web de Cloudflare eran inaccesibles, lo que causó interrupciones en el servicio para miles de organizaciones y millones de usuarios. La interrupción también afectó las operaciones internas de Cloudflare, evitando que los empleados de Cloudflare accedieran a varios servicios, como la herramienta de gestión de cambios de la compañía y el panel de control interno. Se tuvo que abordar la interrupción para reanudar las operaciones normales de servicio.

Cronología de los eventos desde la detección hasta la resolución:

La regla gestionada para el WAF se implementó a las 13:42; tres minutos después, las herramientas de operación de red de Cloudflare comenzaron a marcar la caída del tráfico, muchas otras pruebas de extremo a extremo de los servicios de Cloudflare comenzaron a fallar, los usuarios finales notaron varios errores 502 y Cloudflare recibió muchos reportes de agotamiento de la CPU desde sus puntos con presencia en diferentes ciudades de todo el mundo.

El equipo de ingeniería de confiabilidad del sitio (SRE), el equipo de ingeniería de Londres y otros equipos relevantes se reunieron para detectar y solucionar el problema. A las 14:00, se determinó que el WAF era la causa del incidente. Y a las 14:07, se implementó una «eliminación mundial» del WAF para que los niveles de tráfico volvieran a la normalidad.

A las 14:52, Cloudflare estaba 100 por ciento satisfecho de que entendía la causa de la interrupción y tenía una solución, por lo que se volvió a habilitar el WAF a nivel mundial.

Cambio

La adición, modificación o eliminación de cualquier cosa que pueda afectar directa o indirectamente los servicios.

Gestión de cambios

El proceso que consiste en completar los cambios con interrupciones y conflictos mínimos.

Escalamiento

El acto de transferir la propiedad de un ticket de acuerdo con una necesidad funcional o jerárquica.

Evento

Un suceso que es importante para la gestión de un servicio o activo.

Fallo

Un evento en el que un servicio o activo no funciona de acuerdo con el SLA acordado.

Escalamiento jerárquico

El acto de transferir la propiedad verticalmente a un técnico de la mesa de servicio superior o a la autoridad relevante.

Impacto

Una medida de la gravedad de un incidente.

Incidente

Una interrupción no planificada de un servicio de TI o una reducción en la calidad de un servicio de TI. La falla de un elemento de configuración, incluso si aún no ha afectado un servicio, también es un incidente (por ejemplo, la falla de un disco de un conjunto de replicación).

Gestión de incidentes

El proceso que consiste en gestionar el ciclo de vida de todos los incidentes para restaurar las operaciones normales de servicio lo más rápido posible y minimizar el impacto comercial.

Priorización del incidente

Asignar prioridades a los incidentes y definir lo que constituye un incidente mayor.

Incidente mayor

Un incidente que tiene un alto impacto y una gran urgencia, por tanto requiere un proceso separado de la gestión de incidentes.

Gestor de incidentes mayores

La persona responsable del MIT y la implementación del proceso de MIM.

Tiempo medio para confirmar (MTTA)

Una medición de la rapidez con la que la mesa de servicio confirma un incidente.

Tiempo medio para detectar (MTTD)

Una medición de la rapidez con la que se detecta una amenaza potencial para un servicio o elemento de configuración.

Tiempo medio entre fallos (MTBF)

Una medida de la frecuencia con la que falla un servicio o activo.

Tiempo medio para reparar / resolver/ responder / recuperar (MTTR)

Una medida de la rapidez con la que se restaura un servicio después de una falla.

Operación normal de servicio

Una operación de servicio que cumple con el acuerdo de nivel de servicio (SLA).

Problema

Una causa o posible causa de uno o más incidentes.

Matriz RACI

Define los roles y las responsabilidades en los proyectos y procesos interfuncionales o departamentales.

Mesa de servicio

El punto de comunicación entre los proveedores de servicios y los usuarios de la organización.

Gestor del servicio al cliente

La persona que supervisa las actividades cotidianas de la mesa de servicio y es responsable de su desempeño.

Objetivo de nivel de servicio (SLO)

Define el objetivo de los proveedores de servicios y es una forma de medir su desempeño.

SLA

Un acuerdo entre el proveedor de servicios y el cliente respecto al nivel de servicio esperado y el tiempo de entrega esperado.

Urgencia

Una medida de la velocidad con la que se debe resolver un incidente.