Share via

Recommandations pour la conception d’une stratégie d’atténuation des échecs de déploiement

  • Article

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

OE :12 Implémentez une stratégie d’atténuation des échecs de déploiement qui résout les problèmes inattendus à mi-déploiement avec une récupération rapide. Combinez plusieurs approches, telles que la restauration, la désactivation des fonctionnalités ou l’utilisation des fonctionnalités natives de votre modèle de déploiement.

Ce guide décrit les recommandations relatives à la conception d’une stratégie standardisée pour gérer efficacement les échecs de déploiement. Comme d’autres problèmes de charge de travail, les échecs de déploiement font inévitablement partie du cycle de vie d’une charge de travail. Avec cet état d’esprit, vous pouvez être proactif en ayant une stratégie bien conçue et intentionnelle pour faire face aux échecs de déploiement. Une telle stratégie permet à votre équipe de charge de travail d’atténuer efficacement les défaillances avec le moins d’impact possible sur vos utilisateurs finaux.

L’absence d’un tel plan peut entraîner des réponses chaotiques et potentiellement préjudiciables aux problèmes, ce qui peut affecter considérablement la cohésion de l’équipe et de l’organisation, la confiance des clients et les finances.

Stratégies de conception

Parfois, malgré la maturité de vos pratiques de développement, des problèmes de déploiement se produisent. L’utilisation de pratiques de déploiement sécurisées et l’exploitation d’une chaîne d’approvisionnement de charge de travail robuste peuvent vous aider à réduire la fréquence des déploiements ayant échoué. Mais vous devez également concevoir une stratégie standardisée pour gérer les déploiements ayant échoué lorsqu’ils se produisent.

Lorsque vous utilisez un modèle de déploiement d’exposition progressive comme pratique standard :

  • Vous disposez des bases appropriées pour réduire les effets sur vos clients ou les utilisateurs internes en cas d’échec des déploiements.
  • Vous pouvez atténuer efficacement les problèmes.

Une stratégie d’atténuation des échecs de déploiement se compose de cinq grandes phases :

  1. Détection : pour répondre à un déploiement ayant échoué, vous devez d’abord détecter l’échec. La détection peut prendre plusieurs formes, comme l’échec des tests de fumée, les problèmes signalés par l’utilisateur ou les alertes générées par votre plateforme de surveillance.

  2. Décision : vous devez décider quelle est la meilleure stratégie d’atténuation pour le type de défaillance spécifique.

  3. Atténuation : vous effectuez l’action d’atténuation identifiée. L’atténuation peut prendre la forme d’un secours, d’une restauration, d’une restauration ou de l’utilisation d’une configuration d’exécution pour contourner la fonction incriminant.

  4. Communication : les parties prenantes et les utilisateurs finaux concernés doivent être informés de la status à mesure que vous détectez et gérez le problème, comme l’exige votre plan d’intervention d’urgence.

  5. Post-mortem : les post-mortems sans blâme offrent à l’équipe de charge de travail des opportunités d’identifier les domaines à améliorer et de créer des plans pour appliquer les apprentissages.

Les sections suivantes fournissent des recommandations détaillées pour ces phases. Ces sections supposent que vous détectez un problème après avoir déployé vos modifications sur un ou plusieurs groupes d’utilisateurs ou de systèmes, mais avant de mettre à jour tous les groupes de votre plan de déploiement.

Détection

Pour identifier rapidement les problèmes liés aux déploiements, vous avez besoin de pratiques de test et d’observabilité robustes en ce qui concerne les déploiements. Pour vous aider à détecter rapidement les anomalies, vous pouvez compléter la surveillance et les alertes de votre charge de travail en effectuant les étapes suivantes :

  • Utilisez un outil de gestion des performances des applications.
  • Activez la journalisation via l’instrumentation.

Le dépistage de la fumée et d’autres tests de qualité doivent se produire à chaque phase de votre déploiement. Les tests réussis dans un groupe de déploiement ne doivent pas influencer les décisions de test dans les groupes suivants.

Vous pouvez implémenter la télémétrie qui met en corrélation les problèmes des utilisateurs avec une phase de déploiement. Vous pouvez ensuite identifier rapidement le groupe de déploiement auquel un utilisateur particulier est associé. Cette approche est particulièrement importante pour les déploiements à exposition progressive, car plusieurs configurations peuvent s’exécuter sur votre base d’utilisateurs à un moment donné du déploiement.

