Le 18 novembre, Cloudflare a connu une panne majeure, un incident assez important - des produits tels que CDN, services de sécurité, Workers KV, Turnstile, Access, tous ont échoué. Ils ont déclaré que c'était la plus grosse panne depuis 2019.
Au début, l'équipe pensait avoir été victime d'un DDoS, mais après une longue enquête, ils ont découvert que c'était un problème interne : ils avaient modifié les permissions de la base de données, ce qui a engendré un bug dans le fichier de configuration généré, mettant à mal le système d'agent central. Finalement, ils ont dû revenir à l'ancienne configuration pour sauver la situation, et tout a été complètement rétabli à 1h06 du matin, heure de Pékin, le 19.
Le rapport de rétrospective du blog officiel est plutôt sincère, admettant directement que c'est “inacceptable” et disant qu'ils doivent accélérer la transformation de la résilience du système. Pour nous qui utilisons leurs services pour exécuter des projets, ce niveau de défaillance des infrastructures doit vraiment nous faire réfléchir - même le meilleur des fournisseurs peut faire naufrage en raison d'une erreur de manipulation interne, il est donc nécessaire de préparer à l'avance le déploiement multi-cloud et les plans d'urgence.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Retour sur la plus grave panne de l'histoire de Cloudflare : ce n'est pas une attaque, mais une erreur de configuration.
Le 18 novembre, Cloudflare a connu une panne majeure, un incident assez important - des produits tels que CDN, services de sécurité, Workers KV, Turnstile, Access, tous ont échoué. Ils ont déclaré que c'était la plus grosse panne depuis 2019.
Au début, l'équipe pensait avoir été victime d'un DDoS, mais après une longue enquête, ils ont découvert que c'était un problème interne : ils avaient modifié les permissions de la base de données, ce qui a engendré un bug dans le fichier de configuration généré, mettant à mal le système d'agent central. Finalement, ils ont dû revenir à l'ancienne configuration pour sauver la situation, et tout a été complètement rétabli à 1h06 du matin, heure de Pékin, le 19.
Le rapport de rétrospective du blog officiel est plutôt sincère, admettant directement que c'est “inacceptable” et disant qu'ils doivent accélérer la transformation de la résilience du système. Pour nous qui utilisons leurs services pour exécuter des projets, ce niveau de défaillance des infrastructures doit vraiment nous faire réfléchir - même le meilleur des fournisseurs peut faire naufrage en raison d'une erreur de manipulation interne, il est donc nécessaire de préparer à l'avance le déploiement multi-cloud et les plans d'urgence.