Recomendaciones para diseñar una estrategia de recuperación ante desastres

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

En esta guía se describen las recomendaciones para diseñar una estrategia de recuperación ante desastres confiable para una carga de trabajo. Para cumplir los objetivos internos de nivel de servicio (SLO) o incluso un acuerdo de nivel de servicio (SLA) que haya garantizado para sus clientes, debe tener una estrategia de recuperación ante desastres sólida y confiable. Se esperan errores y otros problemas importantes. Los preparativos para tratar estos incidentes determinan cuánto pueden confiar sus clientes en su negocio para ofrecerlos de forma confiable. Una estrategia de recuperación ante desastres es la columna troncal de preparación para incidentes importantes.

Definiciones

Estrategias de diseño principales

En esta guía se da por hecho que ya ha realizado las siguientes tareas como parte del planeamiento de confiabilidad:

• Identificar flujos críticos y no críticos.

• Realice el análisis del modo de error (FMA) para los flujos.

• Identificar los destinos de confiabilidad.

• Diseñe la confiabilidad mediante redundancia, escalado, autoconservación y recuperación automática.

• Diseñar una estrategia de prueba sólida.

Una estrategia de recuperación ante desastres (DR) confiable se basa en una arquitectura de carga de trabajo confiable. Solucione la confiabilidad en cada fase de la creación de la carga de trabajo para asegurarse de que las partes necesarias para la recuperación optimizada están en vigor antes de empezar a diseñar la estrategia de recuperación ante desastres. Esta base garantiza que los objetivos de confiabilidad de la carga de trabajo, como el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO), sean realistas y factibles.

Mantenimiento de un plan de recuperación ante desastres

La piedra angular de una estrategia de recuperación ante desastres confiable para una carga de trabajo es el plan de recuperación ante desastres. El plan debe ser un documento vivo que se revise y actualice periódicamente a medida que evoluciona el entorno. Presente el plan a los equipos adecuados (operaciones, liderazgo tecnológico y partes interesadas empresariales) periódicamente (cada seis meses, por ejemplo). Almacénelo en un almacén de datos seguro y de alta disponibilidad, como OneDrive para la Empresa.

Siga estas recomendaciones para desarrollar el plan de recuperación ante desastres:

• Defina claramente lo que constituye un desastre y, por lo tanto, requiere la activación del plan de recuperación ante desastres.

  • Los desastres son problemas a gran escala. Pueden ser interrupciones regionales, interrupciones de servicios como Microsoft Entra id. o DNS de Azure, o ataques malintencionados graves, como ataques de ransomware o ataques DDoS.

  • Identifique los modos de error que no se consideran desastres, como el error de un único recurso, para que los operadores no invoquen erróneamente sus escalaciones de recuperación ante desastres.

• Compile el plan de recuperación ante desastres en la documentación de FMA. Asegúrese de que el plan de recuperación ante desastres captura los modos de error y las estrategias de mitigación de interrupciones definidas como desastres. Actualice el plan de recuperación ante desastres y los documentos de FMA en paralelo para que sean precisos cuando el entorno cambie o cuando las pruebas descubran comportamientos inesperados.

  • Si desarrolla planes de recuperación ante desastres para entornos que no son de producción depende de los requisitos empresariales y los impactos en los costos. Por ejemplo, si ofrece entornos de control de calidad (QA) a determinados clientes para pruebas preliminares, es posible que desee incluir esos entornos en el planeamiento de recuperación ante desastres.

• Defina claramente roles y responsabilidades dentro del equipo de carga de trabajo y comprenda los roles externos relacionados de su organización. Los roles deben incluir:

  • La parte responsable de declarar un desastre.

  • La parte responsable de declarar el cierre de incidentes.

  • Roles de operaciones.

  • Roles de prueba y validación.

  • Roles de comunicaciones internas y externas.

  • Roles principales de análisis de causa principal y retrospectiva (RCA).

• Defina las rutas de escalación que el equipo de carga de trabajo debe seguir para asegurarse de que el estado de recuperación se comunica a las partes interesadas.