Vous devez être prêt à répondre immédiatement aux problèmes signalés par l’utilisateur. Chaque fois que cela est possible, déployez votre phase de déploiement pendant les heures de travail, lorsque vous disposez d’une équipe de support complète. Assurez-vous que le personnel du support technique est formé sur la façon d’escalader les problèmes de déploiement pour un routage approprié. Les escalades doivent s’aligner sur le plan d’intervention d’urgence de votre charge de travail.

Décision

Pour décider d’une stratégie d’atténuation appropriée pour un problème de déploiement donné, il faut prendre en compte de nombreux facteurs, notamment :

  • Type de modèle d’exposition progressive que vous utilisez. Par exemple, vous pouvez utiliser un modèle bleu-vert ou un modèle canary.

    Si vous utilisez un modèle bleu-vert, il est plus pratique de revenir en arrière que de revenir en arrière. Vous pouvez facilement réorienter le trafic vers la pile qui exécute la configuration qui n’est pas mise à jour. Vous pouvez ensuite résoudre le problème dans l’environnement problématique et réessayer votre déploiement au moment approprié.

  • Méthodes que vous avez à votre disposition pour contourner le problème. Les exemples incluent l’utilisation d’indicateurs de fonctionnalité, de variables d’environnement ou de tout autre type de propriété de configuration du runtime que vous pouvez activer et désactiver.

    Parfois, vous pouvez facilement contourner un problème en désactivant un indicateur de fonctionnalité ou en désactivant un paramètre. Dans ce cas, vous pouvez :

    • Poursuivez le déploiement.
    • Évitez de revenir en arrière.
    • Effectuez une restauration pendant que vous corrigez le code incriminé.

  • Niveau d’effort requis pour implémenter un correctif dans le code.

    Si le niveau d’effort nécessaire pour corriger le code est faible, la progression en implémentant un correctif à chaud est le bon choix pour certains scénarios.

  • Niveau de criticité pour la charge de travail affectée.

    Les charges de travail critiques pour l’entreprise doivent toujours être déployées côte à côte, comme dans un modèle bleu-vert, pour obtenir des déploiements sans temps d’arrêt. Par conséquent, le retour en arrière est la stratégie d’atténuation préférable pour ces types de charges de travail.

  • Type d’infrastructure utilisé par la charge de travail : mutable ou immuable.

    Si votre charge de travail est conçue pour utiliser une infrastructure mutable, la progression peut être logique, car elle implique la mise à jour de l’infrastructure en place. À l’inverse, la restauration ou la restauration peuvent être logiques lorsque vous utilisez une infrastructure immuable.

Quels que soient les choix que vous faites, vous devez inclure les approbations appropriées dans votre processus de prise de décision et les codifier dans votre arbre de décision.

