Modifier

Partager via

Récupération d’urgence pour Azure Data Platform - Déployer ce scénario

Azure Synapse Analytics
Azure Machine Learning
Azure Cosmos DB
Azure Data Lake
Hubs d'événements Azure

Activités client nécessaires

Pré-incident

Pour les services Azure

  • Familiarisez-vous avec Azure Service Health dans le portail Azure. Cette page agit en tant que « magasin à un arrêt » pendant un incident.
  • Envisagez l’utilisation des alertes Service Health, qui peuvent être configurées pour générer automatiquement des notifications lorsque des incidents Azure se produisent.

Pour Power BI

  • Familiarisez-vous avec Service Health dans le Centre d’administration Microsoft 365. Cette page agit en tant que « magasin à un arrêt » pendant un incident.
  • Envisagez d’utiliser Centre d’administration Microsoft 365 application mobile pour obtenir des notifications automatiques d’alerte d’incident de service.

Pendant l’incident

Pour les services Azure

  • Azure Service Health dans son portail de gestion Azure fournit les dernières mises à jour.
    • S’il existe des problèmes d’accès à Service Health, reportez-vous à la page État d’Azure.
    • S’il existe des problèmes d’accès à la page Status, accédez à @AzureSupport X (anciennement Twitter).
  • Si l’impact/les problèmes ne correspondent pas à l’incident (ou persistent après atténuation), contactez le support technique pour déclencher un ticket de support de service.

Pour Power BI

  • La page Service Health dans le Centre d’administration Microsoft 365 fournit les dernières mises à jour
    • Si vous n’arrivez pas à accéder à Service Health, reportez-vous à la page État de Microsoft 365
    • Si l’impact ou les problèmes ne correspondent pas à l’incident (ou si les problèmes persistent après atténuation), les clients doivent créer un ticket de support de service.

Après la reprise d’activité Microsoft

Pour plus d’informations, consultez les sections ci-dessous.

Après l’incident

Pour les services Azure

  • Microsoft publiera un PIR sur l’Portail Azure - Service Health pour révision.

Pour Power BI

Processus Attendre Microsoft

Le processus « Wait for Microsoft » consiste simplement à attendre que Microsoft récupère tous les composants et services dans la région primaire affectée. Une fois la récupération effectuée, validez la liaison entre la plateforme de données et les services partagés d’entreprise ou autres services, ainsi que la date du jeu de données, puis exécutez les processus nécessaires à la mise à jour du système à la date actuelle.

Une fois ce processus achevé, la validation des experts techniques et commerciaux peut être réalisée, ce qui permet aux parties prenantes d'approuver le rétablissement des services.

Redéployer en cas de sinistre

