« Des incidents de service tels que des interruptions sont malheureusement des corollaires impondérables du secteur des technologies. Bien entendu, nous améliorons sans cesse la fiabilité de la plateforme cloud Microsoft Azure. Nous respectons, voire dépassons, nos Contrats de niveau de service (SLA) pour la grande majorité des clients, et continuons d’investir dans des outils et formations en constante évolution, qui facilitent la conception et l’exploitation en toute confiance de systèmes stratégiques.

Malgré ces efforts, nous reconnaissons la malheureuse réalité : compte tenu de l’échelle de nos opérations et du rythme du changement, nous ne pourrons jamais éviter totalement les interruptions. En cette période, nous nous efforçons d’être aussi ouverts et transparents que possible pour être certains que tous les clients et partenaires concernés comprennent ce qui se passe. Dans le cadre de notre série de blogs Advancing Reliability, j’ai demandé à Sami Kubba, responsable de programme principal qui supervise notre processus de communications d’interruption, de décrire les investissements que nous consacrons à l’amélioration continue de cette expérience. » — Mark Russinovich, directeur technique, Azure

---

 

Dans le secteur du cloud, nous nous engageons à apporter à nos clients la technologie la plus récente à grande échelle, à assurer la sécurité des clients et de notre plateforme, et à veiller à ce que l’expérience client soit toujours optimale. À cette fin, Azure fait l’objet d’un grand nombre de changements qui peuvent sporadiquement avoir une incidence inattendue sur nos clients. Comme nous l’avons déjà mentionné dans cette série de billets de blog, nous prenons les changements très au sérieux et veillons à adopter une approche à la fois systématique et progressive de leur implémentation en prenant un maximum de précautions.

Nous n’avons de cesse d’identifier les imperfections (parfois subtiles) inhérentes aux façons complexes dont nos conceptions architecturales, nos processus opérationnels, nos problèmes matériels, nos failles logicielles et nos facteurs humains peuvent quelquefois s’aligner pour provoquer des incidents de service, également appelés interruptions. La réalité de notre secteur est que l’impact du changement est intrinsèquement problématique. Lorsque nous réfléchissons aux communications en lien avec les interruptions, nous avons tendance à considérer nos concurrents, non pas comme d’autres fournisseurs de cloud, mais comme l’environnement local. Les fenêtres de changement locales sont contrôlées par des administrateurs. Ceux-ci choisissent le moment optimal pour implémenter tout changement, gérer et surveiller les risques et opérer une restauration en cas de défaillances.

De même, quand une interruption survient dans un environnement local, les clients et les utilisateurs ont le sentiment d’être davantage « en terrain connu ». La direction est rapidement informée de l’interruption, a accès au support pour la résolution des problèmes, et s’attend à ce que son équipe ou un partenaire soient en mesure de produire un rapport post-incident (Post-Incident Report, PIR) complet (précédemment appelé analyse de cause première (Root Cause Analysis, RCA)), une fois le problème circonscrit. Bien que notre analyse des données étaye l’hypothèse que le temps nécessaire pour remédier à un incident est plus bref dans le cloud que localement, les interruptions de cloud peuvent être ressenties comme plus stressantes par les clients lorsqu’il s’agit de comprendre le problème et ce qu’ils peuvent faire pour le corriger.

Présentation de nos principes de communication

Lors d’interruptions du cloud, certains clients nous ont confiés avoir eu l’impression de ne pas être informés rapidement, ou de ne pas recevoir les mises à jour nécessaires, et donc de ne pas comprendre tout à fait ce qui se passait et ce qui était fait pour éviter que de nouveaux problèmes surviennent à l’avenir. Tenant compte de ces perceptions, nous opérons à présent sur la base de cinq piliers qui sous-tendent notre stratégie de communication, et qui ont tous influencé notre expérience Azure Service Health dans le portail Azure, à savoir :

1. Vitesse
2. Granularité
3. Détectabilité
4. Parité
5. Transparence

Vitesse