Limitation des risques

  • Restauration : dans un scénario de restauration, vous rétablissez les systèmes mis à jour à l’état de configuration du dernier bon état connu.

    Il est important que l’ensemble de l’équipe de charge de travail soit d’accord sur la signification du dernier bien connu. Cette expression fait référence au dernier état de la charge de travail qui était sain avant le début du déploiement, qui n’est pas nécessairement la version antérieure de l’application.

    La restauration peut être complexe, en particulier en ce qui concerne les modifications de données. Les modifications de schéma peuvent rendre la restauration risquée. Leur implémentation en toute sécurité peut nécessiter une planification considérable. Comme recommandation générale, les mises à jour de schéma doivent être additives. Ils ne doivent pas être des modifications de remplacement. Les enregistrements ne doivent pas être remplacés par de nouveaux enregistrements. Au lieu de cela, les enregistrements plus anciens doivent être déconseillés et doivent coexister avec de nouveaux enregistrements jusqu’à ce qu’il soit possible de supprimer les enregistrements déconseillés en toute sécurité.

  • Secours : dans un scénario de secours, les systèmes mis à jour sont supprimés du routage du trafic de production. Tout le trafic est dirigé vers la pile qui n’est pas mise à jour. Cette stratégie à faible risque vous permet de résoudre les problèmes de votre code sans introduire d’autres interruptions.

    Avec les déploiements canary, la restauration en arrière n’est peut-être pas simple ou même possible, en fonction de votre infrastructure et de la conception de votre application. Si vous devez effectuer une mise à l’échelle pour gérer la charge sur les systèmes qui ne sont pas mis à jour, effectuez cette mise à l’échelle avant de revenir en arrière.

  • Contourner la fonction incriminée : si vous pouvez contourner le problème à l’aide d’indicateurs de fonctionnalité ou d’un autre type de propriété de configuration du runtime, vous pouvez décider que la poursuite du déploiement est la bonne stratégie pour un problème donné.

    Vous devez comprendre clairement le compromis de contournement de la fonction, et vous devez être en mesure de communiquer ce compromis aux parties prenantes. Les parties prenantes doivent approuver le plan de progression. Les parties prenantes doivent déterminer la durée tolérable pour fonctionner dans un état dégradé. Ils doivent également évaluer cette détermination par rapport à votre estimation du temps nécessaire pour corriger le code incriminé et le déployer.

  • Déploiement d’urgence (correctif à chaud) : si vous pouvez résoudre le problème à la mi-déploiement, un correctif à chaud peut être la stratégie d’atténuation la plus pratique.

    Comme tout autre code, les correctifs à chaud doivent passer en revue vos pratiques de déploiement sécurisées. Mais avec une solution à chaud, la chronologie est considérablement accélérée. Vous devez utiliser une stratégie de promotion du code dans tous vos environnements. Vous devez également case activée code de correctif à chaud à toutes les portes qualité. Mais vous devrez peut-être réduire considérablement les temps de cuisson, et vous devrez peut-être modifier les tests pour les accélérer. Assurez-vous que vous pouvez exécuter des tests complets sur le code mis à jour dès que possible après le déploiement. L’automatisation des tests d’assurance qualité à un degré élevé permet de rendre les tests efficaces dans ces scénarios.

Compromis :

  • Le fait de pouvoir reculer signifie généralement que vous avez besoin d’une capacité d’infrastructure suffisante pour gérer deux versions de la configuration de votre charge de travail en même temps. Vos équipes de charge de travail doivent également être en mesure de prendre en charge deux versions en production en même temps.
  • La restauration efficace peut impliquer la refactorisation d’éléments de votre charge de travail. Par exemple, vous devrez peut-être dissocier les fonctions ou modifier votre modèle de données.

Communication

Il est important d’avoir des responsabilités de communication clairement définies pour réduire le chaos pendant les incidents. Ces responsabilités doivent établir la façon dont l’équipe de charge de travail collabore avec les équipes de support, les parties prenantes et le personnel de l’équipe d’intervention d’urgence, comme le gestionnaire d’intervention d’urgence.

Standardisez la cadence que l’équipe de charge de travail suit pour fournir status mises à jour. Assurez-vous que les parties prenantes sont au courant de cette norme afin qu’elles sachent quand attendre des mises à jour.

Si l’équipe de charge de travail doit communiquer directement avec les utilisateurs finaux, précisez le type d’informations et le niveau de détail appropriés pour le partage avec les utilisateurs. Communiquez également à l’équipe de charge de travail toutes les autres exigences qui s’appliquent à ces cas.

Analyse post-mortem

Les post-mortem doivent suivre tous les déploiements ayant échoué, sans exception. Chaque déploiement ayant échoué est une opportunité d’apprentissage. Les post-mortem peuvent vous aider à identifier les faiblesses de vos processus de déploiement et de développement. Vous pouvez également identifier des configurations incorrectes dans votre infrastructure, parmi de nombreuses autres possibilités.

Les post-mortems doivent toujours être irréprochables afin que les personnes impliquées dans l’incident se sentent en sécurité lorsqu’elles partagent leur point de vue sur ce qui peut être amélioré. Les responsables post-mortem doivent suivre les plans d’implémentation des améliorations qui ont été identifiées et ajouter ces plans au backlog de charge de travail.

Considérations et recommandations générales

Assurez-vous que votre pipeline de déploiement peut accepter des versions distinctes en tant que paramètres afin de pouvoir déployer facilement les dernières configurations connues.

Maintenez la cohérence avec les plans de gestion et de données lors de la restauration ou de la progression. Les clés, les secrets, les données d’état de la base de données et les configurations spécifiques aux ressources et aux stratégies doivent tous être inclus dans l’étendue et pris en compte. Par exemple, faites attention à la conception de la mise à l’échelle de votre infrastructure dans votre dernier déploiement connu-correct. Déterminez si vous devez ajuster cette configuration lorsque vous redéployez votre code.

