Última actualización: 24 de octubre de 2023
En el acelerado panorama empresarial actual, los incidentes mayores pueden ocurrir de forma inesperada, afectando la productividad y la satisfacción del cliente. Independientemente de la industria, es fundamental establecer planes de recuperación y fomentar una cultura de resiliencia para garantizar la continuidad del negocio en tiempos de crisis. Tomemos como ejemplo las operaciones de las aerolíneas. Las operaciones de las aerolíneas son complejas, y su eficiencia depende del esfuerzo conjunto de muchas personas. Sin embargo, los sistemas de TI se han vuelto esenciales para el cumplimiento de los horarios de las aerolíneas. Por lo tanto, las crisis de TI afectan a muchos usuarios. Por ejemplo, Zylker Airlines experimentó recientemente una interrupción de TI, lo que impactó a miles de pasajeros.
Echemos un vistazo a la causa y los eventos de la interrupción de Zylker.
Causa de la interrupción
Las operaciones de la aerolínea de Zylker se vieron obstaculizadas debido a una interrupción de TI. En el sitio web de la aerolínea aparecía un mensaje que decía "Error 502: Gateway incorrecto", que causaba problemas con las reservas, registro, cancelaciones y otras operaciones. La causa principal de la interrupción de TI se atribuyó a un fallo del firewall suministrado por el proveedor.
Para responder a las nuevas vulnerabilidades y amenazas, el equipo de firewall del proveedor publicó nuevas reglas para las reglas gestionadas existentes del firewall de aplicaciones web (WAF) de forma regular y, a continuación, aplicó una actualización a nivel mundial. Durante una de estas actualizaciones, uno de los ingenieros del equipo de firewall hizo una modificación menor que inadvertidamente aumentó en casi 100% el uso de las CPU dedicadas a servir el tráfico HTTP y HTTPS en toda la red. Esto provocó que el sitio web de la aerolínea y los sistemas clave quedaran inaccesibles durante unas horas.
Eventos que condujeron a la interrupción
Durante la ventana de mantenimiento, se aplicaron las reglas WAF actualizadas, y el sistema parecía funcionar normalmente. Varias horas después de la actualización de la regla, los usuarios comenzaron a reportar problemas para acceder al sitio web de la aerolínea. El equipo de TI comenzó a investigar la causa, y después de 13 minutos, se declaró un incidente mayor y se notificó a las partes interesadas. Mientras tanto, hubo un alto volumen de llamadas que reportaron el problema.
Los miembros de varios equipos se reunieron para formar un equipo de respuesta a incidentes 33 minutos después de que ocurriera el incidente. El equipo investigó la hipótesis de un ciberataque. Le tomó 53 minutos descartar la posibilidad de un ciberataque, y aun así no logró identificar la causa raíz.
Tras una investigación adicional, el equipo determinó que la causa de la interrupción de TI podría atribuirse a la actualización de las reglas gestionadas del WAF, y comenzó a revertir la actualización de las reglas gestionadas para restaurar el servicio. Las operaciones normales se reanudaron luego de 78 minutos después de que ocurriera la interrupción de la aplicación web de la aerolínea.
A pesar de usar diversas aplicaciones y herramientas de monitoreo, Zylker tuvo varios problemas y no pudo manejar la interrupción principal de manera eficiente. Este incidente resaltó la importancia de contar con un sólido proceso de gestión de incidentes mayores y protocolos de comunicación eficaces para mitigar el impacto de futuras interrupciones.
Building a
Crear un ciclo de vida de solicitud para manejar incidentes mayores en ServiceDesk Plus
Ahora, veamos lo que podría haber sucedido si Zylker Airlines hubiera utilizado un proceso de gestión de incidentes simplificado y lo hubiera implementado con ServiceDesk Plus, que habría contenido la interrupción creada por la actualización de la regla del WAF y minimizado la interrupción a sus clientes de manera mucho más efectiva.
- ServiceDesk Plus puede ayudar a Zylker a seguir un marco de prácticas recomendadas (Fig. 1) para garantizar que la empresa maneje los incidentes mayores de manera eficiente.
Fig. 1: Marco de prácticas recomendadas
Para implementar este marco en tiempo real, ServiceDesk Plus utiliza la función ciclo de vida de solicitud (RLC). Los RLC le permiten diseñar el ciclo de vida completo de un ticket de forma visual en una interfaz simple de arrastrar y soltar. Además, divide el ciclo de vida de un ticket en varios estados y transiciones. Cada ticket en ServiceDesk Plus pasa por varios estados como Abierto, En espera, Esperando una actualización, Resuelto y Cerrado. Con los RLC, puede diseñar la secuencia de los estados junto con las condiciones y acciones (transiciones) necesarias para cambiar de estado simplemente arrastrando y soltando los estados en la interfaz (Fig. 1.1).
Fig. 1.1: Interfaz RLC de arrastrar y soltar
Las transiciones son las acciones necesarias para mover el ticket de un estado a otro. En cada estado, las transiciones guían a los técnicos a través de acciones condicionales para avanzar al siguiente estado. Los técnicos pueden cambiar el estado solo a través de las transiciones disponibles en la página de detalles del ticket de incidente (Fig. 1.2). Hay tres etapas de transición: ANTES, DURANTE y DESPUÉS, lo que le permite establecer varias opciones para controlar el cambio de estado en función del cumplimiento de las condiciones especificadas (Fig. 1.3). Este RLC se puede asociar con una o más plantillas de incidentes.
Fig. 1.2: Página de detalles del incidente
Fig. 1.3: Etapas de transición
Ahora veamos cómo la función de RLC podría haber ayudado a Zylker a contener el incidente mayor.
- Durante la ventana de mantenimiento, se aplica una actualización de reglas del WAF. ServiceDesk Plus se integra con varios productos ITOM, incluido ManageEngine OpManager, para monitorear redes y servicios. Cuando OpManager identifica una anomalía en los servicios, automáticamente se registra una alerta como un ticket de incidente en ServiceDesk Plus con todos los detalles relevantes, como la fecha y hora de la interrupción, los sistemas o aplicaciones afectados y los mensajes de error recibidos.
- Este ticket utiliza automáticamente la plantilla de incidentes mayores a través de una simple automatización sin código basada en reglas. Una vez que el ticket se registra con la plantilla de incidente mayor, el RLC de incidente mayor asociado con esa plantilla se activa instantáneamente y comienza a guiar el proceso.
- En los próximos tres minutos, el representante de la mesa de servicio de Zylker evalúa el impacto del incidente para evitar falsas alarmas y marca el ticket de incidente como un incidente mayor haciendo clic en la acción de transición "Reportar" en la página de detalles del ticket de incidente; esto actualiza el estado del ticket y asigna el ticket al equipo de respuesta a incidentes (IRT) automáticamente. Luego, se envía una notificación instantánea a todas las partes interesadas. Estas acciones se configuran utilizando las tres etapas de transición en un RLC, como se explica a continuación.
Acción ANTES:
Zylker restringió el acceso al botón de transición "Reportar" a los representantes de la mesa de servicio con roles específicos a quienes se debe mostrar el botón de transición, y añadió condiciones para determinar si este botón de transición debe mostrarse o no en la página de detalles del incidente (Fig. 2). Si el tipo de solicitud es un incidente, el botón de transición "Reportar" se mostrará en la página de detalles del incidente solo para los técnicos que tengan roles de técnico de TI o IRT.
Fig. 2: Acción ANTES
Acción DURANTE:
Al ejecutar la transición "Reportar", el campo "¿Es un incidente mayor?" es obligatorio, por lo que el representante de la mesa de servicio deberá indicar si el incidente es un incidente mayor o no. Si se marca como un incidente mayor, entonces el campo "Grupo" en la página de detalles del incidente se actualiza a "IRT" (Fig. 3), que transfiere el ticket al bucket del IRT.
Fig. 3: Acción DURANTE
Acción DESPUÉS:
Después de ejecutar la transición "Reportar", se envía automáticamente una notificación personalizada al IRT (Fig. 4) informando sobre la ocurrencia de un incidente mayor. Además de las notificaciones, los webhooks, las tareas y las funciones personalizadas también se pueden activar en función de las condiciones. Al ejecutar esta transición, el estado del ticket de incidente se mueve a WIP.
Fig.4: Acción DESPUÉS
-
Como siguiente paso, se lleva a cabo un proceso de clasificación. En la transición "Colaborar con IRT", Zylker configuró una notificación y agregó una función personalizada (Fig. 5) en la acción de transición DESPUÉS, que permite a ServiceDesk Plus integrarse con Microsoft Teams para crear un enlace de la sala de operaciones virtual. Al hacer clic en esta transición en la página de detalles del incidente, se activa la notificación personalizada con el enlace de la sala de operaciones virtual que se enviará al IRT distribuido, lo que facilita la colaboración entre los equipos que trabajan en un modelo de trabajo híbrido. Luego, el estado del ticket se actualiza automáticamente a "Clasificar".
Fig. 5: Funciones personalizadas
- A medida que se realiza la clasificación, se informa a los clientes sobre la interrupción utilizando la función "Anuncio" en ServiceDesk Plus para evitar que inunden la mesa de servicio con nuevos tickets.
- Ahora, comienza el análisis de la causa raíz (RCA). En la transición de "Análisis RCA" (Fig. 6), las tareas se agregan a la acción DESPUÉS, que ya están asignadas a un grupo de técnicos o técnicos específicos para analizar la causa raíz.
Fig. 6: Transición de análisis RCA
- En cinco minutos, el IRT determina que la causa raíz es la actualización de la regla del WAF y notifica a las partes interesadas apropiadas. Del mismo modo, Zylker configuró tres acciones de transición a varios estados en el ciclo de vida de incidentes mayores (Fig. 7) según sus requisitos.
Fig. 7: El ciclo de vida de incidentes mayores de Zylker
- Al encontrar la causa raíz, el ticket de incidente se delega al equipo apropiado para revertir la actualización de reglas del WAF. Uno de los técnicos de Zylker revierte la actualización de reglas del WAF y restaura los servicios en 28 minutos. Todo el equipo logró identificar la causa raíz y resolverla antes de que ocurriera una interrupción significativa.
- Una vez resuelto el problema, se notifica a las partes interesadas y la resolución se actualiza en la base de conocimientos para ayudar a los técnicos en el futuro.
Por lo tanto, los RLC en el marco de gestión de incidentes mayores proporcionan un enfoque estructurado para abordar incidentes críticos, protegiendo a las empresas contra las consecuencias potencialmente catastróficas de cualquier interrupción. Descubra más sobre la función de RLC de ServiceDesk Plus aquí.