Vaccine CI/CD tự động hoá: học từ lỗi build, không lặp lại

TL;DR: Một blog dùng GitHub Actions để build và deploy tự động sẽ sớm hay muộn gặp lại cùng một loại lỗi nhiều lần — rate limit, conflict dữ liệu tự sinh, cú pháp template sai. Thay vì chẩn đoán lại từ đầu mỗi lần, mình xây một "thư viện vaccine": mỗi lỗi từng gặp được ghi lại kèm dấu hiệu nhận diện và cách sửa đã kiểm chứng, để lần sau máy (hoặc người) chỉ cần so khớp và áp lại, không phải điều tra lại toàn bộ.

Nếu bạn từng vận hành một pipeline CI/CD chạy thật — không phải demo, mà thật sự build và deploy hàng chục lần mỗi ngày — bạn sẽ nhận ra một điều khó chịu: rất nhiều lần build fail không phải vì bug mới. Nó là một lỗi bạn đã từng gặp, đã từng sửa, rồi vài tuần sau lại xuất hiện dưới một cái tên khác, ở một PR khác, và bạn lại ngồi đọc log từ đầu như chưa từng biết gì. Đó chính là lý do mình xây một mô hình vaccine CI/CD tự động hoá cho pipeline của blog này.

Vấn đề thật: build fail lặp lại nhưng không ai nhớ đã sửa thế nào

Ở blog mình đang vận hành, pipeline CI chạy zola build, chấm điểm SEO, kiểm tra internal link, và tự động merge khi mọi thứ xanh. Nghe thì gọn, nhưng thực tế vận hành hàng trăm workflow mỗi tuần lại sinh ra một danh sách lỗi rất "quen mặt":

