Por qué medir un solo lector llevó a eliminar archivos necesarios para las pruebas

El 31 de octubre de 2026, un desarrollador que trabajaba en un sistema de recopilación de contenido movió 34.557 archivos HTML a cuarentena después de determinar que un proceso de lectura específico nunca accedía a ellos. La ronda inmediata de recopilación se completó con éxito, pero una comparación posterior contra una línea base de pruebas sellada reveló 310 nuevos fallos. Los archivos fueron restaurados el mismo día, evitando la pérdida permanente de datos, pero el incidente expuso brechas significativas en cómo el sistema rastreaba el uso de archivos entre diferentes componentes.

Qué ocurrió

El directorio de informes del sistema había crecido hasta 132,8GiB sin activar ninguna alarma, ya que los trabajos que se ejecutaban cada 15 minutos creaban nuevas carpetas sin limpieza. Una primera pasada de poda basada en referencias redujo el tamaño a 115,1GiB al eliminar unidades no referenciadas y compactar una base de datos SQLite, pero la mayoría de los datos restantes seguían siendo referenciados por el estado de la recopilación. Para abordar el volumen restante, el desarrollador midió qué archivos abría un validador de estado de recopilación durante una ejecución de 16:50 a 17:40 KST. De los 46.643 archivos HTML recopilados que sumaban 52,4GiB, el validador solo abrió 1.920 archivos. Los 34.557 archivos restantes, principalmente entradas históricas de videos re-descargados, se consideraron innecesarios y se movieron a cuarentena.

Sin embargo, cuando se ejecutó la suite completa de pruebas, produjo 310 fallos más allá de la línea base existente. Estos errores incluían excepciones ValueError relacionadas con cuerpos de páginas de YouTube no disponibles y problemas de FileNotFoundError por archivos HTML faltantes. Los fallos ocurrieron porque otros procesos, como la reproducción de publicaciones y la evaluación de pendientes, aún requerían acceso a estos cuerpos de captura cruda. El desarrollador había asumido erróneamente que, dado que un lector no abría los archivos, ninguna parte del sistema los necesitaba. La estrategia de cuarentena permitió una recuperación rápida al renombrar los archivos de vuelta, restaurando el sistema a un estado de aprobación con cero archivos faltantes.

Detalles clave

• Error de medición inicial: El desarrollador midió el acceso a archivos para solo un lector (el validador de estado de recopilación), ignorando otros componentes como las reproducciones de cola de publicación.
• Escala del impacto: 34.557 archivos HTML que sumaban 37,8GiB fueron movidos a cuarentena basándose en datos incompletos.
• Fallo de la suite de pruebas: Ejecutar la suite completa de pruebas reveló 310 nuevos fallos, principalmente debido a archivos HTML crudos faltantes necesarios para la reproducción y el seguimiento de procedencia.
• Método de recuperación: Los archivos fueron movidos en lugar de eliminados, permitiendo la restauración mediante renombrado sin requerir una nueva búsqueda en fuentes externas.
• Trampas del grabador: El grabador de acceso a archivos omitió lecturas debido a discrepancias de rutas relativas en los hooks de auditoría de Python 3.13.0 y perdió registros cuando el proceso principal de pytest finalizaba mediante os._exit(1).
• Estado actual: A 4 de noviembre de 2026, la puerta de almacenamiento está en rojo porque tres de cuatro ejecuciones nocturnas terminaron en un estado restored, impidiendo que se ejecutara el paso final de eliminación.

Contexto

En sistemas de software complejos, especialmente aquellos que manejan grandes volúmenes de datos como pipelines de contenido, entender qué archivos están siendo utilizados activamente es crítico para el mantenimiento. Un "lector" en este contexto se refiere a cualquier proceso o componente que abre y procesa archivos de datos. Los desarrolladores suelen utilizar herramientas de monitoreo o hooks de auditoría para rastrear el acceso a archivos, creando un "conjunto de lectura" de archivos que fueron abiertos durante una operación específica. El complemento de este conjunto—archivos que no fueron abiertos—a veces se asume seguro para su eliminación. Sin embargo, esta suposición es peligrosa si el monitoreo no cubre todos los posibles lectores, incluyendo trabajos en segundo plano, suites de pruebas o manejadores de casos límite raros.

