Rapport d'incident : redémarrage de la plateforme après une coupure électrique complète

TL;DR

À partir de 12h56 UTC le jeudi 24 janvier, un défaut électrique dans notre centre de données a créé une réaction en chaîne conduisant à un arrêt complet de la plateforme. À 18h40 UTC le même jour, toutes les applications et bases de données ont été redémarrées avec succès sans aucune perte de données. Cet article détaille le déroulement des événements, analyse la réaction de l’équipe et décrit les actions qui seront prises pour améliorer la situation à l’avenir.

Chronologie de l’incident

• [12h56 UTC] Premiers alertes, tous nos sites Web sont inaccessibles, les opérateurs sont alertés. Toute l’équipe, tous les membres travaillant à distance, est mobilisée. Nous remarquons rapidement que nous n’avons pas d’accès réseau à la plateforme, l’accès VPN est hors service, toutes les applications des clients sont également indisponibles. Le contact avec notre fournisseur d’infrastructure est établi.

• [13h10 UTC] L’équipe de notre fournisseur est déjà sur l’incident et essaie de comprendre la situation.

• [13h25 UTC] Le premier retour que nous avons est qu’un routeur BGP semble être hors service et pourrait être la cause de ce problème. Plus tard, nous comprenons que toute l’infrastructure souffre en fait d’une panne électrique. Une explication détaillée de notre fournisseur est donnée en note de bas de page ¹.

• [14h30 UTC] L’électricité est rétablie, le réseau est opérationnel ainsi que nos serveurs. L’ensemble de l’infrastructure a été redémarré. La première priorité est de redémarrer et garantir le bon fonctionnement de nos services internes (redémarrage des clusters de bases de données, orchestrateur, etc.). Le deuxième objectif est de restaurer, dès que possible, toutes les applications des clients ainsi que leurs modules complémentaires de bases de données.

• [15h13 UTC] Tous les services internes requis sont opérationnels, nous avons commencé à restaurer les bases de données clients.

• [15h45 UTC] Plus de 95 % des bases de données sont opérationnelles, ainsi que tous nos services internes. Nous commençons la récupération des applications des clients et examinons manuellement les bases de données qui ne se sont pas redémarrées correctement.

• [18h40 UTC] Jusque-là, les applications ont été redéployées dans l’infrastructure progressivement jusqu’à l’achèvement. Cela signifie que les applications étaient indisponibles pendant une durée allant de 2h49 à 5h44.

Analyse

Cet incident a été le plus long depuis la genèse de Scalingo. Commençant par une défaillance matérielle majeure dans notre centre de données, suivi d'une période de récupération pour remettre toutes les bases de données et applications en fonctionnement.

Pendant la première partie de l’incident, toute l’équipe était en ligne mais attendait que l’infrastructure matérielle soit disponible. Pendant un certain temps, notre fournisseur d’infrastructure nous a informés qu’il s’agissait d’un problème de réseau. Nous ne nous attendions pas à un redémarrage complet de notre infrastructure.

Une fois l’alimentation rétablie dans notre infrastructure, la récupération a commencé. Nous avons d’abord réalisé que certains de nos services internes avaient échoué à redémarrer correctement. Nous nous appuyons sur etcd pour la découverte des services, mais notre cluster etcd était partiellement hors service en raison d’une mauvaise configuration sur l’un des hôtes suite au redémarrage. Nous ne pouvions pas exécuter nos scripts de récupération sans ce cluster et avons d'abord dû trouver un moyen de le démarrer avant de passer à l’étape suivante.

Beaucoup de nos microservices sont en fait des applications typiques de Scalingo, les mêmes que vous hébergez sur Scalingo. Manger notre propre nourriture est une bonne chose car nous sommes nos premiers clients et testeurs. Sans tous les services internes opérationnels, nous avons dû amorcer manuellement certains services de base. Il a fallu environ 45 minutes pour restaurer les services internes les plus importants.

Pour récupérer toutes les bases de données, nous disposions d'excellents outils et en 30 minutes, la grande majorité d'entre elles étaient opérationnelles. Certaines n'ont pas redémarré car la coupure d'électricité les a mises dans un état de récupération qui devait être géré manuellement par un opérateur. Nous avons finalement réussi à récupérer toutes les bases de données sans aucune perte de données.

