Editar

Share via

Recuperación ante desastres en una plataforma de datos de Azure: implementación de este escenario

Azure Synapse Analytics
Azure Machine Learning
Azure Cosmos DB
Azure Data Lake
Azure Event Hubs

Actividades del cliente necesarias

Previas al incidente

Con respecto a los servicios de Azure

  • Familiarizarse con Azure Service Health en Azure Portal. Esta página servirá como punto de referencia único durante un incidente.
  • Considerar el uso de alertas de Service Health, que se pueden configurar para generar automáticamente notificaciones cuando se produzcan incidentes de Azure.

Para Power BI

Durante el incidente

Con respecto a los servicios de Azure

  • Azure Service Health en su portal de administración de Azure proporcionará las actualizaciones más recientes.
    • Si hay problemas para acceder a Service Health, consulte la página de estado de Azure.
    • Si alguna vez hay problemas para acceder a la página de estado, vaya a @AzureSupport en X (previamente Twitter).
  • Si el impacto o los problemas no coinciden con el incidente (o persisten después de la mitigación), póngase en contacto con el soporte técnico para generar una incidencia de soporte técnico de servicio.

Para Power BI

Después de la recuperación de Microsoft

Consulte las siguientes secciones para más información.

Después del incidente

Con respecto a los servicios de Azure

Para Power BI

Proceso de esperar a Microsoft

El proceso "esperar a Microsoft" consiste simplemente en esperar a que Microsoft recupere todos los componentes y servicios de la región primaria afectada. Una vez recuperados, valide el enlace de la plataforma de datos a servicios compartidos empresariales o de otro tipo y la fecha del conjunto de datos y, luego, ejecute los procesos de puesta al día del sistema.

Una vez completado este proceso, se puede realizar la validación técnica y empresarial por parte del experto en la materia, lo que permite la aprobación por las partes interesadas para la recuperación del servicio.

Reimplementación en caso de desastre

Para llevar a cabo una estrategia de "reimplementación en caso de desastre", se puede describir el siguiente flujo de proceso de alto nivel.

  1. Recuperación de Contoso: servicios compartidos empresariales y sistemas de origen

    Diagram showing the recovery of Contoso's shared services and source systems.

    • Este paso es un requisito previo para la recuperación de la plataforma de datos.
    • Este paso lo completarían los distintos grupos de soporte técnico operativo de Contoso responsables de los servicios compartidos empresariales y los sistemas de origen operativos.

  2. Recuperación de servicios de Azure Los servicios de Azure hacen referencia a las aplicaciones y servicios que constituyen la oferta de nube de Azure y que están disponibles en la región secundaria para su implementación.

    Diagram showing the recovery of the Azure services.

    Los servicios de Azure hacen referencia a las aplicaciones y servicios que constituyen la oferta de nube de Azure y que están disponibles en la región secundaria para su implementación.

    • Este paso es un requisito previo para la recuperación de la plataforma de datos.
    • Este paso lo realizará Microsoft y otros asociados de PaaS o SaaS.

  3. Recuperación de la base de la plataforma de datos

    Diagram showing the recovery of the data platform foundational systems.

    • Este paso es el punto de entrada para las actividades de recuperación de la plataforma.
    • Para la estrategia de reimplementación, cada componente o servicio necesario se adquiriría e implementaría en la región secundaria.
    • Este proceso también debe incluir actividades como el enlace a los servicios compartidos empresariales, la garantía de conectividad al acceso o la autenticación y la validación de que la descarga de registros funciona, al mismo tiempo que se garantiza la conectividad a procesos de nivel superior e inferior.
    • Se deben confirmar los datos o el procesamiento. Por ejemplo, validación de la marca de tiempo de la plataforma recuperada.
      • Si hay dudas sobre la integridad de los datos, se podría tomar la decisión de retroceder más en el tiempo antes de ejecutar el nuevo procesamiento para actualizar la plataforma.
    • Tener un orden de prioridad para los procesos (basado en el impacto empresarial) ayudará a organizar la recuperación.
    • Este paso debe cerrarse con la validación técnica a menos que los usuarios empresariales interactúen directamente con los servicios. Si hay acceso directo, deberá haber un paso de validación empresarial.
    • Una vez completada la validación, tiene lugar el traspaso a los equipos de soluciones individuales para que inicien su propio proceso de DR.
      • Este traspaso debe incluir la confirmación de la marca de tiempo actual de los datos o procesos.
      • Si se van a ejecutar procesos de datos empresariales básicos, las soluciones individuales deben ser conscientes de ello: flujos de entrada y salida, por ejemplo.

  4. Recuperación de las soluciones individuales hospedadas por la plataforma

    Diagram showing the recovery of individual platform systems.

    • Cada solución debe tener su propio runbook de recuperación ante desastres. Los runbooks deben contener al menos las partes interesadas empresariales designadas que probarán y confirmarán que se ha completado la recuperación del servicio
    • Dependiendo de la contención de recursos o de la prioridad, las soluciones y cargas de trabajo principales pueden tener prioridad sobre otras: los procesos empresariales básicos sobre los laboratorios ad hoc, por ejemplo.
    • Una vez que se han completado los pasos de validación, tiene lugar el traspaso a las soluciones de nivel inferior para que inicien su proceso de recuperación ante desastres.

  5. Traspaso a los sistemas dependientes de nivel inferior

    Diagram showing the dependent systems.

    • Una vez recuperados los servicios dependientes, se completa el proceso de recuperación ante desastres de E2E.

    Nota

    Aunque teóricamente es posible automatizar completamente un proceso de recuperación ante desastres E2E, es poco probable dado el riesgo del evento frente al costo de las actividades de SDLC necesarias para cubrir el proceso E2E.

  6. Conmutación por recuperación a la región primaria La conmutación por recuperación es el proceso de mover el servicio de plataforma de datos y sus datos a la región primaria, una vez que está disponible para BAU.

