Étude de cas · Février 2017

Une commande mal saisie a mis à terre une partie d'internet.

Une seule entrée incorrecte dans une commande de débogage de routine a supprimé plus de serveurs que prévu d'un sous-système AWS S3 — et le redémarrage a pris des heures de plus que prévu, car les systèmes concernés n'avaient pas été entièrement redémarrés depuis des années.

coût de la panne AWS S3 panne AWS us-east-1 de 2017 cause de la panne S3 exemple de coût d'une panne d'un fournisseur cloud
Lire les points clés Modéliser une panne d'infrastructure
Faites défiler pour voir la chronologie
~4 h Durée dans la région US-EAST-1
150 M$ Coût estimé pour les entreprises du S&P 500
Points clés

Ce qui s'est passé, en un tableau.

Les sources sont liées directement dans le texte, y compris le propre résumé public d'AWS après l'incident.

Date 28 février 2017, à partir d'environ 9h37, heure du Pacifique.
Ce qui a cassé Un ingénieur autorisé, suivant un playbook établi pour déboguer le système de facturation de S3, a exécuté une commande destinée à retirer un petit nombre de serveurs — mais une entrée a été saisie de manière incorrecte, retirant un ensemble de serveurs bien plus important que prévu et mettant hors ligne deux sous-systèmes S3 centraux, selon le propre résumé d'AWS.
Ampleur La panne a duré environ quatre heures dans la région US-EAST-1 et a perturbé une large part d'internet, car un vaste éventail de sites web, d'applications et même d'autres outils de statut d'AWS dépendaient de S3 pour le stockage ou la configuration — AWS n'a même pas pu mettre à jour son propre tableau de bord de service, car ce tableau de bord dépendait lui-même de la région touchée.
Goulot d'étranglement du rétablissement Les sous-systèmes touchés avaient tellement grossi au fil des années d'exploitation qu'ils n'avaient jamais été entièrement redémarrés à cette échelle, et le processus de redémarrage a pris nettement plus de temps que prévu en conséquence — un écart de capacité et de tests opérationnels, pas une répétition de l'erreur initiale.
Coût déclaré Le Wall Street Journal a rapporté une estimation de la société de modélisation du risque cybernétique Cyence selon laquelle la panne a coûté environ 150 millions de dollars aux entreprises du S&P 500 au total — un chiffre largement cité mais modélisé par un tiers, et non une somme de déclarations individuelles des entreprises.
Pourquoi cela a autant coûté

Le rayon d'impact était le graphe de dépendances de tout internet.

Presque aucun de ces coûts n'a été supporté par les propres clients d'AWS du sous-système de facturation — ils ont été supportés par tous les autres, qui dépendaient de S3 sans en réaliser la profondeur.

01

Une commande de routine reste un changement en production

L'opérateur suivait un playbook établi, il n'improvisait pas — pourtant, une seule entrée mal saisie a eu un rayon d'impact disproportionné, ce qui explique pourquoi la validation des entrées et les limites au rayon d'impact comptent même pour des commandes opérationnelles « de routine ».

02

Des systèmes qui ne redémarrent jamais sont des systèmes qui n'ont pas été testés

Le rétablissement a pris plus de temps que prévu précisément parce que les sous-systèmes touchés n'avaient jamais été redémarrés à leur échelle actuelle — des chemins de récupération non testés constituent une source cachée de risque de MTTR que la croissance de capacité crée silencieusement.

03

La dépendance à un tiers est invisible jusqu'à ce qu'elle échoue

Des entreprises sans relation directe avec le sous-système de facturation d'AWS sont quand même tombées en panne, car leur propre infrastructure dépendait silencieusement de la même couche de stockage régionale — un rappel qu'il faut cartographier, et non supposer, son rayon d'impact réel face à la région d'un seul fournisseur.

FAQ

Panne AWS S3, expliquée.

Les questions qui reviennent lorsqu'on cite cet incident dans un dossier de dépendance cloud ou de risque fournisseur.

S'agissait-il d'une attaque contre AWS ? Non — AWS l'a attribuée à une erreur opérationnelle interne survenue durant une procédure de débogage de routine, et non à une attaque externe.
Pourquoi le chiffre de 150 millions de dollars est-il une estimation d'un tiers plutôt que le chiffre propre d'AWS ? AWS ne publie pas d'estimation de coût pour ses propres pannes ; le chiffre de 150 millions de dollars provient de la modélisation du risque cybernétique de Cyence, tel que rapporté par le Wall Street Journal, ce qui en fait une indication plutôt qu'un total audité.
Qu'est-ce qu'AWS a changé par la suite ? Le résumé public d'AWS a décrit des modifications apportées à ses outils, notamment des garde-fous empêchant de retirer de la capacité sous un niveau minimal requis et des améliorations du temps de redémarrage des sous-systèmes.
Comment cela se traduit-il dans le calculateur ? Utilisez le calculateur de temps d'arrêt informatique ou le calculateur de temps d'arrêt de site web selon que vous modélisez une infrastructure interne ou l'impact orienté client d'une panne fournisseur.
À vous de jouer

Combien coûterait la panne d'un fournisseur cloud à votre activité ?

Modélisez votre propre empreinte de dépendances, vos revenus et votre temps de rétablissement avec la même formule.

Ouvrir le calculateur de temps d'arrêt informatique Toutes les études de cas

Mode

Couleur d'accent