Analyse post-incident de la défaillance des outils d'analyse et du plan de contrôle de Cloudflare

Le jeudi 2 novembre, à partir de 11 h 43 UTC, les services d'analyse et le plan de contrôle de Cloudflare ont connu une défaillance. Le plan de contrôle de Cloudflare désigne principalement l'interface utilisée par nos clients pour piloter l'ensemble des services, dont notre site web et nos API. Notre service d'analyse inclut des fonctions de journalisation et de rapport d'analyses.

L'incident a duré du 2 novembre à 11 h 44 UTC au 4 novembre à 4 h 25 UTC. Nous avons pu restaurer la plus grande partie de notre plan de contrôle dans notre installation de reprise après sinistre dès le 2 novembre 17 h 57 UTC. Bon nombre de nos clients n'auraient rencontré aucun problème avec la plupart de nos produits après la mise en ligne de l'installation de reprise après sinistre. Toutefois, la restauration d'autres services a demandé plus de temps et les clients qui s'en sont servis ont pu faire face à certaines difficultés avant la résolution complète de l'incident. Nos services de journaux bruts sont restés indisponibles à la plupart de nos clients pendant toute la durée de l'incident.

Les services sont désormais rétablis pour l'ensemble de nos clients. Les services réseau et les services de sécurité ont continué à fonctionner comme prévu tout au long de l'incident. Le trafic transitant via notre réseau n'a pas été affecté, même si les clients n'ont pas pu apporter de modifications à ces services à certains moments.

Le présent article décrit les événements à l'origine de cet incident, l'architecture que nous avions mise en place pour empêcher ce genre de problèmes, les éléments qui ont failli à leur mission et pourquoi, ainsi que les modifications que nous apportons à l'ensemble en fonction de ce que nous avons appris ces dernières 36 heures.

Pour commencer, cette situation n'aurait jamais dû se produire. Nous pensions que nous disposions de systèmes à haute disponibilité, qui auraient dû empêcher ce genre de défaillance, même lorsque l'un des fournisseurs de nos datacenters principaux a subi une panne catastrophique. En outre, si de nombreux systèmes sont restés en ligne comme prévu, certains systèmes essentiels disposaient de dépendances non évidentes au premier abord qui les ont rendus indisponibles. Je suis navré et embarrassé de cet incident, mais aussi des difficultés que ce dernier a entraînées pour nos clients et notre équipe.

Le plan de contrôle et les systèmes d'analyse de Cloudflare sont principalement exécutés sur des serveurs situés dans trois datacenters implantés autour d'Hillsboro, dans l'Oregon. Dissociés les uns des autres, chacun de ces trois datacenters dispose de plusieurs alimentations secteur, ainsi que de plusieurs connexions réseau redondantes et indépendantes.

Les installations ont été intentionnellement choisies pour se trouver à une certaine distance les unes des autres afin de minimiser les chances qu'une catastrophe naturelle affecte les trois, tout en restant suffisamment proches pour que chacune exécute des clusters de données actif-actif. Elles synchronisent donc en permanence les données entre elles. Cette conception implique donc que si l'une des installations se retrouve hors ligne, les datacenters restants peuvent continuer à fonctionner.

Il s'agit là du design système que nous avons commencé à mettre en œuvre il y a quatre ans. Alors que la plupart des systèmes essentiels de notre plan de contrôle avaient fait l'objet d'une migration vers le cluster à haute disponibilité, certains services (notamment ceux de nos produits les plus récents) n'avaient pas encore été ajoutés à ce cluster.

En outre, nos systèmes de journalisation ne se trouvaient pas sur ce dernier, et ce intentionnellement. La logique à l'œuvre derrière cette décision est que la journalisation constitue déjà un problème distribué lorsque les journaux se trouvent placés en file d'attente à la périphérie de notre réseau, avant d'être renvoyés au datacenter central en Oregon (ou vers une autre installation pour les clients qui utilisent des services régionaux pour la journalisation). Si notre installation de journalisation se retrouve hors ligne, les journaux d'analyse sont donc mis en file d'attente à la périphérie de notre réseau jusqu'au retour en ligne de cette dernière. Nous avons déterminé que le retard dans les analyses était acceptable.

