Partager via

Recommandations pour la conception d’une stratégie de récupération d’urgence

S’applique à cette recommandation de liste de contrôle de fiabilité d’Azure Well-Architected Framework :

RE :09 Implémentez des plans structurés, testés et documentés de continuité d’activité et de récupération d’urgence (BCDR) qui s’alignent sur les cibles de récupération. Les plans doivent couvrir tous les composants et le système dans son ensemble.

Ce guide décrit les recommandations relatives à la conception d’une stratégie de récupération d’urgence fiable pour une charge de travail. Pour répondre aux objectifs internes de niveau de service (SLA) ou même à un contrat de niveau de service (SLA) que vous avez garanti pour vos clients, vous devez disposer d’une stratégie de récupération d’urgence robuste et fiable. Les défaillances et autres problèmes majeurs sont attendus. Vos préparatifs pour gérer ces incidents déterminent la confiance que vos clients peuvent avoir en votre entreprise pour fournir un service fiable. Une stratégie de récupération d’urgence est l’épine dorsale de la préparation des incidents majeurs.

Définitions

Terme Définition
Basculement Déplacement automatisé et/ou manuel du trafic de charge de travail de production d’une région indisponible vers une région géographique non affectée.
Restauration automatique Le transfert automatisé et/ou manuel de la charge de travail de production d'une région basculante vers la région primaire.

Stratégies de conception clés

Ce guide suppose que vous avez déjà effectué les tâches suivantes dans le cadre de votre planification de fiabilité :

Une stratégie de récupération d’urgence fiable repose sur la base d’une architecture de charge de travail fiable. Assurez la fiabilité à chaque étape de la création de votre charge de travail pour vous assurer que les éléments nécessaires à une récupération optimisée sont en place avant de concevoir votre stratégie de récupération d’urgence. Cette base garantit que les cibles de fiabilité de votre charge de travail, telles que l’objectif de délai de récupération (RTO) et l’objectif de point de récupération (RPO), sont réalistes et réalisables.

Maintenir un plan de récupération d’urgence

La pierre angulaire d’une stratégie de récupération d’urgence fiable pour une charge de travail est le plan de récupération d’urgence. Votre plan doit être un document vivant qui est régulièrement examiné et mis à jour à mesure que votre environnement évolue. Présentez régulièrement le plan aux équipes appropriées (opérations, leadership technologique et parties prenantes de l’entreprise) (tous les six mois, par exemple). Stockez-le dans un magasin de données hautement disponible et sécurisé tel que OneDrive Entreprise.

