Desarrollo de un plan de recuperación ante desastres para implementaciones en varias regiones

Como arquitecto de soluciones en la nube, desempeña un papel clave para garantizar que la recuperación de errores de ámbito amplio se planee, diseñe y documente intencionadamente como un plan de recuperación ante desastres (DR). En caso de fracaso, la calidad de ese plan influye en si el evento es un retroceso temporal o se convierte en una crisis financiera y de reputación.

El plan debe basarse en estrategias guiadas por prioridades empresariales y regidas por objetivos medibles. Este artículo le guía a través del proceso de desarrollo de un plan práctico de recuperación ante desastres, empezando por las prácticas fundamentales de restauración de servicios a un cambio de mentalidad que defiende la continuidad empresarial bajo presión.

En este artículo se centra en cómo lograr la continuidad empresarial a través de mitigaciones técnicas y procesos. Antes de comenzar, revise las estrategias clave y elija las que tienen sentido para su negocio. Consulte Estrategias de arquitectura DE RE:09 para la recuperación ante desastres para obtener más información.

Un plan de recuperación ante desastres debe basarse en los principios básicos de la administración de incidentes, que sirve como requisito previo para la planificación eficaz de la recuperación ante desastres. Para obtener instrucciones sobre el desarrollo de un plan de administración de incidentes, consulte Desarrollo de una práctica de administración de incidentes para recuperarse de interrupciones.

Terminología

Antes de empezar a desarrollar su plan, le recomendamos que se familiarice con un vocabulario común. Establezca estos términos como lenguaje compartido para permitir una comunicación clara y una toma de decisiones coordinadas al activar el plan de recuperación ante desastres.

Término	Definición
Activo-activo (en espera activa)	Dos o más entornos totalmente operativos y que gestionan el tráfico en tiempo real simultáneamente en varias regiones. Si se produce un error en un entorno, otros siguen controlando la carga con una interrupción cero o casi cero.
Activo-pasivo (espera en frío)	Entorno que no se está ejecutando y requiere el aprovisionamiento de recursos y la restauración de datos cuando se activa. Menor costo, mayor tiempo de recuperación.
Activo-pasivo (espera pasiva)	Entorno aprovisionado parcialmente que ejecuta servicios mínimos que se pueden escalar rápidamente durante los fallos.
Continuidad empresarial	Las estrategias para garantizar que las operaciones críticas continúen durante y después de las interrupciones, abarcando la recuperación ante desastres, el personal, la comunicación y los procesos.
Plan de recuperación ante desastres (DR)	Procedimientos detallados y ejecutables para recuperar sistemas específicos, incluidas las acciones paso a paso, los roles, las responsabilidades, las secuencias de conmutación y los flujos de trabajo de comunicación.
Estrategia de recuperación ante desastres (DR)	Enfoque de alto nivel que define objetivos, principios y posición de recuperación para responder a errores catastróficos en todas las cargas de trabajo.
Activación de DR	Decisión formal para iniciar procedimientos de recuperación ante desastres, normalmente que requieren autorización ejecutiva.
Conmutación por recuperación	Proceso de devolver cargas de trabajo al entorno principal original después de la resolución de incidentes.
Conmutación por error	Proceso de cambio de cargas de trabajo del entorno principal al en espera durante un desastre.
Objetivo de punto de recuperación (RPO)	Cantidad de pérdida de datos que se puede tolerar antes de incurrir en pérdidas importantes. El RPO determina la frecuencia con la que se debe realizar una copia de seguridad de los datos esenciales.
Objetivo de tiempo de recuperación (RTO)	Cantidad de tiempo que se tarda en restaurar el acceso, los datos y las funcionalidades esenciales después de un desastre relacionado con la tecnología.

¿Qué es la recuperación ante desastres?

La recuperación ante desastres (DR) es un enfoque estratégico y metódico para restaurar sistemas o partes críticas de ellos, después de un evento de error importante.

En entornos de nube, los errores temporales son normales. Estas breves interrupciones, a menudo denominadas errores blips o transitorios, pueden dar lugar a la falta de disponibilidad de componentes aislados o caídas inesperadas en el rendimiento. Normalmente se resuelven a través de características de resistencia de plataforma y mecanismos integrados de recuperación automática sin intervención humana.

Sin embargo, los desastres son una clase de evento diferente. Son amplios en el ámbito, afectan simultáneamente a varios sistemas o servicios y pueden detener el sistema. Estos eventos requieren intervención externa y roles especializados, guiados por un plan de recuperación ante desastres bien definido que se puede activar cuando la capacidad de autorrecuperación integrada del sistema no es suficiente. Algunos ejemplos son:

• Interrupciones regionales totales

• Pérdida de funcionalidades de acceso al plano de control o administración de servicios

• Entornos de producción dañados debido a una actividad malintencionada o a una configuración incorrecta crítica

• Errores graves de infraestructura que afectan a varios niveles del sistema

• Desastres naturales o eventos geopolíticos que provocan la indisponibilidad prolongada del servicio