Nous devons notifier les clients affectés le plus rapidement possible. Il s’agit de l’objectif clé de nos communications en lien avec les interruptions. Notre objectif est d’informer tous les abonnements Azure affectés dans les 15 minutes suivant une panne. Nous savons que nous ne pouvons pas y parvenir uniquement avec une intervention humaine. Avant qu’un ingénieur commence à investiguer sur une alerte de surveillance pour confirmer son impact (sans parler du temps nécessaire pour identifier les ingénieurs ad hoc dans ce qui peut être un tableau complexe d’interconnexions incluant des dépendances de tiers), trop de temps s’est écoulé. Tout retard de communications amène les clients à se demander si l’incident relève de leur propre responsabilité ou de celle d’Azure. Les clients risquent alors de consacrer un temps inutile au dépannage de leur propre environnement. À l’inverse, si nous décidons d’être précautionneux et de communiquer chaque fois que nous soupçonnons un impact potentiel sur les clients, ceux-ci risquent de recevoir un trop grand nombre de fausses alertes. Qui plus est, s’ils rencontrent un problème avec leur propre environnement, ils risquent d’attribuer ce problème non lié à une fausse alarme émanant de la plateforme. Il est donc essentiel que nous investissions dans notre capacité à faire des communications à la fois rapides et précises.

Le mois dernier, nous avons décrit notre investissement continu dans l’amélioration la qualité du service Azure avec l’intelligence artificielle : AIOps. L’AIOps inclut l’amélioration de la détection automatique, de l’engagement et de l’atténuation des interruptions du cloud. Des éléments de ce programme d’AIOps élargi sont déjà utilisés en production pour informer les clients de pannes susceptibles d’avoir une incidence sur leurs ressources. Ces notifications automatiques ont représenté plus de la moitié de nos communications en lien avec les interruptions au cours du dernier trimestre. Pour de nombreux services Azure, des notifications automatiques sont envoyées en moins de 10 minutes aux clients concernés via Service Health. Ces notifications sont accessibles dans le portail Azure. Concernant le déclenchement des alertes Service Health configurées, vous trouverez des informations supplémentaires ci-dessous.

Grâce à nos investissements dans ce domaine, qui améliorent déjà l’expérience client, nous continuerons à développer les scénarios dans lesquels nous pouvons informer les clients en moins de 15 minutes à partir du début de l’impact sur ceux-ci, sans que des intervenants humains aient à confirmer cet impact. Nous en sommes également à un stade précoce de l’extension de notre utilisation d’opérations d’intelligence artificielle pour identifier automatiquement les services concernés et, en cas de remédiation, envoyer des communications relatives à la résolution des problèmes (pour les scénarios pris en charge) le plus rapidement possible.

Granularité

Nous savons que, quand une interruption a une incidence, les clients doivent savoir précisément quelles ressources sont affectées. L’un des principaux blocs de construction pour l’intégrité de ressources spécifiques est celui constitué par les signaux d’Azure Resource Health. Un signal de Resource Health vérifie si une ressource, telle qu’une machine virtuelle, une base de données SQL ou un compte de stockage, est dans un bon état d’intégrité. Les clients peuvent également créer des alertes Resource Health, qui tirent parti d’Azure Monitor pour informer les personnes concernées si une ressource particulière rencontre des problèmes, que ceux-ci se produisent ou non au niveau de la plateforme. Il est important de noter qu’une alerte Resource Health peut être déclenchée en cas de dégradation de l’état d’intégrité d’une ressource (par exemple, si la machine virtuelle est redémarrée à partir de l’invité), sans qu’il y ait forcément de lien avec un événement de plateforme tel qu’une interruption. Les clients peuvent voir les contrôles Resource Health associés, organisés par type de ressource.

Nous nous appuyons sur cette technologie pour augmenter et mettre en corrélation toute ressource de client dont l’état d’intégrité s’est dégradé avec des interruptions de plateforme, le tout dans Service Health. Nous étudions également la manière d’inclure les ressources affectées dans nos charges utiles de communication, de sorte que les clients ne doivent pas nécessairement se connecter à Service Health pour comprendre quelles ressources sont affectées. Et bien entendu, chacun doit pouvoir utiliser cette solution par programmation.

Tout cela permettra aux clients disposant d’un grand nombre de ressources de savoir plus précisément les services qu’une interruption affecte, sans avoir à investiguer de leur côté. Plus important encore, les clients peuvent créer des alertes relatives à l’intégrité de ressources et déclencher des réponses à celles-ci à l’aide d’intégrations natives à Logic Apps et à Azure Functions.

Détectabilité