Suivez ces recommandations pour développer votre plan de reprise d'activité :

  • Définissez clairement ce qui constitue un désastre et nécessite donc l’activation du plan de récupération d’urgence.

    • Les catastrophes sont des problèmes à grande échelle. Il peut s’agir de pannes régionales, de pannes de services comme Microsoft Entra ID ou Azure DNS, ou d’attaques malveillantes graves telles que les attaques par ransomware ou les attaques DDoS.

    • Identifiez les modes de défaillance qui ne sont pas considérés comme des catastrophes, tels que la défaillance d'une seule ressource, afin que les opérateurs n'invoquent pas par erreur leurs escalades DR. Ces modes d’échec peuvent être résolus en dépannant le problème en place, en redéployant les ressources ayant échoué ou en utilisant un plan de sauvegarde

  • Construisez le plan DR sur votre documentation FMA. Assurez-vous que votre plan de récupération d’urgence capture les modes d’échec et les stratégies d’atténuation des pannes définies en tant que sinistres. Mettez à jour votre plan de récupération d’urgence et vos documents FMA en parallèle afin qu’ils soient précis lorsque l’environnement change ou lorsque le test découvre des comportements inattendus.

    • Si vous développez des plans de récupération d’urgence pour les environnements hors production, dépend des besoins de votre entreprise et des impacts sur les coûts. Par exemple, si vous offrez des environnements d’assurance qualité (QA) à certains clients pour les tests de pré-lancement, vous pouvez inclure ces environnements dans votre plan de reprise après sinistre.

  • Définissez clairement les rôles et responsabilités au sein de l’équipe de charge de travail et comprenez les rôles externes associés au sein de votre organisation. Les rôles doivent inclure :

    • Partie responsable de la déclaration d’un désastre.

    • La partie responsable de la déclaration de clôture de l'incident.

    • Rôles d’opérations.

    • Tests et rôles de validation.

    • Rôles de communication interne et externe.

    • Rôles principaux dans l'analyse rétrospective et l'analyse des causes profondes (RCA).

  • Définissez les chemins d’escalade que l’équipe de charge de travail doit suivre pour vous assurer que l’état de récupération est communiqué aux parties prenantes.

  • Capturez les procédures de récupération au niveau des composants, la récupération au niveau du patrimoine de données et les processus de récupération à l’échelle de la charge de travail. Incluez un ordre d’opérations prescrit pour s’assurer que les composants sont récupérés de manière la moins impactante. Par exemple, récupérez et vérifiez les bases de données avant de récupérer l’application.

    • Détaillez chaque procédure de récupération au niveau du composant en tant que guide pas à pas. Incluez des captures d’écran si possible.

    • Définissez les responsabilités de votre équipe par rapport aux responsabilités de votre fournisseur d’hébergement cloud. Par exemple, Microsoft est responsable de la restauration d’un PaaS (plateforme en tant que service), mais vous êtes responsable de la réhydratage des données et de l’application de votre configuration au service.

    • Incluez les prérequis pour l’exécution de la procédure. Par exemple, dressez la liste des scripts ou des informations d'identification nécessaires.

    • Capturez la cause racine de l’incident et effectuez une atténuation avant de commencer la récupération. Par exemple, si la cause de l’incident est un problème de sécurité, atténuez ce problème avant de récupérer les systèmes concernés dans votre environnement de basculement.

  • En fonction de la conception de la redondance de votre charge de travail, il se peut que vous deviez effectuer d'importants travaux après le basculement avant de remettre la charge de travail à la disposition de vos clients. Le travail après basculement peut inclure des mises à jour DNS, des mises à jour des chaînes de connexion aux bases de données et des modifications de routage du trafic. Consignez tous les travaux effectués après le basculement dans vos procédures de récupération.

    Remarque

    Votre conception de redondance peut vous permettre de récupérer automatiquement des incidents majeurs entièrement ou partiellement. Veillez donc à ce que votre plan inclut des processus et des procédures autour de ces scénarios. Par exemple, si vous disposez d'une conception entièrement active-active qui s'étend sur des zones de disponibilité ou des régions, vous pourriez être en mesure de basculer automatiquement de manière transparente après une panne de zone de disponibilité ou de région et de minimiser les étapes à exécuter dans votre plan DR. De même, si vous avez conçu votre charge de travail en utilisant des timbres de déploiement, vous risquez de ne subir qu'une panne partielle si les timbres sont déployés par zones. Dans ce cas, votre plan DR doit prévoir comment récupérer les cachets dans les zones ou régions non affectées.

  • Si vous devez redéployer votre application dans l’environnement de basculement, utilisez des outils pour automatiser le processus de déploiement autant que possible. Vérifiez que vos pipelines DevOps ont été prédéployés et configurés dans les environnements de basculement afin de pouvoir commencer immédiatement vos déploiements d’applications. Utilisez des déploiements de bout en bout automatisés, avec des portes d’approbation manuelles si nécessaire, pour garantir un processus de déploiement cohérent et efficace. La durée complète du déploiement doit s’aligner sur vos cibles de récupération.

    • Lorsqu’une phase du processus de déploiement nécessite une intervention manuelle, documentez les étapes manuelles. Définissez clairement les rôles et responsabilités.

  • Automatisez autant de procédures que vous pouvez. Dans vos scripts, utilisez la programmation déclarative, car elle autorise l’idempotence. Lorsque vous ne pouvez pas utiliser de programmation déclarative, n’oubliez pas de développer et d’exécuter votre code personnalisé. Utilisez la logique de réessai et la logique de disjoncteur pour éviter de perdre du temps avec des scripts bloqués sur une tâche non exécutée. Étant donné que vous exécutez ces scripts uniquement en cas d’urgence, vous ne souhaitez pas que les scripts mal développés provoquent des dommages ou ralentissent votre processus de récupération.

    Remarque

    L’automatisation pose des risques. Les opérateurs formés doivent surveiller attentivement les processus automatisés et intervenir si un processus rencontre des problèmes. Pour minimiser le risque que l'automatisation réagisse à des faux positifs, soyez rigoureux dans vos exercices de DR. Testez toutes les phases du plan. Simuler la détection pour générer des alertes, puis parcourir l’ensemble de la procédure de récupération.

    N'oubliez pas que vos exercices de DR doivent valider ou informer les mises à jour de vos mesures cibles de récupération. Si vous constatez que votre automatisation est susceptible de faux positifs, vous devrez peut-être augmenter vos seuils de basculement.

  • Séparez le plan de retour arrière du plan de reprise après sinistre pour éviter toute confusion potentielle avec les procédures de reprise après sinistre. Le plan de repli doit suivre toutes les recommandations de développement et de maintenance du plan de reprise après sinistre et doit être structuré de la même façon. Toutes les étapes manuelles qui ont été nécessaires pour le basculement doivent être reprises dans le plan de secours. Le basculement peut se produire rapidement après le basculement, ou prendre des jours ou des semaines. Considérez le basculement comme une opération distincte du basculement.

    • La nécessité de faire marche arrière est liée à la situation. Si vous acheminez du trafic entre des régions pour des raisons de performances, il est important de rétablir la charge qui se trouvait initialement dans la région qui a basculé. Dans d’autres cas, vous avez peut-être conçu votre charge de travail pour fonctionner pleinement quel que soit l’environnement de production dans lequel il se trouve à tout moment.

