Une commande mal parameterisée a suffi en 2017 à provoquer l’une des pannes les plus remarquables d’Amazon Web Services (AWS). Amazon S3 a perdu une partie importante de sa capacité dans us-east-1, nécessitant le redémarrage de deux sous-systèmes, entraînant avec eux d’autres services. Cet incident est particulièrement instructif pour les administrateurs système et les développeurs, car il n’était pas exceptionnel en nature : GitLab, Meta, Cloudflare, Fastly et Atlassian ont documenté des incidents où des commandes, scripts, configurations ou codes parfaitement autorisés ont finalement causé d’importantes interruptions.

Les clés des erreurs ayant brisé de grandes plateformes en 30 secondes

• En 2017, AWS a retiré trop de serveurs S3 avec un paramètre incorrect et a dû redémarrer deux sous-systèmes.
• GitLab a involontairement effacé le répertoire de sa base de données principale la même année, perdant plusieurs heures de données.
• Une expression régulière a saturé les CPU de Cloudflare en 2019.
• Meta a déconnecté son backbone mondial en 2021 lors d’une opération de maintenance.
• Fastly et Atlassian montrent que même une configuration valide ou un script autorisé peuvent avoir un impact inattendu.

Le cas de S3 est particulièrement illustratif car AWS a détaillé assez précisément ce qui s’est produit. À 9h37, heure du Pacifique, le 28 février 2017, un membre autorisé de l’équipe a exécuté une procédure habituelle pour retirer certains serveurs, en investiguant un problème de facturation. Une valeur saisie dans la commande était incorrecte, ce qui a entraîné le retrait de beaucoup plus de serveurs que prévu.

Le problème a touché les sous-systèmes d’indexation et d’emplacements d’S3. Le premier stockait les métadonnées et les informations sur l’emplacement des objets ; le second gérait l’allocation de nouveau stockage. Tous deux ont nécessité un redémarrage complet.

Et c’est là qu’un second problème est apparu, bien connu dans les infrastructures en croissance : ces grands sous-systèmes n’avaient pas été complètement redémarrés depuis longtemps. La taille de S3 ayant considérablement augmenté, les vérifications nécessaires pour la récupération de toute la plateforme ont pris plus de temps que prévu.

AWS S3 et le coût de laisser une commande avoir trop de pouvoir

AWS a commencé à restaurer les opérations GET, LIST et DELETE à 12h26. Le sous-système d’indexation a été complètement récupéré à 13h18, et les opérations PUT, dépendantes aussi du système d’emplacement, ont repris normalement à 13h54. D’autres services ont nécessité plus de temps pour traiter le travail accumulé.

Le chiffre de 150 millions de dollars souvent associé à cet incident mérite une précision importante. Il ne s’agit pas d’une perte communiquée directement par Amazon.

L’entreprise de modélisation des risques Cyence a estimé environ 150 millions de dollars de pertes pour des sociétés du S&P 500, et 160 millions pour d’autres entreprises américaines de services financiers. Ce sont des estimations d’ordre économique, pas une facture que AWS aurait payée ni un montant audité de pertes par Amazon.

Ce qui a davantage intéressé une équipe technique, c’est ce que AWS a modifié par la suite.

L’outil permettant de retirer de la capacité pouvait supprimer trop de serveurs trop rapidement. Amazon a changé son fonctionnement pour ralentir ces opérations et a introduit des limites empêchant la réduction de tout sous-système en dessous de la capacité minimale nécessaire.

C’est un exemple presque parfait d’un guardrail.

La solution n’a pas simplement consisté à dire à l’opérateur de mieux vérifier sa commande la prochaine fois. AWS a modifié le système pour qu’une erreur humaine similaire ne puisse produire le même résultat.

La société a aussi accéléré la division de S3 en unités plus petites appelées cells. L’objectif était de réduire le blast radius : si une partie échoue, la récupération et l’impact peuvent se limiter à une fraction du système.

Même le système d’information sur l’incident a été affecté. La console d’administration du Service Health Dashboard dépendait d’S3, empêchant AWS de mettre à jour normalement l’état individuel des composants jusqu’à 11h37. Après cet incident, Amazon a migré cette gestion vers une architecture distribuée entre plusieurs régions.

