« Quelle est la principale cause des problèmes de fiabilité de service que nous observons dans Azure, autre que les petites défaillances matérielles courantes ? Les modifications. L’une des propositions de valeur du cloud est qu’il s’améliore en continu, offre de nouvelles fonctionnalités, ainsi que des améliorations en matière de sécurité et de fiabilité. Toutefois, comme la plateforme évolue constamment, les modifications sont inévitables. Cela nécessite une approche très différente pour garantir la même qualité et stabilité que l’approche des services informatiques traditionnels ou produits en boîte, qui consiste à tester sur de longues périodes et d’éviter les modifications une fois qu’un élément est déployé. Ce billet de blog est le cinquième de la série présentée dans mon billet de blog de juillet, qui partage des insights sur ce que nous faisons pour garantir que la fiabilité d’Azure prend en charge vos charges de travail les plus critiques. Dans ce billet de blog, nous décrivons nos pratiques de déploiement sécurisé avec lesquelles nous gérons l’automatisation des modifications afin que toutes les mises à jour de code et de configuration passent par des étapes bien définies afin d’intercepter les régressions et les bogues avant qu’ils n’atteignent les clients ou, si ces problèmes passent inaperçus lors des toutes premières étapes, pour qu’ils impactent le plus petit nombre de clients possible. Cristina del Amo Casado, qui fait partie de notre équipe d’ingénierie Compute et mène nos initiatives en matière de déploiement sécurisé, a rédigé ce post.» - Mark Russinovich, directeur technique, Azure

---

 

Lorsque vous exécutez des systèmes informatiques en local, vous pouvez essayer de garantir une disponibilité parfaite en utilisant du matériel sécurisé, en verrouillant la salle de serveurs et en jetant la clé. Traditionnellement, en termes de logiciels, les services informatiques évitent autant que possible les modifications, en évitant d’appliquer des mises à jour au système d’exploitation et/ou aux applications parce qu’elles sont trop critiques et en repoussant les demandes de modification des utilisateurs. Si tout le monde marche sur des œufs en « retenant son souffle », cela empêche l’amélioration continue du système, et parfois même compromet la sécurité pour des systèmes jugés trop cruciaux pour être soumis régulièrement à des correctifs. Comme Mark l’a indiqué plus haut, cette approche ne fonctionne pas pour la gestion des modifications et des mises en production dans un cloud public hyperscale tel qu’Azure. Le changement est à la fois inévitable et bénéfique, compte tenu de la nécessité de déployer des mises à jour et des améliorations de service, et compte tenu de notre engagement à agir rapidement face aux failles de sécurité. Comme nous ne pouvons purement et simplement pas éviter le changement, Microsoft, nos clients et nos partenaires doivent reconnaître que des modifications auront bien lieu et nous planifions en conséquence. Microsoft poursuit son travail pour rendre les mises à jour aussi transparentes que possible et déploiera les modifications de façon sécurisée, comme décrit ci-dessous. Cela dit, nos clients et partenaires doivent également concevoir des solutions pour la haute disponibilité, consommer les événements de maintenance envoyés par la plateforme pour s’adapter selon les besoins. Enfin, dans certains cas, les clients peuvent prendre l’initiative des mises à jour de la plateforme à un moment approprié pour leur organisation.

Apporter des modifications de façon sécurisée

Au moment de réfléchir à la façon de déployer des mises en production dans nos centres de données Azure, l’un des principaux postulats qui façonne nos processus est de supposer qu’un problème inconnu pourrait être introduit par la modification déployée, de planifier de manière à permettre la découverte dudit problème avec un impact minimal et d’automatiser les actions d’atténuation à effectuer lorsque le problème apparaît. Même si un développeur peut le juger complètement inoffensif et garantir qu’il n’affectera pas le service, même le plus petit changement apporté à un système pose un risque pour la stabilité de ce dernier. Donc ici, le terme « changements » fait référence à toutes sortes de nouvelles mises en production et couvre à la fois les modifications de code et de configuration. Dans la plupart des cas, un changement de configuration a un impact moins dramatique sur le comportement d’un système mais, tout comme pour un changement de code, aucun changement de configuration n’est sans risque d’activer un défaut de code latent ou un nouveau chemin de code.