Los problemas transitorios desatendidos pueden convertirse en desastres de gran magnitud. Aunque el modelado avanzado de supervisión y estado puede ayudar a detectar y mitigar estos problemas al principio, ese tema está fuera del ámbito de este artículo. Para obtener más información, consulte Modelado de estado.

El objetivo final de la recuperación ante desastres es mantener la continuidad empresarial dentro de las métricas cuantitativas definidas. Piense en el plan como un esfuerzo coordinado que requiere procedimientos predefinidos, protocolos de comunicación claros y toma de decisiones de nivel ejecutivo.

Selección del nivel de importancia crítica

No todas las cargas de trabajo (o partes de ella) necesitan un plan de recuperación heroico. La recuperación debe reflejar su importancia.

Importante

La criticidad es una decisión de negocio y es su responsabilidad orientar esa decisión. Depende de lo que haga la carga de trabajo, quién dependa de ella y qué ocurra si deja de funcionar. Azure no decide qué es crítico para la misión, tú lo decides. Si una interrupción afectara a los ingresos, dañara la confianza del cliente o le hiciera incumplir normativas, ese es un sistema crítico. Posee esa decisión y diseña con ella en mente.

Sobrediseñar servicios de bajo impacto desperdicia recursos; una preparación inadecuada de los de alto impacto conlleva consecuencias graves. La clave es dimensionar correctamente su estrategia de recuperación en función del impacto empresarial. Use los siguientes niveles de clasificación como punto de partida para evaluar la importancia crítica y alinear las inversiones de recuperación ante desastres de forma adecuada.

Una manera común de cuantificar los niveles es mediante objetivos de nivel de servicio (SLO), que a menudo se expresan como "cinco nueves" (99,999%), "cuatro nueves" (99,99%), etc. Estos percentiles representan ampliamente el nivel de disponibilidad esperado para una carga de trabajo determinada.

Las métricas más importantes de la estrategia de recuperación ante desastres son el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO), ambos cuantificados como unidades de tiempo. RTO define la rapidez con la que se debe restaurar un sistema después de una interrupción. Representa la tolerancia de la organización para el tiempo de inactividad. RPO define la cantidad de pérdida de datos aceptable y refleja la frecuencia con la que se debe realizar una copia de seguridad de los datos.

En este artículo se da por supuesto que los SLO y las métricas de recuperación ya se han definido y no tratarán cómo calcularlos. Si necesita instrucciones sobre cómo establecer SLO significativos, consulte Métricas de confiabilidad.

Nivel 0: Crítico para la misión

El nivel crítico incluye cargas de trabajo completas o componentes específicos en los que el tiempo de inactividad no es una opción y el ahorro de costos es secundario a la continuidad. Estos sistemas son fundamentales para la organización, impulsando directamente los ingresos, protegiendo la confianza del cliente o afectando a la vida. Entre los ejemplos comunes se incluyen plataformas financieras, sistemas sanitarios e infraestructura de seguridad.

Este nivel exige SLO por encima de 99,99%, con RTO medido en segundos y RPO que se aproxima a cero. Para cumplir estos requisitos, normalmente es necesaria una implementación activa y activa en varias regiones, lo que permite la recuperación instantánea sin interrupciones a los usuarios.

Cuando se produce un error en los sistemas críticos, las consecuencias son inmediatas y significativas: ingresos perdidos, daños de reputación o exposición normativa.

Nivel 1: Crítico para la empresa

Los sistemas críticos para la empresa son esenciales para las operaciones diarias y la experiencia del cliente, pero a diferencia de los sistemas críticos, pueden tolerar breves períodos de interrupción, siempre y cuando la recuperación sea rápida y la pérdida de datos sea mínima. Estos sistemas suelen estar controlados por incentivos de ingresos, como plataformas de comercio electrónico, aplicaciones orientadas al cliente y portales de asociados.

Normalmente requieren SLOs de aproximadamente el 99,95%, con el RTO y RPO medidos en minutos. A menudo se utiliza una mezcla de implementaciones activo-activo o en espera cálida para equilibrar la resistencia con el costo.

Aunque las interrupciones cortas pueden ser supervivientes, el tiempo de inactividad prolongado en este nivel afecta directamente a los ingresos, la satisfacción del usuario y la credibilidad de la marca. La predicción y la velocidad de recuperación son fundamentales.

Nivel 2: Operativo empresarial

Los sistemas operativos empresariales admiten equipos y procesos internos. Aunque no son directamente orientadas al cliente, son esenciales para la productividad y la continuidad operativa. Entre los ejemplos típicos se incluyen plataformas de informes, paneles internos y herramientas administrativas.

Estos sistemas suelen estar orientados hacia los SLO alrededor del 99,9%, con los RTO y RPO medidos en horas. Es habitual una estrategia de implementación activa-pasiva con implementación activa/inactiva, en la que los entornos secundarios permanecen inactivos hasta que sea necesario, optimizando el costo con respecto a la velocidad de recuperación.

Es posible que las interrupciones de este nivel no afecten inmediatamente a los clientes, pero las interrupciones más largas pueden ralentizar la empresa. La recuperación oportuna es importante, incluso si no es inmediata.