Préférez les changements petits et fréquents aux changements peu fréquents et volumineux afin que le delta entre vos nouveaux déploiements et vos derniers déploiements connus soit faible.

Effectuez une analyse du mode d’échec (FMA) sur vos pipelines d’intégration continue et de livraison continue (CI/CD) pour vous aider à identifier les problèmes qui peuvent compliquer les atténuations. Comme votre charge de travail dans son ensemble, vos pipelines peuvent être analysés pour identifier les zones qui peuvent être problématiques lorsque vous tentez un type d’atténuation donné.

Utilisez judicieusement la fonctionnalité de restauration automatisée :

  • Certains outils CI/CD comme Azure DevOps ont une fonctionnalité de restauration automatique intégrée. Envisagez d’utiliser cette fonctionnalité si elle vous fournit une valeur tangible.
  • Vous ne devez adopter la fonctionnalité de restauration automatique qu’après avoir testé votre pipeline de manière approfondie et régulière. Assurez-vous que votre pipeline est suffisamment mature pour introduire des problèmes supplémentaires si une restauration automatique est déclenchée.
  • Vous devez vous assurer que l’automatisation déploie uniquement les modifications nécessaires et qu’elle n’est déclenchée que si nécessaire. Concevez vos déclencheurs avec soin pour répondre à ces exigences.

Utilisez les fonctionnalités fournies par la plateforme pendant les restaurations. Par exemple, les sauvegardes et les restaurations à un point dans le temps peuvent faciliter les restaurations de stockage et de données. Ou si vous utilisez des machines virtuelles pour héberger votre application, il peut être utile de restaurer votre environnement à un point de contrôle immédiatement avant un incident.

Testez fréquemment l’ensemble de votre stratégie d’atténuation des échecs de déploiement. Comme les plans d’intervention d’urgence et les plans de récupération d’urgence, votre plan d’échec de déploiement n’aboutit que si votre équipe y est formée et l’exerce régulièrement. L’ingénierie du chaos et les tests d’injection d’erreurs peuvent être des techniques efficaces pour tester votre stratégie d’atténuation de déploiement.

Compromis : les membres de l’équipe de support doivent être en mesure d’effectuer leurs tâches normales et de prendre en charge les situations d’urgence. Vous devrez peut-être augmenter le nombre de personnes pour vous assurer que l’équipe de support dispose d’un personnel adéquat et qu’elle est en mesure d’effectuer toutes les tâches requises. Testez soigneusement les déploiements lorsque vous effectuez un déploiement dans des environnements de développement inférieurs. Cette pratique vous aide à détecter les bogues et les erreurs de configuration avant leur mise en production.

Facilitation Azure

  • Azure Pipelines fournit des services de génération et de mise en production pour prendre en charge le CI/CD de vos applications.

  • Azure Test Plans est une solution de gestion des tests basée sur un navigateur facile à utiliser. Cette solution offre des fonctionnalités requises pour les tests manuels planifiés, les tests d’acceptation par l’utilisateur et les tests exploratoires. Azure Test Plans vous permet également de recueillir des commentaires des parties prenantes.

  • Azure Monitor est une solution de supervision complète pour la collecte, l’analyse et la réponse aux données de supervision à partir de vos environnements cloud et locaux. Monitor inclut une plateforme d’alerte robuste. Vous pouvez configurer ce système pour les notifications automatiques et d’autres actions, telles que la mise à l’échelle automatique et d’autres mécanismes d’auto-réparation.

  • Application Insights est une extension de Monitor qui fournit des fonctionnalités d’analyse des performances des applications (APM).

  • Azure Logic Apps est une plateforme cloud permettant d’exécuter des flux de travail automatisés qui intègrent des applications, des données, des services et des systèmes. Vous pouvez utiliser Logic Apps pour créer une nouvelle version de votre application chaque fois qu’une mise à jour y est effectuée. Azure conserve un historique des versions et peut rétablir ou promouvoir n’importe quelle version précédente.

  • De nombreux services de base de données Azure fournissent des fonctionnalités de restauration à un point dans le temps qui peuvent vous aider lorsque vous devez restaurer :

  • Préversion Azure Chaos Studio est un service managé qui utilise l’ingénierie du chaos pour vous permettre de mesurer, comprendre et améliorer votre application cloud et la résilience du service.

Liste de contrôle de l’excellence opérationnelle

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de l’excellence opérationnelle