Dependiendo de la naturaleza de los sistemas de origen y de varios procesos de datos, la conmutación por recuperación de la plataforma de datos podría realizarse independientemente de otras partes del ecosistema de datos.

Se recomienda a los clientes revisar las dependencias de su propia plataforma de datos (tanto de nivel superior como inferior) para tomar la decisión adecuada. En la sección siguiente se supone una recuperación independiente de la plataforma de datos.

  • Una vez que todos los componentes o servicios necesarios estén disponibles en la región primaria, los clientes completarían una prueba de humo para validar la recuperación de Microsoft.
  • Se validará la configuración del componente o servicio. Las diferencias se resolverán mediante la reimplementación a partir del control de código fuente.
  • La fecha del sistema en la región primaria se establecerá en los componentes con estado. La diferencia entre la fecha establecida y la fecha y la marca de tiempo de la región secundaria debe resolverse ejecutando o reproduciendo de nuevo los procesos de ingesta de datos desde ese punto en adelante.
  • Con la aprobación de las partes interesadas empresariales y técnicas, se seleccionará una ventana de conmutación por recuperación. Idealmente, durante una pausa en la actividad del sistema y el procesamiento.
  • Durante la conmutación por recuperación, la región primaria se sincronizará con la región secundaria, antes de que se conmutara el sistema.
  • Después de un período de una ejecución en paralelo, la región secundaria se desconectará del sistema.
  • Los componentes de la región secundaria se eliminarán o reducirán, según la estrategia de recuperación ante desastres seleccionada.

Proceso de reserva semiactiva

En el caso de una estrategia de "reserva semiactiva", el flujo de procesos de alto nivel está estrechamente alineado con el de "reimplementación en caso de desastre"; la principal diferencia es que los componentes ya se han adquirido en la región secundaria. Esta estrategia elimina el riesgo de contención de recursos de otras organizaciones que buscan realizar su propia recuperación ante desastres en esa región.

Proceso de reserva activa

La estrategia de "reserva activa" significa que los servicios de plataforma, incluidos los sistemas PaaS e IaaS, se conservarán a pesar del evento de desastre, ya que los sistemas secundarios funcionan en tándem con los sistemas principales. Al igual que con la estrategia "reserva semiactiva", esta estrategia elimina el riesgo de contención de recursos de otras organizaciones que buscan realizar su propia recuperación ante desastres en esa región.

Los clientes de reserva activa supervisarán la recuperación de Microsoft de componentes o servicios en la región primaria. Una vez completada, los clientes validarán los sistemas de la región primaria y realizarán la conmutación por recuperación a esta región. Este proceso sería similar al proceso de conmutación por error de la recuperación ante desastres, es decir, se comprueba el código base y los datos disponibles y se realiza una nueva implementación en caso necesario.

Nota

Se debe poner especial atención a que los metadatos del sistema sean coherentes entre las dos regiones.

  • Una vez completada la conmutación por recuperación a la región primaria, los equilibradores de carga del sistema se pueden actualizar para devolver la región primaria a la topología del sistema. Si está disponible, se puede usar un enfoque de versión controlada para activar gradualmente la región primaria en el sistema.

Estructura del plan de recuperación ante desastres