Nivel 3: Administrativo

Los sistemas administrativos son cargas de trabajo no críticas que admiten operaciones en segundo plano o sirven casos de uso de baja urgencia. Normalmente se incluyen plataformas de archivado, entornos de espacio aislado, portales de entrenamiento o herramientas de procesamiento por lotes donde la disponibilidad no es sensible al tiempo.

Con los SLO por debajo de 99,9%, estos sistemas toleran ventanas de recuperación más largas, con RTO que va de horas a días y RPO medido en horas. El enfoque más rentable aquí suele ser la copia de seguridad y restauración, lo que minimiza los costos de infraestructura en curso, a la vez que se conserva la capacidad de recuperación.

Aunque los retrasos en este nivel son generalmente aceptables, la integridad de los datos debe estar protegida. Es posible que estos sistemas no detengan la empresa si dejan de funcionar, pero perderlos por completo podrían seguir generando riesgos de cumplimiento o brechas de conocimiento a lo largo del tiempo.

Clasificación de la carga de trabajo

Antes de iniciar la estrategia de recuperación ante desastres, clasifique las cargas de trabajo en función de los requisitos reales de impacto empresarial y recuperación.

Empiece por enumerar cada flujo de usuario de la carga de trabajo. Documente lo que hace, quién se basa en él y qué sucede si deja de funcionar. Los distintos flujos dentro de la misma carga de trabajo pueden requerir diferentes estrategias de recuperación ante desastres en función de su impacto empresarial individual y importancia crítica.

Trabaje con las partes interesadas de su empresa para obtener su firma en estas clasificaciones. Confirme los objetivos de RTO y RPO basados en consecuencias empresariales reales, no solo opiniones técnicas. Su compromiso establece la base y la estrategia de recuperación ante desastres se basa en ello. Sin alineación con el riesgo empresarial, una respuesta técnica carece de dirección.

Revise estas clasificaciones periódicamente. A medida que evolucionan las necesidades empresariales, actualice el plan de recuperación ante desastres según corresponda.

Cuidado con estos puntos de fricción

Estos son algunos puntos clave de fricción con los que debe tener cuidado, ya que de lo contrario, la planificación de la recuperación ante desastres podría convertirse en un ejercicio costoso sin los resultados adecuados.

• Falta de coincidencia entre las expectativas y el presupuesto. Establezca las expectativas correctamente para que las partes interesadas no esperen un rendimiento en espera activa en un presupuesto de espera en frío. La brecha entre las promesas de RTO/RPO y los presupuestos puede provocar riesgos y decepción.

• Las dependencias de servicio compartido pueden romper la cadena. El plan de recuperación ante desastres solo es tan eficaz como su componente más débil. Si las cargas de trabajo dependen de recursos compartidos o de terceros, que carecen de estrategias de conmutación por error adecuadas, puede crear vulnerabilidades durante un desastre.

• Los criterios de activación de recuperación ante desastres deben ser perfectamente claros. Todos los individuos enumerados en la lista de responsabilidad deben tener claridad sobre los criterios. Sin esto, puede haber dudas para iniciar la recuperación, lo que puede provocar retrasos innecesarios.

• La conmutación por recuperación es tan importante como la conmutación por error. Aunque muchos se centran en tratar la conmutación por error como una transferencia unidireccional, a veces la conmutación por recuperación es una opción viable. Sin embargo, la devolución de operaciones al sitio primario suele implicar más complejidad. Asegúrese de planear y probar los procedimientos de recuperación ante fallos. Una buena guía es automatizar la conmutación en caso de fallo al administrar la conmutación de recuperación a través de un proceso controlado.

Optimización de los costos de recuperación

El costo de la recuperación ante desastres se escala con la importancia de la carga de trabajo.

• El nivel 0 (Crítico de Misión) viene con el costo más alto, lo cual es de esperar. Las implementaciones activas y la infraestructura redundante aumentan significativamente el gasto a cambio de casi cero tiempo de inactividad. En lo que respecta a la optimización de costos, las mejores opciones son procedimientos estándar, como instancias reservadas o Ventaja híbrida de Azure cuando corresponda.

  Esfuércese por la simplicidad en su diseño. La ingeniería excesiva más allá de los requisitos bien definidos es donde los costos ocultos se acumulan silenciosamente. Tenga en cuenta que las prácticas fundamentales, como la infraestructura como código, las implementaciones automatizadas y las pruebas, presentan un esfuerzo inicial de ingeniería. Aunque ese esfuerzo podría competir con la entrega de nuevas características, poner en peligro la inversión en operaciones sólidas no es simplemente una opción.

• El nivel 1 (Crítico para la empresa) ofrece un equilibrio, normalmente mediante entornos de espera cálidos que reducen el costo.

  Reduzca la capacidad de línea base en el standby cálido mediante la implementación de recursos de cómputo en la región secundaria a escala parcial, habilitando la escalabilidad automática para aumentar solo cuando sea necesario. Este enfoque evita pagar por capacidad completa 24/7.

  Uso del proceso de conmutación por error desencadenado manualmente con un runbook orquestado para reducir la complejidad y los costos operativos continuos en comparación con la conmutación por error totalmente automatizada. Las pruebas de conmutación por error periódicas ayudan a identificar las ineficiencias,