Effectuer des exercices de récupération d’urgence

Une pratique de test de DR est aussi importante qu'un plan de DR bien conçu. De nombreux secteurs d'activité disposent de frameworks de conformité qui exigent qu'un certain nombre d'exercices de DR soient effectués régulièrement. Quel que soit votre secteur d'activité, des exercices réguliers de DR sont essentiels à votre réussite.

Suivez ces recommandations pour un exercice de reprise après sinistre réussi :

  • Effectuez au moins un exercice de DR de production par an. Les exercices tabletop (exécution sèche) ou les exercices hors production permettent de s’assurer que les parties concernées connaissent leurs rôles et responsabilités. Ces exercices aident également les opérateurs à créer une familiarité (« mémoire musculaire ») en suivant les processus de récupération. Mais seuls les exercices de production permettent de tester véritablement la validité du plan DR et des mesures RTO et RPO. Utilisez vos exercices de production pour chronométrer les processus de récupération des composants et des flux afin de vous assurer que les objectifs de RTO et de RPO qui ont été définis pour votre charge de travail sont réalisables. Pour les fonctions hors de votre contrôle, telles que la propagation DNS, assurez-vous que les cibles RTO et RPO pour les flux qui impliquent ces fonctions comptent pour des retards possibles au-delà de votre contrôle.

  • Utilisez les exercices sur table non seulement pour familiariser les opérateurs chevronnés, mais aussi pour former les nouveaux opérateurs aux processus et procédures de DR. Les opérateurs supérieurs doivent prendre du temps pour permettre aux nouveaux opérateurs d’exercer leur rôle et de surveiller les opportunités d’amélioration. Si un nouvel opérateur est hésitant ou confus par une étape d’une procédure, passez en revue cette procédure pour vous assurer qu’elle est clairement écrite.

