Recommandations pour la conception d’une stratégie d’atténuation des défaillances de déploiement
S’applique à cette recommandation de liste de contrôle Azure Well-Architected Framework Operational Excellence :
| OE :12 | Implémentez une stratégie d’atténuation des défaillances de déploiement qui résout des problèmes inattendus de déploiement intermédiaire 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 d’un cycle de vie de charge de travail. Avec cet état d’esprit, vous pouvez être proactif en ayant une stratégie bien conçue et intentionnelle pour traiter les défaillances de déploiement. Une telle stratégie permet à votre équipe de charge de travail d’atténuer efficacement les défaillances avec autant d’impact que possible sur vos utilisateurs finaux.
L’absence d’un tel plan peut entraîner des réponses chaotiques et potentiellement néfastes aux problèmes, ce qui peut affecter considérablement l’équipe et la cohésion organisationnelle, la confiance des clients et les finances.
Stratégies de conception
Parfois, malgré la maturité de vos pratiques de développement, les 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 robuste de charge de travail peuvent vous aider à réduire la fréquence des déploiements ayant échoué. Toutefois, 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 avez la bonne base pour réduire les effets sur vos clients ou utilisateurs internes lorsque les déploiements échouent.
- Vous pouvez atténuer efficacement les problèmes.
Une stratégie d’atténuation des défaillances de déploiement se compose de cinq phases générales :
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 les tests de fumée ayant échoué, les problèmes signalés par l’utilisateur ou les alertes générées par votre plateforme de surveillance.
Décision : vous devez décider de la meilleure stratégie d’atténuation pour le type d’échec spécifique.
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 vers l’avant ou de l’utilisation d’une configuration d’exécution pour contourner la fonction incriminnée.
Communication : les parties prenantes et les utilisateurs finaux concernés doivent être informés de l’état lorsque vous détectez et travaillez dans le cadre du problème, selon les besoins de votre plan d’intervention d’urgence.
Postmortem : les postmortems sans blâme permettent à l’équipe de charge de travail d’identifier les domaines d’amélioration et de créer des plans pour appliquer des 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 dans votre plan de déploiement.
Mécanismes de détection des défaillances de conception
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.
Les tests de 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 à tester dans les groupes suivants.
Vous pouvez implémenter la télémétrie qui met en corrélation les problèmes utilisateur 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 d’exposition progressive, car vous pouvez avoir plusieurs configurations s’exécutant sur votre base d’utilisateurs à un moment donné dans le déploiement.
Vous devez être prêt à répondre immédiatement aux problèmes signalés par l’utilisateur. Chaque fois que cela est pratique, déployez votre phase de déploiement pendant les heures de travail, lorsque vous disposez d’une équipe de support complète disponible. Assurez-vous que le personnel du support technique est formé sur la façon d’élever les problèmes de déploiement pour un routage approprié. Les escalades doivent s’aligner sur votre plan de réponse d’urgence de charge de travail.
Décider de la stratégie d’atténuation
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 :
Type de modèle d’exposition progressif 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, la restauration est plus pratique que la restauration. Vous pouvez facilement rebasculer 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é.
Méthodes dont vous disposez pour contourner le problème. Les exemples incluent l’utilisation d’indicateurs de fonctionnalité, de variables environnementales ou d’un autre type de propriété de configuration d’exécution 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 pourrez peut-être :
- Passez au déploiement.
- Évitez de revenir en arrière.
- Restaurez pendant que vous corrigez le code incriminé.
Niveau d’effort nécessaire pour implémenter un correctif dans le code.
Si le niveau d’effort 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 de manière côte à côte, comme dans un modèle bleu-vert, pour obtenir des déploiements sans temps d’arrêt. Par conséquent, la restauration 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 arrière 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 décisionnel et les codifier dans votre arbre de décision.
Implémenter la stratégie d’atténuation
Restauration : dans un scénario de restauration, vous rétablissez les systèmes mis à jour à l’état de configuration du dernier état de configuration connu.
Il est important que l’ensemble de l’équipe de charge de travail accepte la signification du dernier bon connu. Cette expression fait référence au dernier état de la charge de travail qui était saine avant le début du déploiement, ce 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 entraîner une restauration à risque. Leur implémentation en toute sécurité peut nécessiter une planification considérable. À titre de recommandation générale, les mises à jour de schéma doivent être additifs. 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 anciens enregistrements doivent être déconseillés et doivent coexister avec de nouveaux enregistrements jusqu’à ce qu’il soit sûr de supprimer les enregistrements déconseillés.
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’interruptions supplémentaires.
Avec les déploiements canary, la restauration automatique peut ne pas être simple ou même possible, en fonction de votre infrastructure et de votre conception d’application. Si vous devez effectuer la 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 d’exécution, 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 devriez ê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 qui est tolérable pour fonctionner dans un état détérioré. 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 au milieu du 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 par vos pratiques de déploiement sécurisées. Mais avec un correctif chaud, la chronologie est considérablement accélérée. Vous devez utiliser une stratégie de promotion du code dans vos environnements. Vous devez également vérifier le code de correctif chaud à toutes les portes de qualité. Mais vous devrez peut-être raccourcir considérablement les temps de cuisson, et vous devrez peut-être modifier les tests pour les accélérer. Vérifiez 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 niveau élevé permet de rendre les tests efficaces dans ces scénarios.
Compromis :
- La possibilité de revenir en arrière 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 possibilité de restaurer efficacement 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.
Normaliser les mises à jour d’état pendant un incident
Il est important d’avoir clairement défini les responsabilités de communication pour réduire le chaos pendant les incidents. Ces responsabilités doivent établir la façon dont l’équipe de charge de travail s’engage 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.
Normalisez la cadence que l’équipe de charge de travail suit pour fournir des mises à jour d’état. Assurez-vous que les parties prenantes sont conscientes de 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 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.
Mener des incidents postmortems
Les postmortems doivent suivre tous les déploiements ayant échoué, sans exception. Chaque déploiement ayant échoué est une opportunité d’apprentissage. Les postmortems 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, entre autres possibilités.
Les postmortems devraient toujours être blâmés afin que les personnes impliquées dans l’incident se sentent en sécurité lorsqu’elles partagent leurs perspectives sur ce qui peut être amélioré. Les responsables postmortems 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.
Opérationnaliser les processus d’atténuation
Assurez-vous que votre pipeline de déploiement peut accepter des versions distinctes en tant que paramètres afin que vous puissiez facilement déployer des configurations bonnes connues.
Maintenez la cohérence avec les plans de gestion et de données au fur et à mesure que vous restaurez ou restaurez vers l’avant. Les clés, les secrets, les données d’état de base de données et les configurations spécifiques aux ressources et stratégies doivent toutes être incluses dans l’étendue et prises en compte. Par exemple, faites attention à la conception de la mise à l’échelle de votre infrastructure dans votre dernier déploiement connu. Déterminez si vous devez ajuster cette configuration lorsque vous redéployez votre code.
Préférez les changements petits et fréquents par rapport à peu de modifications importantes afin que le delta entre vos déploiements nouveaux et connus soit petit.
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. À l’instar de votre charge de travail dans son ensemble, vos pipelines peuvent être analysés pour identifier les zones susceptibles d’être problématiques lorsque vous tentez un type d’atténuation donné.
Utilisez la fonctionnalité de restauration automatisée judicieusement :
- Certains outils CI/CD comme Azure DevOps ont des fonctionnalités de restauration automatique intégrées. Envisagez d’utiliser cette fonctionnalité s’il fournit une valeur tangible à vous.
- Vous devez adopter la fonctionnalité de restauration automatique uniquement après avoir testé votre pipeline minutieusement et régulièrement. 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 faire confiance au fait que l’automatisation déploie uniquement les modifications nécessaires et qu’elle est déclenchée uniquement si nécessaire. Concevez soigneusement vos déclencheurs 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 vous aider à effectuer des 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 sur un point de contrôle immédiatement avant un incident.
Testez fréquemment l’ensemble de votre stratégie d’atténuation des défaillances de déploiement. Comme les plans d’intervention d’urgence et les plans de reprise d’activité après sinistre, votre plan d’échec de déploiement ne réussit que si votre équipe est formée sur celle-ci et les pratique régulièrement. Les tests d’ingénierie de chaos et d’injection d’erreurs peuvent être des techniques efficaces pour tester votre stratégie d’atténuation du déploiement.
Facilitation Azure
Azure Pipelines fournit des services de génération et de mise en production pour prendre en charge CI/CD de vos applications.
Azure Test Plans est une solution de gestion des tests basée sur un navigateur qui est facile à utiliser. Cette solution offre des fonctionnalités requises pour les tests manuels planifiés, les tests d’acceptation des utilisateurs et les tests exploratoires. Les plans de test Azure vous permettent également de recueillir des commentaires des parties prenantes.
Azure Monitor est une solution de supervision complète permettant de collecter, d’analyser et de répondre aux données de surveillance à partir de vos environnements cloud et locaux. Le moniteur inclut une plateforme d’alerte robuste. Vous pouvez configurer ce système pour les notifications automatiques et d’autres actions, comme la mise à l’échelle automatique et d’autres mécanismes de réparation automatique.
Application Insights est une extension de Monitor qui fournit des fonctionnalités de surveillance des performances des applications (APM).
Azure Logic Apps est une plateforme cloud permettant d’exécuter des workflows 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 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 quand 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.
Liens connexes
- Expérimentation progressive avec des indicateurs de fonctionnalité
- Recommandations pour la conception et la création d’un framework d’observabilité
- Recommandations pour la conception d’une stratégie d’intervention d’urgence
- Recommandations pour la conception d’une stratégie de test de fiabilité
- Recommandations pour la conception d’une chaîne logistique de développement de charge de travail
- Recommandations relatives à l’exécution d’une analyse du mode d’échec
- Recommandations pour les pratiques de déploiement sécurisées
Liste de contrôle d’excellence opérationnelle
Reportez-vous à l’ensemble complet de recommandations.