Apparemment, une erreur humaine est à l’origine de la panne massive qui a frappé cette semaine le service de stockage simple S3 du fournisseur de cloud Amazon Web Services, provoquant la paralysie de nombreux sites et services populaires pendant 11 heures d’affilée. Plus précisément, la défaillance système s’est produite dans le service S3 de la région de la Virginie du Nord. Mais d'autres services AWS de la région US-EAST-1 qui s'appuient sur S3, comme Elastic Block Store, Lambda, et la nouvelle instance sur laquelle repose l'offre d'infrastructure en tant que service Elastic Compute Cloud, ont tous été impactés par la panne.

Jeudi, AWS a publié un communiqué pour présenter ses excuses. La panne a touché des sites comme Netflix, Reddit, Adobe et Imgur. « Plus de la moitié des 100 meilleurs sites de vente en ligne ont souffert de ralentissements du fait de la panne », a également fait savoir la plateforme de test, d’optimisation et de monitoring de sites Apica.

Voilà ce qui a déclenché la panne et ce qu'Amazon prévoit de faire :

Selon Amazon, un employé du Simple Storage Service S3 disposant des autorisations nécessaires a exécuté une commande censée « supprimer quelques serveurs dans l'un des sous-systèmes S3 utilisé par le processus de facturation de S3 » afin de résoudre un problème de lenteur dans le processus de facturation du service. Mais, à cause d’une erreur dans la saisie d’un des paramètres de la commande, de nombreux serveurs - dont dépendent notamment deux sous-systèmes S3 critiques - ont également été mis hors circuit.

Il s’agit du sous-système Index, qui « gère les métadonnées et les informations de localisation de tous les objets S3 dans la région », lui-même indispensable au bon fonctionnement du sous-système de placement chargé de gérer l'allocation de nouveaux stockages. Même si ces sous-systèmes sont conçus pour tolérer les défaillances, AWS a dû néanmoins redémarrer complètement les nombreux serveurs mis à l’arrêt par erreur. Or, il apparaît qu’Amazon n'a jamais eu besoin de redémarrer la totalité des systèmes de ces grandes régions depuis plusieurs années, sauf que, entre temps, le service S3 a connu une très forte croissance. Le redémarrage de ces sous-systèmes a pris plus de temps que prévu, prolongeant d’autant les effets de la panne.

Des mesures rajoutées 

Pour éviter que le même incident ne se reproduise, AWS a apporté plusieurs modifications à ses outils et à ses processus internes. L'outil qui a causé la panne a été modifié : la suppression de serveurs se fera par échelle et les opérations dépassant en capacité certains niveaux de sécurité seront bloquées. AWS procède également à la vérification de ses autres outils pour s'assurer qu'ils sont dotés de systèmes de sécurité similaires. Les ingénieurs d'AWS vont également remanier le sous-système d'index S3 afin d’accélérer les redémarrages et réduire l’impact de pannes futures. Le fournisseur de services cloud a également modifié sa console d'administration Service Health Dashboard : désormais, elle pourra tourner dans plusieurs régions. En effet, les employés d'AWS n'ont pas pu mettre à jour le tableau de bord pendant la panne parce que la console était dépendante de la région S3 affectée.