Le plus important des trois datacenters basés en Oregon est pris en charge par Flexential. Nous désignons ce dernier par le nom « PDX-DC04 ». Cloudflare loue de l'espace dans le datacenter PDX-04, au sein duquel nous hébergeons notre cluster d'analyse le plus important, ainsi que plus d'un tiers des machines de notre cluster à haute disponibilité. Il s'agit également de l'emplacement par défaut pour les services qui n'ont pas encore été intégrés sur notre cluster à haute disponibilité. Nous sommes un client relativement important de l'installation, avec une consommation d'environ 10 % de sa capacité totale.

Le 2 novembre à 8 h 50 UTC, Portland General Electric (PGE), le fournisseur d'énergie qui assure l'alimentation du PDX-04, a dû effectuer une opération de maintenance imprévue sur l'une des alimentations électriques indépendantes du bâtiment. Cet événement a coupé l'une des alimentations du PDX-04. L'alimentation du datacenter s'effectue par le biais de plusieurs points présentant un certain niveau d'indépendance. Flexential a toutefois activé ses générateurs afin de compléter efficacement la ligne d'alimentation en panne.

Contrairement aux bonnes pratiques, Flexential n'a pas informé Cloudflare de la défaillance d'alimentation et de l'activation des générateurs. Aucun de nos outils d'observabilité n'a pu détecter que la source d'alimentation avait changé. Si le fournisseur nous avait informés de la situation, nous aurions pu demander à une équipe de surveiller plus étroitement le datacenter et de déplacer les services du plan de contrôle qui dépendaient de cette dernière pendant le dysfonctionnement.

Le fait que Flexential ait utilisé à la fois la ligne secteur restante et les générateurs est également inhabituel. Il n'est pas rare que les fournisseurs d'énergie demandent aux datacenters de se déconnecter du réseau électrique lorsque la demande énergétique est élevée et de fonctionner uniquement sur générateurs. Flexential exploite 10 générateurs, disposant d'unités redondantes et capables d'alimenter l'ensemble du datacenter en pleine charge. Le fournisseur aurait également pu alimenter l'installation uniquement depuis la ligne secteur restante. Nous n'avons pas eu de réponse claire quant à la raison pour laquelle le fournisseur a décidé d'alimenter le datacenter avec le secteur et les générateurs.

À compter de cette décision, nous n'avons toujours pas obtenu d'informations précises de la part de Flexential sur la cause première, certaines décisions qu'ils ont prises ou les événements. Nous mettrons cet article à jour lorsque nous recevrons davantage d'informations de Flexential et de PGE sur ce qui s'est produit. Une partie des hypothèses qui suivent ne sont que pure spéculation sur la série d'événements la plus probable, basée sur ce que certains collaborateurs de Flexential nous ont communiqué officieusement.

L'une des raisons possibles pour laquelle ils auraient laissé la ligne secteur active est que Flexential faisait partie d'un programme PGE nommé DSG. DSG permet au fournisseur d'énergie local d'exploiter les générateurs d'un datacenter afin d'apporter de la puissance supplémentaire sur le réseau. En échange, le fournisseur contribue à l'entretien des générateurs et fournit du carburant à l'entreprise. Nous n'avons retrouvé aucune trace de Flexential nous informant de programme DSG. Nous leur avons demandé si le programme DSG était actif au moment de l'incident, mais n'avons reçu aucune réponse à ce sujet. Nous ne savons pas si ce programme a contribué aux décisions prises par Flexential, mais il pourrait expliquer pourquoi la ligne secteur a été maintenue après le démarrage des générateurs.