• El nivel 2 (operativo empresarial) se centra en optimizar los costos mediante configuraciones de espera en frío y opciones de pago por uso, como instancias puntuales y precios de consumo. Automatice el aprovisionamiento de la computación en PaaS en la región secundaria solo cuando sea necesario para evitar pagar por recursos inactivos. Defina criterios de desastre claros y procesos de conmutación para evitar fallos innecesarios. Las pruebas periódicas garantizan que se cumplan los objetivos de recuperación y resalte las áreas para reducir los costos.

• El nivel 3 (administrativo) da prioridad al ahorro de costos al confiar en el almacenamiento de copia de seguridad y archivado con ventanas de recuperación más largas. Utiliza copias de seguridad replicadas y bóvedas de Azure Backup en una región secundaria para proteger los datos persistentes sin ejecutar la infraestructura de reserva. Pruebe periódicamente los procesos de restauración para garantizar la confiabilidad al tiempo que mantiene los gastos en un mínimo.

Independientemente del nivel que sea, use las herramientas adecuadas para revisar los costos. Use herramientas como Microsoft Cost Management y Azure Advisor para supervisar, predecir y optimizar el gasto en todos los niveles. Etiquete los recursos y establezca umbrales presupuestarios para facilitar el seguimiento de los modelos de responsabilidad y contracargo. Para obtener información sobre las etiquetas recomendadas por Microsoft, consulte Etiquetado de cargas de trabajo críticas.

Documentar el plan de recuperación ante desastres

Un plan fuerte de recuperación ante desastres (DR) convierte la estrategia en una acción decisiva. La activación comienza con una combinación de alertas automatizadas y supervisión humana. Las herramientas de observabilidad marcan posibles problemas, como ralentizaciones del rendimiento y desencadenan alertas para que el equipo de operaciones investigue. Revisan los paneles de anomalías y evalúan la situación. Si el problema aparece más amplio o más grave, es posible que se escale y se puedan implicar equipos adicionales. Una vez que haya suficiente evidencia, el responsable de recuperación ante desastres declara formalmente un desastre, iniciando un proceso de conmutación por error estructurado para mantener la continuidad del sistema.

Para que esto sea posible, todos los planes de recuperación ante desastres deben incluir tres componentes esenciales: un runbook claro, un plan de comunicación bien definido y una ruta de escalación estructurada.

Plan de comunicación de DR

Un plan de comunicación garantiza que la información adecuada llegue a las personas adecuadas en el momento adecuado durante una interrupción. Apoya la coordinación, reduce la confusión y mantiene a las partes interesadas informadas durante el proceso de recuperación. El plan debe cubrir estos aspectos:

• Criterios de activación y aprobaciones. Establezca lo que califica como un evento de recuperación ante desastres. Identifique quién tiene autoridad para desencadenar el proceso de recuperación ante desastres. Documente las rutas de escalación y los puntos de control de decisión.

• Roles y responsabilidades. Defina quién es responsable de comunicarse y a quién.

• Partes interesadas clave. Identifique audiencias internas y externas clave, como, por ejemplo, empleados, liderazgo, asociados y clientes.

• Canales de comunicación. Establezca métodos principales y de copia de seguridad como correo electrónico, SMS y otros. Establezca también la frecuencia de actualizaciones de esos canales.

• Notificaciones y plantillas. Describa cuándo enviar actualizaciones y preparar plantillas de mensajería aprobadas previamente para los canales de correo electrónico, página de estado e incidentes.

• Escalación y continuidad. Asegúrese de que hay una manera estructurada de escalar los problemas si alguien no está disponible o las cosas cambian rápidamente. Los planes de comunicación deben abordar a las partes interesadas internas y externas con los detalles y la frecuencia adecuados y usar canales independientes. La comunicación interna proporciona actualizaciones periódicas a la dirección ejecutiva y a los usuarios empresariales, centrándose en el impacto empresarial, las escalas de tiempo y las necesidades de recursos. La comunicación externa coordina con clientes, socios y organismos reguladores, e incluye los plazos actuales y realistas para la restauración.

Manual operativo de recuperación ante desastres

Un runbook sólido reemplaza las estrategias abstractas por una estructura definida y permite al equipo responder bajo presión. Hazlo claro, hazlo práctico y asegúrate de que funciona. Comience con un esquema sencillo y compile gradualmente. Colabore con empresas, seguridad y operaciones para garantizar una cobertura completa.

