IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

142PARTAGES

4  2 
Microsoft Azure est la plateforme PaaS et IaaS concurrente d'Amazon AC2.

Dans la nuit de mardi à mercredi, entre 1h et 2h (heure française) la quasi-totalité des services était interrompue (Azure Storage, Virtual Machines,Websites,Visual Studio,Azure Backup Services...)
Microsoft a réussi a réglé le problème outre Atlantique, mais les problèmes persistaient en Europe de l'Ouest au moins jusqu'à 12h (confirmé par le biais d'incident de Microsoft)
Citation Envoyé par Journal du net
Selon le spécialiste français du pilotage de la performance des CDN et des Clouds, tout ne semble pas avoir été totalement réglé depuis sur cette zone et son datacenter (basé à Dublin). « À 11h, le taux de disponibilité était toujours sous les 90%, et à 12h il était de 93%, donc toujours pas revenu à la normale », précise-t-on chez Cedexis. Quant à la région Europe de l'ouest d'Azure (datacenter d'Amsterdam), elle semble touchée également, mais dans une moindre mesure.
Jason Zander, explique dans un billet (sur le blog de Microsoft Azure) que le problème a eu lieu durant une procédure d'amélioration des performances.
La mise à jour avait pourtant été testée durant plusieurs semaines sur certains clients avec succès, celle-ci améliorant notablement les performances.

Malheureusement, lors du déploiement sur l'ensemble de l'infrastructure, un bug (qui a échappé aux tests) a provoqué un problème de boucle infinie obligeant les équipes à revenir en arrière sur cette mise à jour et redémarrer une partie des serveurs frontaux.

During the rollout we discovered an issue that resulted in storage blob front ends going into an infinite loop, which had gone undetected during flighting. The net result was an inability for the front ends to take on further traffic, which in turn caused other services built on top to experience issues.
J. Zander, au nom de Microsoft s'excuse pour la gêne occasionnée, et assure que leurs services travaillent pour bien comprendre ce qui est arrivé et éviter que cela se reproduise à l'avenir.

Source: http://azure.microsoft.com/blog/2014...-interruption/

Incident Start Date and Time
11/19/2014 00:51:00 AM (UTC)
Date and Time Service was Restored
11/19/2014 11:45:00 AM (UTC)
Que pensez-vous de cette panne importante de 11h sur un service de Cloud si critique ?

Pensez-vous que cet incident peut faire perdre des parts de marché au profit de ses concurrents ?

Trouvez-vous normal que le problème ait été réglé en 1h pour les clients américains et 11h pour les autres ?
Vous avez lu gratuitement 631 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Pierre GIRARD
Expert éminent https://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.
3  0 
Avatar de AoCannaille
Expert confirmé https://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...
2  0 
Avatar de frfancha
Membre éprouvé https://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
1  0 
Avatar de youtpout978
Expert confirmé https://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
0  0 
Avatar de Saverok
Expert éminent https://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
1  1 
Avatar de imikado
Rédacteur https://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
0  0 
Avatar de AoCannaille
Expert confirmé https://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
0  0 
Avatar de fiftytwo
Membre émérite https://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 !
0  1 
Avatar de Gecko
Membre éprouvé https://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.
1  3 
Avatar de imikado
Rédacteur https://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
0  2