Proceso de gestión de incidentes mayores según ITIL con ejemplos reales

Transcripción del vídeo

Lleve su proceso de gestión de incidentes mayores (MIM) a otro nivel

Ahora, pasemos a nuestro segundo escenario, que consiste en gestionar un incidente mayor y lograr que sus servicios vuelvan a estar en línea. Así que, como organizaciones, no nos gustan los incidentes mayores, ¿verdad? Intentamos mantenernos alejados de ellos, pero siempre es mejor anticipar estos eventos con antelación y tener una estrategia para enfrentarlos porque, si no lo hacemos, sólo se crea caos y confusión. Así que, en este escenario de la vida real, estudiamos una organización que no tenía una estrategia de gestión de incidentes y vamos a ver lo bien que respondió a un incidente mayor.

Estudio de caso: Un gran incidente de disponibilidad afecta a una empresa de rendimiento web

Este es el estudio de caso que tenemos aquí. Tenemos a una empresa de seguridad y rendimiento web que ofrece protección CDN, DNS y DDoS a muchos sitios web. Como proceso operativo estándar, el equipo de firewalls de esta empresa implementaba regularmente nuevas reglas en su firewall de aplicaciones web. Esto se hace para responder a las nuevas vulnerabilidades de seguridad en Internet. Así, durante una de esas actualizaciones rutinarias, un pequeño cambio realizado por uno de sus ingenieros disparó el uso de CPU en todos sus servidores, provocando la caída de la mitad de los sitios web de todo el mundo. Así que lo que los clientes acabaron viendo fue el error 502 gateway incorrecto. Así que, como pueden darse cuenta, se trata de un incidente mayor de la máxima magnitud.

Su equipo de incidentes analiza la situación

Así que vamos a desglosar la secuencia de eventos en una línea de tiempo y vamos a ver cómo la organización trabajó realmente en ello. Así que a las 13:42 se produjo realmente la interrupción y los servicios fallaron. En cuanto eso ocurre, reciben alertas de diferentes herramientas de monitoreo, y se crean diferentes alertas como alertas de servicio caído, alertas de error financiero, etc. A los ocho minutos del incidente, el equipo de SRE se da cuenta de que algo ha salido mal y, para entonces, el 80% del tráfico ya está caído.

Así que especulan sobre un ataque externo y, finalmente, declaran un incidente mayor, dándose cuenta del impacto del incidente. Así pues, su equipo de ingenieros de Londres es alertado de la interrupción global y, durante todo este periodo de tiempo, su equipo de soporte se ve inundado de llamadas. Los teléfonos no paran de sonar y se generan muchos tickets. Treinta y tres minutos después del incidente, se forma un equipo de respuesta a incidentes con miembros procedentes de varios equipos. Sí, permítanme repetirlo. En el momento de mayor caos y confusión, 33 minutos después del incidente mayor, se está constituyendo un equipo de respuesta a incidentes. Eso es un gran cuello de botella justo ahí.

Así pues, este equipo de IRT estaba sometido a una intensa presión por parte de la gestión, y aún no identifican la causa raíz. Y casi una hora después, descartaron la posibilidad de un ataque externo y finalmente descubrieron que el problema estaba en el WAF. Entonces se detiene el WAF global y, finalmente, los sitios web vuelven a estar en línea. Entonces, como pueden ver, a lo largo de esta línea de tiempo se produjeron importantes obstáculos, como reconocer un incidente, reunir un equipo, comunicarse con las partes interesadas y realizar el triaje. Entonces, ¿cómo superar todos estos cuellos de botella para que su negocio no se vea afectado?

Marco de gestión de incidentes mayores que afectan la disponibilidad

Este es un flujo de trabajo de mejores prácticas que utilizamos en Zoho para combatir incidentes mayores. Así que comienza por detectar una alerta de la herramienta de monitoreo y convertirla en un ticket en su herramienta de mesa de servicio. Así que, en cuanto eso ocurre, usted reconoce que hay un incidente mayor y entonces se comunica con sus partes interesadas, como sus CIO o sus CTO o los gestores de los IRT, y los reúne para poner en marcha el proceso de triaje. Entonces se evalúa el impacto del incidente y se decide si se declara o no incidente mayor. Y en este momento, sus usuarios finales estarían entrando en pánico porque no pueden acceder a los servicios críticos de su empresa.

Así que se les comunica externamente, se pone un anuncio diciendo que hay un incidente y que se está trabajando en ello. Así que, a estas alturas, usted crea diferentes tareas, las delega en los grupos resolutores apropiados que, a continuación, proporcionan la solución alternativa y garantizan que sus servicios vuelvan a estar en línea. Y ahí se acaba el ámbito de la gestión de incidentes.

Ahora tenemos que realizar un análisis de causa raíz y garantizar que no se repita este incidente mayor. Para ello, necesitamos crear un ticket de problema.

Marco de gestión de incidentes mayores que afectan la disponibilidad con ServiceDesk Plus

Así es como se afronta con efectividad un incidente mayor. Ahora, veamos cómo pueden aprovechar ServiceDesk Plus para hacer lo mismo.

Lo que están viendo en su pantalla en este momento es OpManager, que es el software para monitoreo de redes de ManageEngine. Así, podrán integrar OpManager con ServiceDesk Plus y garantizar que siempre que se cree una alerta de monitoreo y podrán convertirla automáticamente en un ticket en ServiceDesk Plus. Así que lo que están viendo ahora mismo es exactamente esa implementación. Así, en cuanto se crea la alerta de monitoreo, así es como se refleja el ticket en ServiceDesk Plus. Como pueden ver, se proporciona una breve descripción del incidente, y prácticamente todo lo que se ve es lo que vimos antes en la solicitud de servicio.