• Documente los procedimientos de conmutación por error y recuperación ante fallos. Escriba instrucciones técnicas paso a paso para iniciar la conmutación por error. Herramientas y guiones de referencia para ejecutar utilizando enlaces o referencias. Establecer criterios para iniciar la conmutación inversa y los pasos coordinados de transición.

  Desarrolle un proceso paso a paso para la ejecución de la conmutación por error de sistema:

  Acción	Propietario	Criterios
  1. Detección de incidentes	Supervisión y operaciones	El incidente se desencadena mediante alertas o informes de usuario.
  2. Evaluación de la gravedad	Administrador de incidentes	Use la tabla de clasificación de incidentes para determinar el nivel de gravedad.
  3. Declarar interrupción (si es necesario)	Líder Senior de Operaciones/BCDR	Declare una interrupción solo para incidentes de gravedad alta y crítica.
  4. Notificar a las partes interesadas	Responsable de comunicaciones	Siga el plan de comunicación establecido para las notificaciones.
  5. Iniciar la ejecución del runbook	Equipo de operaciones	Inicie la ejecución de la guía de recuperación ante desastres, que incluye guías automatizadas y pasos manuales.
  6. Preparar la infraestructura secundaria	Equipo de operaciones	Implemente, incremente y valide la configuración de infraestructura en el entorno secundario.
  7. Garantizar la integridad de los datos	Equipo de operaciones	Restaure los datos de las copias de seguridad, si es necesario, y valide la integridad de los datos y la adhesión al RPO.
  8. Recuperación de aplicaciones	Equipo de operaciones y control de calidad	Implemente, si es necesario, y active aplicaciones en el entorno secundario. Validar la operación correcta y todas las dependencias
  9. Transición del tráfico	Equipo de operaciones	Transición del usuario al entorno secundario. Actualizar registros DNS si es necesario
  10. Cierre el incidente y documente las acciones tomadas	Administrador de incidentes	Realice un análisis post-mortem y actualice los registros de incidentes.

  Del mismo modo, cree un proceso de decisión y ejecución de recuperación ante fallos, (región primaria disponible):

  Acción	Propietario	Criterios y punto de decisión
  1. Supervisar el estado de la región primaria	Equipo de Operaciones/Equipo de Nube	Compruebe que la región primaria pasa todas las comprobaciones de estado y está totalmente operativa. Use herramientas de supervisión automatizadas y validación manual para confirmar la preparación.
  2. Evaluar el impacto empresarial	Continuidad empresarial/propietario de la aplicación	Confirme la preparación del negocio para el failback, incluidas las ventanas de tráfico bajo y las aprobaciones necesarias. Coordinarse con las partes interesadas para garantizar que el tiempo se alinee con las necesidades empresariales.
  3. Revisar la sincronización de datos	Equipo de base de datos e infraestructura	Asegúrese de que los datos de la región secundaria se sincronizan con el principal y cumplen los requisitos de RPO/RTO. Use paneles de estado de replicación para comprobar la coherencia de los datos.
  4. Comunicar el plan de restablecimiento	Administrador de incidentes	Notifique a las partes interesadas sobre el failback planeado, incluyendo la línea temporal y el impacto potencial. Use herramientas de correo electrónico, Teams o administración de incidentes para la comunicación.
  5. Preparar la región primaria	Equipo de infraestructura/nube	Compruebe que los componentes de infraestructura, seguridad y aplicación están listos en la región primaria. Ejecute listas de verificación previas al failback para garantizar la preparación completa.
  6. Iniciar la reversión	Equipo de Operaciones/Equipo de Nube	Continúe solo con la solicitud de cambio aprobada y cuando se cumplan todos los criterios. Comience a redirigir el tráfico y las cargas de trabajo a la región primaria.
  7. Supervisar el progreso del proceso de regreso	Equipo de Operaciones/Equipo de Nube	Supervise si hay errores, latencia o pérdida de datos durante el proceso de transición. Use paneles y sistemas de alertas para realizar un seguimiento del progreso.
  8. Validar la funcionalidad de la aplicación	Propietario de la aplicación/QA	Confirme que las aplicaciones y los servicios son totalmente funcionales en la región primaria. Ejecute pruebas de humo y pruebas de regresión para validar la funcionalidad.
  9. Finalización y cierre del incidente	Administrador de incidentes	Asegúrese de que todos los sistemas son estables, se informa a las partes interesadas y se actualiza la documentación. Complete el análisis post mortem y capture las lecciones aprendidas.

• Establecer comprobaciones de preparación y validación de salud. Defina cómo comprobar la funcionalidad del servicio después de la conmutación por error. Incluya comprobaciones de integridad de datos, infraestructura e nivel de aplicación.

• Planee la recuperación y la revisión posteriores. Describir las acciones para limpiar entornos temporales. Documente la conciliación de datos si procede. Programe el análisis de causa raíz y el informe de recuperación ante desastres.

Sugerencia

Trate el runbook de recuperación ante desastres como el código de producción: establezca versiones y asegúrese de que sea accesible. Use herramientas de control de versiones como Git o una wiki con versiones para realizar un seguimiento de las actualizaciones y garantizar la precisión a lo largo del tiempo. Igualmente importante, asegúrese de que el runbook siempre esté accesible, incluso durante una interrupción. Guárdelo en varios formatos, incluidas las versiones sin conexión o imprimibles, para que los equipos puedan acceder a él cuando sea más importante.

Plan de escalación de recuperación ante desastres

