Il s'agit d'un petit article temporaire, qui sera ensuite suivi d'une analyse complète et d'informations exhaustives sur ce qui s'est passé aujourd'hui.
Aujourd'hui, pendant environ 30 minutes, les visiteurs des sites Cloudflare pourraient voir l'erreur 502 causée par une forte augmentation de la charge CPU de notre réseau. Cela était dû à un échec du déploiement du logiciel. Nous avons annulé les modifications, et maintenant le service fonctionne comme d'habitude, comme auparavant, et tous les domaines utilisant Cloudflare sont revenus à des niveaux de trafic normaux.
Nous vous assurons qu'il n'y a pas eu d'attaque et nous vous présentons nos plus sincères excuses pour ce qui s'est passé. Nos développeurs effectuent déjà une analyse détaillée des erreurs et tentent de comprendre ce qui doit être fait pour éviter de tels incidents à l'avenir.
Publié à 20h09 UTC:
Aujourd'hui à 13:42 UTC, une défaillance a été détectée dans notre réseau, à la suite de laquelle les visiteurs des domaines Cloudflare ont vu l'erreur 502 ("Bad Gateway"). La raison de cet échec était le déploiement d'une règle mal configurée dans le pare-feu d'application Web Cloudflare (WAF) au cours du processus standard de déploiement de nouvelles règles gérées Cloudflare WAF.
Les nouvelles règles ont été conçues pour améliorer le mécanisme de blocage du JavaScript intégré utilisé dans les attaques de pirates. Ces règles ont été déployées en mode simulation, dans lequel les erreurs sont généralement détectées et enregistrées sans bloquer le trafic utilisateur, ce qui nous permet de mesurer le nombre de faux positifs et de nous assurer que les nouvelles règles fonctionneront correctement lorsqu'elles seront déployées dans le cadre de ce projet.
Malheureusement, l'une de ces règles contenait une expression régulière, ce qui a entraîné une augmentation de la charge CPU jusqu'à 100% sur nos ordinateurs partout. C'est à cause de ce saut que les utilisateurs de notre service ont été témoins d'une erreur 502, et le trafic est tombé à 82%.
Le graphique ci-dessous montre le saut de charge CPU sur l'un de nos PoPs:
Pour la première fois, nous avons été confrontés au problème de l'épuisement complet des ressources CPU, ce qui était extrêmement inattendu pour nous.
Nous déployons constamment des logiciels sur notre réseau et avons déjà développé des systèmes automatisés pour l'exécution des tests et une procédure de déploiement par phases afin d'éviter les situations désagréables. Malheureusement, le déploiement mondial des règles WAF était un processus ponctuel, qui a provoqué l'échec d'aujourd'hui.
À 14:02 UTC, nous avons réalisé ce qui s'était passé et avons décidé de désactiver complètement les ensembles de règles WAF, ce qui a immédiatement normalisé la charge du processeur et rétabli le trafic. Nous l'avons fait à 14 h 09 UTC.
Après cela, nous avons analysé la demande d'extraction problématique, annulé les modifications des règles pertinentes, testé nos actions pour être sûr à 100% que l'erreur a été trouvée correctement, puis restauré les ensembles de règles WAF à 14:52.
Nous savons combien de dommages ces incidents causent à nos utilisateurs. Dans ce cas, notre mécanisme de test n'a pas fait face à la tâche, et nous travaillons déjà à son amélioration et à l'optimisation du processus de déploiement afin d'éviter des erreurs similaires à l'avenir.