El siguiente proceso es comunicarse con las partes interesadas e informarles de este incidente mayor. Y para ello, volveremos a recurrir a la automatización, pero esta vez de las reglas de negocio. Así pues, las reglas de negocio son acciones basadas en condiciones, que garantizan que no haya retrasos en la comunicación de incidentes mayores. Así, tan pronto como se registre un ticket con el asunto "editado, no detectado o sitio web caído", se realizarían este conjunto de acciones como establecer la prioridad como incidente mayor y colocarlo en el grupo de soporte adecuado para que puedan poner en marcha el proceso de solución de problemas. También pueden enviar notificaciones a ciertas partes interesadas, y esas notificaciones pueden ser a través de correo electrónico o SMS. Como pueden ver, así de sencillo es comunicarse con las partes interesadas en tiempo real. Así se elimina un importante cuello de botella.

Ahora, déjenme volver a nuestro flujo de trabajo de mejores prácticas y veamos en qué punto nos encontramos. Así que, como pueden ver, detectamos el incidente mayor y nos comunicamos inmediatamente con nuestras partes interesadas. Así que el siguiente paso es evaluar los daños que se han producido y declarar un incidente mayor. Así que hemos visto cómo se crean múltiples tickets y se crean múltiples alertas de monitoreo, lo que se traduce en múltiples tickets. Así podrían enlazar todos estos tickets y garantizar la solución del incidente mayor.

Como pueden ver, a su derecha por aquí, todos los activos afectados también están asociados a este ticket de incidente. Así que permítanme hacer clic en estos Activos, y tan pronto como hago eso, todos los detalles de los activos se muestran. Por lo tanto, la información detallada del CI, el hardware, la información de software, y las relaciones se obtienen de la CMDB. Esto les ayudará a saber si los principales servicios se verán afectados o no. Como pueden ver, los servicios administrativos en toda una ubicación geográfica, que es Delhi aquí, se verían afectados porque este servidor aloja estos dos servicios.

Así que lo siguiente es comunicar este incidente a las partes interesadas. Así que para eso, permítame ir a la página principal del técnico y hagamos clic en "Añadir nuevo anuncio". Así, pueden crear un nuevo anuncio por aquí y asegurarse de que se muestre dentro de un plazo específico, y pueden elegir mostrarlo sólo al grupo adecuado de usuarios afectados. Así que, en este caso, vimos que había usuarios de una ubicación concreta en un departamento concreto que se verían afectados. Así podrán garantizar que el resto de los usuarios finales puedan seguir con sus tareas, y se comunicará a estos usuarios finales.

Ahora, volvamos nuevamente a nuestro flujo de trabajo de mejores prácticas y veamos qué tan lejos hemos llegado. Así que, como pueden ver, detectamos la aparición del incidente mayor, lo comunicamos, evaluamos el impacto y lo comunicamos mediante anuncios. Por lo tanto, lo único que queda es delegar diferentes tareas y poner en marcha el proceso de solución de problemas, que es proporcionar una solución alternativa. Para ello, volveremos al ticket del incidente y haremos clic en "Tareas". Ya hemos hablado mucho de las tareas en la solicitud de servicio.

Asimismo, pueden crear diferentes tareas asociadas a diferentes grupos y asegurarse de configurar las dependencias correctas. Y las dependencias aquí importan mucho porque el triaje es realmente necesario y, en un incidente mayor, hay que seguir un procedimiento definido. Por lo tanto, una vez que se hayan realizado las tareas y se haya proporcionado una solución alternativa, deberán añadirla a su resolución. Así que pueden añadir su resolución por aquí. Si no se hubiera producido anteriormente, podrían añadirla a su base de conocimientos. Esto les ayudará a combatir futuros incidentes del mismo tipo.

Ahora, hemos completado el ámbito o el dominio de la gestión de incidentes. Ahora, todo lo que queda es crear un ticket de problema e iniciar un análisis de causa raíz sobre qué causó este incidente en primer lugar. Para ello, pueden ir a "Asociaciones" por aquí y hacer clic en "Crear un nuevo problema". Así que lo que ocurre aquí es que todos los detalles se trasladan. Ustedes podrían crear un nuevo problema y su técnico o un grupo de técnicos adecuado realizaría un análisis de causa raíz. Así de fácil es. Ahora parece muy fácil, ¿verdad? Hemos superado todos los cuellos de botella a los que se enfrentaba la empresa de rendimiento web de datos. Nos aseguramos de comprender las mejores prácticas y las aplicamos en su enfoque de ITSM con las funciones adecuadas.

Ahora, al igual que con la solicitud de servicio anterior, tenemos que supervisar algunas matrices esenciales. Esto es muy importante porque sólo así sabrán cuáles son las brechas presentes en su estrategia y hasta qué punto pueden cerrarlas.

Entonces, aquí tienen su volumen de tickets, la productividad de sus técnicos, su tiempo de resolución y, de nuevo, su rotación de tickets. Por eso les aconsejo que creen dashboards únicos y completos para tratar sus incidentes mayores. Como pueden ver, he creado un dashboard de gestión de incidentes mayores por aquí, que representa en tiempo real los incidentes mayores definidos por categoría, por técnico y el número de incidentes cerrados por técnico. Así llegamos al final de nuestro segundo escenario. A estas alturas ya deberían estar seguros de poder manejar cualquier incidente mayor en el futuro.