Vì sao đo lường một reader duy nhất dẫn đến việc xóa các file cần thiết cho test

Vào ngày 31 tháng 10 năm 2026, một lập trình viên làm việc trên hệ thống thu thập nội dung đã chuyển 34.557 file HTML vào khu vực cách ly (quarantine) sau khi xác định rằng một quy trình reader cụ thể chưa bao giờ truy cập chúng. Vòng thu thập ngay sau đó hoàn tất thành công, nhưng một phép so sánh tiếp theo với baseline test đã được niêm phong tiết lộ 310 lỗi mới. Các file này đã được khôi phục trong cùng ngày, tránh mất mát dữ liệu vĩnh viễn, nhưng sự cố đã phơi bày những lỗ hổng đáng kể trong cách hệ thống theo dõi việc sử dụng file giữa các thành phần khác nhau.

Chuyện gì đã xảy ra

Thư mục báo cáo của hệ thống đã phình to lên tới 132.8GiB mà không kích hoạt bất kỳ cảnh báo nào, do các job chạy mỗi 15 phút tạo ra các thư mục mới mà không dọn dẹp. Một lần cắt tỉa dựa trên tham chiếu ban đầu đã giảm kích thước xuống còn 115.1GiB bằng cách loại bỏ các đơn vị không được tham chiếu và nén cơ sở dữ liệu SQLite, nhưng hầu hết dữ liệu còn lại vẫn được tham chiếu bởi trạng thái thu thập. Để xử lý khối lượng dữ liệu còn lại, lập trình viên đã đo lường xem những file nào được mở bởi một validator trạng thái thu thập trong quá trình chạy từ 16:50 đến 17:40 KST. Trong số 46.643 file HTML đã thu thập với tổng dung lượng 52.4GiB, validator chỉ mở 1.920 file. 34.557 file còn lại, chủ yếu là các mục lịch sử cho các video được fetch lại, bị coi là không cần thiết và được chuyển vào khu vực cách ly.

Tuy nhiên, khi bộ test đầy đủ được thực thi, nó tạo ra 310 lỗi vượt quá baseline hiện có. Những lỗi này bao gồm các exception ValueError liên quan đến body trang YouTube không khả dụng và các vấn đề FileNotFoundError do thiếu file HTML. Các lỗi này xảy ra vì những quy trình khác, chẳng hạn như replay bản publish và đánh giá backlog, vẫn cần truy cập vào các body capture thô này. Lập trình viên đã nhầm lẫn khi giả định rằng vì một reader không mở các file, nên không phần nào của hệ thống cần chúng. Chiến lược cách ly cho phép khôi phục nhanh chóng bằng cách đổi tên các file trở lại, đưa hệ thống về trạng thái pass với zero file bị thiếu.

Chi tiết chính

• Lỗi đo lường ban đầu: Lập trình viên chỉ đo lường quyền truy cập file cho một reader duy nhất (validator trạng thái thu thập), bỏ qua các thành phần khác như replay hàng đợi xuất bản.
• Quy mô tác động: 34.557 file HTML với tổng dung lượng 37.8GiB đã bị chuyển vào khu vực cách ly dựa trên dữ liệu không đầy đủ.
• Thất bại của bộ test suite: Việc chạy bộ test suite đầy đủ tiết lộ 310 lỗi mới, chủ yếu do thiếu các file HTML thô cần thiết cho replay và theo dõi nguồn gốc (provenance tracking).
• Phương pháp khôi phục: Các file được di chuyển thay vì xóa, cho phép khôi phục bằng cách đổi tên mà không cần crawl lại các nguồn bên ngoài.
• Bẫy của recorder: Recorder theo dõi truy cập file đã bỏ sót các thao tác đọc do sự không khớp đường dẫn tương đối trong audit hooks của Python 3.13.0 và mất bản ghi khi tiến trình pytest chính thoát khỏi bằng os._exit(1).
• Trạng thái hiện tại: Tính đến ngày 4 tháng 11 năm 2026, cổng lưu trữ (storage gate) đang ở trạng thái đỏ vì ba trong bốn lần chạy nightly kết thúc ở trạng thái restored, ngăn chặn bước xóa cuối cùng được thực thi.

Bối cảnh

Trong các hệ thống phần mềm phức tạp, đặc biệt là những hệ thống xử lý khối lượng lớn dữ liệu như pipeline nội dung, việc hiểu rõ những file nào đang được sử dụng tích cực là rất quan trọng cho bảo trì. "Reader" trong ngữ cảnh này đề cập đến bất kỳ quy trình hoặc thành phần nào mở và xử lý các file dữ liệu. Các lập trình viên thường sử dụng công cụ giám sát hoặc audit hook để theo dõi truy cập file, tạo ra một "read set" gồm các file đã được mở trong một thao tác cụ thể. Phần bù của tập hợp này—các file không được mở—đôi khi được giả định là an toàn để xóa. Tuy nhiên, giả định này nguy hiểm nếu việc giám sát không bao quát tất cả các reader có thể, bao gồm các background job, bộ test suite, hoặc các handler cho edge-case hiếm gặp.