Bien que nous prenions en charge les approches « push » et « pull » pour les communications relatives aux interruptions, nous encourageons les clients à configurer des alertes pertinentes, de sorte que les informations appropriées soient automatiquement envoyées aux personnes et systèmes ad hoc. Nos clients et partenaires ne devraient pas avoir à effectuer des recherches pour voir si les ressources qui les intéressent sont affectées par une interruption. Ils doivent être en mesure d’utiliser les notifications que nous envoyons (par le moyen de leur choix) et de réagir en conséquence. Malgré cela, nous constatons constamment que les clients visitent la page des états Azure pour suivre l’intégrité des services sur Azure.

Avant l’introduction de l’expérience authentifiée Service Health dans le portail, la page des états était la seule façon de découvrir des problèmes de plateforme connus. Aujourd’hui, cette page des états publique est utilisée uniquement pour communiquer concernant des interruptions massives (par exemple, touchant sur plusieurs régions ou services). Les clients qui recherchent des problèmes potentiels qui les affectent ne trouvent donc pas d’informations exhaustives dans cette page. Dans la mesure où nous déployons les modifications de plateforme de la manière la plus sécurisée possible, la grande majorité des problèmes tels que des interruptions n’ont qu’un rayon d’impact minime sur les abonnements des clients. Pour ces incidents, qui constituent plus de 95 % de ceux que nous rencontrons, nous communiquons directement avec les clients affectés au sein du portail via Service Health.

Nous avons également récemment intégré la fonctionnalité « Nouveaux problèmes » dans Service Health. Cela signifie que, si nous signalons un incident sur la page des états publique mais n’avons pas encore pu identifier les clients affectés et communiquer avec ceux-ci, les utilisateurs peuvent voir ces informations au sein du portail dans Service Health, et accéder ainsi aux renseignements pertinents sans avoir à visiter la page des états. Nous encourageons tous les utilisateurs d’Azure à faire de Service Health leur « guichet unique » pour les informations relatives aux incidents de service, afin de voir les problèmes qui les concernent, de connaître les abonnements et ressources touchés, et d’éviter tout risque de fausse corrélation, par exemple, quand un incident publié sur la page des états est sans incidence pour eux.

Plus important encore, puisque nous évoquons le principe de détectabilité, à partir de Service Health, les clients peuvent créer des alertes Service Health qui sont des notifications push tirant parti de l’intégration avec Azure Monitor. De cette façon, les clients et partenaires peuvent configurer des notifications pertinentes en fonction de la personne qui doit les recevoir et de la meilleure façon de la notifier, par e-mail, SMS, LogicApp et/ou via un webhook qui peut être intégré dans des outils de management des services tels que ServiceNow, PagerDuty ou OPS Genie.

Pour commencer à utiliser des alertes simples, envisagez de router toutes les notifications de façon à adresser un e-mail à une liste de distribution unique. Pour passer au niveau supérieur, envisagez de configurer différentes alertes d’intégrité de service pour différents cas d’utilisation. Par exemple, des problèmes de production peuvent être notifiés à ServiceNow, des problèmes de développement, de test ou de préproduction peuvent simplement entraîner l’envoi d’un SMS à l’équipe de développeurs concernée, et des problèmes d’abonnement également déclencher l’envoi d’un SMS aux personnes clés. Tout cela est entièrement personnalisable, pour s’assurer que les bonnes personnes soient informées de manière appropriée.

Parity

Tous les utilisateurs d’Azure doivent savoir que Service Health est le seul emplacement à visiter pour tous les événements ayant une incidence sur le service. Tout d’abord, nous garantissons que cette expérience est cohérente dans l’ensemble des différents Services Azure, chacun utilisant Service Health pour communiquer sur les problèmes qui surviennent. Aussi simple que cela paraisse, nous continuons à aborder des scénarios uniques qui contribuent à rendre la situation complexe. Par exemple, la plupart des gens qui utilisent Azure DevOps n’interagissent pas avec le portail Azure. Étant donné qu’Azure DevOps ne dispose pas de sa propre expérience Service Health authentifiée, nous ne pouvons pas communiquer les mises à jour directement aux clients affectés par de petites interruptions de DevOps qui ne justifient pas de mention sur la page des états publique. C’est pour prendre en charge de tels scénarios que nous avons élaboré la page des états d’Azure DevOps, dans laquelle les interruptions de DevOps de plus petite échelle peuvent être communiquées directement à la communauté de DevOps.

