Pourquoi la mesure d'un seul lecteur a conduit à la suppression de fichiers nécessaires aux tests

Le 31 octobre 2026, un développeur travaillant sur un système de collecte de contenu a déplacé 34 557 fichiers HTML en quarantaine après avoir déterminé qu'un processus de lecture spécifique n'y accédait jamais. Le tour de collecte immédiat s'est terminé avec succès, mais une comparaison ultérieure avec une base de référence de test scellée a révélé 310 nouveaux échecs. Les fichiers ont été restaurés le jour même, évitant ainsi une perte de données permanente, mais l'incident a exposé des lacunes significatives dans la manière dont le système suivait l'utilisation des fichiers entre différents composants.

Ce qui s'est passé

Le répertoire de rapports du système avait atteint 132,8 GiB sans déclencher d'alerte, car des tâches exécutées toutes les 15 minutes créaient de nouveaux dossiers sans nettoyage. Une première passe d'élagage basée sur les références a réduit la taille à 115,1 GiB en supprimant les unités non référencées et en compactant une base de données SQLite, mais la plupart des données restantes étaient encore référencées par l'état de la collecte. Pour traiter le volume restant, le développeur a mesuré quels fichiers un validateur d'état de collecte ouvrait lors d'une exécution entre 16h50 et 17h40 (heure KST). Sur 46 643 fichiers HTML collectés totalisant 52,4 GiB, le validateur n'a ouvert que 1 920 fichiers. Les 34 557 fichiers restants, principalement des entrées historiques pour des vidéos re-téléchargées, ont été jugés inutiles et déplacés en quarantaine.

Cependant, lorsque la suite de tests complète a été exécutée, elle a produit 310 échecs au-delà de la base de référence existante. Ces erreurs incluaient des exceptions ValueError concernant des corps de pages YouTube indisponibles et des problèmes FileNotFoundError pour des fichiers HTML manquants. Les échecs se sont produits parce que d'autres processus, tels que la relecture de publication et le jugement des arriérés, nécessitaient toujours l'accès à ces corps de capture bruts. Le développeur avait supposé à tort que, puisque un lecteur n'ouvrait pas les fichiers, aucune partie du système n'en avait besoin. La stratégie de quarantaine a permis une récupération rapide en renommant les fichiers, restaurant le système dans un état passant avec zéro fichier manquant.

Détails clés

• Erreur de mesure initiale : Le développeur a mesuré l'accès aux fichiers pour un seul lecteur (le validateur d'état de collecte), ignorant d'autres composants comme les relectures de la file d'attente de publication.
• Échelle de l'impact : 34 557 fichiers HTML totalisant 37,8 GiB ont été déplacés en quarantaine sur la base de données incomplètes.
• Échec de la suite de tests : L'exécution de la suite de tests complète a révélé 310 nouveaux échecs, principalement dus à des fichiers HTML bruts manquants nécessaires pour la relecture et le suivi de provenance.
• Méthode de récupération : Les fichiers ont été déplacés plutôt que supprimés, permettant une restauration via renommage sans nécessiter de nouvelle collecte depuis des sources externes.
• Pièges de l'enregistreur : L'enregistreur d'accès aux fichiers a manqué des lectures en raison de discordances de chemins relatifs dans les hooks d'audit Python 3.13.0 et a perdu des enregistrements lorsque le processus principal pytest s'est terminé via os._exit(1).
• Statut actuel : Au 4 novembre 2026, le seuil de stockage est rouge car trois des quatre exécutions nocturnes se sont terminées dans un état restored, empêchant l'exécution de l'étape finale de suppression.

Contexte

Dans les systèmes logiciels complexes, en particulier ceux traitant de grands volumes de données comme les pipelines de contenu, comprendre quels fichiers sont activement utilisés est crucial pour la maintenance. Un « lecteur » dans ce contexte fait référence à tout processus ou composant qui ouvre et traite des fichiers de données. Les développeurs utilisent souvent des outils de surveillance ou des hooks d'audit pour suivre l'accès aux fichiers, créant un « ensemble de lecture » des fichiers ouverts lors d'une opération spécifique. Le complément de cet ensemble—les fichiers qui n'ont pas été ouverts—est parfois considéré comme sûr pour la suppression. Cependant, cette hypothèse est dangereuse si la surveillance ne couvre pas tous les lecteurs possibles, y compris les tâches en arrière-plan, les suites de tests ou les gestionnaires de cas limites rares.

La mise en quarantaine est une pratique de sécurité où les fichiers sont déplacés vers un emplacement séparé plutôt que d'être définitivement supprimés. Cela permet aux équipes de vérifier que le système fonctionne correctement sans les données avant de s'engager dans une suppression irréversible. Si des problèmes surviennent, les fichiers peuvent être déplacés rapidement à leur emplacement original. Cette approche contraste avec la suppression directe, qui nécessiterait une récupération coûteuse et longue de données depuis des sources externes si la décision s'avère incorrecte.

Pourquoi c'est important

Pour les équipes exécutant des logiciels auto-hébergés ou gérant des pipelines de données internes, cet incident illustre la complexité cachée de la gestion du cycle de vie des données. Il est facile de supposer que l'analyse statique ou une surveillance limitée à l'exécution fournit une image complète des dépendances de données. En réalité, les systèmes ont souvent des dépendances latentes où les données ne sont accédées que lors d'événements spécifiques, tels que la récupération d'erreurs, le retraitement historique ou les tests complets. Supprimer des données basées sur une visibilité partielle peut entraîner des échecs subtils difficiles à diagnostiquer et coûteux à réparer.

La dépendance à une seule métrique—l'ensemble de lecture d'un seul validateur—a créé un faux sentiment de sécurité. Le fait que le tour de collecte immédiat ait réussi après la mise en quarantaine a induit le développeur en erreur, lui faisant croire que le changement était sûr. Ce n'est que la suite de tests plus large, qui simule divers scénarios opérationnels incluant les relectures et les jointures historiques, qui a révélé les dépendances manquantes. Cela souligne l'importance d'utiliser des suites de tests complètes comme outil de validation pour les changements d'infrastructure, et pas seulement pour la logique de code.

De plus, les pièges techniques rencontrés avec l'enregistreur d'accès aux fichiers démontrent que même les outils de surveillance peuvent avoir des angles morts. Des problèmes tels que la résolution de chemins relatifs dans les hooks d'audit ou les comportements de sortie de processus peuvent conduire à sous-compter les accès aux fichiers. Dans les opérations de nettoyage de données, un sous-comptage est particulièrement dangereux car il augmente directement le risque de supprimer des données actives. Les équipes doivent valider leurs outils de surveillance contre des bases de référence connues pour s'assurer qu'ils capturent toute l'activité pertinente.

Ce que vous pouvez faire

• Déplacer avant de supprimer : Déplacez toujours les fichiers candidats vers un répertoire de quarantaine avec un minuteur fixe avant la suppression permanente, garantissant que les erreurs peuvent être annulées à moindre coût.
• Mesurer tous les lecteurs : Calculez les candidats à la suppression contre chaque composant susceptible d'accéder aux données, y compris les tâches en arrière-plan, les mécanismes de relecture et la suite de tests complète.
• Valider les outils de surveillance : Testez vos enregistreurs d'accès aux fichiers contre des lecteurs au comportement connu pour vous assurer qu'ils ne manquent pas de lectures dues à des problèmes de résolution de chemin ou de sortie de processus.
• Exécuter les suites de tests complètes : Après tout mouvement de données, comparez les résultats de la suite de tests complète avec une base de référence scellée pour détecter les dépendances latentes que les tests de fumée immédiats pourraient manquer.
• Implémenter des tripwires : Configurez des tâches qui surveillent les logs pour les tentatives de lecture de fichiers manquants, vous permettant de détecter et de restaurer les données accidentellement supprimées avant qu'elles ne causent des échecs généralisés.
• Exclure la quarantaine des budgets : Lors du calcul de l'utilisation du stockage, excluez les octets en quarantaine du budget principal pour éviter la confusion sur la taille réelle des données actives tout en les gardant disponibles pour la récupération.