La cuarentena es una práctica de seguridad donde los archivos se mueven a una ubicación separada en lugar de ser eliminados permanentemente. Esto permite a los equipos verificar que el sistema funciona correctamente sin los datos antes de comprometerse con una eliminación irreversible. Si surgen problemas, los archivos pueden moverse de vuelta rápidamente. Este enfoque contrasta con la eliminación directa, que requeriría la costosa y lenta re-obtención de datos desde fuentes externas si la decisión resulta incorrecta.

Por qué importa

Para equipos que ejecutan software autoalojado o gestionan pipelines de datos internos, este incidente ilustra la complejidad oculta de la gestión del ciclo de vida de los datos. Es fácil asumir que el análisis estático o el monitoreo limitado en tiempo de ejecución proporciona una imagen completa de las dependencias de datos. En realidad, los sistemas a menudo tienen dependencias latentes donde los datos solo se acceden durante eventos específicos, como la recuperación de errores, el reprocesamiento histórico o pruebas exhaustivas. Eliminar datos basándose en visibilidad parcial puede llevar a fallos sutiles que son difíciles de diagnosticar y costosos de reparar.

La dependencia de una única métrica—el conjunto de lectura de un validador—creó una falsa sensación de seguridad. El hecho de que la ronda inmediata de recopilación pasara después de la cuarentena indujo a error al desarrollador haciéndole pensar que el cambio era seguro. Fue solo la suite de pruebas más amplia, que simula varios escenarios operativos incluyendo reproducciones y uniones históricas, la que reveló las dependencias faltantes. Esto destaca la importancia de usar suites de pruebas comprehensivas como herramienta de validación para cambios de infraestructura, no solo para lógica de código.

Además, las trampas técnicas encontradas con el grabador de acceso a archivos demuestran que incluso las herramientas de monitoreo pueden tener puntos ciegos. Problemas como la resolución de rutas relativas en hooks de auditoría o comportamientos de salida de procesos pueden llevar a subcontar accesos a archivos. En operaciones de limpieza de datos, un subconteo es particularmente peligroso porque aumenta directamente el riesgo de eliminar datos activos. Los equipos deben validar sus herramientas de monitoreo contra líneas bases conocidas para asegurar que están capturando toda la actividad relevante.

Qué puedes hacer

• Mover antes de eliminar: Siempre mueve los archivos candidatos a un directorio de cuarentena con un temporizador fijo antes de la eliminación permanente, asegurando que los errores puedan revertirse de manera económica.
• Medir todos los lectores: Calcula los candidatos a eliminación contra cada componente que podría acceder a los datos, incluyendo trabajos en segundo plano, mecanismos de reproducción y la suite completa de pruebas.
• Validar herramientas de monitoreo: Prueba tus grabadores de acceso a archivos contra lectores con comportamiento conocido para asegurar que no estén omitiendo lecturas debido a problemas de resolución de rutas o salida de procesos.
• Ejecutar suites de pruebas completas: Después de cualquier movimiento de datos, compara los resultados de la suite completa de pruebas contra una línea base sellada para detectar dependencias latentes que las pruebas de humo inmediatas podrían pasar por alto.
• Implementar tripwires: Configura trabajos que monitoreen los logs buscando intentos de leer archivos faltantes, permitiéndote detectar y restaurar datos accidentalmente eliminados antes de que causen fallos generalizados.
• Excluir la cuarentena de los presupuestos: Al calcular el uso de almacenamiento, excluye los bytes en cuarentena del presupuesto principal para evitar confusión sobre el tamaño real de los datos activos mientras se mantienen disponibles para la recuperación.