Pour une stratégie de « redéploiement sur sinistre », le flux de processus de haut niveau suivant peut être décrit.

  1. Récupérer les services partagés d’entreprise et les systèmes sources de Contoso

    Schéma montrant la récupération des services partagés et des systèmes sources Contoso.

    • Cette étape est une condition préalable à la récupération de la plateforme de données.
    • Cette étape serait effectuée par les différents groupes de support opérationnel Contoso responsables des services partagés d’entreprise et des systèmes sources opérationnels.

  2. Récupérer les services Azure Les services Azure font référence aux applications et services qui constituent l’offre cloud Azure, et qui sont disponibles dans la région secondaire pour le déploiement.

    Schéma montrant la récupération des services Azure.

    Les services Azure font référence aux applications et services qui constituent l’offre cloud Azure, et qui sont disponibles dans la région secondaire pour le déploiement.

    • Cette étape est une condition préalable à la récupération de la plateforme de données.
    • Cette étape est effectuée par les partenaires Microsoft et d’autres partenaires PaaS (Platform as a Service)/software as a service (SaaS).

  3. Récupérer les bases de la plateforme de données

    Schéma montrant la récupération des systèmes de base de la plateforme de données.

    • Cette étape est le point d’entrée des activités de récupération de plateforme.
    • Pour la stratégie de redéploiement, chaque composant/service requis serait acheté et déployé dans la région secondaire.
      • Consultez la section Service et composant Azure de cette série pour obtenir une répartition détaillée des composants et des stratégies de déploiement.
    • Ce processus doit également inclure des activités telles que la liaison aux services partagés d’entreprise, garantir la connectivité à l’accès/l’authentification et valider que le déchargement de journal fonctionne, tout en garantissant la connectivité aux processus en amont et en aval.
    • Les données et les traitement doivent être vérifiés. Par exemple, la validation de l’horodatage de la plateforme récupérée.
      • S’il existe des questions sur l’intégrité des données, la décision peut être prise de revenir plus loin dans le temps avant d’exécuter le nouveau traitement pour mettre la plateforme à jour.
    • Le fait d’avoir un ordre de priorité pour les processus (en fonction de l’impact sur l’entreprise) aidera à orchestrer la récupération.
    • Cette étape doit être close par la validation technique, sauf si les utilisateurs professionnels interagissent directement avec les services. S’il existe un accès direct, une étape de validation métier doit être nécessaire.
    • Une fois la validation terminée, une remise aux équipes de solution individuelles pour démarrer leur propre processus de récupération d’urgence (DR) se produit.
      • Cette remise doit inclure la confirmation de l’horodatage actuel des données et des processus.
      • Si les processus de données d’entreprise de base vont être exécutés, les solutions individuelles doivent être prises en compte : flux entrants/sortants, par exemple.

  4. Récupérer les solutions hébergées par la plateforme

    Schéma montrant la récupération des systèmes de plateforme.

    • Chaque solution doit avoir son propre runbook de récupération d’urgence. Les runbooks doivent au moins contenir les parties prenantes commerciales désignées qui testent et vérifient que la récupération de service a été terminée.
    • En fonction de la contention ou de la priorité des ressources, les solutions/charges de travail clés peuvent être hiérarchisées par rapport à d’autres - processus d’entreprise de base sur des laboratoires ad hoc, par exemple.
    • Une fois les étapes de validation terminées, une remise aux solutions en aval pour démarrer leur processus de récupération de récupération d’urgence se produit.

  5. Transfert aux systèmes dépendants en avalSchéma montrant les systèmes dépendants.

    Diagramme montrant les systèmes dépendants.

    • Une fois les services dépendants récupérés, le processus de récupération d’urgence E2E est terminé.

    Remarque

    Bien qu’il soit théoriquement possible d’automatiser complètement un processus de récupération d’urgence E2E, il est peu probable que l’événement soit exposé au risque par rapport au coût des activités SDLC requises pour couvrir le processus E2E.

  6. Rétablissement vers la région primaire Le processus de rétablissement consiste à replacer le service de plateforme de données et ses données dans la région primaire, une fois celui-ci disponible pour l’utilisateur de l’authentification de base.

Selon la nature des systèmes sources et des différents processus de données, le rétablissement de la plateforme de données peut être effectué indépendamment des autres parties de l’écosystème de données.

Il est conseillé aux clients d'examiner les dépendances de leur propre plateforme de données (en amont et en aval) pour prendre la décision appropriée. La section suivante suppose une récupération indépendante de la plateforme de données.

  • Une fois que tous les composants/services requis sont disponibles dans la région primaire, les clients effectuent un test de fumée pour valider la récupération De Microsoft.
  • La configuration du composant ou du service est validée. Les deltas sont traités par le biais d’un redéploiement à partir du contrôle de code source.
  • La date du système dans la région primaire est établie entre les composants avec état. Le delta entre la date établie et l’horodatage/date dans la région secondaire doit être résolu en réexécutant ou en relectant les processus d’ingestion de données à partir de ce point.
  • Avec l’approbation des parties prenantes métier et techniques, une fenêtre est sélectionnée pour le rétablissement. Dans l’idéal, cela doit se produire pendant une accalmie dans l’activité et le traitement du système.
  • Pendant la secours, la région primaire serait mise en synchronisation avec la région secondaire, avant le basculement du système.
  • Après une période d’exécution parallèle, la région secondaire est mise hors connexion à partir du système.
  • Les composants de la région secondaire sont supprimés ou supprimés, selon la stratégie de récupération d’urgence sélectionnée.

