Gérer la panne du 6 décembre : mesures et solutions

Le 6 décembre, ce que nous redoutons le plus s’est produit. À 13:23, nous avons constaté des problèmes de capacité sur notre plateforme. Il s’est rapidement avéré qu’il s’agissait d’un problème grave, qui a entraîné une interruption de service pour de nombreux cas d’usage. Nous sommes profondément désolés d’avoir laissé cela se produire. La disponibilité et la fiabilité sont essentielles au service que nous fournissons à nos clients ; nous travaillons donc dur pour que ces pannes soient aussi rares que possible.

Plutôt que de simplement vous présenter nos excuses, nous aimerions toutefois vous emmener dans les coulisses et vous montrer précisément ce que nous avons fait pour résoudre le problème le plus vite possible.

Plongeons dans une analyse post-mortem détaillée des événements.

Chronologie des événements :

13:12 - Nous avons déployé des préparatifs pour passer à une infrastructure basée sur un VPC. Cela comprenait de nouvelles variables d’environnement contenant des configurations — comme les sous-réseaux, les groupes de sécurité et les répartiteurs de charge auxquels ajouter des machines — propres au nouveau VPC que nous créons pour chaque région. En outre, le déploiement contenait des modifications de GoInstance — un outil que nous avons écrit en Go et qui gère le lancement et l’activation des machines, puis leur retrait. Cette modification n’opérait pas le passage effectif au VPC : elle en posait simplement les bases, tout en restant rétrocompatible avec notre configuration actuelle sans VPC. Le passage au VPC nous permet d’améliorer la sécurité et de tirer parti de fonctionnalités AWS réservées aux VPC, comme des types d’instances offrant de meilleures performances à moindre coût. La modification avait été testée en profondeur, en local comme en CI, mais comme les variables d’environnement diffèrent en production de celles des environnements de développement ou de staging, une incohérence a pu passer inaperçue.

13:23 - La première alerte du pager est arrivée, indiquant que nous disposions de moins d’instances de téléversement que nécessaire. Le problème est passé inaperçu pendant un moment, car le chargement d’un nouvel environnement nécessite de nouveaux processus, et il a fallu un certain temps à notre déploiement blue/green pour remplacer tous les processus actifs.

13:26 - L’équipe d’intervention d’urgence (Emergency Response Team, ERT) est mobilisée.

13:32 - Il a été établi que nous ne pouvions pas lancer de nouvelles machines en raison de variables d’environnement invalides (incohérence entre les ID d’AMI et les noms de groupes de sécurité). Dans certains cas, GoInstance faisait référence à des valeurs inexistantes.

13:39 - À mesure que les anciennes machines étaient retirées de la rotation ou devenaient injoignables, nous ne fonctionnions plus que sur une seule machine par région, que les autoscalers refusaient de retirer.

13:40 - L’ERT a corrigé l’incohérence et lancé un build.

13:45 - Mise à jour de Twitter et de la page de statut.

13:49 - Le build a été déployé.

13:51 - En raison d’un bug sans rapport dans la façon dont GoInstance est compilé, il s’est avéré que les modifications n’avaient pas été mises en production.

13:55 - Perplexe, l’équipe a tenté d’annuler complètement le build défectueux.

14:01 - À cause du même bug, le retour en arrière n’a pas non plus activé les modifications. Comme nous l’avons découvert plus tard, un retour plus loin dans le temps aurait fonctionné. Pour l’expliquer : il y a quelques mois, lors du passage de notre stack à Nix, nous avons introduit un bug qui ne recompilait GoInstance que si ses modifications étaient regroupées avec des modifications d’autres parties de notre stack. Lorsque nous avons tenté de corriger GoInstance, les modifications n’ont donc pas été prises en compte ni déployées en production. Il a fallu un certain temps à l’ERT pour le comprendre.

14:08 - L’ERT a corrigé le problème susmentionné dans notre configuration Nix, et nous avons de nouveau pu déployer des modifications. Nous avons lancé un autre build, puis l’avons déployé.

14:17 - Les flottes EU et US avaient de nouveau atteint la capacité souhaitée. Un composant important avait récemment été ajouté à notre stack sans encore avoir été intégré à nos AMI, si bien que le lancement des machines était plus lent que d’habitude.

14:34 - Rétablissement de tous les services vérifié, toutes les conversations client associées résolues, Twitter et la page de statut mis à jour.

Quelles mesures avons-nous prises ?

• De nouvelles AMI ont été créées pour toutes les régions et tous les types de machines, ce qui ramène de nouveau le temps de lancement de nos machines à près de trois minutes

• Le bug de notre configuration Nix a été corrigé, de sorte que les modifications de GoInstance sont toujours prises en compte dans notre build

• L’incohérence de notre environnement a été corrigée

Ensemble, ces mesures ont permis à tout de fonctionner à nouveau normalement. Nous sommes toutefois conscients qu’à l’avenir, des mesures supplémentaires seront nécessaires pour garantir que ce genre d’incident ne puisse plus jamais se reproduire.

Quelles autres mesures allons-nous prendre ?

Dans le cadre de notre déploiement, nous faisons lancer des machines par les autoscalers, ce qui aurait dû stopper net le déploiement avant qu’il ne cause des dégâts. Malheureusement, il s’avère qu’en raison d’un problème sans rapport, ce test préalable a été exécuté sur l’environnement précédent, et non sur celui actuellement déployé. Nous allons corriger cela afin que ce test fonctionne de manière fiable à l’avenir et puisse détecter ce type de problème.

D’autres parties de notre suite de tests automatisés auraient aussi pu détecter l’environnement invalide, mais elles ne le vérifiaient pas, car l’environnement de staging diffère de l’environnement de production. Nous étudions actuellement la possibilité de rendre nos environnements plus similaires.

Nous sommes désolés

Encore une fois, nous sommes vraiment désolés pour les désagréments que nous vous avons causés. Nous espérons que cette analyse post-mortem a permis d’éclairer ce qui a précisément provoqué la panne et ce que nous faisons pour qu’elle ne se reproduise jamais. Si cette panne a eu des conséquences pour vous, n’hésitez pas à contacter notre équipe d’assistance, et nous essaierons d’arranger les choses !