Analyse post-mortem de l’interruption du plan de contrôle et du système d’analyse de Cloudflare
(blog.cloudflare.com)- À partir du 2 novembre 2023 à 11:43 UTC, le plan de contrôle et les services d’analyse de Cloudflare ont été interrompus, affectant les modifications via le dashboard/API ainsi que les fonctions de logs et d’analyse
- L’incident a démarré avec une panne électrique de PDX-04 dans l’Oregon, un site exploité par Flexential, qui hébergeait le plus grand cluster d’analyse et plus d’un tiers des équipements du cluster haute disponibilité
- Une succession de défaillances et de rétablissements impliquant l’alimentation utility, les générateurs, l’UPS et les disjoncteurs a révélé des dépendances à Kafka et ClickHouse propres à PDX-04, ce qui a compromis la conception haute disponibilité
- À 13:40 UTC le 2 novembre, Cloudflare a décidé un failover vers son site européen de reprise après sinistre, réduisant l’essentiel de l’impact client à 17:57 UTC, mais le traitement des logs, certaines API bespoke, la configuration manuelle de Magic WAN et les uploads Stream ont été affectés plus longtemps
- Cloudflare lance un Code Orange pour renforcer les exigences de haute disponibilité des produits GA, mettre en place des plans de reprise après sinistre validés, faire du chaos testing incluant la suppression complète de datacenters critiques, et éviter toute perte de logs
Périmètre de l’incident et impact client
- À partir du 2 novembre 2023 à 11:43 UTC, le plan de contrôle et les services d’analyse de Cloudflare ont subi une panne
- Le plan de contrôle désigne les interfaces orientées client, notamment le site web et l’API
- Les services d’analyse comprennent la journalisation et les rapports d’analyse
- L’incident complet a duré du 2 novembre 11:44 UTC au 4 novembre 04:25 UTC
- À 17:57 UTC le 2 novembre, la majeure partie du plan de contrôle a été restaurée depuis l’infrastructure de reprise après sinistre
- Une fois cette infrastructure revenue en ligne, beaucoup de clients n’ont probablement plus rencontré de problème sur la plupart des produits
- Certains services ont pris plus de temps à revenir, et les clients qui les utilisaient ont pu continuer à voir des problèmes jusqu’à la résolution complète
- Le service de logs bruts n’a pas été disponible pour la plupart des clients pendant la majeure partie de l’incident
- Les services réseau et de sécurité de Cloudflare ont fonctionné comme prévu pendant toute la durée de l’incident
- Il y a toutefois eu une période pendant laquelle les clients ne pouvaient pas modifier ces services
- Le trafic transitant par le réseau Cloudflare n’a pas été affecté
Conception initiale : haute disponibilité sur 3 datacenters en Oregon
- Le plan de contrôle et les systèmes d’analyse de Cloudflare fonctionnent principalement sur des serveurs répartis dans 3 datacenters autour de Hillsboro, dans l’Oregon
- Ces 3 datacenters sont indépendants les uns des autres et disposent chacun de plusieurs arrivées d’alimentation utility ainsi que de multiples connexions réseau redondantes et indépendantes
- Les sites ont été choisis pour être suffisamment éloignés afin qu’une catastrophe naturelle ne les affecte pas simultanément, tout en restant assez proches pour faire fonctionner des clusters de données redondants en active-active
- Les trois sites synchronisent en continu leurs données
- Par conception, si un site devient indisponible, les autres doivent pouvoir continuer à fonctionner
- Cette architecture haute disponibilité a commencé à être déployée il y a 4 ans
- La plupart des systèmes critiques du plan de contrôle ont été migrés vers des clusters haute disponibilité
- Certains services de produits plus récents n’avaient pas encore été intégrés à ces clusters
- Le système de logs n’avait délibérément pas été intégré au cluster haute disponibilité
- Les logs sont traités comme un problème distribué : ils s’accumulent dans des files d’attente à l’edge puis sont envoyés vers le core de l’Oregon ou vers des installations régionales de logging
- Si une installation de logging est hors ligne, les logs d’analyse restent en attente à l’edge et ce délai était considéré comme acceptable
Début de la panne électrique à PDX-04
- Le plus grand des 3 sites de l’Oregon est PDX-04, exploité par Flexential
- Cloudflare y héberge son plus grand cluster d’analyse
- Plus d’un tiers des équipements du cluster haute disponibilité s’y trouvent également
- C’est aussi l’emplacement par défaut des services non encore onboardés sur le cluster haute disponibilité
- Cloudflare est un client relativement important sur ce site, utilisant environ 10 % de sa capacité totale
- Le 2 novembre à 08:50 UTC, un événement de maintenance non planifié a affecté l’une des arrivées électriques indépendantes de Portland General Electric (PGE) alimentant PDX-04
- Cet événement a interrompu l’une des arrivées vers PDX-04
- Flexential a démarré des générateurs pour compenser cette interruption
- Flexential n’a pas informé Cloudflare du passage sur alimentation par générateur
- Les outils d’observabilité de Cloudflare n’ont pas détecté ce changement de source électrique
- Avec une notification préalable, Cloudflare aurait pu surveiller le site de près et déplacer ailleurs les services du plan de contrôle qui en dépendaient
- Le fait que Flexential ait exploité en même temps l’arrivée utility restante et les générateurs était également inhabituel
- Flexential exploite 10 générateurs, redondance comprise, capables de supporter la charge complète du site
- Le site pouvait aussi fonctionner uniquement avec l’arrivée utility restante
- Cloudflare n’a pas obtenu d’explication claire sur la raison pour laquelle Flexential faisait fonctionner simultanément l’alimentation utility et celle des générateurs
Causes non confirmées et arrêt des générateurs
- La cause profonde des événements qui ont suivi, ainsi que certaines décisions prises, n’ont pas été clairement confirmées par Flexential
- Parmi les explications possibles figure la participation éventuelle de Flexential au programme DSG de PGE
- Le DSG est un programme permettant à l’énergéticien local d’utiliser les générateurs des datacenters pour fournir de l’électricité supplémentaire au réseau
- En échange, l’énergéticien prend en charge la maintenance des générateurs et l’approvisionnement en carburant
- Cloudflare n’a trouvé aucune trace indiquant que Flexential avait signalé sa participation au programme DSG
- Cloudflare n’a pas non plus obtenu de réponse sur le fait de savoir si le DSG était activé au moment de l’incident
- Vers 11:40 UTC, un ground fault s’est produit sur un transformateur PGE de PDX-04
- Cloudflare pense qu’il s’agissait probablement du transformateur qui abaissait la tension de la seconde arrivée vers le datacenter, sans avoir pu en obtenir confirmation
- Il n’a pas non plus été confirmé que ce ground fault provenait de la maintenance non planifiée de PGE ayant affecté la première arrivée
- Les ground faults sur des lignes haute tension de 12 470 V sont conçus pour entraîner une coupure rapide du système électrique afin d’éviter les dommages
- Cette mesure de protection a également arrêté tous les générateurs de PDX-04
- En conséquence, la ligne utility et les 10 générateurs se sont tous retrouvés hors ligne
- PDX-04 disposait d’une batterie UPS censée maintenir le site pendant environ 10 minutes
- Ce délai devait couvrir l’intervalle entre la panne électrique et le redémarrage automatique des générateurs
- D’après les observations de Cloudflare sur les pannes de ses équipements, les batteries ont commencé à défaillir au bout de 4 minutes seulement
- Flexential a mis bien plus de 10 minutes à remettre les générateurs en service
Retard dans le rétablissement électrique et première notification
- Sans avoir reçu de confirmation officielle, Cloudflare a entendu de la part du personnel de Flexential trois facteurs ayant empêché le rétablissement rapide des générateurs
- À cause de la manière dont les circuits avaient disjoncté après le ground fault, il a fallu accéder physiquement aux générateurs pour les redémarrer manuellement
- Le système de contrôle d’accès de Flexential n’était pas alimenté par batterie de secours et était donc hors ligne
- L’équipe de nuit ne comptait ni opérateur expérimenté ni spécialiste électrique ; il n’y avait que des agents de sécurité et un technicien non accompagné en poste depuis une semaine
- Entre 11:44 et 12:01 UTC, alors que les générateurs n’avaient pas encore été complètement relancés, les batteries UPS se sont vidées et tous les clients du datacenter ont perdu l’alimentation
- Flexential n’a pas informé Cloudflare du problème sur le site pendant cette phase
- Cloudflare a pris connaissance du problème du datacenter pour la première fois à 11:44 UTC, lorsque deux routeurs reliant le site à l’extérieur sont passés hors ligne
- Faute de pouvoir accéder aux routeurs directement ou via une gestion out-of-band, Cloudflare a contacté Flexential et envoyé une équipe sur place
- Le premier message d’incident envoyé par Flexential à Cloudflare est arrivé à 12:28 UTC
- Il indiquait qu’un problème électrique à PDX-04 avait commencé vers 12:00 UTC, que des ingénieurs travaillaient à la restauration et qu’un point d’avancement serait communiqué toutes les 30 minutes
Problèmes de dépendances révélés par l’architecture haute disponibilité
- PDX-04 avait reçu une certification de conception Tier III avant sa construction et devait fournir un SLA de haute disponibilité, mais Cloudflare avait malgré tout prévu l’éventualité d’une indisponibilité complète du site
- Les impacts attendus étaient une interruption de l’analyse, une mise en file des logs à l’edge avec délai, et une indisponibilité temporaire des services de moindre priorité non intégrés au cluster haute disponibilité
- Le comportement attendu des deux autres datacenters, qui devaient prendre le relais du cluster haute disponibilité pour maintenir les services critiques en ligne, a globalement fonctionné comme prévu
- Le problème est venu du fait que certains services censés faire partie du cluster haute disponibilité dépendaient de services exécutés uniquement à PDX-04
- Kafka et ClickHouse, chargés du traitement des logs et de l’analyse, n’étaient fournis qu’à PDX-04
- Certains services exécutés dans le cluster haute disponibilité dépendaient d’eux
- Cette dépendance aurait dû être plus lâche, mieux échouer de manière dégradée, et être détectée en amont
- Cloudflare avait déjà testé le cluster haute disponibilité en mettant complètement hors ligne chacun des deux autres sites, puis les deux ensemble
- Des tests avaient aussi été menés en mettant hors ligne la partie haute disponibilité de PDX-04
- En revanche, aucun test n’avait consisté à mettre complètement hors ligne l’intégralité du site PDX-04
- Les critères imposant l’intégration des nouveaux produits et de leurs bases de données associées au cluster haute disponibilité étaient également trop permissifs
- Les équipes produit suivaient des chemins différents pour atteindre l’étape alpha
- L’idée était de migrer les backends vers les bonnes pratiques avec le temps, mais cela n’était pas exigé formellement avant la déclaration GA
- Résultat : la protection par redondance ne fonctionnait pas de manière cohérente selon les produits
Basculement vers le site de reprise après sinistre
- À 12:48 UTC, Flexential a redémarré les générateurs et une partie du site a retrouvé l’alimentation
- La remise sous tension d’un datacenter se fait généralement circuit par circuit
- Au moment où Flexential a tenté de rallumer les circuits de Cloudflare, il a été constaté que des disjoncteurs étaient défectueux
- Impossible de savoir si ces disjoncteurs avaient été endommagés par le ground fault ou une surtension, ou s’ils étaient déjà défaillants auparavant
- Flexential a commencé à remplacer les disjoncteurs défectueux
- Davantage de disjoncteurs étaient en panne que le nombre d’unités disponibles sur site, ce qui a nécessité un nouvel approvisionnement
- Constatant qu’un plus grand nombre de services que prévu étaient hors ligne et que Flexential ne pouvait pas donner de délai de rétablissement, Cloudflare a décidé à 13:40 UTC de faire un failover vers son site européen de reprise après sinistre
- Seule une petite partie du plan de contrôle complet devait y être basculée
- La plupart des services continuaient de tourner sur les systèmes haute disponibilité des deux autres datacenters core
- À 13:43 UTC, le premier service a été lancé sur le site de reprise après sinistre
- Ce site a été conçu pour fournir les services critiques du plan de contrôle en cas de sinistre
- Il ne prend toutefois pas en charge certains services de traitement des logs
- Une fois les services relancés, l’afflux d’appels API auparavant en échec a déclenché un problème de thundering herd
- Cloudflare a appliqué des rate limits pour contrôler le volume de requêtes
- Pendant cette période, les clients de la plupart des produits ont pu voir des erreurs intermittentes en effectuant des modifications via le dashboard ou l’API
- À 17:57 UTC, les services migrés vers le site de reprise après sinistre s’étaient stabilisés, ce qui a réduit l’essentiel de l’impact direct pour la plupart des clients
- Certains systèmes, comme Magic WAN, nécessitaient encore une configuration manuelle
- Le traitement des logs et certains services liés à des API bespoke restaient indisponibles jusqu’au rétablissement de PDX-04
Rétablissement plus lent pour certains produits et redémarrage de PDX-04
- Certains produits n’ont pas correctement démarré sur le site de reprise après sinistre
- Il s’agissait principalement de produits récents dont les procédures de reprise après sinistre n’avaient pas été complètement implémentées ni testées
- Cela incluait le service Stream pour les nouveaux uploads vidéo, ainsi que quelques autres services
- Les équipes Cloudflare ont mené deux chantiers en parallèle
- Réimplémenter ces services sur le site de reprise après sinistre
- Les migrer vers le cluster haute disponibilité
- Flexential a remplacé les disjoncteurs défectueux, restauré les deux arrivées utility, puis confirmé une alimentation stable à 22:48 UTC
- Cloudflare a décidé que, les équipes ayant été mobilisées en urgence toute la journée, la plupart du personnel se reposerait et reprendrait les opérations de retour vers PDX-04 le lendemain matin
- Cette décision a retardé la restauration complète, mais visait à réduire le risque d’erreurs supplémentaires
- La restauration des services sur PDX-04 a commencé dans la matinée du 3 novembre
- Les équipements réseau ont été redémarrés physiquement
- Des milliers de serveurs ont été rallumés et les services ont été restaurés
- Comme plusieurs cycles d’alimentation ont pu se produire pendant l’incident, l’état des services dans le datacenter n’était pas connu
- La procédure de restauration sûre consistait à suivre un bootstrap complet de l’ensemble du site
- Les serveurs de gestion de configuration ont été remis en ligne manuellement, ce qui a pris 3 heures
- Le reste des serveurs a ensuite été reconstruit via le processus de bootstrap
- La reconstruction de chaque serveur prenait entre 10 minutes et 2 heures
- Plusieurs serveurs ont été traités en parallèle, mais certaines restaurations ont dû être séquentielles en raison des dépendances entre services
- Tous les services ont été complètement restaurés le 4 novembre 2023 à 04:25 UTC
- Pour la plupart des clients, aucune perte de données n’est attendue dans la majorité des analyses affichées dans le dashboard et l’API, car les données d’analyse étaient également stockées dans les datacenters core européens
- Certains jeux de données non répliqués vers l’UE présentent cependant des lacunes persistantes
- Pour les clients utilisant Logpush, les logs n’ont pas été traités pendant la majeure partie de l’incident et les logs non livrés n’ont pas pu être récupérés
Code Orange et plan d’amélioration
- Cloudflare estime avoir encore beaucoup de questions à poser à Flexential, mais considère aussi qu’une panne complète de datacenter doit être anticipée
- À l’image des Code Yellow et Code Red de Google, l’entreprise a lancé un Code Orange, son propre processus interne visant à concentrer les ressources d’ingénierie sur la résolution d’incidents graves ou de situations de crise
- Les fonctions d’ingénierie non essentielles ont été réaffectées aux travaux visant à garantir une haute fiabilité du plan de contrôle
- Les changements prévus sont les suivants
- Supprimer, de la configuration du plan de contrôle de tous les services, les dépendances aux datacenters core et, lorsque c’est possible, les migrer pour qu’ils fonctionnent d’abord sur le réseau distribué de Cloudflare
- Garantir que le plan de contrôle exécuté sur le réseau continue de fonctionner même si tous les datacenters core sont hors ligne
- Exiger que les produits et fonctionnalités GA dépendant des datacenters core reposent sur le cluster haute disponibilité, sans dépendance logicielle à un site spécifique
- Exiger que les produits et fonctionnalités GA disposent de plans de reprise après sinistre fiables et testés
- Tester le blast radius des pannes système et minimiser le nombre de services affectés par un incident
- Mettre en œuvre un chaos testing plus strict sur toutes les fonctions des datacenters, y compris la suppression complète de chaque site core
- Auditer en profondeur tous les datacenters core et définir un plan de ré-audit pour garantir le respect des standards
- Élaborer des plans de reprise après sinistre pour la journalisation et l’analyse afin d’éviter toute perte de logs, même en cas de panne de tous les sites core
- Cloudflare conclut qu’au-delà de l’existence des systèmes et procédures nécessaires, l’entreprise a manqué de rigueur pour les faire respecter et pour imposer des tests capables de révéler les dépendances inconnues
1 commentaires
Commentaires sur Hacker News
C’est un choix étrange d’avoir consacré l’essentiel du texte à rejeter la faute sur un fournisseur nommé explicitement et à spéculer sur la cause profonde
Le fait de révéler qu’il s’agit d’un gros client du site, et même d’inclure dans le post-mortem des schémas électriques marqués Confidential par le fournisseur, semble aussi assez inapproprié
Expliquer l’élément déclencheur et le contexte se comprend, mais le post-mortem devrait porter avant tout sur la panne de Cloudflare, pas sur le fournisseur
Flexential devrait sans doute faire son propre post-mortem, mais Cloudflare n’a pas besoin de spéculer publiquement à sa place
Cela peut aussi viser à permettre à Cloudflare de donner sa version en amont, avant que quelqu’un d’autre n’impose son récit
Dans une situation impliquant trois parties et plusieurs systèmes interconnectés, il est raisonnable que Cloudflare veuille savoir jusqu’au bout ce qui s’est passé afin d’intégrer à l’avenir ce type de mode de défaillance composite dans sa conception
Personnellement, je suis reconnaissant des informations partagées par Cloudflare
99 % de la responsabilité incombe à Cloudflare, qui n’a pas assuré sa mission essentielle
Le fait d’enquêter aussi profondément sur un tiers montre surtout à quel point cet épisode est embarrassant pour Cloudflare
Ils semblent aussi ne pas avoir correctement inspecté les disjoncteurs, et, pour une installation relativement récente, ils n’ont même pas assuré la moitié des 10 heures nécessaires pour recharger les batteries des générateurs
Pendant cette maintenance, ils auraient dû basculer entièrement sur les générateurs, et il est probable qu’ils ne l’aient pas fait pour aider PGE
Je pense que le CEO de Cloudflare a raison. On paie un service de datacenter en s’attendant à une redondance complète, et s’il y a 18 MW sur ce site, on ne sait même pas clairement, d’après ce qu’on voit, s’il n’y a que deux alimentations
Si l’une d’elles tombe, une configuration 2N devrait prendre le relais, et avec des générateurs cela ne devrait pas être un problème
Dans ce cas, il est normal qu’il contienne une description initiale des événements établis jusqu’ici
Il est très probable qu’une analyse de suivi soit publiée
https://twitter.com/eastdakota/status/1720688383607861442?t=...
D’après les passages cités, la cause fondamentale de la panne était une dépendance à un seul datacenter
La plupart des systèmes critiques du control plane ont été migrés vers des clusters haute disponibilité, mais certains nouveaux produits ne l’étaient pas encore ; certains services qui auraient dû se trouver dans des clusters haute disponibilité dépendaient de services ne tournant que sur PDX-04 ; et certains produits n’avaient pas été correctement déployés sur le site de reprise après sinistre
C’est assez honteux pour une entreprise comme Cloudflare, qui soutient une partie importante d’Internet
Cloudflare explique avoir laissé plusieurs équipes innover rapidement, avec des chemins différents pour les produits jusqu’aux premiers stades alpha, en prévoyant ensuite une migration vers les bonnes pratiques avec le temps, sans en faire une exigence préalable à la disponibilité générale
C’est un échec complet de management. En clair, Cloudflare a vendu à ses clients un logiciel d’une qualité que ses propres standards internes auraient considérée comme alpha, non ?
https://news.ycombinator.com/item?id=38113503
Cela montre un certain manque de recul
C’est d’un amateurisme inquiétant, surtout le fait que de nouveaux services aient été lancés sans haute disponibilité
Ayant été légèrement affecté par cette panne, je trouve ce post-mortem insuffisant
75 % du texte porte sur la panne électrique de PDX-04 et sur la responsabilité de Flexential ; à lire le texte, ce qui s’est passé sur place ressemblait presque à une catastrophe, donc c’est compréhensible
Mais il est indiqué qu’au 2 novembre en UTC l’alimentation était entièrement rétablie, et qu’il a pourtant fallu à Cloudflare environ 30 heures supplémentaires pour restaurer complètement les services
La remise en service a duré plus longtemps que la panne elle-même, mais le billet dit seulement que trop de services dépendaient les uns des autres. J’aimerais en savoir davantage sur les raisons pour lesquelles le rétablissement complet des opérations a pris autant de temps
N’y a-t-il pas eu d’enseignements tirés du processus de reprise lui-même ? Ou est-ce que cela a vraiment pris tout ce temps uniquement pour resynchroniser les données depuis l’edge vers le « cerveau » ?
Autre point manquant : le manque de communication avec les clients enterprise. En dehors de la page de statut, le support Cloudflare est resté pratiquement silencieux ; même s’il n’y avait pas grand-chose de concret à faire, il aurait quand même fallu tenter de communiquer
C’est d’autant plus vrai après avoir reproché à Flexential son manque de communication ; j’aime les produits Cloudflare, mais je pense qu’il faut tirer davantage de conclusions de cet incident
En revanche, appeler cela un post-mortem n’est peut-être pas tout à fait juste. Un post-mortem complet devrait avoir le niveau de détail évoqué plus haut
Si la journalisation tombe, quels services échouent exactement ? Était-ce devenu ainsi sans le vouloir ? Pourquoi personne ne s’en est aperçu ?
J’apprécie le sérieux de l’analyse post-mortem de Cloudflare
Franchement, une explication honnête et transparente, c’est rafraîchissant par rapport à la stratégie de communication floue de presque toutes les autres entreprises
Nous avons aussi été touchés, mais ce genre de billet me donne au contraire moins envie de partir. Tout le monde peut faire des erreurs et avoir de mauvaises journées ; ce qui fait la différence, c’est la manière dont on réagit ensuite
La panne électrique tenait en un paragraphe ; ensuite, il aurait fallu se concentrer sur Cloudflare. Des incidents de datacenter, ça peut arriver
La vraie leçon à tirer porte sur la réponse de Cloudflare, qui n’a pas su correctement anticiper la situation ni rétablir le service
Nous dépendons fortement de CloudFlare Images, qui a été indisponible plus de 67 heures au cours des 30 derniers jours
22 heures le 9 octobre, 42 heures du 2 au 4 novembre, plus quelques pannes d’environ une heure entre les deux, ce qui donne une disponibilité de 90,6 % sur le dernier mois
La transparence est un excellent facteur de différenciation entre des fournisseurs qui se battent dans la zone des 99,9 % de disponibilité, mais elle perd beaucoup de son intérêt quand on dépasse à peine un seul 9
Ça n’aide pas beaucoup à améliorer les comportements et ça peut même détériorer les incitations
J’apprécie qu’ils veuillent corriger l’erreur de processus ici. Cela dit, il y a toujours une tension entre aller vite et faire les choses de manière sûre
En général, ce genre de sujet est géré comme la météo : on achète un imperméable après avoir pris la pluie
Je me demande comment faire de la fiabilité une partie de la culture sans que le développement se retrouve paralysé par les processus
On pourrait modéliser les systèmes en software, puis valider ces modèles via l’analyse du trafic. Si des expériences virtuelles permettent de réduire le coût des expérimentations de fiabilité, on pourrait peut-être détecter davantage de problèmes avant la mise en production
Ce qui est étrange, c’est que la lecture de ce billet m’a au contraire fait moins confiance à Cloudflare
Ils s’en prennent durement à Flexential en disant qu’ils ont agi de manière non professionnelle, et c’est possible
Mais le fait que tout le système dont les gens dépendent soit tombé en panne révèle surtout un énorme échec de redondance côté Cloudflare. On devrait pouvoir perdre un datacenter de ce type sans interrompre le service
Ce qui est particulièrement inquiétant, c’est que l’architecture prévue commence par : « Le plan de contrôle et les systèmes d’analyse de Cloudflare fonctionnent principalement sur des serveurs répartis dans trois datacenters près de Hillsboro, dans l’Oregon »
Pour un plan de contrôle utilisé à l’échelle mondiale, il faudrait une dispersion géographique bien plus large. Le plus surprenant, c’est que ce n’était pas un défaut d’implémentation, mais bien un choix de conception
Si l’on met de nouveaux produits sur le marché, la redondance ne devrait-elle pas être la priorité absolue de la conception ? Le simple fait que ce soit resté optionnel est étonnant
J’utilise aussi Cloudflare pour certains systèmes, justement parce que je pensais qu’en cas d’incident de ce type, ils disposeraient d’un excellent basculement
Ça me pousse maintenant à reconsidérer si Cloudflare Workers est réellement à l’abri de ce genre de décisions d’architecture
Le fait qu’une vague d’appels API en échec ait submergé le service au moment de l’activation du site de reprise après sinistre montre aussi, à mes yeux, que l’architecture centrale de Cloudflare n’était tout simplement pas assez redondante
Je suis déçu par cette tentative de rejeter la faute sur Flexential. Du point de vue du client, même si Flexential disparaissait demain dans un tremblement de terre, on s’attend à ce que Cloudflare gère cela proprement
Est-ce vraiment une bonne idée de placer tout un cluster aussi critique dans une zone connue à risque sismique et tsunami ?
On dirait aussi que la reprise après sinistre européenne n’a pas fonctionné correctement
Le passage disant qu’ils « n’avaient jamais testé le basculement complet hors ligne de l’ensemble du site PDX-04 » est une leçon douloureuse
Mais tant qu’on n’a pas physiquement coupé l’alimentation du datacenter, ou au minimum rompu sa connectivité réseau avec le monde extérieur, on n’a pas vraiment testé un désastre réel
On peut reprocher beaucoup de choses à l’exploitant du site, mais au final il faut pouvoir se rétablir même si un datacenter entier passe complètement hors ligne et ne revient jamais
Une catastrophe naturelle pourrait tout simplement effacer ce site de la surface de la Terre
J’ai trouvé bon le passage disant que « l’équipe a été pleinement mobilisée dans la réponse d’urgence toute la journée, et qu’il a donc été décidé que la plupart des personnes se reposeraient et que le retour vers PDX-04 commencerait le matin. Cette décision a retardé la restauration complète, mais nous pensons qu’elle a réduit le risque d’ajouter d’autres erreurs »
Dans ce genre de rapport, la fatigue humaine est souvent sous-estimée. Essayer de résoudre un incident majeur dans un état d’épuisement avancé ne fait qu’augmenter le risque d’erreurs évitables
Je ne sais pas comment cela fonctionne dans une organisation de la taille de Cloudflare, mais chez nous aussi, en cas d’incident majeur, nous avons un plan pour faire tourner les équipes et les laisser dormir
Le problème, c’est qu’il faut un moyen de transmettre l’état actuel de l’incident aux nouvelles personnes qui se réveillent ou se connectent
Comme le disait Mike Tyson, tout le monde a un plan jusqu’à ce qu’il reçoive un coup au visage
La structure du billet est assez surprenante. 75 % du blog parlent d’un tiers, puis les propres efforts de restauration de Cloudflare sont traités en bien moins de paragraphes
C’est positif qu’ils aient proposé une trajectoire pour la suite, mais je me demande pourquoi ils n’ont pas simplement reconnu l’échec et les faits pour l’instant, puis publié plus tard une analyse post-mortem complète, sans spéculation, une fois la poussière retombée
Les investisseurs peuvent lire ce billet, ou seulement son résumé, et y voir un simple problème fournisseur plutôt qu’un problème profond qui nécessitera des mois de reprise du travail et des millions de dollars
Le document n’est pas bon
Il y avait une configuration haute disponibilité répartie sur trois datacenters, et elle a totalement échoué
Pourquoi remplir le début du document d’accusations contre l’exploitant du datacenter ? La gestion des installations d’un datacenter échappe au contrôle de Cloudflare
Cloudflare a parié sur le fait qu’il n’y aurait pas de problème, sans tester correctement la configuration de haute disponibilité qu’ils contrôlent pourtant eux-mêmes
Les problèmes d’exploitation du datacenter doivent être discutés avec l’exploitant, mais cela relève de la relation entre les deux parties et n’a pas sa place dans cette analyse post-mortem
Le passage important est vraiment enterré très profondément. Il faut scroller un bon moment avant de tomber sur cette phrase
« Certains services qui auraient dû se trouver dans un cluster haute disponibilité dépendaient de services exécutés uniquement sur PDX-04 »
C’est exactement ça, le point essentiel.
Si on met en place un site « sinistre », il faut bien trouver un moyen de le tester.
Une fois le service relancé, un problème de troupeau tonitruant s’est produit, avec un afflux d’appels API qui échouaient jusque-là, et ils disent avoir mis en place du rate limiting pour contrôler le volume de requêtes.
Pourtant, ce point semble absent des éléments listés à la fin de l’article.
Ce qui m’intéresse maintenant, c’est comment concevoir un basculement à froid quand le système est assez complexe pour provoquer des pannes métastables[1] et qu’on n’a pas la marge nécessaire pour le tester avec du trafic réel.
On peut imaginer les techniques à utiliser pour l’implémentation, mais le vrai problème, c’est la conception et les tests permettant de vérifier que ces techniques fonctionneront dans une situation réelle.
Un autre point qui semble complètement absent, c’est que l’incident a commencé le 2 novembre à 11:43 UTC, mais la décision de basculer vers le site européen de reprise après sinistre n’a été prise qu’à 13:40 UTC.
Pourquoi la décision a-t-elle pris autant de temps ? Je comprends que ce ne soit pas une décision qu’on prend à la légère, mais même en supposant qu’on ait espéré pendant la majeure partie du temps un rétablissement rapide de l’alimentation, deux heures donnent quand même l’impression d’une hésitation excessive.
Quels que soient les engagements pris, il devrait y avoir un seuil prédéfini à partir duquel on actionne le basculement. Ce seuil était-il vraiment placé aussi loin ?
[1] http://charap.co/metastable-failures-in-distributed-systems/
Et ce qui provoque la défaillance, c’est souvent le système redondant lui-même.