Pourquoi Microsoft Azure a subi une panne de près de 11h
Sur le blog Azure, Microsoft a publié de premières explications pour tenter d'expliquer les raisons de la panne massive qui a affecté ses services de cloud le 19 novembre dernier.
Officiellement, c’est une erreur d’un opérateur qui a été la cause de la panne catastrophique de Microsoft Azure le 19 novembre dernier, qui a conduit à l’arrêt de multiples applications et empêché les utilisateurs d’accéder au Cloud Microsoft. Les services Azure ont au total été affectés pendant près de 11 heures, ce qui est plutôt problématique pour des services de cloud qui prétendent de plus en plus se comporter comme des services utilitaires.
Selon Microsoft, les services Azure Storage ont été largement affectés dans la plupart ensemble des régions à la suite d’une mise à jour qui a particulièrement mal tourné. Sur le blog Azure, Microsoft explique « qu’un changement de configuration pour les serveurs frontaux du service de Blobs (Binary Large Objects) a révélé un bug dans ces serveurs, qui fonctionnaient jusqu’alors comme prévu. »
Ce bug s’est traduit par le fait que les serveurs frontaux sont entrés dans un phénomène de boucle infinie et ont refusé tout trafic entrant. Le problème est que le bug n’a été détecté qu’après que la mise à jour ait été déployée dans plusieurs régions.
Une mise jour déployée par erreur dans la plupart des régions
« Malheureusement, le problème a été perçu largement, car la mise à jour a été effectuée dans la plupart des régions au cours d’une très courte période de temps, du fait d’une erreur des opérateurs, qui n’ont pas appliqué le protocole standard consistant à appliquer des changements en production par petits lots », explique Jason Zander un vice-président d’Azure sur le blog.
En appliquant la mise à jour, Microsoft a de facto généré un déni de service qui a empêché les utilisateurs d’accéder aux services Azure Storage. AU passage la panne a eu des conséquences pour des services comme OneDrive ou Office365, mais aussi sur l’accès au portail de management d’Azure qui dépend d’Azure Storage.
Ce qui est plus inquiétant est que selon Jason Zander la mise à jour avait été testée de façon isolée puis dans un environnement de production restreint (ce que Microsoft appelle « flighting ») et avait passé tous les tests avec succès.
Un "post-mortem" plus complet de l'incident devrait être rendu public par Microsoft dans les prochaines semaines. Il permettra peut-être d'en savoir plus sur les causes profondes de la panne.