Un plan de recuperación ante desastres eficaz presenta una guía paso a paso para la recuperación de servicios que se puede ejecutar mediante un recurso técnico de Azure. Por ello, a continuación se presenta una propuesta de estructura de MVP para un plan de recuperación ante desastres.

  • Requisitos del proceso
    • Todos los detalles específicos del proceso de recuperación ante desastres del cliente, como la autorización correcta necesaria para iniciar la recuperación ante desastres y tomar decisiones importantes sobre la recuperación según sea necesario (incluida la "definición de listo"), la referencia de vales de recuperación ante desastres de soporte técnico del servicio y los detalles de la sala de guerra.
    • Confirmación de recursos, incluida la copia de seguridad del líder y del ejecutor de recuperación ante desastres. Todos los recursos deben estar documentados con contactos primarios y secundarios, vías de escalación y calendarios de permisos. En situaciones críticas de recuperación ante desastres, es posible que sea necesario tener en cuenta los sistemas de listas.
    • Equipo portátil, cargadores portátiles o energía de reserva, conectividad de red y detalles del teléfono móvil del ejecutor de la recuperación ante desastres, de la copia de seguridad de recuperación ante desastres y de los puntos de escalación.
    • El proceso que se va a seguir si no se cumple alguno de los requisitos del proceso.
  • Lista de contactos.
    • Liderazgo de recuperación ante desastres y grupos de apoyo.
    • Expertos en la materia empresariales que realizarán el ciclo de prueba y revisión para la recuperación técnica.
    • Propietarios de empresa afectados, incluidos los aprobadores de recuperación del servicio.
    • Propietarios técnicos afectados, incluidos los aprobadores de recuperación técnica.
    • Soporte técnico de expertos en la materia en todas las áreas afectadas, incluidas soluciones clave hospedadas por la plataforma.
    • Impacto en los sistemas de nivel inferior: soporte técnico operativo.
    • Sistemas de origen de nivel superior: soporte técnico operativo.
    • Contactos de servicios compartidos de empresa. Por ejemplo, soporte técnico para el acceso o la autenticación, supervisión de seguridad y soporte técnico para la puerta de enlace de red.
    • Cualquier proveedor externo o de terceros, incluidos los contactos de soporte técnico para proveedores en la nube.
  • Diseño de arquitectura
    • Describir en detalle el escenario completo de E2E y adjuntar toda la documentación de soporte técnico asociada.
  • Dependencias
    • Enumerar todas las relaciones y dependencias del componente.
  • Requisitos previos de DR
    • Confirmación de que los sistemas de origen de nivel superior están disponibles como es necesario.
    • Se ha concedido acceso elevado en la pila a los recursos del ejecutor de recuperación ante desastres.
    • Los servicios de Azure están disponibles como es necesario.
    • El proceso que se va a seguir si no se ha cumplido alguno de los requisitos previos.
  • Recuperación técnica: instrucciones paso a paso
    • Orden de ejecución.
    • Descripción del paso
    • Paso que es requisito previo.
    • Pasos detallados del proceso de cada acción discreta, incluida la dirección URL.
    • Instrucciones de validación, incluida la evidencia necesaria.
    • Tiempo esperado para completar cada paso, incluida la contingencia.
    • Proceso que se va a seguir si se produce un error en el paso.
    • Puntos de escalación en caso de error o soporte técnico del experto en la materia.
  • Recuperación técnica: requisitos posteriores
    • Confirmar la marca de tiempo de fecha actual del sistema en los componentes clave.
    • Confirmar las direcciones URL e IP del sistema de recuperación ante desastres
    • Prepararse para el proceso de revisión por las partes interesadas de la empresa, incluida la confirmación del acceso a los sistemas y la validación y la aprobación por parte de los expertos en la materia.
  • Revisión y aprobación por las partes interesadas de la empresa
    • Detalles de contacto de los recursos empresariales.
    • Los pasos de validación empresarial según la recuperación técnica anterior.
    • Seguimiento de la evidencia exigida al aprobador empresarial que firma la recuperación.
  • Requisitos posteriores a la recuperación
    • Traspasar al soporte técnico operativo la ejecución de los procesos de datos para la puesta al día del sistema.
    • Traspasar los procesos y soluciones de nivel inferior: confirmación de los detalles de fecha y conexión del sistema de recuperación ante desastres.
    • Confirmar que el proceso de recuperación se ha completado con el líder de la recuperación ante desastres: confirmación del seguimiento de la evidencia y runbook completado.
    • Notificar a la administración de seguridad que se pueden retirar los privilegios de acceso elevados al equipo de recuperación ante desastres.