Processus de rechange chaud

Pour une stratégie « Warm Spare », le processus de haut niveau est étroitement aligné sur celui du « Redeploy on Disaster », la principale différence étant que les composants ont déjà été achetés dans la région secondaire. Cette stratégie élimine le risque de conflit de ressources d’autres organisations qui cherchent à effectuer leur propre récupération d’urgence dans cette région.

Processus de rechange à chaud

La stratégie « Hot Spare » signifie que les services de la plateforme, y compris les systèmes PaaS et d'infrastructure en tant que service (IaaS), persisteront malgré le sinistre, les systèmes secondaires fonctionnant en tandem avec les systèmes primaires. Comme pour la stratégie « Warm Spare », cette stratégie élimine le risque de conflit de ressources d’autres organisations qui cherchent à effectuer leur propre récupération d’urgence dans la même région.

Les clients Hot Spare monitorent la récupération Microsoft des composants et services dans la région primaire. Une fois la récupération terminée, les clients valident les systèmes de la région primaire et procèdent au rétablissement vers la région primaire. Ce processus est similaire au processus de basculement de la récupération d’urgence, c’est-à-dire vérifier le codebase et les données disponibles, en redéployant si nécessaire.

Notes

Notez que toutes les métadonnées système doivent être cohérentes entre les deux régions.

  • Une fois le rétablissement effectué vers la région primaire, les équilibreurs de charge système peuvent être mis à jour pour rétablir la région primaire dans la topologie système. Si cette option est disponible, vous pouvez effectuer un contrôle de validité de mise en production afin d’activer de manière incrémentielle la région primaire pour le système.

Structure du plan de récupération d’urgence