• Capture procedimientos de recuperación de nivel de componente, recuperación de nivel de patrimonio de datos y procesos de recuperación para toda la carga de trabajo. Incluya un orden prescrito de operaciones para asegurarse de que los componentes se recuperan de la manera menos impactante. Por ejemplo, recupere y compruebe las bases de datos antes de recuperar la aplicación.

  • Detalla cada procedimiento de recuperación de nivel de componente como guía paso a paso. Incluya capturas de pantalla si es posible.

  • Defina las responsabilidades del equipo frente a las responsabilidades del proveedor de hospedaje en la nube. Por ejemplo, Microsoft es responsable de restaurar un PaaS (plataforma como servicio), pero es responsable de rehidratar los datos y aplicar la configuración al servicio.

  • Incluya los requisitos previos para ejecutar el procedimiento. Por ejemplo, enumere los scripts o credenciales necesarios que deben recopilarse.

  • Capture la causa principal del incidente y realice la mitigación antes de iniciar la recuperación. Por ejemplo, si la causa del incidente es un problema de seguridad, mitigue ese problema antes de recuperar los sistemas afectados en el entorno de conmutación por error.

• En función del diseño de redundancia de la carga de trabajo, es posible que tenga que realizar un trabajo importante posterior a la conmutación por error antes de que la carga de trabajo esté disponible de nuevo para los clientes. El trabajo posterior a la conmutación por error podría incluir actualizaciones de DNS, actualizaciones de base de datos cadena de conexión y cambios de enrutamiento del tráfico. Capture todo el trabajo posterior a la conmutación por error en los procedimientos de recuperación.

  Nota

  El diseño de redundancia puede permitirle recuperarse automáticamente de incidentes principales completamente o parcialmente, por lo que asegúrese de que el plan incluye procesos y procedimientos en torno a estos escenarios. Por ejemplo, si tiene un diseño totalmente activo-activo que abarca zonas de disponibilidad o regiones, es posible que pueda conmutar por error de forma transparente automáticamente después de una interrupción regional o zona de disponibilidad y minimizar los pasos del plan de recuperación ante desastres que deben realizarse. De forma similar, si ha diseñado la carga de trabajo mediante stamps de implementación, es posible que solo se produzca una interrupción parcial si los stamps se implementan de forma zonal. En este caso, el plan de recuperación ante desastres debe cubrir cómo recuperar sellos en zonas o regiones no afectadas.

• Si necesita volver a implementar la aplicación en el entorno de conmutación por error, use herramientas para automatizar el proceso de implementación tanto como sea posible. Asegúrese de que las canalizaciones de DevOps se han preimplementado y configurado en los entornos de conmutación por error para que pueda iniciar inmediatamente las implementaciones de la aplicación. Use implementaciones automatizadas de un extremo a otro, con puertas de aprobación manuales cuando sea necesario, para garantizar un proceso de implementación coherente y eficaz. La duración completa de la implementación debe alinearse con los destinos de recuperación.

  • Cuando una fase del proceso de implementación requiere intervención manual, documente los pasos manuales. Defina claramente los roles y las responsabilidades.

• Automatice la mayor parte del procedimiento que pueda. En los scripts, use la programación declarativa porque permite la idempotencia. Cuando no pueda usar programación declarativa, tenga en cuenta el desarrollo y la ejecución del código personalizado. Use la lógica de reintento y la lógica del disyuntor para evitar perder tiempo en los scripts que están bloqueados en una tarea rota. Dado que ejecuta estos scripts solo en situaciones de emergencia, no quiere que los scripts desarrollados incorrectamente causen más daños o ralentice el proceso de recuperación.

  Nota

  La automatización supone riesgos. Los operadores entrenados deben supervisar cuidadosamente los procesos automatizados e intervenir si algún proceso encuentra problemas. Para minimizar el riesgo de que la automatización reaccione a falsos positivos, sea exhaustiva en los simulacros de recuperación ante desastres. Pruebe todas las fases del plan. Simule la detección para generar alertas y, a continuación, pase por todo el procedimiento de recuperación.

  Recuerde que los simulacros de recuperación ante desastres deben validar o informar a las actualizaciones de las métricas de destino de recuperación. Si observa que la automatización es susceptible a falsos positivos, es posible que tenga que aumentar los umbrales de conmutación por error.

