Discussion :

[imikado]

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

[youtpout978]

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

[Saverok]

Et licencié le technicien n'effectuant pas les tests

Suivant le principe de Peter, il n'est pas impossible qu'il ait été promu

[Guikingone]

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

[AoCannaille]

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...

[imikado]

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

[Pierre GIRARD]

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.

[AoCannaille]

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

[fiftytwo]

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 !