• GitHub Pages API bị rate limit khi nhiều PR merge dồn dập.
• File dữ liệu tự sinh (data/*.json) bị hai job ghi đè lẫn nhau, tạo conflict giả.
• Một cú pháp template sai chỉ lộ ra khi có nội dung mới chạm đúng nhánh code hiếm khi chạy tới.

Ba loại lỗi này có điểm chung: chúng không phải bug logic khó. Cái khó là nhớ lại mình đã từng gặp lỗi y hệt vậy, và đã sửa bằng cách nào. Nếu không có nơi lưu lại, mỗi lần lỗi tái xuất, người xử lý (dù là con người hay AI agent) đều phải điều tra lại từ số 0 — đọc log, dò nguyên nhân, thử fix, xác nhận — tốn thời gian gấp nhiều lần so với lần đầu.

Ý tưởng vaccine CI/CD tự động hoá: biến lỗi đã gặp thành tri thức tái sử dụng được

Cách mình giải quyết là mượn đúng logic của y học: vaccine dạy hệ miễn dịch nhận diện một mối đe dọa đã biết, để lần sau phản ứng nhanh hơn thay vì phải học lại từ đầu. Áp dụng vào CI/CD:

1. Mỗi lỗi từng gặp được ghi lại thành một entry, có số thứ tự riêng (ở blog mình hiện đã tới gần 30 entry).
2. Mỗi entry có ba phần bắt buộc:
   • Dấu hiệu (signature): đoạn log lỗi đặc trưng, đủ cụ thể để không nhầm với lỗi khác.
   • Nguyên nhân gốc: giải thích ngắn gọn vì sao lỗi này xảy ra — không chỉ mô tả triệu chứng.
   • Fixer: các bước sửa đã kiểm chứng, viết đủ chi tiết để làm lại y hệt mà không cần đoán.
3. Khi lỗi mới xuất hiện, quy trình bắt buộc là so khớp dấu hiệu với thư viện trước, chỉ khi không khớp entry nào mới bắt đầu chẩn đoán từ đầu — và sau khi chẩn đoán xong, bắt buộc ghi thêm một entry mới.

Nghe đơn giản, nhưng phần khó nhất không phải là viết code — mà là kỷ luật ghi lại. Rất dễ sửa xong một lỗi rồi quên ghi chú, để rồi ba tuần sau gặp lại chính lỗi đó và lại mất nửa tiếng chẩn đoán lại.

Severity model: không phải lỗi nào cũng đáng chặn deploy

Một sai lầm phổ biến khi mới xây CI nghiêm ngặt là để mọi cảnh báo đều chặn merge. Kết quả là QA biến thành cảnh sát, làm chậm mọi thứ, và người ta bắt đầu tìm cách né qua (--no-verify, comment code test, v.v.) — phản tác dụng hoàn toàn.

Cách xử lý hợp lý hơn là phân loại mức độ nghiêm trọng rõ ràng:

Mức	Ý nghĩa	Hành vi CI
P0	Build vỡ, cú pháp template sai, secret bị commit, route quan trọng hỏng	Chặn deploy ngay
P1	Có thể tự sửa an toàn (rate limit, dữ liệu tự sinh conflict)	Thử tự sửa trước, chỉ chặn nếu tự sửa thất bại
P2/P3	SEO chưa tối ưu, cảnh báo hiệu năng, gợi ý cải thiện	Chỉ ghi nhận, không chặn

Phân loại này quan trọng hơn người ta nghĩ. Nó trả lời câu hỏi "khi nào nên dừng lại và khi nào nên tiếp tục" — thứ mà rất nhiều pipeline CI/CD không có câu trả lời rõ ràng, dẫn tới tình trạng hoặc chặn quá tay (làm chậm team) hoặc lỏng quá tay (bug lọt lên production). Tài liệu chính thức của GitHub Actions cũng khuyến nghị dùng concurrency và required status checks đúng chỗ thay vì chặn mọi workflow như nhau — nguyên tắc nền tảng mà mô hình severity ở trên áp dụng cụ thể hơn cho từng loại lỗi.

Vì sao "auto-fix" một mình chưa đủ

Có công cụ tự động sửa lỗi build không có nghĩa là an toàn tuyệt đối. Trong quá trình vận hành, mình từng thấy chính công cụ auto-fix tự gây ra lỗi mới — ví dụ một script tự động rerun các job CI bị fail, nhưng lại rerun luôn cả job không liên quan, gây ra một vòng lặp CI tự kích hoạt lẫn nhau. Bài học rút ra: auto-fix cần có giới hạn rõ ràng — chỉ tự sửa những gì đã được kiểm chứng là an toàn (deterministic, idempotent), còn lại phải để lộ ra cho người xử lý, không được âm thầm "tự xử" rồi báo xanh giả.

Đây cũng là lý do vì sao mọi thay đổi từ hệ thống auto-fix, kể cả bot, vẫn phải đi qua Pull Request thay vì push thẳng vào nhánh chính — để luôn có một điểm dừng cho phép review, dù là review tự động qua CI hay review bằng mắt.

Bài tiếp theo: một ca thật, không phải lý thuyết

Nói lý thuyết thì dễ, nhưng cách tốt nhất để hiểu mô hình vaccine có thực sự hữu ích hay không là nhìn vào một ca lỗi thật — nơi một dòng cú pháp sai kéo theo hàng loạt PR bị chặn, một lần tự động merge nhầm bản fix cũ, và một false positive khiến toàn bộ deploy đứng hình. Phần 2 của series sẽ đi thẳng vào case study đó, từng bước một, kể cả những chỗ mọi thứ không diễn ra suôn sẻ như lý thuyết vẽ ra.

Đọc thêm

• Merged is not live: vì sao PR merge xong chưa chắc đã lên production
• Giảm deploy fail từ hàng chục xuống gần 0: case study Deploy Guard + Snapshot Production
• Checklist theo dõi deploy sau khi merge: từ merge tới xác nhận production 200 OK
• Codex CLI báo node_repl failed to start: đây là lỗi gì?
• Chuyên mục Công nghệ +++