Amazon et ses pannes : «too big to fail», vraiment ?

Amazon serait devenu «too big to fail», sauf qu’il peut tout de même tomber. La preuve, encore, mardi passé. De là, toujours les mêmes questions.

Une commande incorrecte a abouti à désactiver un ensemble de serveurs beaucoup plus important que souhaité, expliquait Amazon dans un blog jeudi 2 mars 2017. Amazon faisait référence à la panne du mardi 28 février, qui a affecté son service Simple Storage Service, le fameux S3.

Dans la matinée du mardi, en effet, nombre de services web et sites internet ont cessé de fonctionner aux États-Unis. De l’App Store ou Apple Music à la plateforme de communication collaborative Slack, en passant par Docker. Officiellement, S3 a connu un «taux d’erreurs élevé». Plus précisément, ce sont les infrastructures d’Amazon, hébergées dans ses data serveurs de la côte Est qui ont rencontré des difficultés pour recevoir et envoyer les données des clients, rendant inaccessible une grande partie du web. Après enquête, le géant américain a mis le doigt sur la cause du problème : une faute de frappe dans une formule de code utilisée par un technicien.

«Un membre de l’équipe S3 a lancé une commande pour retirer un petit nombre de sous-systèmes gérant la facturation. Malheureusement, l’une des commandes a été entrée de manière erronée et un nombre plus élevé de serveurs a été retiré», a expliqué Amazon.

Dans son message d’excuse, l’entreprise de Jeff Bezos indiqué qu’elle allait changer certaines procédures pour éviter qu’une telle mésaventure ne se reproduire. Certaines mesures étaient pourtant déjà en place, dont le fractionnement des services en partitions plus petites, permettant un redémarrage rapide en cas d’incident. Mais elles n’ont pas suffi, l’opération ayant pris plus de temps qu’escompté.

Avec cette panne, qui n’est évidemment pas la première, les mêmes questions reviennent au sujet de tous les grands prestataires, qu’ils se nomment Amazon, Microsoft Azure, Google ou IBM. Peut-on légitimement dépendre d’une seule infrastructure que ce soit pour des raisons de disponibilité ou de sécurité ? Comment, de façon plus prosaïque, survivre si ces services ne fonctionnent pas ? Cette gigantesque perturbation met une fois de plus en évidence la dépendance croissante de nos entreprises qui ont opté pour le stockage de leurs données dans le cloud afin d’obtenir des coûts compétitifs et un service sécurisé.

En avril 2011, un orage magnétique avait mis à genoux les serveurs d’Amazon, fin février ce fut une erreur technique. Il y a six ans, il a fallu attendre cinq jours pour retrouver l’intégralité du service; cette fois, un peu plus de quatre heures. Une panne n’est pas l’autre, c’est évident. La comparaison s’arrête là. Restent les questions. Et les pertes. Selon Apica, un spécialiste de la supervision de la performance web,  la panne de S3 a touché 54 des 100 plus importants sites d’e-commerce aux Etats-Unis. De son côté, Cyence, spécialisé dans l’analyse des impacts liés aux risques digitaux,  estime la perte enregistrée par les sociétés américaines du S&P 500 à 150 millions USD, et celle des sociétés de services financiers à 160 millions de USD.