Résumé

  • Cloudflare a créé l'incident xl112dfsfz6q à 17 h 39 min 20 s UTC le 21 août. L'entreprise a dit enquêter sur des problèmes de performance réseau en Asie-Pacifique, puis a annoncé à 17 h 47 min 56 s qu'un correctif avait été appliqué.
  • Lorsque BTW a relevé la source à 19 h 14 min 34 s UTC, l'avis était toujours en surveillance et non résolu. Son champ d'impact indiquait none, tandis que le composant Network restait opérationnel avant et après les deux mises à jour.

« Asie-Pacifique » situe un domaine de recherche, mais ne mesure pas un impact. Le réseau public de Cloudflare couvre de nombreuses villes d'Asie et d'Océanie. L'avis ne précise pourtant ni centre de données, ni pays, ni réseau d'accès, ni route. Il serait donc incorrect de transformer le nom de la région en affirmation selon laquelle l'ensemble de ses utilisateurs ou de ses sites aurait été touché.

La chronologie publique est plus étroite. Huit minutes et 36 secondes séparent l'ouverture de l'enquête du passage en surveillance. Ce délai mesure la progression du processus de Cloudflare : reconnaissance, analyse, action corrective annoncée. Il ne mesure pas la durée vécue par un client, car l'heure de début des symptômes, leur distribution et le moment de récupération de chaque chemin ne sont pas publiés.

Les métadonnées ne comblent pas ce vide. Les deux mises à jour associent le composant Network avec une transition d'« opérationnel » à « opérationnel ». L'inventaire courant le montre également opérationnel, et l'impact structuré vaut none. En parallèle, le texte dit qu'un problème de performance était en cours d'analyse et d'atténuation, puis qu'un correctif avait été mis en œuvre. Sans métrique, aucun de ces champs ne donne une proportion d'erreurs, une latence ou un volume de trafic affecté.

Le dossier ne nomme pas davantage de produit. CDN, DNS, Workers, Zero Trust ou Magic Transit ne peuvent pas être ajoutés au périmètre par déduction. La nature du symptôme reste tout aussi ouverte : l'avis ne parle ni de pertes de paquets, ni d'échecs de connexion, ni d'erreurs HTTP, ni d'instabilité de routage. Cette retenue évite de faire d'un libellé générique une topologie imaginaire.

Pour un exploitant, le bon dénominateur vient de son propre trafic. La documentation de dépannage de Cloudflare recommande d'identifier le centre de données qui sert une requête grâce au champ colo, de mesurer les phases de la transaction et d'utiliser traceroute ou MTR pour les problèmes de chemin. Origin Analytics distingue en outre la réponse de l'origine de la réponse à la périphérie et expose des percentiles de temps de réponse.

Ces observations permettent de construire des cohortes limitées : tel réseau d'accès vers tel colo, pour tel hôte et telle origine, pendant la fenêtre UTC publiée. Une cohorte de contrôle non affectée est aussi importante que la cohorte suspecte. Sans cette comparaison, une lenteur d'origine peut être attribuée à tort à Cloudflare, ou un retour local à la normale peut être confondu avec la réussite universelle du correctif.

Au moment du gel des faits, la surveillance durait depuis plus de 86 minutes et resolved_at restait nul. Cloudflare avait donc annoncé une action, pas une clôture. La différence est importante : le fournisseur observe son système, tandis que le client doit encore déterminer si les transactions et chemins qui lui importent ont retrouvé leur comportement normal.

Sources