Microsoft a publié les détails sur son analyse de la cause de la panne rencontrée par Azure en novembre dernier qui a débuté le 18 novembre et a duré pendant deux jours dans certaines régions, interrompant ainsi la quasi-totalité des services. C’est le vice-président de l’équipe responsable d’Azure, Jason Zander, qui va apporter des éclaircissements au public : « le 18 novembre 2014, nombreux sont les utilisateurs Microsoft Azure qui ont été confrontés à une interruption des services qui a eu un impact sur Azure Storage et de nombreux autres services, parmi lesquels Virtual Machines ».« Aujourd’hui nous partageons notre dernière RCA (Route Cause Analysis), qui comporte un aperçu complet des mesures que nous avons prises pour atténuer cette situation dans le cas où elle devrait se reproduire, ainsi que les mesures que nous prenons pour améliorer nos communications et les réponses du support [technique]. Nous nous excusons sincèrement et nous reconnaissons l'impact significatif que cette interruption de service a pu avoir sur vos applications et services ».
Qu’a donc révélé la RCA ? Tout d’abord il faut savoir comment est effectué le déploiement Microsoft Azure Storage. « Il existe deux types de déploiements d’Azure Storage : les déploiements de logiciels (c’est-à-dire la publication de code) et les déploiements de configuration (c‘est à dire le changement des paramètres). Les déploiements logiciels et de configuration exigent tous les deux de multiples étapes de validation et sont progressivement déployés dans l'infrastructure Azure en petits lots. Cette approche de déploiement progressif est appelée ‘flighting’. Quand ils sont en cours, nous opérons des contrôles de près. Comme l'utilisation continue et les tests ont apporté des résultats satisfaisants, nous avons déployé le changement dans une tranche supplémentaire dans l'infrastructure Azure Storage ».
Mais d’où est venu le problème ? Comme Zander l’a expliqué, Microsoft procède habituellement à un test avant chaque mise à jour de ses services Cloud sur quelques serveurs, de façon à repérer les éventuels problèmes de changement de configuration. Pourtant, cette fois-ci, l’ingénieur responsable de la résolution des problèmes de performances du stockage Azure Table a cru que parce que le changement était déjà passé par un ‘flighting’ sur une portion de la production pendant plusieurs semaines, l’activer à l’échelle de l’infrastructure représentait un faible risque. Malheureusement, l'outillage de configuration n'a pas eu une bonne application de cette politique de déployer progressivement le changement à travers l'infrastructure. Il s'avère que cette configuration contenait un bug ayant eu pour effet de faire entrer le service de stockage dans une boucle sans fin, empêchant toute communication avec les autres composants du système. Rapidement identifié, le problème a été résolu par la publication de correctifs.
« Microsoft Azure a des directives opérationnelles claires, mais il y avait une lacune dans l'outillage de déploiement dépendant de décisions humaines », a indiqué Jason Zander. Ce n'est pas la première fois que le service Cloud de Microsoft est perturbé par une erreur humaine : en février 2013, un certificat de sécurité expiré avait notamment provoqué une panne majeure d'Azure. Quoi qu’il en soit, pour s’assurer que ce type d’incident ne se reproduise pas, Microsoft a déclaré avoir « sorti une mise à jour à notre outillage de système de déploiement pour faire respecter le test ci-dessus et les politiques sur le Flighting des mises à jour standards qu’il s’agisse d’un déploiement logiciel ou de configuration ».
Source : Azure
Envoyé par Gecko
mais sur l'initiative de la mise en production sans réel test 
