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

S’applique à cette recommandation de liste de contrôle Excellence opérationnelle Power Platform Well-Architected :

OE:11	Mettez en œuvre 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 de fonctionnalités ou l’utilisation des fonctionnalités natives de votre modèle de déploiement.

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

L’absence d’un tel plan peut conduire à 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 clés

Parfois, malgré la maturité de vos pratiques de développement, des problèmes de déploiement surviennent. L’utilisation de pratiques de déploiement sûres et l’exploitation d’une chaîne d’approvisionnement de charges de travail robuste peuvent vous aider à minimiser la fréquence des échecs de déploiement. Mais vous devez également concevoir une stratégie standardisée pour gérer les échecs de déploiement lorsqu’ils se produisent.

Une stratégie d’atténuation des échecs de déploiement est composée de cinq grandes phases :

1. Détection : pour répondre à un échec de déploiement, vous devez d’abord détecter l’échec. La détection peut prendre plusieurs formes, comme des tests de fumée échoués, des problèmes signalés par les utilisateurs ou des 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 panne spécifique.
3. Atténuation : vous effectuez l’action d’atténuation identifiée. L’atténuation peut prendre la forme d’un repli, d’une restauration ou d’une restauration.
4. Communication : les parties prenantes et les utilisateurs finaux concernés doivent être informés de l’état à mesure que vous détectez et résolvez le problème, comme l’exige votre plan d’intervention d’urgence.
5. Post-mortem : des post-mortems irréprochables offrent à l’équipe chargée de la charge de travail la possibilité 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.

Détection

Pour identifier rapidement les problèmes liés aux déploiements, vous avez besoin de pratiques de test et de surveillance 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 suivant les étapes suivantes :

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

Des tests de fumée et d’autres tests de qualité doivent avoir lieu à chaque phase de votre déploiement. Les tests réussis dans un groupe de déploiement ne devraient pas influencer les décisions de tester dans les groupes suivants.

Vous pouvez implémenter une 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 à quel groupe de déploiement un utilisateur particulier est associé. Cette approche est particulièrement importante pour les déploiements d’exposition progressifs, car plusieurs configurations peuvent s’exécuter sur votre base d’utilisateurs à tout moment du déploiement.

Vous devez être prêt à répondre immédiatement aux problèmes signalés par les utilisateurs. Dans la mesure du possible, déployez votre phase de déploiement pendant les heures de travail, lorsque vous disposez d’une équipe d’assistance complète. Assurez-vous que le personnel d’assistance est formé sur la façon de faire remonter les problèmes de déploiement pour un acheminement correct. Les escalades doivent correspondre à votre plan d’intervention d’urgence en matière de charge de travail.

Décision

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

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

  Si vous utilisez un modèle bleu-vert, le retour en arrière est plus pratique que le retour en arrière. Vous pouvez facilement rediriger 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 à un moment approprié.

• Les méthodes dont vous disposez pour contourner le problème. Les exemples incluent l’utilisation d’indicateurs de fonctionnalités, de variables d’environnement ou de tout autre type de propriété de configuration d’exécution que vous pouvez activer ou désactiver.

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

  • Procédez au déploiement.
  • Évitez de retomber.
  • Revenez en arrière pendant que vous corrigez le code incriminé.

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

  Si le niveau d’effort pour corriger le code est faible, la mise en œuvre d’un correctif logiciel est le bon choix pour certains scénarios.

• Le niveau de criticité de 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 repli est la stratégie d’atténuation préférable pour ces types de charges de travail.

Correction

Voici les stratégies de atténuation les plus courantes :

• Rollback : dans un scénario de restauration, vous rétablissez les systèmes mis à jour au dernier état de configuration connu.

  Il est important que toute l’équipe chargée de la 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 précédente de l’application.

  La restauration peut être complexe, notamment en ce qui concerne les modifications de données. Les modifications du schéma peuvent rendre la restauration risquée. Leur mise en œuvre en toute sécurité peut nécessiter une planification considérable. En règle générale, les mises à jour de schéma doivent être additives. Il ne doit pas s’agir de 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 obsolètes et doivent coexister avec les nouveaux enregistrements jusqu’à ce qu’il soit possible de supprimer en toute sécurité les enregistrements obsolètes.