À approximativement 11 h 40 UTC, un transformateur PGE du PDX-04 a connu un défaut de terre. Nous pensons, mais n'avons pas réussi à obtenir confirmation de la part de Flexential ou de PGE, que c'est ce transformateur qui a abaissé le courant électrique en provenance du réseau pour la seconde ligne d'alimentation, toujours active lorsque le courant est entré dans le datacenter. Il semble probable, bien qu'il nous reste encore à le confirmer auprès de Flexential ou de PGE, que le défaut de terre a été provoqué par l'opération de maintenance imprévue à laquelle PGE était en train de procéder et qui a affecté la première ligne d'alimentation. À moins qu'il ne se soit agi d'une coïncidence des plus malheureuses.

Les défauts de terre des lignes électriques à haute tension (12 470 V) sont une très mauvaise nouvelle. Les systèmes électriques sont conçus pour se couper rapidement afin de prévenir d'éventuels dégâts lorsqu'un tel événement se produit. Malheureusement, dans ce cas précis, les mesures de protection ont également coupé l'ensemble des générateurs du PDX-04. Cette situation impliquait que les deux sources d'énergie alimentant le datacenter (les deux lignes secteur et les 10 générateurs) étaient coupées.

Fort heureusement, en plus des générateurs, le PDX-04 peut également compter sur un jeu de batteries UPS. Ces batteries sont censément suffisantes pour alimenter l'installation pendant environ 10 minutes. Ce temps est prévu pour être suffisant pour assurer le relais entre la coupure du secteur et le démarrage automatique des générateurs. Si Flexential pouvait redémarrer les générateurs ou restaurer l'alimentation secteur en l'espace de 10 minutes, aucune interruption n'aurait lieu. En réalité, les batteries ont commencé à flancher au bout de seulement 4 minutes, d'après ce que nous avons pu déduire de l'observation des défaillances de nos propres équipements. De même, il a fallu à Flexential bien plus de 10 minutes pour redémarrer les générateurs.

Bien que nous n'ayons pas encore reçu de confirmation officielle, certains collaborateurs nous ont révélé que trois problèmes ont entravé la remise en route des générateurs. Premièrement, les techniciens devaient y accéder physiquement et les redémarrer manuellement, car le défaut de terre avait fait disjoncter les circuits. Deuxièmement, le système de contrôle des accès de Flexential n'était pas alimenté par les batteries de secours. Il était donc hors ligne. Enfin, troisièmement, l'équipe de nuit sur site ne comprenait pas d'expert électricien ou de spécialiste des opérations expérimenté. Elle se composait uniquement de l'équipe de sécurité et d'un technicien non accompagné, qui n'était en poste que depuis une semaine.

Entre 11 h 44 et 12 h 01 UTC, les générateurs n'étant pas intégralement redémarrés, les batteries UPS sont arrivées à court de réserves et tous les clients du datacenter ont perdu leur alimentation électrique. Tout au long de l'incident, Flexential n'a jamais informé Cloudflare d'un quelconque problème au sein de l'installation. Nous avons été prévenus des problèmes rencontrés par le datacenter lorsque les deux routeurs qui connectent ce dernier au reste du monde est passé hors ligne, à 11 h 44 UTC. Devant l'impossibilité de joindre les routeurs directement ou via un système de gestion hors bande, nous avons tenté de contacter Flexential et envoyé notre équipe locale se rendre physiquement au datacenter. Le premier message reçu de la part de Flexential et expliquant qu'ils rencontraient un problème est arrivé à 12 h 28 UTC.

Nous rencontrons actuellement un problème d'alimentation électrique dans notre [PDX-04]. Ce problème a commencé approximativement à 5 h 00 UTC-7 [12 h 00 UTC]. Nos techniciens travaillent activement à la résolution de ce dernier et au rétablissement des services. Nous vous informerons de notre progression toutes les 30 minutes ou à mesure que d'autres informations seront disponibles quant au temps estimé pour ce rétablissement. Merci de votre patience et de votre compréhension.

Bien que la conception du PDX-04 ait été certifiée de niveau 3 avant sa construction et soit prévue pour assurer une haute disponibilité dans le cadre de ses SLA, nous avons prévu la possibilité qu'il soit mis hors ligne. Même les installations les mieux tenues peuvent avoir leurs mauvais jours. Nous avons donc planifié cette potentialité. D'après nos prévisions, si ce genre de cas devait survenir, nos outils d'analyse seraient hors ligne et les journaux mis en file d'attente à la périphérie du réseau et retardés. De même, certains services de moindre priorité non encore intégrés à notre cluster haute disponibilité seraient temporairement mis hors ligne, le temps de les rétablir sur un autre site.

Nos deux autres datacenters dans la région prendraient en charge le cluster haute disponibilité et maintiendraient les services essentiels en ligne. De manière générale, tout s'est produit conformément à nos prévisions. Malheureusement, nous avons découvert qu'un sous-ensemble de services censés se trouver sur le cluster haute disponibilité avaient comme dépendances des services exécutés exclusivement sur le PDX-04.

Deux services en particulier, Kafka et ClickHouse, qui traitent les journaux et soutiennent nos outils d'analyses, n'étaient disponibles que sur le PDX-04, mais disposaient de services dépendant d'eux exécutés sur le cluster haute disponibilité. Ces dépendances n'auraient pas dû être si étroites et auraient dû s'interrompre de manière plus fluide. En outre, nous aurions dû les remarquer.

Nous avions effectué des tests de notre cluster haute disponibilité en procédant à la mise hors ligne complète de chacun des deux autres datacenters (et des deux). De même, nous avions également testé la mise hors ligne de la partie haute disponibilité du PDX-04. Toutefois, nous n'avions jamais testé la mise hors ligne totale de l'ensemble du datacenter PDX-04. En conséquence, nous avions manqué l'importance de certaines de ces dépendances sur notre plan de données.

Nous avons également été bien trop laxistes sur la nécessité d'intégrer les nouveaux produits et leurs bases de données associées au cluster haute disponibilité. Cloudflare fait travailler plusieurs équipes pour innover rapidement. De ce fait, les produits prennent souvent une voie différente de celle qui était prévue lors de la première alpha. Si, au fil du temps, nos bonnes pratiques penchent vers la migration du back-end de ces services, nous ne l'avons pas requise formellement avant la mise en disponibilité générale des produits. Il s'agissait d'une erreur, car ce manquement implique que les protections redondantes que nous avions mises en place fonctionnaient de manière incohérente en fonction du produit.

En outre, un nombre bien trop important de services dépendent de la disponibilité de nos installations centrales. Si c'est ainsi que bon nombre de services logiciels sont effectivement développés, ce constat ne joue pas en la faveur de Cloudflare. Nous sommes doués en matière de systèmes distribués. Notre réseau mondial a continué à fonctionner comme prévu tout au long de l'incident. Et bien que certains de nos produits et de nos fonctionnalités soient configurables et utilisables via la périphérie de notre réseau, sans avoir besoin des systèmes centraux, un nombre bien trop important de services ne fonctionnent plus si les systèmes centraux ne sont plus disponibles. Nous devons utiliser les produits de système distribué que nous mettons à la disposition de tous nos clients pour l'ensemble de nos services, afin qu'ils puissent continuer à fonctionner de manière presque normale, même en cas de perturbation de nos installations centrales.

À 12 h 48 UTC, Flexential a réussi à redémarrer les générateurs. Le courant est revenu dans certaines parties du datacenter. Afin de ne pas submerger le système, le rétablissement du courant au sein d'un datacenter s'effectue généralement de manière progressive, en redémarrant un circuit à la fois. Comme les disjoncteurs d'une maison d'habitation, chaque client est protégé par des coupe-circuits redondants. Lorsque Flexential a tenté de relancer les circuits de Cloudflare, les techniciens se sont aperçus que les coupe-circuits étaient défectueux. Nous ne savons pas si le problème était dû au défaut de terre ou à une autre surtension résultant de l'incident, ni même si l'appareil était défectueux bien avant ce dernier. Le défaut n'a été découvert qu'après la coupure de courant.

Flexential a entamé le processus de remplacement des coupe-circuits défectueux. L'opération impliquait le fait de trouver de nouveaux dispositifs, car le nombre de coupe-circuits défectueux était supérieur au nombre d'appareils de remplacement dont le fournisseur disposait sur site. Comme un plus grand nombre de services que prévu étaient hors ligne, et parce que Flexential ne pouvait pas nous donner d'estimation de temps pour le rétablissement de nos services, nous avons décidé (à 13 h 40 UTC) d'effectuer un basculement vers les sites de reprise après sinistre Cloudflare situés en Europe. Fort heureusement, nous n'avions besoin de faire basculer qu'un petit pourcentage de notre plan de contrôle général. La plupart de nos services continuaient de fonctionner sur les systèmes haute disponibilité des deux autres datacenters centraux encore actifs.

Nous avons redémarré les premiers services sur le site de reprise après sinistre à 13 h 43 UTC. Les sites de reprise de Cloudflare assurent les services essentiels du plan de contrôle en cas de sinistre. Si ces sites ne prennent pas en charge certains de nos services de traitement de journaux, ils sont néanmoins conçus pour prendre en charge les autres parties de notre plan de contrôle.

Quand les services ont été relancés sur ces sites, nous avons rencontré un problème de « bousculade », lorsque les appels d'API qui échouaient jusqu'ici ont commencé à submerger nos services. Nous avons mis en place des limites de volume de requêtes afin de ramener ce dernier sous contrôle. Pendant cette période, les clients de la plupart de nos produits ont pu constater des erreurs intermittentes lorsqu'ils effectuaient des modifications via notre tableau de bord ou notre API. À 17 h 57 UTC, les services qui avaient fait l'objet d'un basculement vers le site de reprise après sinistre étaient stables et la majeure partie de nos clients n'étaient plus affectés de manière directe. Toutefois, certains systèmes nécessitaient toujours une configuration manuelle (p. ex. Magic WAN) et d'autres services, pour la plupart liés au traitement des journaux et à d'autres API sur mesure, sont restés indisponibles jusqu'à la restauration du PDX-04.

Un petit ensemble de produits n'ont pas correctement tenu sur nos sites de reprise après sinistre. Il s'agissait principalement de produits plus récents, sur lesquels les travaux d'implémentation et de test de la procédure de reprise après sinistre n'était pas totalement achevés. Ces produits comprenaient notre service Stream, dédié à l'importation de nouvelles vidéos, parmi quelques autres. Notre équipe a suivi deux pistes simultanées pour rétablir ces services : 1) procéder à leur réimplémentation sur nos sites de reprise après sinistre, et 2) les faire migrer vers notre cluster haute disponibilité.

Flexential a remplacé nos coupe-circuits défectueux, rétabli les deux lignes secteur et confirmé la reprise de l'alimentation appropriée à 22 h 48 UTC. L'ensemble de notre équipe avait été mobilisée et avait travaillé toute la journée sur cette urgence. J'ai donc pris la décision d'envoyer une bonne partie de celle-ci se reposer et de reprendre le travail sur le PDX-04 dans la matinée. Cette décision a retardé notre reprise complète, mais permettait de minimiser les chances d'envenimer encore la situation par des erreurs supplémentaires dues à la fatigue.

Première tâche de la journée au matin du 3 novembre, notre équipe a entamé le rétablissement de nos services sur le PDX-04. L'opération a commencé par le redémarrage physique de nos équipements réseau, puis par le démarrage de milliers de serveurs afin de rétablir les services. L'état de ces derniers au sein du datacenter nous était inconnu, car nous pensions que plusieurs remises sous tension s'étaient probablement produites au cours de l'incident. Le seul moyen de procéder à un rétablissement sûr était de suivre la procédure de redémarrage complet de l'ensemble de l'installation.

Cette dernière impliquait un processus de remise en ligne manuelle de nos serveurs de gestion des configurations afin de commencer la restauration du datacenter. La reconstruction de ces derniers a demandé 3 heures. Notre équipe a pu ensuite lancer la reconstruction du reste des serveurs hébergeant nos services. La reconstruction de chaque serveur a demandé entre 10 minutes et 2 heures. Si nous avons pu suivre cette procédure en parallèle sur plusieurs serveurs, certains d'entre eux ont nécessité une remise en ligne en séquence du fait de certaines dépendances intrinsèques entre services.

Les services ont été intégralement rétablis le 4 novembre 2023 à 4 h 25 UTC. Comme nous stockons nos données analytiques dans nos datacenters centraux européens, la majorité de nos clients ne devraient pas constater de perte de données pour la plupart des outils d'analyse de notre tableau de bord et de nos API. Certains ensembles de données non répliqués dans l'UE présenteront toutefois des lacunes persistantes. Pour les clients qui utilisent notre fonctionnalité Logpush, vos journaux n'ont pas été traités pendant la majeure partie de l'événement. Tout ce que vous n'avez pas reçu avant ne sera donc pas récupéré.

Nous avons un certain nombre de questions auxquelles nous souhaiterions que Flexential apporte une réponse. Toutefois, nous devons également nous attendre à ce que des datacenters entiers puissent connaître une défaillance. Google dispose d'une procédure en ce sens et l'entreprise peut ainsi déclencher un « Code Yellow » (code jaune) ou « Code Red » (code rouge) en cas de crise ou d'incident important. La plupart, voire l'ensemble, de ses ressources techniques sont alors réorientées vers la résolution du problème en cours.

Nous ne disposions pas d'une telle procédure avant l'incident, mais il apparaît clairement aujourd'hui que nous devons mettre en œuvre notre propre version de cette procédure : le Code Orange. Nous réorientons l'ensemble des fonctions techniques non essentielles afin de nous concentrer sur le fait de garantir la fiabilité de notre plan de contrôle. À cet égard, nous comptons mettre en œuvre les changements suivants :

• Éliminer les dépendances résidant sur nos datacenters principaux à des fins de configuration du plan de contrôle pour l'ensemble des services et les faire migrer dès que possible afin qu'elles soient tout d'abord prises en charge par notre réseau distribué.

• Nous assurer que le plan de contrôle exécuté sur le réseau continue à fonctionner, même si tous nos datacenters centraux sont hors ligne.

• Exiger que tous les produits et toutes les fonctionnalités en disponibilité générale se fondent sur le cluster haute disponibilité (s'ils reposent sur n'importe lequel de nos datacenters centraux), sans avoir de dépendances logicielles au sein d'installations spécifiques.

• Exiger que tous les produits et toutes les fonctionnalités en disponibilité générale disposent d'une procédure testée et fiable de reprise après sinistre.

• Tester l'étendue des défaillances système et minimiser le nombre de services affectés par ces défaillances.

• Mettre en place une procédure de chaos testing (ingénierie du chaos) plus rigoureuse de toutes les fonctions des datacenters, y compris la suppression complète de chacun de nos datacenters centraux.

• Mettre en place une procédure d'audit minutieuse de tous nos datacenters centraux, suivie d'un plan d'audit subséquent, afin de garantir leur conformité à nos normes.

• Mettre en place un plan de reprise après sinistre de la journalisation et de l'analyse afin de nous assurer qu'aucun journal ne sera perdu en cas de défaillance de l'ensemble de nos installations centrales.

Comme je l'ai écrit plus haut, je suis navré et embarrassé de cet incident, mais aussi des difficultés que ce dernier a entraînées pour nos clients et notre équipe. Nous disposons des systèmes appropriés et des bonnes procédures en place pour résister même à la chaîne de défaillances en cascade que nous avons pu observer chez notre fournisseur de datacenter, mais nous devons être plus rigoureux sur le fait que ces procédures soient bien suivies et ces systèmes testés à la recherche de dépendances inconnues. Ces points auront ma plus grande attention et l'attention d'une grande partie de notre équipe au cours du reste de l'exercice. Les difficultés traversées ces derniers jours nous auront rendus meilleurs.