Deuxièmement, l’expérience Service Health est conçue pour communiquer tous les événements ayant une incidence dans Azure : événements de maintenance, ainsi que retraits de services ou de fonctionnalités occasionnant tant des interruptions générales que des contretemps ponctuels n’affectant qu’un seul abonnement. Il est impératif que, pour tout impact (qu’il soit potentiel, réel ou futur), les clients puissent s’attendre à la même expérience et mettre en place un plan d’action prévisible dans l’ensemble de leurs services sur Azure.

Enfin, nous œuvrons à l’extension de notre philosophie en lien avec ce pilier à d’autres produits cloud Microsoft. Nous sommes conscients que, parfois, la navigation dans nos différents produits cloud tels qu’Azure, Microsoft 365 et Power Platform, peut donner l’impression d’évoluer dans les technologies de trois entreprises différentes. À l’avenir, nous nous efforcerons d’harmoniser ces produits afin d’offrir une expérience plus cohérente et d’une qualité optimale.

Transparence

Comme nous l’avons déjà mentionné à maintes reprises dans la série de blogs Advancing Reliability, nous savons que la confiance se gagne et s’entretient. En ce qui concerne les interruptions, nous savons que nous devons impérativement être transparents concernant ce qui se passe, ce que nous savons et ce que nous ne savons pas. Le cloud ne doit pas ressembler à une boîte noire. En cas de problèmes de service, nous adressons des communications régulières à tous les clients et partenaires concernés. Souvent, en début d’investigation sur un problème, en attendant que nous en sachions plus sur ce qui se passe, ces communications peuvent sembler peu détaillées. Si nous nous efforçons de partager des informations tangibles, nous essayons généralement d’éviter de partager des spéculations, car nous savons que les clients basent leur décisions sur les informations que nous leur communiquons pendant les pannes.

Par ailleurs, une interruption n’est pas terminée une fois son impact sur le client atténué. Il se peut que nous devions encore étudier les complexités de ce qui a occasionné le problème. Ainsi, le message envoyé au moment de la résolution de celui-ci ou juste après, est parfois une synthèse assez rudimentaire de ce qui s’est passé. Pour les incidents majeurs, nous enchaînons avec l’envoi d’un PIR, généralement dans un délai de trois jours, une fois les facteurs déclencheurs mieux compris.

Pour les incidents qui ont un impact sur un moindre nombre d’abonnements, nos clients et partenaires peuvent demander des informations supplémentaires via Service Health en sollicitant un PIR pour l’incident. Étant donné que nous avons reçu des commentaires disant que les PIR devraient être encore plus transparents, nous continuons à encourager nos gestionnaires d’incidents et de communications à fournir autant de détails que possible, y compris des informations sur l’impact des problèmes et les mesures que nous comptons prendre pour atténuer les risques futurs. Dans l’idéal, pour s’assurer que des problèmes de ce type soient moins susceptibles de se produire et/ou nuire.

Notre secteur ne sera jamais totalement à l’abri des interruptions de service, mais nous saisissons toute opportunité pour comprendre ce qui s’est globalement passé et partager les enseignements que nous tirons de nos investigations. L’un des futurs domaines d’investissement que nous examinons de près, est la meilleure façon de tenir nos clients informés des progrès que nous accomplissons en lien avec les engagements décrits dans nos étapes suivantes du PIR. En reliant nos interventions de réparation internes à nos engagements externes dans les étapes suivantes, nous permettons à nos clients et partenaires de suivre les progrès que nos équipes d’ingénierie accomplissent pour s’assurer que des actions correctives sont effectuées.

Nos communications dans tous ces scénarios (interruptions, maintenance, retraits de service et avis d’intégrité) continueront d’évoluer à mesure que nous en apprendrons davantage et continuerons d’investir dans les programmes qui sous-tendent ces cinq piliers.

La fiabilité est une responsabilité partagée

