Microsoft a achevé son enquête sur la panne qu'a connu son service Cloud en novembre dernier
L'erreur serait humaine

Le , par Stéphane le calme, Chroniqueur Actualités
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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Gecko Gecko - Membre éprouvé http://www.developpez.com
le 19/12/2014 à 2:50
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.
Avatar de frfancha frfancha - Membre averti http://www.developpez.com
le 19/12/2014 à 9:05
Citation Envoyé par Gecko  Voir le message
...pas un pavé passé sur google translate et corrigé à l'arrache...

Oui cela fait mal aux yeux
Avatar de imikado imikado - Rédacteur http://www.developpez.com
le 19/12/2014 à 9:25
Effectivement:
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.

C'est une erreur humaine, mais le plus grave, c'est l'exhaustivité des tests qui ont laissé passer le bug
Avatar de youtpout978 youtpout978 - Membre expert http://www.developpez.com
le 19/12/2014 à 10:42
Quoiqu’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

Et licencié le technicien n'effectuant pas les tests
Avatar de Saverok Saverok - Expert éminent http://www.developpez.com
le 19/12/2014 à 10:46
Citation Envoyé par youtpout978  Voir le message
Et licencié le technicien n'effectuant pas les tests

Suivant le principe de Peter, il n'est pas impossible qu'il ait été promu
Avatar de Guikingone Guikingone - Membre éprouvé http://www.developpez.com
le 19/12/2014 à 11:36
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
Avatar de AoCannaille AoCannaille - Membre expérimenté http://www.developpez.com
le 19/12/2014 à 14:42
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...
Avatar de imikado imikado - Rédacteur http://www.developpez.com
le 19/12/2014 à 16:47
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
Avatar de Pierre GIRARD Pierre GIRARD - Expert confirmé http://www.developpez.com
le 19/12/2014 à 17:21
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.
Avatar de AoCannaille AoCannaille - Membre expérimenté http://www.developpez.com
le 19/12/2014 à 17:25
Citation Envoyé par imikado  Voir le message
mais sur l'initiative de la mise en production sans réel test

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
Avatar de fiftytwo fiftytwo - Membre expérimenté http://www.developpez.com
le 26/01/2015 à 12:39
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 !
Offres d'emploi IT
Lead développeur iOS H/F
Mobiskill - Allemagne - Berlin
Ingénieur développeur c#/.net (h/f)
Team Trade - Ile de France - IDF
UX et webdesign h/f
Paris&Co Incubateurs - Ile de France - Paris (75000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil