Le 28 février 2017, une équipe d’Amazon veut ralentir un système de facturation qui prend du retard. Un opérateur lance une commande prévue pour retirer quelques serveurs. Une valeur est mal saisie, beaucoup plus de machines quittent la scène, et une partie du Web découvre qu’il n’existe pas de grande touche Annuler au-dessus du cloud.
Une opération de routine avec un zéro de trop dans l’ambiance
L’incident se déroule dans la région US-EAST-1 d’Amazon Web Services, en Virginie du Nord. L’équipe S3 enquête sur un problème de facturation. À 9 h 37, heure du Pacifique, un membre autorisé suit une procédure connue et exécute une commande destinée à retirer un petit nombre de serveurs d’un sous-système.
Amazon expliquera ensuite qu’une entrée de la commande a été saisie incorrectement. Le nombre de serveurs retirés est bien supérieur à celui prévu. Ce n’est pas le geste spectaculaire d’un pirate dans une capuche ; c’est l’événement beaucoup plus crédible d’un humain, d’un clavier et d’un outil qui a accepté la demande avec un professionnalisme désarmant.
Les serveurs partis tenaient les clés du placard
Les machines retirées soutenaient deux composants essentiels de S3. Le premier gérait l’index : les métadonnées et l’emplacement des objets stockés. Le second attribuait l’espace nécessaire aux nouveaux objets. Sans eux, les requêtes de lecture, de liste, d’écriture et de suppression ne pouvaient plus fonctionner normalement.
Une grande partie de ces composants a dû redémarrer entièrement. Or S3 avait énormément grandi depuis son lancement, et certains sous-systèmes n’avaient pas connu de redémarrage complet depuis des années. La remise en route, accompagnée de contrôles d’intégrité, a donc pris plus de temps que prévu. Le nuage n’était pas tombé du ciel ; il attendait que son index retrouve où il avait rangé ses affaires.
Quand un service tousse, ses voisins demandent un mouchoir
S3 servait déjà de fondation à de nombreux services AWS et sites clients. L’interruption a affecté le stockage, mais aussi des lancements d’instances EC2, certains volumes EBS, AWS Lambda et diverses applications dépendantes. Même le tableau de santé d’AWS a rencontré des difficultés d’actualisation, car certains de ses composants dépendaient eux aussi de S3.
L’épisode est devenu un rappel grandeur nature des dépendances invisibles. Un site peut sembler autonome tout en reposant sur un fichier, une bibliothèque ou une image stockée dans la même région qu’une foule d’autres services. Le Web ressemble à une ville moderne : chaque boutique a sa propre enseigne, mais beaucoup partagent la même conduite d’eau.
Amazon réduit le rayon d’explosion
Dans son compte rendu officiel, Amazon ne se contente pas d’écrire « erreur humaine » puis de refermer le dossier. L’entreprise modifie l’outil afin que le retrait de capacité soit plus lent et qu’il refuse une opération faisant passer un sous-système sous son minimum requis. Elle ajoute aussi des garde-fous contre les valeurs incorrectes et accélère le découpage des grands composants en cellules plus petites.
C’est la partie la plus utile de l’histoire. Demander à des humains de ne jamais se tromper constitue un plan fragile. Concevoir un outil qui limite les conséquences d’une faute de frappe constitue une défense. En cybersécurité et en exploitation, on appelle cela réduire le rayon d’explosion : une erreur peut encore arriver, mais elle ne doit pas obtenir les clés de tout le bâtiment.
La morale tient entre deux validations
Pour une petite équipe comme pour un géant du cloud, les opérations sensibles gagnent à prévoir un aperçu, un seuil maximal, une confirmation distincte et un retour arrière testé. Les sauvegardes doivent vivre ailleurs que le service qu’elles sont censées sauver. Les dépendances critiques doivent être cartographiées avant qu’une panne ne se charge de faire le dessin.
En 2017, une mauvaise valeur a transformé une commande de maintenance en visite guidée de l’infrastructure mondiale. Depuis, chaque boîte de dialogue qui demande « êtes-vous vraiment sûr ? » peut revendiquer une petite part d’héroïsme.