Un plan de récupération d’urgence efficace fournit un guide pas à pas pour la récupération des services qui peut être exécutée par le personnel technique Azure. Voici donc une proposition de structure MVP pour un plan de récupération d’urgence.

  • Exigences relatives au processus
    • Tous les détails spécifiques au processus de récupération d’urgence du client, tels que l’autorisation correcte requise pour démarrer la récupération d’urgence, et prendre des décisions clés sur la récupération si nécessaire (y compris la « définition de terminé »), le service prend en charge les informations de référence sur les tickets de récupération d’urgence et les détails de la salle de guerre.
    • Confirmation des ressources, notamment le responsable de la récupération d’urgence et son remplaçant. Toutes les ressources doivent être documentées avec des contacts principaux et secondaires, des chemins d’escalade et des calendriers de congés. Dans les situations critiques de récupération d’urgence, les systèmes de liste doivent peut-être être pris en compte.
    • Ordinateur portable, packs d’alimentation ou alimentation de sauvegarde, connectivité réseau et détails de téléphone mobile pour l’exécuteur de récupération d’urgence, la sauvegarde de récupération d’urgence et tous les points d’escalade.
    • Processus à suivre si l’une des exigences du processus n’est pas remplie.
  • Liste des contacts
    • Leadership de la RÉCUPÉRATION d’urgence et groupes de soutien.
    • Les PME commerciales qui terminent le cycle de test/révision pour la récupération technique.
    • Propriétaires d’entreprise concernés, y compris les approbateurs de récupération de service.
    • Propriétaires techniques concernés, y compris les approbateurs de récupération technique.
    • Prise en charge des PME dans tous les domaines concernés, y compris les solutions clés hébergées par la plateforme.
    • Systèmes en aval affectés : support opérationnel.
    • Systèmes sources en amont : support opérationnel.
    • Contacts des services partagés d’entreprise. Par exemple, prise en charge de l’accès et de l’authentification, surveillance de la sécurité et prise en charge de la passerelle
    • Tous les fournisseurs externes ou tiers, y compris les contacts de support pour les fournisseurs de cloud.
  • Conception d’architecture
    • Décrivez les détails du scénario de bout en bout (E2E) et joignez toute la documentation de support associée.
  • Dépendances
    • Répertorier toutes les relations et dépendances des composants.
  • Conditions préalables à la récupération d’urgence
    • Confirmation que les systèmes sources en amont sont disponibles selon les besoins.
    • L’accès élevé sur la pile a été accordé aux ressources de l’exécuteur de récupération d’urgence.
    • Les services Azure sont disponibles selon les besoins.
    • Processus à suivre si l’une des conditions préalables n’a pas été remplie.
  • Récupération technique - instructions pas à pas
    • Ordre d’exécution.
    • Description de l’étape.
    • Prérequis de l’étape.
    • Étapes de processus détaillées pour chaque action discrète, y compris les URL.
    • Instructions de validation, y compris les preuves requises.
    • Délai prévu pour effectuer chaque étape, y compris les urgences.
    • Processus à suivre si l’étape échoue.
    • Les points d’escalade en cas d’échec ou de soutien aux PME.
  • Récupération technique - post-conditions requises
    • Confirmez l’horodatage de date actuel du système entre les composants clés.
    • Confirmez les URL système de récupération d’urgence et les adresses IP.
    • Préparez le processus d’examen des parties prenantes, y compris la confirmation de l’accès aux systèmes et des PME commerciales qui terminent la validation et l’approbation.
  • Examen et approbation des parties prenantes métier
    • Détails du contact des ressources professionnelles.
    • Étapes de validation métier en fonction de la récupération technique ci-dessus.
    • Piste de preuve requise par l’approbateur d’entreprise signant la récupération.
  • Conditions requises pour la récupération
    • Transfert vers le support opérationnel pour exécuter les processus de données pour mettre le système à jour.
    • Remise des processus et solutions en aval : confirmant la date et les détails de connexion du système de récupération d’urgence.
    • Vérifiez que le processus de récupération est terminé avec le prospect de récupération d’urgence : confirmant la piste de preuve et le runbook terminé.
    • Informer les équipes de sécurité que des privilèges d’accès élevés peuvent être supprimés de l’équipe de récupération d’urgence.

Légendes

  • Il est recommandé d’inclure des captures d’écran système de chaque processus d’étape. Ces captures d’écran vous aideront à résoudre la dépendance vis-à-vis des PME système pour effectuer les tâches.
    • Pour suivre l’évolution rapide des services cloud, le plan de récupération d’urgence doit être régulièrement revisité, testé et exécuté par des ressources avec des connaissances actuelles d’Azure et de ses services.
  • Les étapes de récupération technique doivent refléter la priorité du composant et de la solution pour l’organisation. Par exemple, les flux de données d’entreprise de base sont récupérés avant les laboratoires d’analyse des données ad hoc.
  • Les étapes de récupération technique doivent suivre l’ordre des flux de travail (généralement de gauche à droite), une fois que les composants de base ou le service comme Key Vault ont été récupérés. Cette stratégie garantit que les dépendances en amont sont disponibles et que les composants peuvent être testés de manière appropriée.
  • Une fois le plan pas à pas terminé, il convient d’obtenir un délai total pour les activités en cas d’urgence. Si ce total est supérieur à l'objectif de délai de rétablissement (RTO) convenu, plusieurs options sont possibles :
    • Automatisez les processus de récupération sélectionnés (le cas échéant).
    • Rechercher les opportunités d’exécution des étapes de récupération sélectionnées en parallèle (si possible). Toutefois, notez que cette stratégie peut nécessiter des exécuteurs de récupération d’urgence supplémentaires.
    • Élever les composants clés vers des niveaux de service plus élevés tels que PaaS, où Microsoft prend plus de responsabilité pour les activités de récupération de service.
    • Étendez le RTO avec les parties prenantes.

