Compartir vía

Recomendaciones para diseñar una estrategia de respuesta de emergencia

  • Artículo

Se aplica a esta recomendación de lista de comprobación de excelencia operativa de Azure Well-Architected Framework:

OE:08 Desarrollar una práctica eficaz de operaciones de emergencia. Asegúrese de que la carga de trabajo emite señales de estado significativas en toda la infraestructura y el código. Recopile los datos resultantes y úselo para generar alertas accionables que apliquen respuestas de emergencia a través de paneles y consultas. Defina claramente responsabilidades humanas, como rotaciones de llamadas, administración de incidentes, acceso a recursos de emergencia y ejecución de postmortems.

En esta guía se describen las recomendaciones para diseñar una estrategia de respuesta de emergencia. Algunos problemas que surgen durante el ciclo de vida de una carga de trabajo son lo suficientemente críticos como para garantizar la declaración de emergencias. Puede implementar procesos y procedimientos estrechamente controlados y centrados que el equipo puede seguir para asegurarse de que un problema se controla de forma tranquila y ordenada. Las emergencias aumentan naturalmente los niveles de estrés de todos y pueden conducir a un entorno caótico si su equipo no está bien preparado. Para ayudar a minimizar el estrés y la confusión, diseñar una estrategia de respuesta, compartir la estrategia de respuesta con su organización y realizar un entrenamiento de respuesta de emergencia normal.

Estrategias de diseño principales

Una estrategia de respuesta de emergencia debe ser un conjunto ordenado y bien definido de procesos y procedimientos. Cada proceso y procedimiento debe tener scripts para asegurarse de que cada paso avanza al equipo hacia la resolución rápida y segura de un problema. Para desarrollar una estrategia de respuesta de emergencia, tenga en cuenta la información general siguiente:

  • Requisitos previos
    • Desarrollo de una plataforma de observabilidad
    • Creación de un plan de respuesta ante incidentes
  • Fases de incidente
    • Detección
    • Containment
    • Evaluación de errores
  • Fases posteriores a incidentes
    • Análisis de causa principal (RCA)
    • Autopsia
  • Actividad en curso
    • Simulacros de respuesta de emergencia

En las secciones siguientes se proporcionan recomendaciones para cada una de estas fases.

Observabilidad

Para tener una estrategia sólida de respuesta de emergencia, debe tener una plataforma sólida de observabilidad en su lugar. La plataforma de observabilidad debe tener las siguientes características:

  • Supervisión holística: asegúrese de supervisar exhaustivamente la carga de trabajo desde una perspectiva de la infraestructura y de la aplicación.

  • Registro detallado: habilite el registro detallado para los componentes para ayudar con las investigaciones al evaluar un problema. Registros de estructura para que sean fáciles de administrar. Envíe automáticamente registros a receptores de datos que se prepararán para su análisis.

  • Paneles útiles: cree paneles basados en modelos de mantenimiento adaptados a cada equipo de toda la organización. Los distintos equipos son responsables de distintos aspectos del estado de la carga de trabajo.

  • Alertas accionables: cree alertas que sean útiles para los equipos de carga de trabajo. Evite alertas que no requieran acción de los equipos. Demasiadas alertas de este tipo pueden provocar que las personas omiten o bloquean las notificaciones de alerta.

  • Notificaciones automáticas: asegúrese de que los equipos adecuados reciban automáticamente alertas que requieran acción de ellos. Por ejemplo, el equipo de soporte técnico de nivel 1 debe recibir notificaciones para todas las alertas, mientras que los ingenieros de seguridad solo deben recibir alertas para eventos de seguridad.

Para obtener más información, consulte Recomendaciones para diseñar y crear un marco de observabilidad.

Plan de respuesta a incidentes

La base de una estrategia de respuesta de emergencia es un plan de respuesta a incidentes. Al igual que un plan de recuperación ante desastres, defina claramente y exhaustivamente roles, responsabilidades y procedimientos para un plan de respuesta a incidentes. El plan debe ser un documento controlado por versiones que esté sujeto a revisiones periódicas que asegúrese de que está actualizado.

Defina claramente los siguientes componentes en el plan.

Roles

