Résumé

  • Cloudflare indique que le plan de contrôle et les services d'analyse ont été perturbés à partir du 2 novembre 2023, alors que le trafic edge principal continuait [1].
  • Le déclencheur public était une chaîne de panne électrique dans PDX-04, un centre de données en Oregon qui hébergeait des dépendances critiques [1][3].
  • L'incident a exposé des dépendances dans Kafka, ClickHouse, l'identité, les outils internes et les systèmes nécessaires à la reprise [1].
  • Une panne électrique ultérieure dans le même site, en 2024, a testé la préparation « Code Orange » et a eu un effet réduit sur le plan de contrôle [2].
  • La preuve crédible doit couvrir la configuration, l'analyse, l'identité, les outils internes et les actions visibles par les clients pendant la perte complète d'un site.

Ce qui s'est passé

Cloudflare situe le début de l'incident à 11 h 43 UTC le 2 novembre. La société décrit la couche touchée comme le plan de contrôle et les services d'analyse [1]. Cela signifie qu'un client pouvait rencontrer des difficultés à changer une règle, consulter des mesures ou utiliser l'interface d'administration, même si la couche distribuée continuait à servir les requêtes qui ne nécessitaient pas de nouvelle décision.

Le point physique de départ était PDX-04. Cloudflare explique qu'un événement de maintenance non planifié de Portland General Electric a affecté une arrivée électrique indépendante du bâtiment, puis décrit l'épuisement des batteries, les difficultés de redémarrage des générateurs, l'accès au site, le remplacement de disjoncteurs et le redémarrage contrôlé des serveurs [1]. Baxtel relie aussi la perturbation à une panne électrique dans un site Flexential à Hillsboro, en Oregon, et cite la même explication de Cloudflare [3].

Le point opérationnel est plus important que le détail électrique. Un réseau cloud peut continuer à livrer du trafic déjà configuré pendant que la surface qui permet de changer, diagnostiquer ou vérifier le service est dégradée. Cette séparation crée un risque de continuité pour les clients qui ont besoin d'agir précisément pendant une crise.

La dépendance cachée n'était pas un seul serveur

Le postmortem ne décrit pas une machine isolée. Il nomme un ensemble de dépendances : composants du plan de contrôle et de l'analyse, Kafka, ClickHouse, identité et autorisation, outils internes et systèmes de redémarrage [1]. Certaines dépendances étaient connues ; d'autres n'étaient pas visibles avec assez de force avant la perte du site.

C'est une question d'infrastructure réseau. Le plan de contrôle est la surface d'autorité : une modification devient configuration, une alerte devient action, un client comprend si l'état est sain. Si cette surface dépend d'un site unique d'une manière non testée, le risque public n'est pas seulement l'indisponibilité. C'est la perte de visibilité et de capacité de changement.

Le récit distingue aussi ce qui a tenu de ce qui a échoué. Le trafic edge a continué dans de nombreux cas [1]. Ce fait ne rend pas l'incident mineur ; il prouve que la résilience doit être mesurée par couche. Un plan de données sain ne prouve pas qu'un plan de contrôle est récupérable.

La reprise après sinistre doit être du code en fonctionnement

Cloudflare indique avoir eu des plans de reprise, mais l'événement a montré que certains services n'étaient pas prêts pour la perte totale du site et que certaines procédures n'avaient pas été testées dans les bonnes conditions [1]. Un document peut nommer un site de secours ; seuls la réplication, les files, l'identité, les tableaux de bord et les outils internes en fonctionnement prouvent la reprise.

La reprise comporte aussi un problème de demande. Quand les services reviennent, les clients et systèmes internes réessaient en masse. Le postmortem parle d'un effet de troupeau qui peut transformer le redémarrage en deuxième incident si le plan de contrôle ne peut pas absorber l'arriéré [1].

Le rapport 2024 est utile comme comparaison. Cloudflare décrit une nouvelle panne électrique majeure dans le même site, quatre mois plus tard, et dit que l'activation Code Orange et les changements précédents ont réduit l'impact [2]. Ce n'est pas une preuve que tout est résolu ; c'est le bon type de preuve : un événement similaire, une préparation nouvelle et un résultat différent.

La propriété physique reste visible

Les plans de contrôle cloud semblent abstraits, mais l'incident rappelle les dépendances matérielles : alimentations électriques, batteries, générateurs, accès au bâtiment, interventions du site et ordre de redémarrage [1][3]. Ces éléments se trouvent sous l'API, mais ils gouvernent le résultat client.

Une dépendance à un opérateur de centre de données n'est pas une faute en soi. Le point de responsabilité est la preuve : que sait l'opérateur, qui peut activer le plan alternatif, quel service client reste disponible, quelles fonctions sont volontairement dégradées, et quelles traces montrent que le scénario a été testé.

Baxtel ajoute le contexte de l'exploitant du site et cite une réponse de Flexential sur des scénarios liés au réseau électrique [3]. L'article ne doit pas transformer cela en verdict complet sur la cause. Il montre surtout que la chaîne de reprise traversait des frontières organisationnelles.

Surface Heng.lu : continuité opérationnelle

La surface Heng.lu est la continuité d'opérateur et l'identité d'hébergement/réseau. Un annuaire ou une page d'état peut nommer l'opérateur et le site ; cela ne prouve pas que la configuration, l'analyse, l'identité et l'outillage survivent à la perte d'un bâtiment. La couche réelle est la preuve de reprise.

Le test public doit donc éviter le théâtre de blâme. La question est de savoir quelle dépendance était sur le chemin critique, si Cloudflare le savait avant l'incident, et quel exercice prouve désormais qu'elle ne retire plus l'autorité de contrôle.

À surveiller

Le premier signal est la séparation publique entre santé du trafic edge et santé du plan de contrôle. Un statut global vert ne suffit pas si les clients ne peuvent pas modifier ou observer leur configuration.

Le deuxième signal est la répétition du modèle Code Orange : perte complète de site, test de reprise, mesure de l'arriéré, disponibilité de l'identité, succès des actions client et comparaison avec l'incident précédent. La leçon durable est claire : transporter du trafic ne suffit pas. L'opérateur doit encore voir, changer, redémarrer et expliquer le service quand un bâtiment critique tombe.

Sources

  1. https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/
  2. https://blog.cloudflare.com/major-data-center-power-failure-again-cloudflare-code-orange-tested/
  3. https://baxtel.com/news/cloudflare-blames-flexential-dc-outage-for-its-service-disruption