Une fois les bases de données disponibles, nous nous sommes concentrés sur la récupération des applications : L’entité ayant la responsabilité de donner des ordres aux serveurs pour démarrer les applications est le planificateur. Il est conçu pour choisir toujours les nœuds les plus disponibles. Cette stratégie fonctionne très bien dans un contexte opérationnel normal, mais nous avons rapidement remarqué que, dans une situation de récupération, cela nous ralentissait vraiment. L’algorithme responsable de choisir le meilleur nœud trie la liste des nœuds disponibles en fonction de différents indicateurs de surveillance qui sont actualisés toutes les ~30 secondes. Ainsi, lorsque nous interrogeons le planificateur pour démarrer les applications durant cette période de 30 secondes, seuls les nœuds considérés comme les plus disponibles étaient ordonnés pour démarrer des conteneurs. En conséquence, toutes les applications étaient planifiées sur une poignée de serveurs, entraînant des erreurs de délai d'attente. Nous devions ralentir le processus de récupération des applications pour éviter ce problème. La récupération a donc ralenti ici, mais les applications ont continué à être redémarrées. Cette partie de la récupération avait déjà été testée sur notre infrastructure de staging, mais ce problème n'est apparu qu'à l’échelle de l’environnement de production. Nous avons observé un manque d'outils pour suivre ce processus de récupération.

Après la tentative qui a entraîné des surcharges des serveurs et des délais d'attente, nous n’avions pas les moyens d’observation pour savoir ce qui était opérationnel et ce qui ne l’était pas. En raison de ce manque de visibilité, certaines applications ont dû être redémarrées plusieurs fois. Le problème corollaire à ce manque était que nous ne pouvions pas estimer efficacement et précisément combien étaient opérationnels et combien restaient à faire. Les estimations que nous avons données publiquement étaient basées sur la consommation de RAM de notre infrastructure. Nous savions combien nous utilisions auparavant, donc avec un simple calcul, en tenant compte de l’utilisation actuelle de la RAM, nous avons fait cette estimation.

Donc, en fin de compte, aucune opération ne s’est vraiment mal déroulée dans la récupération, elle n’était tout simplement pas assez rapide, pour toutes les raisons différentes énoncées dans les paragraphes précédents. Nous devrions être beaucoup mieux préparés et plus efficaces pour accomplir ce processus. C’est pourquoi de nombreuses actions seront planifiées et exécutées.

Actions prises et plan futur

Comme l’incident était lié à deux acteurs différents, des actions doivent être prises par notre fournisseur d’infrastructure pour s'assurer qu'un tel défaut électrique ne puisse pas avoir un impact aussi important sur l’infrastructure (routeurs / serveurs / SANs). Ils ont immédiatement réorganisé leur équipement d'alimentation, afin d'améliorer l'équilibre de consommation électrique. De plus, une capacité électrique supplémentaire sera fournie cette semaine.

La deuxième partie de l’incident était liée à nous et pourrait être améliorée pour une récupération plus rapide. Notre plan pour l’avenir se compose de deux parties : organisationnelle et technique, car nous avons défini que les deux peuvent être améliorés.

D'un point de vue organisationnel, les actions suivantes seront réalisées :

• Formation à la récupération après sinistre : l’équipe a été formée pour récupérer une infrastructure complètement en panne dans l’environnement de staging. Cependant, c'était la première fois qu'un événement aussi majeur se produisait dans l'environnement de production, à cette échelle. Nous prévoyons d’organiser des formations régulières dans notre environnement de staging pour garantir que nos processus sont bons et que nous sommes capables de récupérer efficacement d'un désastre d'infrastructure. Nous allons mettre plus de pression sur cet environnement pour réduire l'écart entre les deux environnements.

• Définitions et tests des processus : nous maintenons une documentation interne contenant des processus pour les demandes de support ainsi que la récupération d’incidents, mais elle est encore incomplète. Les processus à appliquer en cas d’incidents majeurs comme celui-ci ne sont pas tous présents, en raison de leur rareté. Des ressources seront investies pour améliorer la documentation opérationnelle actuelle. Bien sûr, ces processus n'ont aucune valeur s'ils ne sont pas testés, c'est l'objectif des formations définies ci-dessus.