Identifique un administrador de respuesta a incidentes. Esta persona posee el incidente desde el inicio hasta la corrección al análisis de la causa principal. Un administrador de respuesta a incidentes garantiza que se sigan los procesos y que las partes adecuadas se informen a medida que el equipo de respuesta realiza su trabajo.

Identifique un líder postmortem. Esta persona garantiza que las postmortems se realicen poco después de que se resuelva el incidente. Generan un informe, que le ayuda a aplicar los resultados que salen del incidente.

Procesos y procedimientos

El equipo de carga de trabajo debe definir y comprender los criterios de emergencia. Cuando el equipo determina que un caso es grave, puede declarar un desastre e iniciar el plan de recuperación ante desastres. En casos menos graves, es posible que el problema no cumpla los criterios de un desastre. Sin embargo, debe considerar el problema de una emergencia, lo que requiere iniciar el plan de respuesta de emergencia. Las emergencias pueden ser problemas internos para la carga de trabajo, o pueden ser el resultado de un problema con una dependencia de la carga de trabajo. El equipo de soporte técnico debe ser capaz de determinar si un problema notificado por los usuarios externos cumple los criterios de emergencia, incluso si no tienen visibilidad sobre el problema subyacente.

Defina precisamente los planes de comunicación y escalación. En función del tipo de notificación de alerta que reciben, asegúrese de que el soporte técnico de nivel 1 pueda ponerse en contacto fácilmente con los equipos adecuados para escalar los problemas. Asegúrese de que saben qué tipo de comunicación es adecuado para las partes internas y externas. En los planes de comunicación y escalación, incluya una lista de la programación de llamadas y el personal.

En el plan general, incluya scripts de contención y evaluación de prioridades. Los equipos siguen estos procedimientos paso a paso cuando realizan sus funciones de contención y evaluación de prioridades. Incluya una descripción de lo que define un cierre de incidentes.

Otros elementos que se van a incluir

Documente todas las herramientas estándar que se usarán durante los incidentes para la comunicación interna, como Microsoft Teams, y para realizar un seguimiento de las actividades durante el transcurso del incidente, como las herramientas de vales o las herramientas de planificación de trabajos pendientes.

Documente las credenciales de emergencia, lo que se conoce como cuentas de emergencia. Incluya una guía paso a paso que describa cómo se deben usar.

Cree instrucciones de obtención de detalles de respuesta de emergencia y mantenga un registro de cuándo se han realizado los simulacros.

Documente las medidas legales o reglamentarias necesarias, por ejemplo, la comunicación de infracciones de datos.

Detección de incidentes

Cuando tiene una plataforma de observabilidad bien diseñada que supervisa las anomalías y las alertas automáticamente sobre ellas, puede detectar rápidamente problemas y determinar su gravedad. Si el problema se considera una emergencia, se puede iniciar el plan. En algunos casos, el equipo de soporte técnico no recibe notificaciones a través de la plataforma de observabilidad. Los clientes pueden notificar problemas de soporte técnico mediante las vías de comunicación del equipo de soporte técnico. O pueden ponerse en contacto con personas con las que trabajan regularmente, como ejecutivos de cuentas o DIRECCIONES VIRTUALES. Independientemente de cómo se notifique al equipo de soporte técnico, siempre deben seguir los mismos pasos para validar el problema y determinar la gravedad. La desviación del plan de respuesta puede agregar estrés y confusión.

Containment

El primer paso de corrección de problemas es contener el problema para proteger el resto de la carga de trabajo. Una estrategia de contención depende del tipo de problema, pero normalmente implica quitar el componente afectado de las rutas de flujo de carga de trabajo. Por ejemplo, podría apagar un recurso o quitarlo de las rutas de enrutamiento de red. Los administradores de sistemas, los ingenieros y los desarrolladores sénior deben trabajar juntos para diseñar estrategias de contención. La contención debe limitar el radio de explosión de problemas y mantener la funcionalidad de carga de trabajo en un estado degradado hasta que se resuelva el problema. Si un componente afectado debe ser accesible para realizar una evaluación de prioridades, es fundamental que se bloquee su acceso al resto de la carga de trabajo. Tanto como sea posible, solo debe acceder al componente a través de una ruta de acceso separada de la carga de trabajo y el resto de los sistemas.

Evaluación de errores