L’erreur humaine a mis en lumière plusieurs dépendances qui semblaient raisonnables séparément, mais pas combinées.

Et AWS n’est pas le seul exemple.

Six incidents que tout administrateur système devrait connaître

Les analyses post-mortem publiées par de grandes entreprises permettent de constituer une petite collection d’échecs ayant un point commun : l’action initiale semblait beaucoup moins dangereuse que ses conséquences.

Ce tableau démontre également que ces incidents ne s’expliquent pas simplement par un « erreur humaine ».

Chez GitLab, par exemple, un ingénieur a accidentellement supprimé le répertoire des données du serveur PostgreSQL principal en essayant de reconstruire le secondaire. Mais le post-mortem a révélé une chaîne de problèmes bien plus longue.

GitLab estime avoir perdu des modifications concernant environ 5 000 projets, 5 000 commentaires et 700 nouvelles comptes. Les dépôts Git et les wikis n’ont pas été perdus car stockés séparément. Le service a été hors ligne pendant une quarantaine d’heures.

L’incident a aussi testé ses copies et ses procédures de récupération. L’erreur humaine n’était que la dernière étape d’une chaîne opérative beaucoup plus longue.

Cloudflare offre un exemple encore plus proche du développement logiciel.

En juillet 2019, une nouvelle règle a été déployée pour son Web Application Firewall (WAF). Elle contenait une expression régulière provoquant un backtracking massif. Résultat : les CPU traitant le trafic HTTP et HTTPS ont atteint près de 100 % d’utilisation sur tout le réseau.

Au pire, Cloudflare a constaté une réduction du trafic de 82 %.

Ce qui est intéressant, c’est que le changement a suivi la procédure : pull request, validation, intégration continue, tests et déploiement.

Les tests vérifiaient que le WAF détectait correctement certaines requêtes, mais ne vérifiaient pas si une règle pouvait entraîner une surcharge CPU. De plus, ces règles pouvaient être déployées mondialement en quelques secondes.

Le pipeline était vert et la production a été impactée.

Cloudflare a répondu en intégrant des profils de performance à ses tests, en déployant de manière progressive et en modifiant son moteur d’expressions régulières, entre autres mesures.

Quand l’erreur détruit aussi les outils pour la corriger

Meta a porté cette problématique à une autre échelle le 4 octobre 2021.

Lors d’une maintenance de routine, un commande destinée à évaluer la disponibilité de son backbone a involontairement coupé les connexions du réseau mondial.

Un système conçu justement pour auditer ce genre d’ordres et bloquer les erreurs graves n’a pas pu agir à cause d’un bug dans cet outil d’audit, empêchant l’arrêt du script.

Le défaillance du backbone a ensuite conduit à la désactivation de leurs annonces Border Gateway Protocol (BGP) pour DNS. Les serveurs continuaient de fonctionner, mais le reste d’Internet ne trouvait plus les services.

La difficulté supplémentaire était que les outils internes de diagnostic avaient disparu également. Les ingénieurs ont dû se déplacer physiquement dans les centres de données pour restaurer certains systèmes.

C’est la même dépendance circulaire que AWS avait identifiée quatre ans auparavant avec sa page de statut.

Le système de récupération ne doit pas dépendre uniquement du système à restaurer.

Fastly a montré une autre variante en juin 2021.

La société avait introduit le 12 mai une erreur latente qui est restée inactive pendant plusieurs semaines. Le 8 juin, un client a effectué une modification de configuration parfaitement valable, qui a rempli les conditions pour la déclencher.

85 % du réseau Fastly a commencé à renvoyer des erreurs.

La surveillance a détecté la panne en environ une minute. Fastly a ensuite identifié la configuration déclenchant, et, 49 minutes après le début, 95 % de son réseau fonctionnait à nouveau normalement.

Dans ce cas, il n’y avait même pas nécessairement un opérateur ayant écrit une commande incorrecte.

La configuration était valide.

Le logiciel n’était pas préparé à cette configuration.