Considérations

  • L'exécution d'exercices de DR en production peut provoquer des défaillances catastrophiques inattendues. Veillez à tester les procédures de récupération dans des environnements hors production pendant vos déploiements initiaux.

  • Donnez à votre équipe autant de temps de maintenance que possible pendant les exercices. Lors de la planification du temps de maintenance, utilisez les métriques de récupération que vous capturez pendant le test en tant qu’allocations minimales nécessaires .

  • À mesure que vos exercices de reprise après sinistre arrivent à maturité, vous découvrez les procédures que vous pouvez exécuter en parallèle et celles que vous devez exécuter en séquence. Au début de vos exercices d'entraînement, supposez que chaque procédure doit être exécutée en séquence et que vous avez besoin de temps supplémentaire pour chaque étape afin de gérer les problèmes imprévus.

Définir et gérer des plans de sauvegarde pour les ressources au sein de flux critiques

La sauvegarde est une partie importante de votre processus de récupération global. Souvent, il s’agit simplement d’une partie de votre environnement qui a besoin de récupération. Les plans de DR sont généralement mis en œuvre à l'échelle d'une application, voire d'une région. La suppression accidentelle ou malveillante de données, la corruption de fichiers, les programmes malveillants et les attaques de ransomware ciblées peuvent toutes affecter la disponibilité de votre charge de travail. Avoir des plans de sauvegarde solides pour chaque partie de votre environnement est tout aussi important que d’avoir un plan de récupération d’urgence efficace, car un plan de récupération d’urgence dépend d’un plan de sauvegarde solide pour être efficace. Comme votre plan de récupération d’urgence, les plans de sauvegarde doivent également être convenus par les niveaux de gestion appropriés, revisités régulièrement pour les mises à jour possibles et documentées dans un magasin de données hautement disponible et sécurisé.

  • Déterminez les solutions de sauvegarde appropriées pour les différents services Azure qui font partie des chemins critiques au sein de votre charge de travail.

  • Définissez les périodes de rétention requises pour chaque service différent.

  • Comprenez qu’un outil peut ne pas fonctionner pour tout. Les outils sauvegarde Azure peuvent couvrir de nombreux types de ressources, mais pas tous.

  • Parfois, la meilleure option pour restaurer certains types d’objets est un redéploiement à partir d’un type de référentiel hautement disponible. (Azure DevOps, GitHub ou d’autres)

  • Les services de données ont des exigences différentes des objets liés à l’application.

  • Veillez à envisager une stratégie de stockage multirégion pour vos données de sauvegarde afin de créer une récupération interrégion.

  • Exécutez des restaurations de test régulières planifiées des données de sauvegarde pour vous assurer que les services fonctionnent comme prévu.

Facilitation Azure

De nombreux produits Azure ont des fonctionnalités de basculement intégrées. Familiarisez-vous avec ces fonctionnalités et incluez-les dans les procédures de récupération. Consultez la série Reprise après sinistre pour la plateforme de données Azure pour obtenir des conseils sur la préparation d’une infrastructure de données d’entreprise pour la reprise après sinistre.

Pour les systèmes IaaS (infrastructure as a service), utilisez Azure Site Recovery pour automatiser le basculement et la récupération. Reportez-vous aux articles suivants pour les produits PaaS courants :

De nombreux produits Azure ont des fonctionnalités de sauvegarde intégrées. Familiarisez-vous avec ces fonctionnalités et incluez-les dans les procédures de récupération.

Pour les systèmes IaaS (infrastructure as a service), utilisez Sauvegarde Azure pour faciliter la sauvegarde des machines virtuelles et des services liés aux machines virtuelles et à certains services de données. Reportez-vous aux articles suivants pour les produits courants :

Liste de contrôle de fiabilité

Reportez-vous à l’ensemble complet de recommandations.

liste de contrôle de fiabilité