Durante la recuperación ante desastres, la velocidad y la claridad son todo. Un plan de escalada garantiza que, cuando las cosas no vayan según el plan, se alertará rápidamente a las personas adecuadas.

• Desencadenadores de escalación. Defina exactamente cuándo escalar, ya sea un hito de recuperación perdido, una falla crítica del sistema o un proveedor que no responde.

• Cadena de comandos. En la lista identificada de roles y contactos, indicar en qué orden contactar. Es decir, cómo gestionar la escalación de problemas a través del personal principal, secundario y de respaldo. Incluya también expectativas de tiempo de respuesta. Por ejemplo, llame al administrador de recuperación ante desastres dentro de 15 minutos por teléfono o en una plataforma de comunicaciones de emergencia.

• Niveles de gravedad del incidente. Clasifique los incidentes por impacto para que los problemas menores no obstruyan el sistema y los mayores obtengan atención inmediata del liderazgo.

Esta es una plantilla de ejemplo:

Nivel de gravedad	Description	Examples	Activador de declaración de falla	Partes interesadas notificadas
Low	Degradación de servicios menores	Pico de latencia breve	Ninguna declaración formal	Equipo de operaciones
Mediana	Degradación parcial del servicio	Errores de servicio único	Incidente registrado, bajo observación	Operaciones, clientes potenciales de negocio
High	Interrupción importante, impacto generalizado	Error de varios servicios	Declaración de interrupción formal	Todas las partes interesadas, clientes
Crítico	Pérdida total, crítico para la empresa	Error de Azure regional completo	Declaración inmediata, nivel ejecutivo	Todas las partes interesadas, equipo ejecutivo

Prueba periódica y mejora del plan

La recuperación ante desastres es una materia operativa. Un plan de recuperación ante desastres que nunca se ha probado permanece teórico y sin verificar.

• Ensaye el manual de procedimientos de manera regular para simular escenarios y aclarar los roles del equipo.

• Programe simulacros de conmutación por error completos o parciales para validar los pasos y los tiempos reales de recuperación. Una conmutación por error planeada simula una interrupción regional para ensayar suaves transiciones del sistema. Las herramientas como Azure Chaos Studio se usan para probar errores no planeados y ver cómo responden los sistemas.

• Después de cada prueba, compruebe los datos para confirmar que no se perdió ni se ha dañado nada. Capture los huecos o problemas detectados y actualice rápidamente la arquitectura y los runbooks.

Estrategia de recuperación para la copia de seguridad y restauración

Las estrategias de copia de seguridad y restauración deben formar parte de todas las estrategias de recuperación.

Acciones recomendadas

Úselo como base para todos los niveles. Cada paso debe incluir un objetivo claro y una manera de validar su eficacia.

Acciones	Configuración	Validation
Configuración de directivas de copia de seguridad y retención	- Configurar programaciones de copia de seguridad y períodos de retención para la infraestructura y las bases de datos alineadas con los requisitos de RPO - Uso de Azure Backup para máquinas virtuales, Azure Files y Blob Storage - Almacenar copias de seguridad en la región secundaria, como utilizando una Bóveda de Respaldo Geo-Redundante cuando esté disponible.	- Prueba de la ejecución de la directiva de copia de seguridad - Comprobación de la finalización e integridad de la copia de seguridad - Validar la aplicación de directivas de retención
Implementación de niveles de almacenamiento rentables	- Uso de niveles de almacenamiento de archivo o acceso esporádico para datos a los que se accede con poca frecuencia - Aplicación de directivas de niveles de copia de seguridad para realizar la transición de las copias de seguridad anteriores a opciones de menor costo - Configuración de la compresión y desduplicación para minimizar los costos de almacenamiento	- Revisión de los informes de optimización de costos de almacenamiento - Verificación de la ejecución de la política de jerarquización - Prueba de la recuperación de datos de diferentes niveles de almacenamiento
Procedimientos de restauración de documentos	- Mantenimiento de runbooks con pasos de recuperación detallados - Definición de entornos de destino para la restauración - Incluir listas de contactos para aprobaciones y escalaciones	- Probar la precisión de la documentación del procedimiento de restauración - Comprobar la moneda de la información de contacto - Probar rutas de escalación y flujos de trabajo de aprobación
Supervisión de los costos y el cumplimiento de las copias de seguridad	- Establecimiento de umbrales de presupuesto para recursos relacionados con la copia de seguridad - Aplicar etiquetas específicas de copia de seguridad para habilitar el seguimiento adecuado - Configuración de directivas de retención para cumplir los requisitos de cumplimiento normativo	- Revisión mensual de los informes de costos de copia de seguridad - Comprobación de la eficacia del umbral de presupuesto - Auditar el cumplimiento de las directivas de retención
Mantenimiento y auditoría de sistemas de copia de seguridad	- Realizar auditorías trimestrales de los requisitos de copia de seguridad - Retirar sistemas obsoletos y ajustar directivas - Revisión y actualización de los requisitos de RPO/RTO en función de los cambios empresariales y tecnológicos	- Comprobación de que se abordan los resultados de auditoría - Confirmar que los sistemas retirados se han retirado correctamente - Validar que los cambios de los requisitos de RPO/RTO son factibles.

