Un code mal configuré a causé la panne d'Azure du 18 novembre – Microsoft

Table des matières

• Microsoft dit que la panne d’Azure du 18 novembre est due à un code mal configuré
• Protocole de contournement
• La déclaration

Microsoft dit que la panne d’Azure du 18 novembre est due à un code mal configuré

Microsoft Azure, sa plateforme cloud pour les entreprises, a subi une panne majeure le 18 novembre qui a laissé de nombreux utilisateurs dans l’embarras. Dans une déclaration, Microsoft a affirmé que la panne était causée par ses développeurs mettant en œuvre un code défectueux.

Protocole de contournement

Il semble que les développeurs de Microsoft travaillaient à résoudre un bug dans leur logiciel. La solution au bug, apparemment, a causé la massive panne des services cloud Azure. Microsoft a déclaré qu’il avait testé la mise à jour avant de la déployer. Mais il n’est pas toujours possible de prédire avec précision le résultat d’une mise à jour logicielle sur une plateforme aussi vaste dans un environnement de test contrôlé. Par conséquent, Microsoft suit une politique de déploiement de toute nouvelle mise à jour section par section, quelque chose qu’ils appellent flighting, c’est-à-dire limiter le déploiement. Cette fois cependant, probablement en raison d’un excès d’enthousiasme, les développeurs ont déployé l’ensemble du package de mise à jour d’un seul coup, ce qui a causé un effet en cascade sur tous ses serveurs. Dans une déclaration publiée sur le blog Azure, Jazon Zander, CVP, Azure Team, a noté que,

En conséquence, les taux de connexion à Azure le 18 novembre sont tombés de 97 % à 7-8 % après 19 heures, heure de l’Est, en Virginie du Nord. Le centre de données Azure à Dallas a subi une panne complète pendant un court moment. Les centres de données en Europe ne se sont pas rétablis avant bien après le lendemain.

Il a ajouté que bien qu’ils aient une politique de déploiement standard pour la mise à jour/le patch des bugs, il y avait des communications manifestement erronées. « La politique de déploiement standard de flighting, qui consiste à déployer progressivement des changements sur de petites tranches, n’a pas été suivie », a écrit Zander. Zander a déclaré que leur équipe avait identifié le problème clé, qui était un problème de configuration dans les interfaces de stockage de table Azure. « L’interrupteur de configuration a été incorrectement activé pour les interfaces de stockage Blob Azure », a écrit Zander.

Les interfaces de stockage de table enregistrent la séquence des différents types de données entrant dans un Blob (un service de stockage de grandes quantités de données non structurées) et peuvent être utilisées pour guider la récupération des données. L’erreur dans l’interrupteur de configuration semble avoir causé une boucle infinie qui a finalement entraîné la panne du service cloud Azure.

La déclaration

La mise à jour originale visait à corriger certains bugs découverts par l’équipe Azure et à améliorer les performances de la plateforme cloud. La mise à jour s’est avérée efficace dans chaque test de la phase de test alpha. Les résultats réussis des tests alpha ont probablement trop excité les développeurs pour renoncer à la méthode de déploiement par flighting et ils ont mis en œuvre la mise à jour d’un seul coup. Le résultat, comme on l’a vu le 18 novembre, a été une panne totale causant des problèmes aux utilisateurs. En réponse, les administrateurs Azure ont maintenant mis en œuvre une pratique de mise à jour automatisée, qui n’autorisera pas qu’un tel événement se reproduise.

Dans ce qui pourrait être le résultat le plus clair de l’incident, Zander a écrit : « Microsoft Azure avait des directives opérationnelles claires, mais il y avait une lacune dans les outils de déploiement qui reposaient sur des décisions humaines… Avec les mises à jour des outils, la politique est désormais appliquée par la plateforme de déploiement elle-même. »

Zander a reconnu que les opérations cloud doivent devenir plus fiables et a déclaré que Microsoft continuera à travailler sur cet objectif. « Nous nous excusons sincèrement et reconnaissons l’impact significatif que cette interruption de service a pu avoir sur vos applications et services », a-t-il écrit.

Zander a peut-être sincèrement présenté des excuses pour l’excitation excessive de son équipe de développement, mais le fait demeure que Microsoft pousse des correctifs et des mises à jour dans la précipitation sans tests nécessaires. Ce problème a déjà conduit Microsoft à publier des correctifs/mises à jour bogués qui provoquent des BSOD, lors de ses mises à jour du Patch Tuesday à deux reprises, une fois en octobre avec KB 2949927 et en décembre avec KB 3004394, pour les retirer plus tard. Les utilisateurs espèrent que Microsoft publiera une SOP pour ne laisser sortir que les mises à jour/correctifs qui ont été vérifiés dans un environnement de travail en temps réel.