Le cloud se développe, mais les pannes de cloud ne sont pas nouvelles. Et nous non plus. InformationWeek a été fondée en 1985 et nos archives en ligne remontent à 1998. Voici quelques points faibles des pires moments du cloud, extraits de nos archives.
17 avril 2007 / Dans le discours d’ouverture du Web 2.0, Jeff Bezos vante les services à la demande d’Amazon, par Thomas Claburn — “Le fondateur de la conférence, Tim O’Reilly, a demandé si Amazon gagnait de l’argent là-dessus, Bezos a répondu : “Nous avons certainement l’intention de gagner de l’argent là-dessus”, avant d’admettre finalement qu’AWS n’était pas rentable aujourd’hui.”
(Pour rappel, les amis, ici en 2022, AWS vaut maintenant un billion de dollars.)
12 août 2008 / Désolé, les Internets sont cassés aujourd’hui, par Dave Methvin et Google s’excuse pour la panne de Gmailpar Thomas Claburn — Après une série de perturbations maladroites sur les forums Microsoft MSDN, Gmail, Amazon S3, GoToMeeting et SiteMeter, Methvin se lamente : “Lorsque vous utilisez un service tiers, il devient une boîte noire difficile à vérifier. , ou même savoir si ou quand quelque chose a changé. Bienvenue dans votre futur cauchemar.
17 octobre 2008 / La panne de Google Gmail fait ressortir les opposants au cloud computing, par Thomas Claburn — Étant donné que la panne semble avoir duré plus de 24 heures pour certains, les clients Gmail payants concernés semblent devoir des crédits de service, conformément aux termes du SLA de Gmail. Comme l’a dit un client : “Ce n’est pas un problème temporaire s’il dure aussi longtemps. Il est frustrant de ne pas pouvoir accélérer ces problèmes.”
11 juin 2010 / Les cinq plus grandes faiblesses du cloud, par John Soat – “Les récents problèmes avec Twitter (“Fail Whale”) et l’embarras de Steve Jobs face à la panne de réseau lors de l’introduction du nouvel iPhone ne transmettent pas exactement des sentiments flous chaleureux sur Internet et les performances du réseau en général. Un SLA ne peut pas garantir les performances ; il ne peut que punir les mauvaises performances.”
[In 2022, a cloud SLA can accomplish basically nothing at all. As Richard Pallardy and Carrie Pallardy wrote this week, “Industry standard service level agreements are remarkably restrictive, with most companies assuming little if any liability.”]
21 avril 2011 / Amazon EC2 panne entrave les sites Webde Thomas Claburn / 22 avril 2011 / Le cloud prend un coup, Amazon doit réparer EC2, par Charles Babcock / 29 avril 2011 / Post-mortem : Quand le cloud d’Amazon s’est allumé tout seul, par Charles Babcock – La panne d’Amazon du “week-end de Pâques” qui a eu un impact sur Yard, Foursquare, Hootsuite, Heroku, Quora et Reddit, entre autres. Babcock écrit : “En intégrant la haute disponibilité dans les logiciels cloud, nous avons échappé aux limites des pannes matérielles qui ont interrompu les systèmes en cours d’exécution. Dans le cloud, le matériel peut tomber en panne et tout le reste continue de fonctionner. D’un autre côté, nous ‘ Nous avons découvert que nous sommes entrés dans une atmosphère d’opérations plus élevée et un avion plus grand sur lequel des pannes potentielles peuvent se produire.
“La nouvelle architecture fonctionne très bien lorsqu’un seul disque ou serveur tombe en panne, un événement prévisible lors de l’exécution de dizaines de milliers d’appareils. Mais la solution elle-même ne fonctionne pas si elle pense que des centaines de serveurs ou des milliers de disques sont tombés en panne en même temps, emportant avec eux des données précieuses. C’est un événement imprévu dans l’architecture cloud, car cela n’est pas censé se produire. Cela ne s’est pas produit non plus la semaine dernière. Mais le logiciel cloud régissant pensait il l’a fait et a déclenché un effort de récupération massif. Cet effort a à son tour gelé EBS et le service de base de données relationnelle en place. Les instances de serveur ont continué à fonctionner dans l’US East-1, mais elles n’ont pu accéder à rien, plus de serveurs n’ont pu être lancés et le cloud a cessé de fonctionner dans l’une de ses zones de disponibilité à toutes fins pratiques pendant plus de 12 heures.”
9 août 2011 / Amazon Cloud Outage : que peut-on apprendre ? par Charles Babcock — Un coup de foudre à Dublin, en Irlande, a mis les services cloud européens d’Amazon hors ligne dimanche et certains clients devaient être indisponibles jusqu’à deux jours. (La foudre fera son apparition dans d’autres pannes à l’avenir.)
2 juillet 2012 / La panne d’Amazon frappe Netflix, Heroku, Pinterest, Instagram, par Charles Babcock — Le centre de données d’Amazon Web Services dans la région US East-1 perd de l’électricité en raison de violents orages électriques, ce qui assomme de nombreux clients de sites Web.
26 juillet 2012 / Google Talk, Twitter, Microsoft Pannes : Bad Cloud Day, par Paul McDougall / 26 juillet 2012 / Microsoft enquête sur la panne d’Azure en Europe, par Charles Babcock / 1 mars 2012 / L’explication de Microsoft Azure n’apaise pas, par Charles Babcock — Google a signalé que son service de messagerie instantanée et de chat vidéo Google Talk était en panne dans certaines parties des États-Unis et dans le monde entier le même jour, Twitter était également hors ligne dans certaines régions, et le service cloud Azure de Microsoft était disponible dans toute l’Europe. Le post-mortem du leader de Microsoft sur la panne du cloud Azure cite un facteur d’erreur humaine, mais laisse d’autres questions sans réponse. Cela vous rappelle-t-il comment Amazon a joué son premier incident de foudre ?
23 octobre 2012 / Panne d’Amazon : plusieurs zones, une stratégie intelligente, par Charles Babcock — Le trafic dans le complexe de centres de données le plus utilisé d’Amazon Web Services, US East-1 en Virginie du Nord, a été bloqué par une panne dans l’une de ses zones de disponibilité. Le contrôle des dégâts a commencé immédiatement, mais les effets de la panne se sont fait sentir tout au long de la journée, a déclaré Adam D’Amico, directeur des opérations techniques d’Okta. Les clients avertis, tels que Netflix, qui ont fait un investissement majeur dans l’utilisation de l’EC2 d’Amazon, peuvent parfois éviter les interruptions de service en utilisant plusieurs zones. Mais comme le rapporte NBC News, certains services régionaux de Netflix ont été affectés par la panne de lundi.
Le directeur des opérations techniques d’Okta a déclaré à Babcock qu’ils utilisaient les cinq zones pour se prémunir contre les pannes. “S’il y a une sixième zone demain, vous pouvez parier que nous y serons dans quelques jours.”
4 janvier 2013 / Panne du 24 décembre d’Amazon : un examen plus approfondi, par Charles Babcock – Amazon Web Services cite une fois de plus l’erreur humaine propagée par les systèmes automatisés pour la perte d’équilibrage de charge dans une installation clé la veille de Noël.
15 novembre 2013 / Microsoft épingle le ralentissement d’Azure sur une défaillance logiciellepar Charles Babcock — Mike Neil, directeur général de Microsoft Azure, explique le ralentissement des 29 et 30 octobre et la raison de cet échec généralisé.
23 mai 2014 / Rackspace résout la panne de stockage dans le cloud, par Charles Babcock — La pénurie de capacité de disque SSD perturbe les opérations de certains clients de stockage Cloud Block dans les centres de données de Rackspace à Chicago et à Dallas. Le service de rapport d’état de Rackspace a déclaré que le problème “était dû à une croissance de la clientèle plus élevée que prévu”.
20 juillet 2014 / Microsoft explique la panne d’Exchange, par Michael Endler — Certains clients n’ont pas pu joindre Lync pendant plusieurs heures lundi, et certains utilisateurs d’Exchange sont restés neuf heures mardi sans accès au courrier électronique.
15 août 2014 / Practice Fusion EHR Pris dans Internet Brownout, par Alison Diana – Un certain nombre de petits cabinets médicaux et de cliniques ont renvoyé des patients et du personnel chez eux après que le site du fournisseur de dossiers de santé électroniques basé sur le cloud, Practice Fusion, ait fait partie d’une panne mondiale de deux jours.
26 septembre 2014 / Amazon redémarre les serveurs cloud, Xen Bug blâmé, par Charles Babcock — Amazon dit à ses clients qu’il doit corriger et redémarrer 10 % de ses serveurs cloud EC2
22 décembre 2014 / La panne de Microsoft Azure est imputée à un mauvais code, par Charles Babcock — L’analyse par Microsoft de la panne d’Azure du 18 novembre indique que la décision des ingénieurs de déployer largement du code mal configuré a déclenché une panne majeure du cloud.
28 janvier 2015 / Lorsque Facebook est en panne, des milliers de personnes ralentissent, par Charles Babcock – Lorsque Facebook est tombé en panne cette semaine, des milliers de sites Web liés au site de médias sociaux ont également ralenti, selon Dynatrace. Au moins 7 500 sites Web qui dépendent d’une réponse JavaScript d’un serveur Facebook ont vu leurs opérations ralenties ou bloquées par un manque de réponse de Facebook.
20 août 2015 / Google perd des données : qui a dit que la foudre ne frappe jamais deux fois ? par Charles Babcock — Google a connu des taux d’erreurs de lecture/écriture élevés et une petite perte de données dans son centre de données Google Compute Engine à Ghislain, en Belgique, du 13 au 17 août, à la suite d’un orage qui a causé quatre coups de foudre sur ou à proximité du centre de données.
22 septembre 2015 / La perturbation d’Amazon produit une spirale d’indisponibilité du cloud, par Charles Babcock — L’échec d’Amazon DynamoDB tôt dimanche a déclenché des ralentissements en cascade et des interruptions de service qui illustrent la nature hautement connectée du cloud computing. Un certain nombre de sociétés Web, dont AirBnB, IMDB, Pocket, Netflix, Tinder et Buffer, ont été touchées par le ralentissement du service et, dans certains cas, par une interruption du service. L’incident a commencé à 3 h 00 PT dimanche, soit 6 h 00 à l’endroit où il a eu le plus grand impact : le complexe de centres de données le plus fréquenté d’Amazon à Ashburn, en Virginie, également connu sous le nom de US-East-1.
12 mai 2016 / Panne de Salesforce : les clients peuvent-ils faire confiance au cloud ?, par Jessica Davis — La panne du service Salesforce a commencé mardi avec l’instance NA14 de l’entreprise, affectant les clients de la côte ouest des États-Unis. Et bien que le service ait été rétabli mercredi après presque une journée complète d’indisponibilité, l’instance a continué de subir une dégradation du service, selon le site d’état en ligne de Salesforce.
7 mars 2017 / La croissance d’Amazon est-elle un peu hors de contrôle ? par Charles Babcock — Après une panne S3 de cinq heures dans l’US East-1 le 28 février, les opérations d’AWS expliquent qu’il était plus difficile de redémarrer son système d’indexation S3 cette fois-ci que la dernière fois qu’elles ont essayé de le redémarrer.
Babcock écrit : “Étant donné que la panne a commencé par une erreur de saisie de données, de nombreux rapports sur l’incident ont décrit l’événement comme étant aussi explicable qu’une erreur humaine. L’erreur humaine impliquée était si prévisible et courante qu’il s’agit d’une description inadéquate de ce qui est Il n’a fallu qu’une erreur humaine mineure pour que les systèmes opérationnels d’AWS commencent à fonctionner contre eux-mêmes. C’est la nature automatisée et galopante de l’échec qui est troublante. Les systèmes automatisés fonctionnant de manière inévitablement vouée à l’échec sont la marque d’une architecture immature .”
Avance rapide jusqu’à aujourd’hui
Comme Sal Salamone l’a soigneusement détaillé cette semaine, dans son article sur les leçons tirées des récentes pannes majeures : Cloudflare, Fastly, Akamai, Facebook, AWS, Azure, Google et IBM ont tous connu des calamités similaires à celle-ci en 2021-22. Les erreurs humaines, les bogues logiciels, les surtensions, les réponses automatisées aux conséquences inattendues, causent tous des ravages.
Qu’écrirons-nous dans 15 ans sur les pannes de cloud ?
Peut-être plus de la même chose. Mais vous ne pourrez peut-être pas le lire s’il y a des éclairs en Virginie.
Que lire ensuite :
Leçons tirées des récentes pannes majeures
Pouvez-vous récupérer les pertes subies lors d’une panne ?
Rapport spécial : À quel point le cloud est-il vraiment fragile ?
