Microsoft a achevé son enquête sur la panne qu'a connu son service Cloud en novembre dernier,
l'erreur serait humaine
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
Ce serait bien d'avoir des news, des vrais et pas un pavé passé sur google translate et corrigé à l'arrache...
La qualité des news sur DVP est de plus en plus décevante, c'est triste pour la première communauté de dev fancophones.
Effectivement:
C'est une erreur humaine, mais le plus grave, c'est l'exhaustivité des tests qui ont laissé passer le bugPourtant, 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.
Et licencié le technicien n'effectuant pas les testsQuoiqu’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
Je suis vraiment sur le c** de voir que tout les problèmes rencontrés suite à ce bug lancé par un tech en mousse soit passé inaperçu pendant autant de temps ... Si une promotion est donnée à cet incompétent, je vote pour un latage de g***** en règle
Moi cette histoire de faute humaine me fait doucement rire...
Les logiciels ne se codant pas tout seul l'erreur est forcément humaine in fine.
Comme dans ces accidents d'avions où l'ont déclare les pilotes responsables (même si c'est probablement vrai) pour pas entacher la confiance générale envers les voyages en Avions. Ils ont bon dos les pilotes, à 3000m sous la mer...
Attention, ils ne rejettent pas l'erreur sur l'humain pour le bug, ce qui est forcément humain mais sur l'initiative de la mise en production sans réel test
Maintenant, j'ai connu un peu la même chose chez FT/Orange : la mise à niveau d'un Serveur IBM AIX.
Tout avait été testé, les patchs avaient été déposé à l'endroit habituel. J'ai suivi toute la procédure de A à Z. Mais comme les tests s'étaient bien passés, ils ont supprimés certains contrôles de sécurité ... dommage.
Résultat, les patchs se sont mal copiés sur le serveur de patch et l'un d'entre eux était vérolé. Résultat, il a fallu 6 heures (quasiment tout le reste de la nuit) pour tout remettre en ordre de marche sur une application indispensable pour tout le grand-ouest de la France.
Faute humaine, certes (suppression des procédures de sécurité pour gagner du temps) + une dose de Murphy. Ça s'est bien terminé, mais l'expert de l'application + un expert AIX ont été obligés de revenir en urgence (en dehors des heures ouvrées ... forcément).
La différence avec Azure est que, même dans les heures ouvrées, ça n'aurait touché qu'un cinquième de France Télécom. Ça a été transparent pour l'utilisateur, mais on a quand même eu chaud.
C'est ce qu'ils annoncent. ça a peut être été testé selon le cahier des charges de 'crosoft et c'est passé quand même. la clef de l'info est : "Microsoft a publié les détails sur son analyse "
C'est microsoft qui communique sur les résultat de leur propre analyse, ce n'est pas une société d'audit externe. Bref, je ne vois aucune raison pour ne pas remettre en cause l'origine du bug, C'est de la propagande classique finalement "Oui oui, on a fait une erreur, mais ça n'aurait pas du se produire, ça ne se reproduira plus"... Enfin, c'est déjà mieux que la politique Apple qui par défaut nie tout en bloc
Bon au final autant jadore aws et azure , autant je vois que les boites nont rien compris au cloud ! Tu veux un systeme avec des SLA de 99.99% et de la redondance etc ... le tout sans payer trop cher (services + humains) pour faire tourner des applications critiques !
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager