Résumé

  • Le 8 septembre, RIPE NCC a signalé qu'un traitement de partition Kafka avait dépassé son délai au démarrage, face à un volume inhabituel d'enregistrements. Les fichiers RRC24 ont été publiés.
  • Un lien avec l'incident RRC18 est désormais jugé peu probable. Le communiqué ne précise ni la correction appliquée ni la charge de démarrage validée.

Le retour d'un service se juge souvent à ce qu'il produit de nouveau. L'explication publiée pour RRC24 invite à examiner aussi ce qu'il doit absorber avant d'y parvenir. Soutenir un flux régulier et terminer un traitement initial particulièrement chargé ne constituent pas la même preuve de capacité.

Sur sa page d'état, RIPE NCC indique, le 8 septembre à 16 h 01 CEST, que le traitement d'une partition Kafka a rencontré un volume inhabituel d'enregistrements au démarrage, entraînant un dépassement de délai. Les updates et bviews de RRC24 ont été publiés. L'opérateur estime maintenant peu probable un lien avec RRC18 et ne prévoit pas d'autres collecteurs touchés. Il resserre ainsi l'hypothèse du 7 septembre, qui envisageait une cause commune. Cette appréciation ne vaut pas exclusion démontrée de tout autre risque.

L'enjeu porte sur l'accès à une observation du routage. La documentation MRT distingue les instantanés d'état et les fichiers de changements, conservés par collecteur. Elle indique une génération toutes les huit heures pour les premiers et toutes les cinq minutes pour les seconds. Un fichier tardif peut retarder une analyse sans établir que les réseaux observés ont cessé d'acheminer du trafic. Nous n'avons pas contrôlé l'exhaustivité de l'archive rétablie.

RRC24 est décrit dans le répertoire technique des collecteurs comme un collecteur multihop installé à Montevideo, en Uruguay, couvrant la région LACNIC et soutenu par LACNIC. Ses sessions peuvent dépasser le réseau local d'un point d'échange. Cette localisation ne démontre pas que LACNIC serait responsable du traitement défaillant.

La conséquence opérationnelle relève de l'analyse : il faut éprouver le démarrage avec une charge définie, au lieu de lui attribuer les performances constatées en fonctionnement courant. Le communiqué ne fournit ni nombre d'enregistrements, ni délai limite, ni détail d'implémentation. Il n'identifie pas non plus la modification ayant permis le rétablissement. On ne peut en déduire un défaut du produit Kafka, une panne BGP ou une perte de données.

Il serait excessif d'exiger qu'un bref avis d'incident contienne tout un dossier d'ingénierie. L'opérateur a apporté un élément causal concret et révisé son appréciation. Reste une demande proportionnée pour le propriétaire du service : sur quel essai reposera l'assurance qu'un prochain démarrage terminera son travail ?

La distinction entre constat et recommandation suit le principe éditorial de Lu Heng : décrire la réalité plutôt que défendre une cause. Ce texte éclaire notre méthode, pas la mécanique de l'incident.