Les équipes Azure suivent des processus similaires pour empêcher ou au moins réduire au minimum l’impact lié aux modifications. Tout d’abord, en veillant à ce que les modifications répondent au standard de qualité avant le début du déploiement, grâce à des validations de test et d’intégration. Ensuite, après la validation, nous déployons la modification de manière progressive et mesurons les signaux d’intégrité en continu. Cela nous permet de détecter dans un isolement relatif si un impact inattendu associé à la modification est apparu pendant le test. Comme nous ne voulons pas qu’une modification entraîne des problèmes dans une production à grande échelle, nous prenons des mesures pour éviter cela dès que possible. Le déploiement progressif est une bonne occasion de détecter des problèmes à une échelle plus petite (ou avec des conséquences moindres) avant qu’ils n’aient un impact généralisé.

Azure approche l’automatisation des modifications, en adéquation avec le processus de haut niveau ci-dessus, via un cadre de pratique de déploiement sécurisé, qui vise à garantir que tous les changements de code et de configuration passent par un cycle d’étapes spécifiques, où les métriques d’intégrité sont surveillées pour déclencher des alertes et des actions automatiques lorsqu’une dégradation est détectée. Ces étapes (illustrées dans le schéma ci-dessous) réduisent le risque que les modifications logicielles affectent négativement vos charges de travail Azure existantes.

Ceci montre une simplification de notre pipeline de déploiement, en commençant à gauche par les développeurs qui modifient leur code, le testent sur leurs propres systèmes et le poussent vers des environnements intermédiaires. Généralement, cet environnement d’intégration est dédié à des équipes pour un sous-ensemble de services Azure qui doivent tester ensemble les interactions de leurs composants particuliers. Par exemple, les équipes d’infrastructure de base telles que le calcul, la mise en réseau et le stockage partagent un environnement d’intégration. Chaque équipe exécute des tests synthétiques et des tests de contrainte sur le logiciel dans cet environnement, effectue des répétitions de ces tests jusqu’à atteindre la stabilité. Ensuite, une fois que les résultats de qualité indiquent qu’une mise en production, une fonctionnalité ou une modification donnée est prête pour la production, l’équipe déploie les modifications dans les régions « canary ».

Régions « canary »

Publiquement, nous appelons régions « canary » les régions du « programme d’accès anticipé aux mises à jour » et ce sont effectivement des régions Azure à part entière avec la grande majorité des services Azure. L’une des régions « canary » est construite avec des zones de disponibilité et l’autre sans, et les deux régions forment une paire de régions, ce qui nous permet de valider les capacités de géoréplication des données. Ces régions « canary » sont utilisées pour des validations complètes et de bout en bout au niveau de la production et une couverture des scénarios à grande échelle. Elles hébergent des services internes (pour les clients internes), plusieurs services tiers et un petit ensemble de clients externes que nous invitons dans le programme pour augmenter la richesse et la complexité des scénarios couverts, le tout pour garantir que les régions « canary » ont des modèles d’utilisation représentatifs de nos régions Azure publiques. Les équipes Azure exécutent également des tests de contrainte et de synthèse dans ces environnements, et nous exécutons régulièrement des injections d’erreurs ou des exercices de reprise d’activité après sinistre au niveau de la région ou de la zone de disponibilité, ce qui sert d’entraînement pour les workflows de détection et de récupération qui seraient exécutés si cela se produisait réellement. Séparément et ensemble, ces exercices ont pour but de garantir que les logiciels sont de la plus haute qualité possible avant que les modifications ne touchent les nombreuses charges de travail client dans Azure.

Phase pilote

Une fois que les résultats des régions « canary » indiquent qu’aucun problème connu n’a été détecté, le déploiement progressif en production peut commencer avec ce que nous appelons notre phase pilote. Cette phase nous permet de tester les modifications, toujours à une échelle relativement petite, mais avec une plus grande diversité de matériels et de configurations. Cette phase est particulièrement importante pour les logiciels tels que les services de stockage de base et les services d’infrastructure de calcul de base, qui ont des dépendances matérielles. Par exemple, Azure propose des serveurs avec GPU, des serveurs à mémoire volumineuse, des serveurs de base, plusieurs générations et types de processeurs, Infiniband, etc. Cela permet de déployer en mode Flighting les modifications et peut permettre la détection de problèmes qui n’apparaissent pas durant des tests à plus petite échelle. À chaque étape du processus, une surveillance approfondie de l’intégrité et des « temps de cuisson » prolongés permettent aux patterns de défaillance potentiels de faire surface, accroissent notre confiance dans les modifications, tout en réduisant considérablement le risque global pour nos clients.