Atlassian propose sûrement le cas le plus inquiétant pour ceux qui gèrent des scripts internes.

En avril 2022, la société exécutait un script visant à supprimer certaines anciennes applications. À cause d’un problème dans les données fournies, elle a fini par supprimer 883 sites clients. Atlassian a ensuite confirmé que 775 clients avaient été affectés.

Le script a supprimé les sites de façon séquentielle sans générer d’alerte immédiate.

Jira, Confluence, Atlassian Access, Opsgenie et Statuspage sont devenus inaccessibles pour ces clients. Certains ont mis jusqu’à 14 jours pour récupérer complètement leur service.

La leçon n’est pas d’interdire l’accès à la production

Ces incidents révèlent une conclusion bien plus utile que l’idée que « les humains font des erreurs ».

Les systèmes doivent être conçus en partant du principe que un administrateur introduira un jour un paramètre incorrect, un développeur écrira une expression régulière problématique, un script recevra des données erronées ou une configuration apparemment valide activera une combinaison inexplorée.

Cela modifie la manière de concevoir les opérations critiques.

Une rm, une modification BGP ou une suppression massive ne devraient pas suivre le même processus que des opérations routinières. Les actions destructrices peuvent intégrer des limites maximales, des dry-runs, des confirmations indépendantes, des fenêtres d’attente et des mécanismes automatiques pour bloquer des états incompatibles avec les paramètres minimums opérationnels.

Les déploiements ne doivent pas forcément passer directement de zéro à 100 %.

Canary deployments, déploiements par phases et feature flags permettent d’observer une petite partie du trafic avant de déployer à l’échelle. Cloudflare a découvert en 2019 combien cette précaution était cruciale, quand la distribution mondiale de règles en quelques secondes a transformé une avancée technologique en une amplification du risque.

Les sauvegardes exigent le même degré de méfiance.

Afficher un message « sauvegarde terminée avec succès » ne suffit pas à garantir une restauration dans le délai cible (RTO). GitLab a prouvé dans la difficulté qu’une restauration est aussi une partie intégrante du processus de sauvegarde.

L’observabilité doit aussi survivre au service observé.

Les pages de statut, canaux d’urgence, systèmes d’authentification et outils d’administration doivent disposer de chemins alternatifs en cas de panne, surtout si leur perte accidentelle représente un coût élevé.

AWS, Meta et Cloudflare ont tous documenté des incidents où leurs propres dépendances ont compliqué le diagnostic ou la restauration.

La question essentielle avant d’exécuter une opération critique n’est pas seulement de savoir si la commande est correcte.

Il faut aussi se demander que se passerait-il si elle était incorrecte et pourquoi le système permettrait que cette erreur atteigne toute la production.

Ce changement de paradigme fait du « human error » une condition prévue dans la conception.

Questions fréquentes

L’incident Amazon S3 de 2017 a-t-il été causé par une commande mal formulée ?

AWS a confirmé qu’un membre autorisé de l’équipe avait incorrectement saisi un paramètre destiné à retirer quelques serveurs, ce qui a conduit à retirer beaucoup plus de capacité que prévu.

Amazon a-t-il perdu 150 millions de dollars lors de cet incident ?

Ce n’est pas exact. Cyence a estimé environ 150 millions de dollars de pertes pour des entreprises du S&P 500 et 160 millions pour d’autres entreprises américaines de services financiers, mais ce ne sont pas des pertes déclarées par Amazon.

Quelle a été la principale innovation après cet incident chez AWS ?

AWS a introduit des limites dans son outil de retrait pour empêcher qu’une commande retire trop de capacité ou laisse un sous-système sous le seuil minimum. Elle a aussi accéléré la segmentation de S3 en cellules plus petites et modifié l’architecture du tableau de bord de sa page d’état.

Comment éviter qu’une erreur humaine provoque une panne globale ?

Il n’existe pas une solution unique. Les cas analysés montrent l’efficacité de combiner guardrails, minimums opérationnels, dry-runs, permissions limitées, déploiements progressifs, plans de reprise, observabilité indépendante et réduction du blast radius.