• Separe el plan de conmutación por recuperación del plan de recuperación ante desastres para evitar posibles confusiones con los procedimientos de recuperación ante desastres. El plan de conmutación por recuperación debe seguir todas las recomendaciones de desarrollo y mantenimiento del plan de recuperación ante desastres y debe estructurarse de la misma manera. Los pasos manuales necesarios para la conmutación por error deben reflejarse en el plan de conmutación por recuperación. La conmutación por recuperación puede producirse rápidamente después de la conmutación por error o puede tardar días o semanas. Considere la conmutación por recuperación como independiente de la conmutación por error.

  • La necesidad de conmutar por recuperación es situacional. Si está enrutando el tráfico entre regiones por motivos de rendimiento, la conmutación por recuperación de la carga originalmente en la región conmutada por error es importante. En otros casos, es posible que haya diseñado la carga de trabajo para funcionar completamente independientemente del entorno de producción en el que se encuentre en cualquier momento.

Realización de simulacros de recuperación ante desastres

Una práctica de pruebas de recuperación ante desastres es tan importante como un plan de recuperación ante desastres bien desarrollado. Muchos sectores tienen marcos de cumplimiento que requieren que se realicen periódicamente un número especificado de simulacros de recuperación ante desastres. Independientemente de su sector, los simulacros de recuperación ante desastres normales son primordiales para su éxito.

Siga estas recomendaciones para obtener simulacros de recuperación ante desastres correctos:

• Realice al menos un simulacro de recuperación ante desastres de producción por año. Los simulacros de tableta (seco) o los simulacros que no son de producción ayudan a garantizar que las partes implicadas estén familiarizados con sus roles y responsabilidades. Estos simulacros también ayudan a los operadores a crear familiaridad ("memoria muscular") siguiendo los procesos de recuperación. Pero solo los simulacros de producción prueban realmente la validez del plan de recuperación ante desastres y las métricas de RTO y RPO. Use los simulacros de producción para los procesos de recuperación de tiempo de los componentes y los flujos para asegurarse de que se pueden lograr los destinos RTO y RPO definidos para la carga de trabajo. Para las funciones que están fuera del control, como la propagación de DNS, asegúrese de que los destinos de RTO y RPO para los flujos que implican esas funciones tienen en cuenta posibles retrasos más allá del control.

• Use taladros de tableta no solo para crear familiaridad para los operadores entrenados, sino también para educar a los nuevos operadores sobre los procesos y procedimientos de recuperación ante desastres. Los operadores sénior deben tardar tiempo en permitir que los nuevos operadores realicen su rol y deben watch para mejorar las oportunidades. Si un operador nuevo está indecible o confundido por un paso en un procedimiento, revise ese procedimiento para asegurarse de que está claramente escrito.

Consideraciones

• La realización de simulacros de recuperación ante desastres en producción puede provocar errores catastróficos inesperados. Asegúrese de probar los procedimientos de recuperación en entornos que no son de producción durante las implementaciones iniciales.

• Dé al equipo tanto tiempo de mantenimiento como sea posible durante los simulacros. Al planear el tiempo de mantenimiento, use las métricas de recuperación que se capturan durante las pruebas como tiempo mínimo necesario para las asignaciones.

• A medida que maduran las prácticas de exploración de recuperación ante desastres, aprenderá qué procedimientos puede ejecutar en paralelo y cuál debe ejecutar en secuencia. Al principio de las prácticas de obtención de detalles, supongamos que cada procedimiento debe ejecutarse en secuencia y que necesita tiempo adicional en cada paso para controlar problemas imprevistos.

Facilitación de Azure

Muchos productos de Azure tienen funcionalidades de conmutación por error integradas. Familiarícese con estas funcionalidades e inclúyelas en los procedimientos de recuperación.

En el caso de los sistemas IaaS (infraestructura como servicio), use Azure Site Recovery para automatizar la conmutación por error y la recuperación. Consulte los siguientes artículos para obtener productos comunes de PaaS:

• Azure App Service

• Azure Container Apps

• Azure Kubernetes Service

• Azure SQL Database

• Azure Event Hubs

• Azure Cache for Redis

Ejemplo

Consulte la serie de la plataforma de datos de Recuperación ante desastres de Azure para obtener instrucciones sobre cómo preparar un patrimonio de datos empresarial para la recuperación ante desastres.

Vínculos relacionados

• Recomendaciones para el diseño de redundancia

• Recomendaciones para el diseño de varias regiones de alta disponibilidad

• Recomendaciones para usar zonas de disponibilidad y regiones

Lista de comprobación de confiabilidad

Consulte el conjunto completo de recomendaciones.