Test de récupération d’urgence

La nature de l’offre du service Cloud Azure entraîne des contraintes pour tous les scénarios de test de récupération d’urgence. Il est donc conseillé de mettre en place un abonnement de récupération d’urgence avec les composants de plateforme de données qui sont disponibles dans la région secondaire.

À partir de cette base de référence, le runbook du plan de récupération d’urgence peut être exécuté de manière sélective, en accordant une attention particulière aux services et aux composants qui peuvent être déployés et validés. Ce processus nécessite un jeu de données de test organisé permettant la confirmation des vérifications de validation technique et métier, conformément au plan.

Un plan de récupération d’urgence doit être testé régulièrement pour non seulement s’assurer qu’il est à jour, mais également pour créer une « mémoire musculaire » à destination des équipes qui effectuent des activités de basculement et de récupération.

  • Les sauvegardes des données et de la configuration doivent également être testées régulièrement afin de s'assurer qu'elles sont « adaptées à l'usage » pour soutenir toute activité de récupération.

Pendant un test de récupération d’urgence, il faut principalement s’assurer que les étapes prescriptives sont toujours correctes et que les délais estimés sont toujours pertinents.

  • Si les instructions reflètent les écrans du portail plutôt que le code, elles doivent être validées au moins tous les 12 mois en raison de la cadence des changements du cloud.

Même si l’on pourrait souhaiter un processus de récupération d’urgence entièrement automatisé, l’automatisation complète est peu probable en raison de la rareté de l’événement. Il est donc recommandé d'établir la base de reprise avec la configuration de l'état désiré (DSC) de l'infrastructure en tant que code (IaC) utilisée pour fournir la plateforme, puis de la relever au fur et à mesure que les nouveaux projets se construisent sur la base de la base.

  • À mesure que les composants et les services sont étendus, un NFR doit être appliqué, ce qui nécessite que le pipeline de déploiement de production soit refactorisé dans le but de fournir une couverture pour la récupération d’urgence.

Si les minutages de votre runbook dépassent votre RTO, plusieurs options s’offrent à vous :

  • Étendez le RTO avec les parties prenantes.
  • Réduisez le temps nécessaire pour les activités de récupération, via l’automatisation, en exécutant des tâches en parallèle ou en migration vers des niveaux de serveur cloud supérieurs.

Azure Chaos Studio

Azure Chaos Studio est un service géré permettant d’améliorer la résilience en injectant des erreurs dans vos applications Azure. Chaos Studio vous permet d’orchestrer l’injection d’erreurs sur vos ressources Azure de façon sécurisée et contrôlée, à l’aide d’expériences. Consultez la documentation du produit pour obtenir une description des types d’erreurs actuellement pris en charge.

L’itération actuelle de Chaos Studio couvre uniquement un sous-ensemble de composants et de services Azure. Tant que d’autres bibliothèques d’erreurs ne sont pas ajoutées, nous vous recommandons d’utiliser Chaos Studio pour les tests de résilience isolés plutôt que pour les tests de récupération d’urgence système complets.

Vous trouverez plus d'informations sur Chaos Studio dans la documentation d'Azure Chaos Studio.

Azure Site Recovery

Pour les composants IaaS, Azure Site Recovery protège la plupart des charges de travail exécutées sur une machine virtuelle ou un serveur physique pris en charge

Vous trouverez des instructions détaillées pour les actions suivantes :

Étapes suivantes

Maintenant que vous avez appris à déployer ce scénario, vous pouvez lire un résumé de la série relative à la plateforme de données de récupération d’urgence pour Azure.