Después de contener correctamente el problema, puede comenzar el trabajo de evaluación de prioridades. Los pasos que siga durante la evaluación de prioridades dependen del tipo de problema. El equipo para una determinada área de soporte técnico de carga de trabajo debe crear procedimientos para incidentes relacionados con su equipo. Por ejemplo, los equipos de seguridad deben evaluar los problemas de seguridad y deben seguir los scripts que desarrollan. Es importante que los equipos sigan scripts bien definidos a medida que trabajan a través de sus esfuerzos de evaluación de prioridades. Estos scripts deben ser procesos paso a paso que incluyen procesos de reversión para deshacer cambios que no son eficaces o pueden causar otros problemas. Use herramientas de agregación y análisis de registros no disponibles para investigar de forma eficaz los problemas que requieren un análisis profundo. Una vez resuelto el problema, siga los procesos bien definidos para devolver el componente afectado de forma segura a las rutas de flujo de carga de trabajo.

Informes de RCA

Los acuerdos de nivel de servicio (SLA) para los clientes pueden dictar que tiene que emitir informes de RCA dentro de un período de tiempo determinado después de resolver el incidente. El propietario del incidente debe crear los informes de RCA. Si eso no es posible, otra persona que trabajó estrechamente con el propietario del incidente puede crear los informes de RCA. Esta estrategia garantiza una contabilidad precisa del incidente. Normalmente, las organizaciones tienen una plantilla de RCA definida con instrucciones sobre cómo se presenta la información y qué tipos de información se pueden compartir o no. Si necesita crear su propia plantilla e instrucciones, asegúrese de que las partes interesadas las revisan y aprueban.

Postmortems de incidentes

Un individuo imparcial debe conducir postmortems sin culpa. En las sesiones posteriores a la memoria, todos comparten sus hallazgos de un incidente. Cada equipo implicado en la respuesta a incidentes debe estar representado por personas que trabajaron en el incidente. Esas personas deben venir a la sesión preparada con ejemplos de las áreas que han sido exitosas y que se pueden mejorar. La sesión no es un foro para asignar la culpa por el incidente o los problemas que podrían surgir durante la respuesta. El líder de postmortem debe dejar la sesión con una lista clara de elementos de acción que se centran en la mejora, como:

  • Mejoras en el plan de respuesta. Es posible que los procesos o procedimientos deban volver a evaluarse y reescribirse para capturar mejor las acciones adecuadas.

  • Mejoras en la plataforma de observabilidad. Es posible que sea necesario volver a evaluar los umbrales para detectar el tipo específico de incidente anteriormente, o es posible que sea necesario implementar una nueva supervisión para detectar el comportamiento que no se ha contabilizado.

  • Mejoras en la carga de trabajo. El incidente puede exponer una vulnerabilidad en la carga de trabajo que se debe abordar como una corrección permanente.

Consideraciones

Una estrategia de respuesta excesivamente agresiva puede provocar alarmas falsas o escalaciones innecesarias.

De forma similar, la implementación agresiva del escalado automático u otras acciones de recuperación automática para responder a las infracciones de umbral puede provocar gastos innecesarios y carga de administración. Es posible que no conozca los umbrales exactos que se van a establecer para las alertas y las acciones automáticas, como el escalado. Realice pruebas en entornos inferiores y en producción para ayudarle a determinar los umbrales adecuados para sus requisitos.

Facilitación de Azure

Azure Monitor es una solución completa para recopilar, analizar y responder a los datos de supervisión de entornos locales y en la nube. Incluye una sólida plataforma de alertas que puede configurar para notificaciones automáticas y otras acciones, como el escalado automático y otros mecanismos de recuperación automática.

Use Monitor para integrar el aprendizaje automático. Automatice y optimice la evaluación de prioridades de incidentes y las medidas proactivas. Para más información, consulte AIOps y aprendizaje automático en Monitor.

Log Analytics es una herramienta de análisis sólida integrada en Monitor. Puede usar Log Analytics para ejecutar consultas en registros agregados y obtener información sobre la carga de trabajo.

Microsoft ofrece entrenamiento de preparación para incidentes relacionados con Azure. Para más información, consulte Introducción a la preparación de incidentes de Azure y a la preparación de incidentes.

Lista de comprobación de excelencia operativa

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de excelencia operativa