Làm DevOps thì CI/CD là một phần không thể thiếu rồi và cảnh Pipeline failed là điều rất hay gặp, đây là một chút kinh nghiệm thực tế của tôi để phát hiện vấn đề một cách hiệu quả với cả màn hình hàng nghìn dòng log. Exp xương máu gửi tới các bác nhé. Mong hữu ích.

Lúc CI/CD Pipeline failed, coi log trả về cả vài nghìn dòng (thật ra toàn phần info và Warning là chính). Lúc đấy scroll một hồi, tìm thấy một block stacktrace, rồi câu hỏi vẫn vô thức nảy lên: bước tiếp theo nên làm gì nhỉ :))

Cái này lặp đi lặp lại rất tốn thời gian. Nhìn kỹ thì CI fail thường chỉ xoay quanh vài issue quen thuộc: test fail thật, dependency hoặc version mismatch, flaky test, timeout, thiếu resource, lỗi môi trường (docker layer cache, build cache, runner), hoặc dính config permission/secret.

Vấn đề là raw log không thể hiện ngay cho chúng ta biết nên bắt đầu ở đâu. Flow thông thường là tự lọc noise, tìm đoạn evidence, đoán 2-3 hướng điều tra. Nhiều lúc ông dev thấy failed bấm chọn rerun như kiểu hệ tâm linh chứ chưa giải quyết được vấn đề.

AI giờ rất phát triển nhưng trong mảng DevOps/Infra thì mọi người đều hiểu rồi, chưa ai dám đưa hạ tầng cho AI quản trị hay thực hiện các tác vụ gì sâu cả. Kể cả các bác Pro ở doanh nghiệp Tây hay Ta tôi quen thì AI chỉ support chủ yếu liên quan đến config, check log, mấy issue giúp giảm bớt chân tay chứ chưa kinh khủng như bên mảng Dev, AI code mà choáng luôn.

Vì vậy với AI, lúc này tôi chỉ cần một bước triage đủ gọn để dùng ngay: chỉ đúng đoạn log cần đọc trước, đưa ra vài khả năng hợp lý kèm evidence lines, rồi list ra các bước tiếp theo để thử.

Kỳ vọng thực tế với AI trong CI

Mọi người làm hạ tầng mà đang ứng dụng AI vào thì đừng mong AI đoán đúng hết mọi thứ. Mục tiêu cốt lõi là kéo Dev ra khỏi công đoạn mất thời gian nhất của một CI/CD fail là ngồi lọc log để quyết định xem nên bắt đầu từ đâu.

Một luồng AI triage đủ dùng chỉ cần giải quyết ba việc:

1. Trích xuất đúng block log chứa nguyên nhân.
2. Nêu ra các khả năng dựa trên evidence thực tế trong log.
3. Đề xuất action items theo thứ tự ưu tiên.

Chỉ vậy thôi. AI không sửa bug hộ, nhưng nó ngăn Dev bắt đầu sai chỗ (ứng dụng một thời gian thấy tiết kiệm rất nhiều công số mà vẫn AN TOÀN đấy)

Triển khai tối giản để dễ dàng cắm vào Pipeline

Cách làm rất đơn giản: Bước CI nào fail -> Trích một đoạn log snippet -> Redact dữ liệu nhạy cảm -> Gọi AI gen ra Triage Report -> Append output vào CI job hoặc comment thẳng vào PR.

Điểm quyết định thành bại nằm ở bước trích xuất log. Gửi toàn bộ payload vừa tốn token, vừa tăng độ nhiễu (hallucination), lại rủi ro bảo mật. Tôi thường ưu tiên lấy một trong các dạng sau:

• Vài trăm dòng cuối của log.
• Cụm block chứa stacktrace.
• Phần test summary kèm danh sách failed tests.
• Nếu CI system bắt được first error section thì dùng phần đó, vì tail log đôi khi chỉ chứa process cleanup.

Cấu trúc của một Triage Report tốt

Lúc debug, không ai cần đọc văn. Report trả về phải là một thứ đọc xong biết gõ lệnh gì tiếp theo. Một report có giá trị với tôi là:

• Likely cause: 1-2 câu đi thẳng vào vấn đề.
• Evidence lines: Trích dẫn nguyên văn đoạn log gây lỗi để xác thực.
• Category: Phân loại lỗi (CODE, TEST, INFRA, CONFIG…) để localize vấn đề.
• Next steps: 3 action items cụ thể. Ví dụ: chạy lệnh gì ở local, check file config nào, xác nhận bằng điều kiện gì.
• Confidence level: Cấp độ tự tin của AI. Nếu thiếu context, AI phải yêu cầu chính xác đoạn log nó cần thêm thay vì bịa ra nguyên nhân.

Ví dụ, log báo lỗi format timestamp. Triage report chỉ cần trích dòng Expected... got..., phân loại lỗi vào TEST, rồi gợi ý check commit đụng formatter hoặc chạy test local với timezone fixed. Vậy là đủ để dev bắt tay vào làm.

Kiểm soát rủi ro khi chạy tự động

Phần này thì luôn luôn quan trọng, có thể nói là phải ngấm vào máu anh em làm DevOps/Infra không là dễ toang lắm…

Đưa AI vào CI/CD Pipeline mà thiếu guardrails thì việc hỏng system chỉ là chuyện sớm muộn. Tôi giữ ba rule cứng là:

1. Redact trước khi request: Token, password, secret, private key, connection string, auth header bắt buộc phải filter ở local runner trước khi gửi đi. Tùy security policy mà lọc thêm internal URL, private repo path, email.
2. Giới hạn input: Tuyệt đối không pass full log. Chỉ gửi snippet đã xử lý.
3. Giới hạn quyền: AI chỉ có quyền read và suggest. Không cấp quyền tự động merge, không tự động retry, không tự đổi config. Nếu cần auto-retry, phải cấu hình bằng rule tĩnh của hệ thống, không dựa vào AI.

Và để scale dài hạn, hãy đưa vào feedback loop. Dev chỉ cần thả react (đúng/sai/thiếu info) vào report. Sau vài tuần, metrics sẽ chỉ ra prompt đang hiệu quả hay đang tạo thêm false lead cho team.

Prompt mẫu

Đây là template mọi người có thể tham khảo nhé. Điểm mấu chốt là ép LLM bám vào evidence và cấm tự bịa lỗi. Paste log snippet vào cuối là chạy.

You are a CI failure triage assistant.

Given the CI log below, produce a structured triage report in Vietnamese with:

1) Likely cause (1-2 sentences)
2) Evidence lines (3-7 lines copied verbatim from the log)
3) Category: one of [CODE, TEST, FLAKY, INFRA, CONFIG, DEPENDENCY]
4) Next steps: 3 concrete steps, each actionable and verifiable
5) Confidence: low/medium/high, and what additional info would raise confidence

Rules:
- Do not invent errors not present in the log.
- If the log is ambiguous, say so and request the exact missing snippet.
- Assume secrets are redacted; never suggest printing secrets.

...paste log snippet here...

Lưu ý: Nếu stack của mọi người đa dạng, hãy inject thêm context vào đầu snippet (vd: Language=Go, Runner=Gotest, CI=Gitlab) để next steps sát với thực tế hơn.

Đo lường bằng Data, không dùng cảm giác

Muốn biết luồng triage này có thực sự ROI (Return on Investment) hay không, hãy nhìn vào ba metrics:

• Time-to-first-action: Thời gian từ lúc nhận alert đến khi dev bắt đầu điều tra giảm được bao nhiêu?
• Mean Time To Fix CI: Tổng thời gian kéo CI từ đỏ sang xanh.
• Retry Waste: Số lần bấm rerun mù quáng giảm đi được bao nhiêu lần.

Để track chất lượng model, đo thêm Acceptance Rate (số lần dev vote hữu ích) và False Lead Rate (số lần AI dẫn sai hướng). Có data này thì việc tinh chỉnh prompt hay thuật toán cắt log snippet mới đi đúng hướng.

Kết luận

CI/CD fail không mà dành thời gian ngồi scroll log thì lúc gấp cũng rất vấn đề. Dù AI chưa thể viết code pass CI thay anh em, nhưng bằng cách cung cấp cho chúng ta đúng evidence và một vài hướng tiếp cận có logic, nó sẽ triệt tiêu được phase tốn sức nhất trong quá trình debug.

Nếu mọi người hứng thú thì có thể cho vài lời ủng hộ, tôi sẽ chia sẻ nhiều mindsets, usecases ứng dụng thực tế tiếp nhé.