Cách ly (Quarantining) là một thực hành an toàn, trong đó các file được di chuyển đến một vị trí riêng biệt thay vì bị xóa vĩnh viễn. Điều này cho phép các nhóm xác minh rằng hệ thống hoạt động đúng mà không có dữ liệu trước khi cam kết xóa không thể đảo ngược. Nếu có vấn đề phát sinh, các file có thể được di chuyển trở lại nhanh chóng. Cách tiếp cận này trái ngược với việc xóa trực tiếp, vốn sẽ đòi hỏi phải fetch lại dữ liệu từ các nguồn bên ngoài tốn kém và mất thời gian nếu quyết định chứng tỏ là sai lầm.

Tại sao điều này quan trọng

Đối với các nhóm vận hành phần mềm tự host (self-hosted) hoặc quản lý pipeline dữ liệu nội bộ, sự cố này minh họa tính phức tạp ẩn giấu của việc quản lý vòng đời dữ liệu. Thật dễ dàng để giả định rằng phân tích tĩnh hoặc giám sát runtime hạn chế cung cấp một bức tranh hoàn chỉnh về các phụ thuộc dữ liệu. Trên thực tế, các hệ thống thường có các phụ thuộc tiềm ẩn (latent dependencies), nơi dữ liệu chỉ được truy cập trong các sự kiện cụ thể, chẳng hạn như khôi phục lỗi, xử lý lại dữ liệu lịch sử, hoặc kiểm thử toàn diện. Xóa dữ liệu dựa trên tầm nhìn một phần có thể dẫn đến các lỗi tinh vi khó chẩn đoán và tốn kém để sửa chữa.

Việc phụ thuộc vào một metric duy nhất—read set của một validator—đã tạo ra cảm giác an toàn giả tạo. Thực tế rằng vòng thu thập ngay lập tức pass sau khi cách ly đã khiến lập trình viên nghĩ rằng thay đổi này là an toàn. Chỉ có bộ test suite rộng hơn, mô phỏng nhiều kịch bản vận hành bao gồm replay và join dữ liệu lịch sử, mới tiết lộ các phụ thuộc bị thiếu. Điều này nhấn mạnh tầm quan trọng của việc sử dụng các bộ test suite toàn diện như một công cụ xác thực cho các thay đổi hạ tầng, không chỉ logic code.

Hơn nữa, các cạm bẫy kỹ thuật gặp phải với recorder theo dõi truy cập file chứng minh rằng ngay cả các công cụ giám sát cũng có thể có điểm mù. Các vấn đề như giải quyết đường dẫn tương đối trong audit hooks hoặc hành vi thoát tiến trình có thể dẫn đến việc đếm thiếu các lượt truy cập file. Trong các thao tác dọn dẹp dữ liệu, việc đếm thiếu đặc biệt nguy hiểm vì nó trực tiếp làm tăng rủi ro xóa dữ liệu đang hoạt động. Các nhóm phải xác thực công cụ giám sát của họ chống lại các baseline đã biết để đảm bảo chúng nắm bắt được mọi hoạt động liên quan.

Bạn có thể làm gì

• Di chuyển trước khi xóa: Luôn di chuyển các file ứng viên vào thư mục cách ly với một timer cố định trước khi xóa vĩnh viễn, đảm bảo rằng các sai lầm có thể được đảo ngược với chi phí thấp.
• Đo lường tất cả các reader: Tính toán các ứng viên xóa dựa trên mọi thành phần có thể truy cập dữ liệu, bao gồm background job, cơ chế replay và bộ test suite đầy đủ.
• Xác thực công cụ giám sát: Kiểm tra các recorder theo dõi truy cập file của bạn chống lại các reader có hành vi đã biết để đảm bảo chúng không bỏ sót các thao tác đọc do vấn đề giải quyết đường dẫn hoặc thoát tiến trình.
• Chạy bộ test suite đầy đủ: Sau bất kỳ thao tác di chuyển dữ liệu nào, so sánh kết quả của bộ test suite đầy đủ với một baseline đã niêm phong để bắt các phụ thuộc tiềm ẩn mà các smoke test ngay lập tức có thể bỏ sót.
• Triển khai tripwire: Thiết lập các job giám sát log để tìm kiếm các nỗ lực đọc file bị thiếu, cho phép bạn phát hiện và khôi phục dữ liệu bị xóa nhầm trước khi nó gây ra thất bại lan rộng.
• Loại trừ cách ly khỏi ngân sách: Khi tính toán mức sử dụng lưu trữ, hãy loại trừ các byte đã cách ly khỏi ngân sách chính để tránh nhầm lẫn về kích thước dữ liệu hoạt động thực tế trong khi vẫn giữ chúng sẵn sàng cho việc khôi phục.