Recommandations pour la conception d’une stratégie d’atténuation des échecs de déploiement
S’applique à cette recommandation de la liste de contrôle d’excellence opérationnelle bien conçue : Power Platform
| 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 de charge de travail d’atténuer efficacement les pannes avec le moins d’impact possible sur vos utilisateurs.
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. Vous devez également concevoir une stratégie standardisée pour gérer les déploiements échoués lorsqu’ils se produisent.
Une stratégie d’atténuation des échecs de déploiement est composée de cinq grandes phases :
- 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 des tests de fumée échoués, des rapports d’utilisateurs ou des alertes générées par votre plateforme de surveillance.
- Décision : Vous devez décider quelle est la meilleure stratégie d’atténuation pour le type de défaillance spécifique.
- Atténuation : vous devez exécuter l’action d’atténuation identifiée. L’atténuation peut prendre la forme d’un repli, d’une restauration ou d’une restauration.
- Communication : Les parties prenantes et les utilisateurs concernés doivent être informés de l’état d’avancement du problème au fur et à mesure que vous le détectez et le résolvez, comme l’exige votre plan d’urgence réponse.
- Post-mortem : les post-mortem sans reproche offrent à l’équipe de charge de travail l’occasion 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 liées aux déploiements. Pour aider à détecter rapidement les anomalies, vous pouvez compléter votre surveillance de la charge de travail et vos alertes en utilisant un outil de gestion des performances des applications et en journalisant 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 manière de signaler les problèmes de déploiement pour un routage approprié. Les escalades doivent correspondre à votre plan d’intervention d’urgence en matière de charge de travail.
Décision
Déterminer une stratégie d’atténuation appropriée pour un problème de déploiement implique de prendre en compte des facteurs tels que :
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 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 :
Restauration : 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 de charge de travail soit d’accord sur la signification de "dernier état 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, ce 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. 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.
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 pouvez résoudre le problème au cours du déploiement, un correctif peut être 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 de correctif à tous les points de contrôle 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 de charge de travail doit communiquer directement avec les utilisateurs, clarifiez le type d’informations et le niveau de détail appropriés au partage. Communiquez également à l’équipe chargée de la charge de travail toute autre exigence qui s’applique à ces cas.
Post-mortem
Les autopsies doivent suivre tous les déploiements ayant échoué sans exception. Chaque échec de déploiement est une opportunité d’apprentissage. Les post-mortem peuvent vous aider à identifier les faiblesses de vos processus de déploiement et de développement ainsi que les mauvaises configurations de votre infrastructure.
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 responsables de l’autopsie devraient suivi prévoir la mise en œuvre des améliorations identifiées et l’ajout de ces plans à l’arriéré de la 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 la différence entre vos nouveaux déploiements et les derniers déploiements connus soit faible.
Effectuez une analyse des modes de défaillance sur vos pipelines d’intégration continue et de livraison continue (CI/CD) pour aider à identifier les problèmes qui peuvent compliquer les efforts d’atténuation. Comme pour votre charge de travail dans son ensemble, vos pipelines peuvent être analysés pour identifier les zones qui pourraient être problématiques 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 la restauration à un instant donné peuvent aider à restaurer le stockage et les 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. À 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 pannes peuvent être des techniques efficaces pour tester votre stratégie d’atténuation du déploiement.
Facilitation de Power Platform
Microsoft Power Platform Les outils de création pour Azure DevOps peuvent être utilisés pour automatiser les tâches de création et de déploiement courantes liées aux applications créées sur Power Platform.
Les actions GitHub permettent aux développeurs de créer des flux de travail automatisés tout au long du cycle de vie du développement logiciel. Power Platform 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 continue/livraison continue.
Automatisez les tests avec Azure Pipelines.
Utilisez le kit Power CAT pour configurer les copilotes et les tests. Copilot Studio En exécutant des tests individuels sur les API ( Copilot Studio ), les réponses du copilote sont évaluées par rapport aux résultats attendus.Direct Line
Les variables environnement dans les solutions stockent les clés et les valeurs des paramètres, qui servent ensuite d’entrée à d’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.
Power Platform Les environnements offrent une fonctionnalité de restauration à un instant donné qui peut vous aider à revenir en arrière.
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.
Configurez la Power Automate télémétrie à laquelle s’adresser Application Insights ; par exemple, pour surveiller les exécutions flux de cloud et créer des alertes pour les échecs d’exécution flux de cloud.
Capturez les données de télémétrie de votre Microsoft Copilot Studio copilote pour les utiliser dans Azure Application Insights. Vous pouvez utiliser cette télémétrie pour surveiller les messages et événements enregistrés envoyés vers et depuis votre copilote, les sujets à déclencher pendant les conversations des utilisateurs et les événements de télémétrie personnalisés qui peuvent être envoyés à partir de vos sujets.
Liste de contrôle de l’excellence opérationnelle
Référez-vous à l’ensemble complet des recommandations.