• Repli : dans un scénario de repli, 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 de nouvelles perturbations.

  Avec les déploiements Canary, le repli peut ne pas être simple, ni même possible, en fonction de la conception de votre infrastructure et de vos applications. Si vous devez effectuer une mise à l’échelle pour gérer la charge sur des 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 en utilisant des indicateurs de fonctionnalité ou un autre type de propriété de configuration d’exécution, vous pouvez décider que poursuivre le déploiement est la bonne stratégie pour un problème donné.

  Vous devez clairement comprendre le compromis qu’il y a à contourner la fonction et vous devez être en mesure de communiquer ce compromis aux parties prenantes. Les parties prenantes devraient approuver le plan d’avenir. Les parties prenantes doivent déterminer la durée tolérable pour fonctionner dans un état dégradé. Ils doivent également comparer cette détermination à votre estimation du temps nécessaire pour corriger le code incriminé et le déployer.

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

  Comme tout autre code, les correctifs doivent passer par vos pratiques de déploiement sécurisées. Mais avec un correctif, le délai est considérablement accéléré. Vous devez utiliser une stratégie de promotion de code dans tous vos environnements. Vous devez également vérifier le code du correctif à toutes les portes de qualité. Mais vous devrez peut-être réduire considérablement les temps de cuisson et modifier les tests pour les accélérer. Assurez-vous de pouvoir exécuter des tests complets sur le code mis à jour dès que possible après le déploiement. L’automatisation dans une large mesure des tests d’assurance qualité contribue à rendre les tests efficaces dans ces scénarios.

Communication

Il est important de définir clairement les responsabilités en matière de communication afin de minimiser le chaos lors d’incidents. Ces responsabilités doivent établir la manière dont l’équipe chargée de la charge de travail interagit avec les équipes de support, les parties prenantes et le personnel de l’équipe d’intervention d’urgence, comme le responsable des interventions d’urgence.

Standardisez la cadence suivie par l’équipe chargée de la charge de travail pour fournir des mises à jour de statut. Assurez-vous que les parties prenantes connaissent cette norme afin qu’elles sachent quand s’attendre à des mises à jour.

Si l’équipe chargée de la charge de travail doit communiquer directement avec les utilisateurs finaux, clarifiez le type d’informations et le niveau de détail appropriés pour le partage avec les utilisateurs. Communiquez également à l’équipe chargée de la charge de travail toute autre exigence qui s’applique à ces cas.

Post-mortem

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

Les autopsies doivent toujours être irréprochables afin que les personnes impliquées dans l’incident se sentent en sécurité lorsqu’elles partagent leurs points de vue sur ce qui peut être amélioré. Les dirigeants post-mortem doivent suivi avec des plans pour mettre en œuvre les améliorations identifiées et pour ajouter ces plans à l’arriéré de charge de travail.

Considérations et recommandations générales

Assurez-vous que votre pipeline de déploiement peut accepter des versions distinctes comme 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 restauration. 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 politiques doivent tous être inclus dans la portée et pris en compte. Par exemple, faites attention à la conception de la mise à l’échelle de votre infrastructure lors de votre dernier déploiement connu. Déterminez si vous devez ajuster cette configuration lorsque vous redéployez votre code.

Préférez les petits changements fréquents aux changements peu fréquents et importants afin que le delta entre vos nouveaux déploiements et le dernier déploiement connu soit faible.

Effectuez une analyse des modes de défaillance (FMA) sur vos pipelines d’intégration continue et de livraison continue (CI/CD) pour vous aider à identifier les problèmes susceptibles de compliquer les efforts d’atténuation. Comme votre charge de travail dans son ensemble, vos pipelines peuvent être analysés pour identifier les domaines susceptibles de poser problème lorsque vous tentez un type d’atténuation donné.