Si Microsoft est responsable de la fiabilité de la plateforme Azure proprement dite, nos clients et partenaires sont responsables de la fiabilité de leurs applications cloud, notamment en mettant en œuvre les meilleures pratiques architecturales en fonction des exigences de chaque charge de travail. Concevoir une application fiable dans le cloud est un processus différent du développement d’applications traditionnelles. Certains clients ont pris l’habitude d’acheter du matériel haut de gamme redondant pour atténuer le risque de panne généralisée de plateforme d’application. Dans le cloud, nous anticipons les pannes. Comme indiqué ci-dessus, nous ne pourrons jamais prévenir toutes les interruptions. À côté de Microsoft s’efforçant d’éviter les interruptions, lors de la création d’applications fiables dans le cloud, votre objectif doit être de réduire les effets de tout composant défaillant.

À cette fin, nous avons récemment lancé la solution Microsoft Azure Well-Architected Framework, un ensemble de principes directeurs qui peuvent être utilisés pour améliorer la qualité d’une charge de travail. La fiabilité est l’un des cinq piliers de l’excellence architecturale en ce qui concerne l’optimisation des coûts, l’excellence opérationnelle, l’efficacité des performances et la sécurité. Si vous avez déjà une charge de travail s’exécutant dans Azure et souhaitez évaluer votre alignement sur les meilleures pratiques dans un ou plusieurs de ces domaines, essayez la solution Microsoft Azure Well-Architected Review.

Plus précisément, le pilier Fiabilité décrit six étapes de création d’une application Azure fiable. Définissez des exigences de disponibilité et de récupération basées sur chaque charge de travail et besoin métier. Utilisez les meilleures pratiques architecturales pour identifier des points de défaillance possibles dans votre architecture proposée/existante et déterminer la manière dont l’application répondra aux défaillances. Testez à l’aide de simulations et de basculements forcés tant la détection que la récupération de défaillances diverses. Déployez l’application de façon cohérente à l’aide de processus fiables et reproductibles. Surveillez l’intégrité des applications afin de détecter les défaillances, d’observer les indicateurs de défaillances potentielles et d’évaluer leur état d’intégrité. Enfin, réagissez aux défaillances et aux sinistres en déterminant la meilleure façon de les traiter en fonction de stratégies établies.

Pour revenir à notre thème principal des communications relatives aux interruptions, nous nous efforçons d’intégrer des conseils pertinents en lien avec l’architecture dans les PIR que nous établissons suite à chaque incident de service. Les clients qui exécutent des charges de travail critiques pourront ainsi découvrir des mesures spécifiques à prendre pour améliorer la fiabilité, qui auraient permis d’éviter et d’atténuer l’impact d’une interruption particulière. Par exemple, si une interruption affecte des ressources au sein uniquement d’une zone de disponibilité, nous la mettons en évidence dans les PIRs et encourageons les clients affectés à envisager des redondances zonales pour leurs charges de travail critiques.

À l’avenir

Nous avons décrit comment Azure approche les communications pendant et après des incidents de service tels que des interruptions. Nous tenons à être transparents concernant nos cinq piliers de communication, expliquer les progrès accomplis à ce jour et les domaines dans lesquels nous continuons à investir. Tout comme nos équipes d’ingénierie s’efforcent de tirer des enseignements de chaque incident pour améliorer la fiabilité de la plateforme, nos équipes de communication n’ont de cesse de retenir les leçons de chaque incident de façon à communiquer de manière plus transparente, afin d’obtenir des clients et des partenaires les détails appropriés pour prendre des décisions éclairées et de leur offrir le meilleur support possible dans chaque situation difficile.

Nous sommes convaincus que nous faisons les bons investissements pour poursuivre l’amélioration dans ce domaine, mais nous tenons aussi à recueillir un maximum de commentaires pour nous aider à déterminer si nos communications atteignent leur but. Nous incluons un questionnaire post-incident Azure à la fin de chaque PIR que nous publions. Nous nous efforçons d’examiner chaque réponse pour apprendre de nos clients et partenaires, et de vérifier si nous nous concentrons sur les domaines appropriés pour continuer à améliorer l’expérience.

Nous n’avons de cesse d’identifier les imperfections (parfois subtiles) inhérentes aux façons complexes dont nos conceptions architecturales, nos processus opérationnels, nos problèmes matériels, nos failles logicielles et nos facteurs humains s’alignent pour occasionner des interruptions. Étant donné que la confiance se gagne et s’entretient, nous nous engageons à être aussi transparents que possible, en particulier quand surviennent ces problèmes de service rares mais inévitables.