Une fois que nous avons déterminé que les résultats de la phase pilote sont bons, les systèmes de déploiement autorisent le déploiement de la modification dans un plus grand nombre de régions de manière incrémentielle. Tout au long du déploiement vers les régions Azure plus larges, les systèmes de déploiement s’efforcent de respecter les zones de disponibilité (une modification ne concerne qu’une seule zone de disponibilité au sein d’une région) et le jumelage des régions (chaque région est « jumelée » avec une deuxième région pour fournir un stockage géoredondant) afin qu’une modification se déploie d’abord sur une région puis sur sa paire. En général, les modifications se déploient tant qu’aucun signal négatif n’apparaît.

Pratiques de déploiement sécurisé en action

Compte tenu de l’échelle d’Azure au niveau mondial, l’ensemble du processus de déploiement est entièrement automatisé et piloté par une stratégie. Ces stratégies et processus déclaratifs (et non les développeurs) déterminent la vitesse de déploiement des logiciels. Les stratégies sont définies de manière centralisée et incluent des signaux d’intégrité obligatoires pour surveiller la qualité des logiciels ainsi que des « temps de cuisson » obligatoires entre les différentes étapes décrites ci-dessus. Tester un logiciel pendant différentes périodes lors de chaque phase permet d’exposer la modification à un large éventail de charges sur ce service. Par exemple, des utilisateurs d’une organisation peuvent se connecter le matin, des clients de gaming peuvent se connecter le soir et de nouvelles machines virtuelles ou des créations de ressources de clients peuvent se produire sur une longue période.

Les services internationaux, qui ne peuvent pas adopter une approche de déploiement progressif sur différents clusters, régions ou anneaux de services, exécutent également des déploiements progressifs en alignement avec les stratégies de déploiement sécurisé. Ces services suivent le modèle de mise à jour de leurs instances de service en plusieurs phases, déviant progressivement le trafic vers les instances mises à jour via Azure Traffic Manager. Si les signaux sont positifs, plus de trafic est dévié au fil du temps vers les instances mises à jour, augmentant la confiance et permettant au déploiement d’être appliqué à plus d’instances de service au fil du temps.

Bien sûr, la plateforme Azure a également la possibilité de déployer une modification simultanément sur l’ensemble d’Azure, lorsque cela est nécessaire pour atténuer une vulnérabilité extrêmement critique. Bien que notre stratégie de déploiement sécurisé soit obligatoire, nous pouvons choisir de l’accélérer lorsque certaines conditions d’urgence sont remplies. Par exemple, pour publier une mise à jour de sécurité qui nous oblige à agir beaucoup plus rapidement que nous le ferions normalement, ou pour un correctif où le risque de régression est surmonté par le correctif atténuant un problème ayant déjà un impact très important sur les clients. Ces exceptions sont très rares. En général, nos outils et processus de déploiement sacrifient intentionnellement la vitesse pour maximiser les chances de renforcer les signaux et d’exercer des scénarios et workflows à grande échelle, ce qui rend permet ainsi de découvrir les problèmes lorsque leur niveau d’impact est au plus bas.

Améliorations continues

Nos pratiques de déploiement sécurisé et nos outils de déploiement continuent d’évoluer avec les enseignements tirés des pannes et des événements de maintenance précédents, et conformément à notre objectif de détecter les problèmes à une échelle significativement plus petite. Par exemple, nous avons appris l’importance de continuer à enrichir nos signaux d’intégrité et d’utiliser le Machine Learning pour mieux corréler les défauts et détecter les anomalies. Nous continuons également d’améliorer la façon dont nous effectuons les pilotes et les déploiements en mode Flighting, afin de pouvoir couvrir une plus grande diversité de matériels avec moins de risque. Nous continuons d’améliorer notre capacité à annuler automatiquement les modifications si elles montrent des signes potentiels de problèmes. Nous continuons également à investir dans des fonctionnalités de plateforme qui réduisent ou éliminent l’impact des modifications en général.

Avec plus d’un millier de nouvelles fonctionnalités publiées l’année dernière, nous savons que le rythme des modifications dans Azure peut sembler écrasant. Comme Mark l’a mentionné, l’agilité et l’amélioration continue des services cloud sont l’une des principales propositions de valeur du cloud ; le changement est une fonctionnalité, pas un bogue. Pour en savoir plus sur les dernières mises en production, nous encourageons les clients et partenaires à s’informer en consultant la page Azure.com/Updates. Nous faisons en sorte que cette page soit l’emplacement unique pour en savoir plus sur les mises à jour récentes et à venir des produits Azure, notamment la feuille de route des innovations que nous avons en développement. Pour connaître les régions dans lesquelles ces différents services sont disponibles, ou quand ils seront disponibles, vous pouvez également utiliser notre outil à la page Azure.com/ProductsbyRegion.