Estrategia de recuperación para sistemas activo-pasivo (modalidad de espera en frío)

Las implementaciones de espera en frío activa-pasiva mantienen los recursos de computación de la región secundaria detenidos hasta que se necesiten. Este enfoque es ideal para las cargas de trabajo de nivel 2 o nivel 3, donde los RTO pueden tolerar retrasos más largos, pero la recuperación debe ser confiable y repetible.

La región primaria controla todo el tráfico de producción mientras la región secundaria mantiene la preparación de la infraestructura con recursos en ejecución mínimos, lo que requiere activación manual durante escenarios de desastre.

Acciones recomendadas

Cree estrategias de recuperación para copias de seguridad y restauración y cubra estos puntos. Ampliarlo según sea necesario.

Acciones	Configuración	Validation
Configuración de regiones primarias y secundarias	- Despliegue de una carga de trabajo de escala completa en la región primaria - Duplicar la topología de red, políticas y configuraciones del servidor principal - Asegúrese de que RBAC, las líneas base de seguridad, los agentes de supervisión y las directivas son coherentes. - Implementación de la infraestructura como código con recursos de computación detenidos	- Comprobación de la preparación de la infraestructura de la región secundaria - Probar la coherencia de directivas entre regiones - Validar la conectividad de red y el enrutamiento
Configuración de la replicación de datos entre regiones	- Habilitación de la replicación integrada para Azure SQL Database, PostgreSQL, MySQL, Cosmos DB - Habilite GZRS o RA-GZRS para la replicación de almacenamiento de regiones emparejadas. - Configuración de la replicación de objetos para Blob Storage en regiones no emparejadas - Configuración de lectura y escritura en varias regiones con niveles de coherencia configurables para Azure Cosmos DB - Configuración de procesos de validación de coherencia de datos y supervisión del retardo de replicación	- Prueba del retraso de sincronización de datos contra objetivos de RPO - Comprobación del estado de replicación y las métricas de latencia - Validación de la coherencia de datos entre regiones - Validación de la integridad de los datos durante escenarios de conmutación por error
Protección del entorno de recuperación ante desastres y mantenimiento del cumplimiento	- Replicar los requisitos de residencia de datos en todas las regiones - Mantener la identidad y la paridad de acceso entre regiones - Prueba de la continuidad del registro de auditoría durante y después de la conmutación por error	- Auditar configuraciones de seguridad entre regiones - Probar escenarios de conmutación por error de identidad - Verificar el cumplimiento durante los eventos de DR - Validación de la continuidad del registro de auditoría
Automatización del aprovisionamiento y preparación de operaciones	- Definición de plantillas de IaC para el entorno de aprovisionamiento de recursos automatizado según sea necesario - Incluir configuraciones de servicio, parámetros de escalado y dependencias - Predefinir los objetivos de escalado para satisfacer la carga máxima cuando se activa - Para IaC: Bicep, Terraform, plantillas de ARM - Automatización de la implementación: canalizaciones de CI/CD para ambas regiones - "Runbooks": pasos automatizados y manuales para invocar procedimientos de recuperación ante desastres	- Prueba de procedimientos de aprovisionamiento automatizado - Verificar que los tiempos de inicio de cómputo cumplen con los objetivos de RTO - Validación de secuencias de activación de dependencias de servicio - Probar la coherencia de la implementación de IaC entre regiones - Verificar la ejecución y el tiempo del runbook
Supervisión de la disponibilidad y la salud	- Establecimiento de alertas sobre las métricas de estado y latencia de replicación - Supervisión del estado de la infraestructura de la región secundaria - Supervisión de la preparación para la activación en todos los componentes - Implementación de verificaciones de salud para el estado de replicación - Configuración de alertas para eventos de escalado automático y enrutamiento de tráfico - Asegurarse de que las herramientas de observabilidad abarcan ambas regiones	- Probar sistemas de supervisión y alertas Verificar los controles de estado de la infraestructura - Validar la precisión de los indicadores de preparación - Validar la cobertura de observabilidad
Configuración del equilibrador de carga con conmutación por error manual	- Azure Front Door o Traffic Manager con enrutamiento basado en prioridad - Enrutar todo el tráfico de producción a la región primaria en condiciones normales - Desencadenar manualmente el redireccionamiento del tráfico durante un failover	- Probar escenarios de conmutación por error de tráfico - Comprobación de las configuraciones de prioridad de enrutamiento - Validación de tiempos de propagación y migración de DNS
Definir el runbook y los criterios de conmutación por error manual	- Establecimiento de desencadenadores de conmutación por error claros y criterios de activación - Documente los pasos de activación manual, incluidos el inicio de proceso y las actualizaciones de DNS. - Incluir procedimientos de reversión para activaciones fallidas o temporales	- Prueba de ejecución del manual operacional de conmutación por error - Comprobar los procedimientos de activación manuales - Validación de procesos de reversión y cronograma
Prueba periódica de procesos de restauración	- Programar simulacros de restauración periódicos para validar la integridad de la copia de seguridad - Incluir la restauración a entornos de ensayo - Registrar el tiempo empleado y comparar con los objetivos de RTO	- Ejecutar simulacros de restauración trimestral - Comprobación de la coherencia de los datos después de la restauración - Documentar el rendimiento con respecto a los objetivos de RTO