Llamadas

  • Se recomienda incluir capturas de pantalla del sistema de cada proceso. Estas capturas de pantalla ayudarán a solucionar la dependencia de SME de sistema para realizar las tareas.
    • Para mitigar el riesgo de que los servicios en la nube evolucionen rápidamente, el plan de recuperación ante desastres se debe revisar, probar y ejecutar periódicamente mediante recursos con conocimientos actuales de Azure y sus servicios.
  • Los pasos de recuperación técnica deben reflejar la prioridad del componente y la solución para la organización. Por ejemplo, los flujos de datos empresariales principales se recuperan antes que los laboratorios de análisis de datos ad hoc.
  • Los pasos de recuperación técnica deben seguir el orden de los flujos de trabajo (normalmente de izquierda a derecha), una vez que se han recuperado los componentes o servicios básicos, como Key Vault. Esta estrategia garantizará que las dependencias de nivel superior estén disponibles y que los componentes se puedan probar correctamente.
  • Una vez completado el plan paso a paso, se debe obtener un tiempo total para las actividades con contingencia. Si este total supera el RTO acordado, hay varias opciones disponibles:
    • Automatizar los procesos de recuperación seleccionados (siempre que sea posible).
    • Buscar oportunidades para ejecutar los pasos de recuperación seleccionados en paralelo (siempre que sea posible). Teniendo en cuenta, sin embargo, que esta estrategia puede requerir recursos adicionales del ejecutor de la recuperación ante desastres.
    • Elevar los componentes clave a niveles de servicio más altos, como PaaS, donde Microsoft asume una mayor responsabilidad sobre las actividades de recuperación del servicio.
    • Ampliar el RTO con las partes interesadas.

Pruebas de recuperación ante desastres

La naturaleza de la oferta de servicio en la nube de Azure da como resultado restricciones en cualquier escenario de pruebas de recuperación ante desastres. Por lo tanto, se aconseja mantener una suscripción de recuperación ante desastres con los componentes de la plataforma de datos, ya que estarán disponibles en la región secundaria.

A partir de esta línea de base, el runbook del plan de recuperación ante desastres se puede ejecutar de forma selectiva, prestando atención específica a los servicios y componentes que se pueden implementar y validar. Este proceso requerirá un conjunto de datos de prueba mantenido, lo que permitirá la confirmación de las comprobaciones de validación técnica y empresarial según el plan.

Un plan de recuperación ante desastres debe probarse periódicamente para no solo asegurarse de que está actualizado, sino también para crear "memoria muscular" para los equipos que realizan actividades de conmutación por error y recuperación.

  • Las copias de seguridad de los datos y de la configuración también deben probarse regularmente para garantizar que son "aptas" para apoyar cualquier actividad de recuperación.

El área clave en la que centrarse durante una prueba de recuperación ante desastres es asegurarse de que los pasos prescriptivos siguen siendo correctos y los tiempos estimados siguen siendo pertinentes.

  • Si las instrucciones reflejan las pantallas del portal en lugar de código, estas se deben validar al menos cada 12 meses debido a la cadencia del cambio en la nube.

Aunque la aspiración es tener un proceso de recuperación ante desastres totalmente automatizado, la automatización total puede ser improbable debido a la rareza del evento. Por lo tanto, se recomienda establecer la línea de base de la recuperación con la infraestructura como código (IaC) de DSC utilizada para entregar la plataforma y luego aumentar a medida que se crean nuevos proyectos sobre la línea de base.

  • Con el tiempo, a medida que se amplían los componentes y servicios, se debe aplicar una NFR, que requiere que la canalización de la implementación de producción se refactorice para proporcionar cobertura para la recuperación ante desastres.

Si los tiempos del runbook superan el RTO, hay varias opciones:

  • Ampliar el RTO con las partes interesadas.
  • Reducir el tiempo necesario para las actividades de recuperación, a través de la automatización, la ejecución de tareas en paralelo o la migración a niveles superiores del servidor de nube.

Azure Chaos Studio

Azure Chaos Studio es un servicio administrado para mejorar la resistencia mediante la inserción de errores en las aplicaciones de Azure. Chaos Studio permite orquestar la inserción de errores en los recursos de Azure de forma segura y controlada, por medio de experimentos. Consulte la documentación del producto para ver una descripción de los tipos de errores admitidos actualmente.

La iteración actual de Chaos Studio solo cubre un subconjunto de componentes y servicios de Azure. Hasta que se agreguen más bibliotecas de errores, Chaos Studio es un enfoque recomendado para pruebas de resistencia aisladas en lugar de pruebas completas de recuperación ante desastres del sistema.

Puede encontrar más información sobre Chaos Studio aquí.

Azure Site Recovery

En el caso de los componentes de IaaS, Azure Site Recovery protegerá la mayoría de las cargas de trabajo que se ejecutan en una máquina virtual o un servidor físico compatibles.

Existen instrucciones detalladas para estas tareas:

Pasos siguientes

Ahora que ha aprendido a implementar el escenario, puede leer un resumen de la serie de recuperación ante desastres para la plataforma de datos de Azure.