• Amélioration de la communication interne : durant cet incident, tous les membres de l’équipe ont travaillé à distance. La communication s'est bien déroulée mais pourrait être améliorée. Nous avons principalement utilisé Slack pour communiquer en interne. Cela a bien fonctionné, mais à un moment donné, nous avons perdu du temps à chercher des informations opérationnelles (qui faisait précisément quoi, etc.). Ces éléments étaient explicitement écrits, mais ensuite recouverts par d’autres messages. La prochaine fois, un canal personnalisé dédié à l'incident sera créé, ainsi qu'un document de co-création en temps réel où chaque opérateur pourra écrire et mettre à jour les tâches sur lesquelles ils travaillent.

De tous les problèmes techniques que nous avons identifiés après l’analyse de l'événement, plusieurs mesures techniques seront prises :

• Un outil de diagnostic de bas niveau sera développé pour aider les opérateurs à vérifier l'état de tous les composants de base et de leurs dépendances (etcd, DNS, Message Queue, etc.) automatiquement, sans avoir à faire de vérification manuelle pour chaque composant.

• Un mode de récupération sera ajouté à notre planificateur qui distribuera les applications différemment de son flux de travail normal afin de redémarrer les applications plus rapidement et d’éviter de surcharger les serveurs qui exécutent les applications. Ce mode de récupération devrait également désactiver la collecte des images de cache des applications. Cela aiderait à redémarrer les applications plus rapidement, si les images ne sont pas téléchargées mais déjà présentes sur les serveurs.

• Un outil de diagnostic de haut niveau sera développé afin de suivre la récupération de la plateforme. Il était difficile pour les opérateurs de suivre l'avancement du processus de récupération. Nous avons besoin de ces informations pour communiquer efficacement avec nos clients.

À une échelle plus large, nous travaillons depuis un certain temps sur une présence multi-centres de données. Tout d'abord, cela vise à être présent dans plus d'un centre de données. Cependant, notre objectif à plus long terme est de fournir une résilience des centres de données en cas d'incident majeur comme celui qui s'est produit la semaine dernière.

Quelques mots pour conclure

Nous tenons sincèrement à remercier nos clients qui ont été très compréhensifs et encourageants pendant l’incident. Vous avez choisi d'utiliser Scalingo parce que vous ne voulez pas gérer la partie infrastructure dans votre entreprise. Vous avez plus de temps pour ce qui compte vraiment : votre code, vos applications, et non des tâches d'administration système (ni de récupération après sinistre).

Ici, le temps de récupération a été long, et nous travaillerons à le réduire autant que possible. Nous allons utiliser l’incident de jeudi pour améliorer nos processus et notre pile technique afin d’être plus efficaces. Les ressources nécessaires seront consacrées au développement d’outils internes meilleurs, et éventuellement pour accélérer le processus de récupération.

Enfin, bien que cet incident de temps d'arrêt soit encore dans la plage de nos Conditions de Service, nous comprenons pleinement qu'il s'agissait d'une longue période d'inactivité continue. Par conséquent, une compensation financière suivra pour les clients de notre premier niveau (99,9 % de disponibilité garantie avec au moins 2 conteneurs web en fonctionnement). Elle sera automatiquement déduite de la prochaine facture.

Notes de bas de page

1 : Le 24 janvier 2019 à 13h56 (heure de Paris UTC+1), un appareil déployé dans l'un de nos centres de données a rencontré un problème électrique impactant l'un de ses deux blocs d'alimentation. Ce défaut électrique a déclenché le disjoncteur du circuit d'alimentation concerné. Le rack entier où cet équipement est déployé aurait dû être alimenté par le second circuit d'alimentation, mais malheureusement, son disjoncteur a également sauté, en raison de ce que nous avons pu identifier comme une surcharge générée par tous les appareils du rack passant leur alimentation redondante sur ce circuit unique.

Le problème nécessitait une intervention sur site dans le centre de données qui consistait en plusieurs vérifications avant de restaurer l'alimentation puis, séquentiellement, de mettre sous tension les appareils pour identifier celui qui a généré le déclenchement initial du disjoncteur. Tous les appareils étaient pleinement disponibles à 15h30 (heure de Paris UTC+1).