Estrategia de recuperación para activo-pasivo (espera caliente)

Las implementaciones en espera activa-pasiva equilibran el costo y la resiliencia al mantener un entorno secundario mínimamente aprovisionado que se puede escalar rápidamente durante los eventos de fallo. Este enfoque reduce el tiempo de inactividad y evita el costo total de redundancia siempre activada entre regiones.

La región primaria controla todo el tráfico de producción en condiciones normales, mientras que la región secundaria se ejecuta con recursos mínimos y se escala verticalmente solo cuando se activa para la recuperación ante desastres.

Acciones recomendadas

Desarrolle estrategias de recuperación para activo-pasivo (espera en frío) y cubra estos puntos. Ampliarlo según sea necesario.

Acciones	Configuración	Validation
Configuración de la región secundaria a escala parcial	- Desplegar una huella informática mínima viable en la región secundaria	- Comprobación de la preparación de la infraestructura de la región secundaria
Habilitación del escalado automático en la región secundaria	- Configurar reglas de escalado automático para aumentar recursos de computación después de la conmutación por error - Establecimiento de los límites y umbrales de escala adecuados - Definición de secuencias de inicio para servicios dependientes	- Probar el comportamiento de escalado durante los simulacros de conmutación por error - Comprobación de la disponibilidad de los recursos durante el escalado vertical
Configuración de procedimientos de conmutación por error automatizados	- Habilitar la conmutación automática por error cuando se admita - Documentación de procedimientos de conmutación por error manuales para otros servicios - Crear guías de ejecución de conmutación por error orquestadas con procesos detallados paso a paso	- Probar mecanismos de conmutación por error automatizados - Validar procedimientos manuales de conmutación por error - Verificación de la precisión y del tiempo de ejecución del runbook
Configurar el equilibrador de carga con conmutación por error automática	- Azure Front Door o Traffic Manager con conmutación automática por error habilitada - Configura comprobaciones de estado para redirigir el tráfico automáticamente	- Probar escenarios de conmutación por error de tráfico - Comprobación de las configuraciones de prioridad de enrutamiento

Estrategia de recuperación para implementaciones activas y activas

Las implementaciones activas maximizan la disponibilidad del servicio mediante la ejecución de varias instancias de carga de trabajo entre regiones, con cada instancia que controla activamente el tráfico de producción. Este diseño elimina el tiempo de inactividad y permite la conmutación por error instantánea, pero también exige un planeamiento preciso para administrar la coherencia, el enrutamiento y el costo en todos los sistemas distribuidos.

Elija uno de los dos enfoques de implementación:

• Activo-activo (a plena capacidad): sellos de implementación reflejados o geodes en dos o más regiones, donde cada región maneja una parte de la carga de producción y puede escalar para absorber la carga completa en caso de falla regional.

• Activo-activo (sobreaprovisionado): sellos de implementación reflejados o geodes en dos o más regiones. Cada región está a plena capacidad en todo momento para gestionar de forma independiente el 100% del tráfico.

Nota:

En escenarios activos-activos, cuando se produce un error, la experiencia del usuario puede permanecer sin verse afectada ya que la carga se transfiere a las instancias restantes. Sin embargo, los esfuerzos de recuperación ante desastres son todavía necesarios para restaurar la instancia fallida.

Acciones recomendadas

Construir sobre las estrategias de recuperación para activo-pasivo (espera tibia). Ampliarlo según sea necesario.

Acciones	Configuración	Validation
Configuración de la región secundaria a capacidad completa	- Implementación de una región secundaria a escala completa, a la par con la principal	- Validar que la región secundaria es capaz de admitir instantáneamente la carga completa cuando se produce un error principal.
Configuración del equilibrador de carga para distribuir el tráfico entre instancias activas	- Azure Front Door o Traffic Manager con enrutamiento ponderado o basado en latencia - Sondeos de estado configurados por cada punto de conexión - Reenrutamiento automático del tráfico tras la detección de errores	- Probar escenarios de conmutación por error entre regiones - Comprobar la precisión del sondeo de salud y los tiempos de respuesta - Validación del enrutamiento del tráfico durante interrupciones simuladas
Configuración del comportamiento de distribución de carga	- Umbral de carga de documentos que maneja cada región durante la operación normal - Rendimiento esperado y comportamiento de escalado si falla la región homóloga - Definir el comportamiento del sistema en caso de error de una sola región, interrupción parcial del servicio, creación de particiones de red	- Probar escenarios de fallo regionales bajo carga - Comprobación de los límites de degradación del rendimiento - Prueba del control de particiones de red

Pasos siguientes

• RE:09 Estrategias de arquitectura para diseñar una estrategia de recuperación ante desastres

• RE:05 Estrategias de arquitectura para diseñar redundancia