Utilisez judicieusement la fonctionnalité de restauration automatique :

• Certains outils CI/CD tels que Azure DevOps ont une fonctionnalité de restauration automatique intégrée. Pensez à utiliser cette fonctionnalité si elle vous apporte 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 être sûr que l’automatisation déploie uniquement les modifications nécessaires et qu’elle n’est déclenchée que lorsque cela est nécessaire. Concevez soigneusement vos déclencheurs pour répondre à ces exigences.

Utilisez les fonctionnalités fournies par la plateforme lors des restaurations. Par exemple, les sauvegardes et les restaurations ponctuelles peuvent faciliter la restauration du stockage et des données. Ou si vous utilisez des machines virtuelles (VM) pour héberger votre application, il peut être utile de restaurer votre environnement à un point de contrôle situé juste avant un incident.

Testez fréquemment l’ensemble de votre stratégie d’atténuation des échecs de déploiement. À l’instar des plans d’intervention d’urgence et des plans de reprise après sinistre, votre plan d’échec de déploiement ne réussit que si votre équipe y est formée et le met en pratique régulièrement. L’ingénierie du chaos et les tests d’injection de fautes peuvent être des techniques efficaces pour tester votre stratégie d’atténuation des déploiements.

Facilitation de Power Platform

Les pipelines dans Power Platform visent à démocratiser la gestion du cycle de vie des applications (ALM) pour les clients Power Platform et Dynamics 365 en intégrant l’automatisation ALM et les fonctionnalités d’intégration continue et de livraison continue (CI/CD) dans le service.

Microsoft Power Platform Build Tools pour Azure DevOps peut être utilisé pour automatiser les tâches courantes de création et de déploiement associées aux applications créées sur Power Platform.

Actions GitHub pour Power Platform permet aux développeurs de créer des workflows de cycle de vie de développement logiciel automatisés. Avec les actions GitHub pour Microsoft Power Platform, vous pouvez créer des flux de travail dans votre référentiel afin de créer, tester, empaqueter, publier et déployer des applications, effectuer l’automatisation et gérer les bots et autres composants basés sur Microsoft Power Platform.

ALM Accelerator est un outil open source composé d’un ensemble d’applications, de scripts et de pipelines conçus pour automatiser le processus d’intégration et de livraison continue.

Automatiser les tests avec les pipelines Azure avec YAML.

Les variables d’environnement dans les solutions stockent les clés et les valeurs des paramètres, qui servent ensuite d’entrée à divers autres objets d’application. La séparation des paramètres des objets qui les consomment vous permet de modifier les valeurs dans le même environnement ou lorsque vous migrez des solutions vers d’autres environnements.

Les environnements Power Platform fournissent une fonctionnalité de restauration à un moment précis qui peut vous aider à effectuer une restauration par annulation.

Power Platform s’intègre à Application Insights, qui fait partie de l’écosystème Azure Monitor. Utilisez cette intégration pour :

• Recevoir la télémétrie sur les diagnostics et les performances capturées par la plateforme Dataverse dans Application Insights. Vous pouvez vous abonner pour recevoir la télémétrie sur les opérations que les applications effectuent sur votre base de données Dataverse et dans les applications basées sur des modèles. Cette télémétrie fournit des informations que vous pouvez utiliser pour diagnostiquer et résoudre les problèmes liés aux erreurs et aux performances.

• Connectez vos applications canevas à Application Insights. Vous pouvez utiliser ces analyses pour diagnostiquer les problèmes et comprendre ce que les utilisateurs font avec vos applications. Vous pouvez collecter des informations pour vous aider à prendre de meilleures décisions commerciales et à améliorer la qualité de vos applications.

• Configurer la télémétrie Power Automate pour les flux dans Application Insights. Par exemple, pour surveiller les exécutions de flux de cloud et créer des alertes pour les échecs d’exécution de flux de cloud.

Liste de contrôle d’excellence opérationnelle

Référez-vous à l’ensemble complet des recommandations.

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