Mở đầu — vì sao bài này quan trọng
Bạn đã xây được pipeline chạy được. Code push lên, test chạy, build ra artifact, deploy lên production. Mọi thứ nhìn có vẻ ổn — cho đến một buổi sáng thứ Hai, cả team bắt đầu than: "Sao dạo này build lâu thế?", "Hình như tuần vừa rồi hỏng main mấy lần đúng không?", "Deploy hôm qua có phải mất gần một tiếng không?". Và không ai trả lời được chính xác. Không có con số. Chỉ có cảm giác.
Đó chính là lúc bạn nhận ra: một pipeline không có observability giống như lái xe ban đêm mà không bật đèn. Nó vẫn chạy, nhưng bạn không biết mình đang đi nhanh hay chậm, có sắp đâm vào đâu không, và khi có sự cố thì cũng chẳng biết vì sao.
Observability (khả năng quan sát) trong CI/CD không phải là chuyện "cho vui" hay "để báo cáo sếp". Nó là nền tảng để bạn cải tiến liên tục. Bạn không thể tối ưu cái mà bạn không đo được. Nếu không biết build đang mất bao lâu, bạn không biết nên đầu tư vào caching hay không. Nếu không biết tỷ lệ build fail, bạn không biết pipeline của mình có đang cản trở anh em hay không. Nếu không biết mất bao lâu để sửa một main bị hỏng, bạn không biết đội mình phản ứng nhanh hay chậm khi có sự cố.
Bài này tập trung vào đo lường và trực quan hóa sức khỏe của pipeline — những chỉ số cần theo dõi, cách thu thập chúng, và cách biến dữ liệu thành quyết định. Đây là kỹ năng tách biệt một kỹ sư DevOps "vận hành theo cảm tính" với một kỹ sư "vận hành theo dữ liệu".
Khái niệm cốt lõi
Observability của pipeline khác với observability của ứng dụng production. Application observability nói về ba trụ cột metrics, logs, traces để hiểu hệ thống đang chạy ra sao. Pipeline observability thì tập trung vào quá trình đưa code từ commit đến production — nó nhanh không, đáng tin không, và tốn kém ra sao.
Bốn chỉ số nền tảng bạn bắt buộc phải track
1. Pipeline Duration (thời gian chạy pipeline)
Đây là tổng thời gian từ lúc developer push code đến lúc code đó chạy trên production (hoặc ít nhất đến lúc pipeline hoàn tất). Nhưng đừng chỉ nhìn con số trung bình. Trung bình rất dễ đánh lừa. Bạn cần nhìn theo phân vị (percentile): p50, p90, p95. Ví dụ, p50 = 8 phút nghĩa là một nửa số lần chạy nhanh hơn 8 phút; p95 = 25 phút nghĩa là 5% số lần chạy chậm hơn 25 phút. Chính cái đuôi p95 đó mới là thứ làm anh em bực bội nhất.
Quan trọng hơn, hãy tách nhỏ duration theo từng stage (lint, test, build, deploy). Nếu tổng thời gian tăng, bạn cần biết stage nào đang phình to. Có khi 70% thời gian nằm ở bước test, có khi lại nằm ở bước kéo dependency vì thiếu cache.
2. Success Rate (tỷ lệ thành công)
Phần trăm số lần chạy pipeline pass. Nhưng hãy phân biệt rõ hai loại pipeline: pipeline trên nhánh main và pipeline trên feature branch / pull request. Success rate trên PR thấp là bình thường (developer đang thử nghiệm, code chưa hoàn thiện). Nhưng success rate trên main mà thấp là báo động đỏ — vì main hỏng nghĩa là cả team bị chặn, không ai merge hay deploy được.
Đi kèm với success rate là khái niệm flaky test — test lúc pass lúc fail dù code không đổi. Flaky test là kẻ thù giấu mặt: nó làm success rate giảm giả tạo và khiến team mất niềm tin vào pipeline ("cứ chạy lại là được mà"). Bạn cần track riêng tỷ lệ flaky để biết pipeline đang "thật sự hỏng" hay chỉ "hỏng ảo".
3. MTTR — Mean Time To Recovery (thời gian trung bình để khôi phục)
Khi nhánh main bị hỏng (một build fail trên main), mất bao lâu để nó xanh trở lại? Đây là chỉ số về khả năng phản ứng của team. MTTR thấp (ví dụ dưới 15 phút) nghĩa là team phát hiện và xử lý nhanh. MTTR cao (vài tiếng, thậm chí qua ngày) nghĩa là main bị hỏng lâu, chặn cả đội, và văn hóa "để đó mai sửa" đang len lỏi.
4. Deployment Frequency & Change Failure Rate
Hai chỉ số này nằm trong bộ DORA metrics nổi tiếng (do nhóm nghiên cứu DevOps của Google phát triển). Deployment Frequency là bạn deploy lên production bao nhiêu lần trong một khoảng thời gian — đội tinh nhuệ deploy nhiều lần mỗi ngày, đội yếu deploy mỗi tháng một lần. Change Failure Rate là tỷ lệ deploy gây ra sự cố phải rollback hoặc hotfix. Bộ DORA đầy đủ gồm bốn chỉ số: Deployment Frequency, Lead Time for Changes, Change Failure Rate, và Time to Restore Service — đây là ngôn ngữ chung để so sánh hiệu suất phân phối phần mềm giữa các đội.
Dữ liệu đến từ đâu và đọng lại ở đâu
Về nguồn dữ liệu, hầu hết nền tảng CI/CD hiện đại đều phát ra sự kiện: GitHub Actions có webhook workflow_run, GitLab có Pipeline API, Jenkins có plugin và API. Mỗi lần pipeline chạy xong, một bản ghi được sinh ra với đầy đủ metadata: thời điểm bắt đầu/kết thúc, trạng thái, nhánh, người trigger, thời gian từng stage.
Bạn thu thập những sự kiện đó, đẩy vào một nơi lưu trữ (thường là time-series database như Prometheus, hoặc data warehouse), rồi trực quan hóa bằng dashboard (Grafana là lựa chọn phổ biến). Nguyên tắc vàng: dashboard phải trả lời được một câu hỏi cụ thể, không phải bày ra hàng chục biểu đồ cho đẹp. Mỗi biểu đồ nên gắn với một quyết định.
Tình huống thực tế
Ví dụ 1 — Tiki và cái đuôi p95 giấu mặt
Một đội platform tại một công ty e-commerce lớn ở TP.HCM (bối cảnh tương tự Tiki) từng tự tin rằng pipeline của họ "nhanh, trung bình chỉ 9 phút". Nhưng anh em developer vẫn liên tục phàn nàn. Khi họ dựng dashboard Grafana và vẽ theo percentile thay vì trung bình, sự thật lộ ra: p50 đúng là 9 phút, nhưng p95 lên tới 31 phút. Nghĩa là cứ 20 lần chạy thì có 1 lần developer phải chờ hơn nửa tiếng.
Đào sâu vào breakdown theo stage, họ phát hiện stage test đôi khi phình to bất thường vì một nhóm integration test phải chờ khởi động một container database, mà container đó thỉnh thoảng bị kéo image lại từ đầu do cache miss. Cái đuôi p95 đó chính là những lần cache miss.
Bài học: Trung bình che giấu nỗi đau. Trải nghiệm thực tế của developer nằm ở phân vị cao (p90, p95), không phải ở con số trung bình đẹp đẽ. Luôn đo theo percentile, và luôn tách nhỏ theo stage để biết vấn đề nằm đâu.
Ví dụ 2 — Startup fintech Singapore và MTTR mù mờ
Một startup fintech ở Singapore, khoảng 25 kỹ sư, có văn hóa "main hỏng thì ai đó sẽ sửa". Vấn đề là không ai đo xem "ai đó" mất bao lâu. Sau một quý, họ bắt đầu track MTTR bằng cách ghi lại thời điểm main chuyển từ xanh sang đỏ và thời điểm nó xanh trở lại.
Con số gây sốc: MTTR trung bình là 4 tiếng 20 phút. Tệ hơn, có những lần main đỏ suốt cả buổi chiều vì "người làm hỏng đã về, không ai dám đụng vào code người khác". Trong suốt thời gian đó, cả team 25 người không ai deploy được — thiệt hại rất lớn với một fintech cần release tính năng liên tục.
Họ áp dụng hai thay đổi: đưa MTTR lên dashboard chung hiển thị ở màn hình văn phòng, và đặt quy tắc "ai làm hỏng main thì có trách nhiệm sửa hoặc revert trong 20 phút". Sau hai tháng, MTTR trung bình giảm còn 18 phút. Điều thú vị là họ không đổi công nghệ gì cả — chỉ cần làm cho con số trở nên hữu hình là hành vi đã thay đổi.
Bài học: Đo lường bản thân nó đã tạo ra thay đổi hành vi. Một chỉ số được hiển thị công khai sẽ tạo áp lực tích cực và trách nhiệm rõ ràng. MTTR không chỉ là số kỹ thuật, nó phản ánh văn hóa đội.
Ví dụ 3 — Team giao đồ ăn và flaky test bào mòn niềm tin
Một đội backend tại một nền tảng giao đồ ăn ở Đông Nam Á có success rate trên main chỉ khoảng 82%, khiến ban lãnh đạo lo lắng về chất lượng. Nhưng khi kỹ sư QA lead track riêng flaky test — bằng cách chạy lại các build fail mà không đổi code — họ phát hiện: trong số các build "fail", có tới 60% là do cùng một nhóm 7 test bất ổn liên quan đến timeout khi gọi service ngoài.
Nghĩa là pipeline không thật sự tệ; nó bị bôi đen bởi flaky test. Tệ hơn, thói quen "fail cứ bấm retry" đã ăn sâu, đến mức có lần một bug thật lọt qua vì mọi người mặc định "chắc lại flaky thôi".
Họ lập một bảng xếp hạng "Top flaky tests" cập nhật hàng tuần, giao chủ sở hữu cho từng test, và cô lập (quarantine) các test bất ổn nhất ra khỏi luồng chặn merge cho đến khi được sửa. Sau một tháng, success rate thật trên main lên 96%, và quan trọng hơn, niềm tin vào pipeline được khôi phục — khi build đỏ, mọi người lại tin đó là đỏ thật.
Bài học: Success rate thô có thể đánh lừa. Phải tách flaky test ra khỏi lỗi thật, nếu không bạn sẽ vừa hoảng loạn sai chỗ, vừa để lọt lỗi thật. Niềm tin vào pipeline là tài sản quý, và flaky test là thứ bào mòn nó âm thầm nhất.
Hướng dẫn từng bước
Đây là lộ trình dựng observability cho pipeline từ con số không.
Bước 1 — Chọn tập chỉ số tối thiểu. Đừng tham lam đo mọi thứ. Bắt đầu với bốn chỉ số nền tảng: Pipeline Duration (theo p50/p95, tách theo stage), Success Rate (tách main vs PR), MTTR, và Deployment Frequency. Bốn cái này đã đủ cho 80% giá trị.
Bước 2 — Xác định nguồn sự kiện. Với GitHub Actions, đăng ký webhook workflow_run và workflow_job để nhận sự kiện mỗi khi pipeline/job hoàn tất. Với GitLab, dùng Pipeline API hoặc webhook. Với Jenkins, dùng API hoặc plugin xuất metrics. Mỗi sự kiện chứa timestamp bắt đầu/kết thúc, trạng thái, nhánh — đủ để tính mọi chỉ số ở trên.
Bước 3 — Lưu trữ dữ liệu. Đẩy metrics vào một nơi lưu bền vững. Đơn giản nhất: một service nhỏ nhận webhook rồi ghi vào Prometheus (qua Pushgateway) hoặc vào một bảng trong PostgreSQL/data warehouse. Điểm mấu chốt là dữ liệu phải lưu theo thời gian để bạn nhìn được xu hướng, không chỉ ảnh chụp hiện tại.
Bước 4 — Tính các chỉ số phái sinh. Duration thì lấy trực tiếp. Success rate = số run pass / tổng số run trong cửa sổ thời gian. MTTR cần logic phát hiện chuyển trạng thái đỏ→xanh trên main và tính khoảng cách thời gian. Deployment Frequency = đếm số lần job deploy production thành công.
Bước 5 — Dựng dashboard theo câu hỏi. Mỗi panel Grafana trả lời một câu hỏi: "Pipeline đang nhanh hay chậm dần?" (biểu đồ duration p95 theo tuần), "Main có ổn định không?" (success rate main theo ngày), "Đội phản ứng nhanh không?" (MTTR theo tuần). Tránh dashboard nhồi nhét.
Bước 6 — Gắn cảnh báo có ý nghĩa. Đặt alert khi chỉ số vượt ngưỡng gây đau: ví dụ "p95 duration > 20 phút trong 3 ngày liên tục" hoặc "main đỏ quá 30 phút". Alert phải actionable — báo xong thì biết phải làm gì, không phải báo cho có.
Bước 7 — Đưa vào nhịp cải tiến. Mỗi sprint hoặc mỗi hai tuần, dành 15 phút review các chỉ số này trong retro. Con số nào xấu đi? Vì sao? Ai nhận cải thiện? Observability chỉ có giá trị khi nó dẫn tới hành động.
Lỗi thường gặp & mẹo
Chỉ nhìn trung bình. Đây là sai lầm phổ biến nhất. Trung bình che giấu cái đuôi dài. Luôn dùng percentile (p50, p90, p95) cho các chỉ số về thời gian.
Trộn lẫn main và PR. Gộp chung success rate của mọi nhánh khiến bạn không đọc được tín hiệu quan trọng nhất — sức khỏe của main. Luôn tách theo loại nhánh.
Bỏ qua flaky test. Nếu không tách flaky ra, success rate của bạn vừa sai vừa gây mất niềm tin. Track riêng, quarantine, và giao chủ sở hữu.
Dashboard "cây thông Noel". Nhồi 30 biểu đồ lấp lánh mà không ai biết nhìn cái nào. Ít mà đúng trọng tâm tốt hơn nhiều mà nhiễu. Mỗi panel = một quyết định.
Đo mà không hành động. Dựng dashboard xong rồi để đó, không ai xem, không đưa vào retro. Metrics không được nhìn tới thì vô dụng. Hãy đặt nó vào một nhịp làm việc cố định.
Vanity metrics. Đừng chọn chỉ số chỉ vì nó dễ đẹp lên. "Số lượng build" tăng chưa chắc là tốt. Hãy chọn chỉ số phản ánh nỗi đau thật của developer và rủi ro thật của business.
Mẹo — chuẩn hóa DORA từ sớm. Dùng bộ bốn DORA metrics làm khung xương. Nó đã được kiểm chứng, có ngôn ngữ chung để so sánh, và giúp bạn nói chuyện với lãnh đạo bằng con số họ hiểu.
Mẹo — gắn deploy marker vào dashboard. Đánh dấu thời điểm mỗi lần deploy lên biểu đồ. Khi một chỉ số xấu đi đột ngột, bạn nhìn ngay được nó có trùng với một deploy nào không.
Bài tập thực hành
- Kiểm kê hiện trạng. Với pipeline hiện tại của bạn (hoặc một repo mẫu trên GitHub Actions), hãy tự trả lời bốn câu: p95 duration là bao nhiêu? Success rate trên main tuần qua? Lần gần nhất main hỏng mất bao lâu để xanh lại? Tuần qua deploy production mấy lần? Nếu không trả lời được câu nào, đó chính là lỗ hổng observability của bạn.
- Thu thập dữ liệu thô. Dùng GitHub Actions API (hoặc GitLab Pipeline API) lấy về 100 lần chạy gần nhất của một workflow. Xuất ra bảng gồm: thời gian bắt đầu, thời gian kết thúc, trạng thái, nhánh. Tính duration của từng lần.
- Tính percentile và success rate. Từ bảng trên, tính p50 và p95 của duration. Tính success rate riêng cho nhánh main và cho các nhánh khác. So sánh hai con số và giải thích chênh lệch.
- Dựng một dashboard tối giản. Tạo một dashboard (Grafana, hoặc thậm chí một Google Sheet) với đúng ba biểu đồ: duration p95 theo tuần, success rate main theo ngày, và số lần deploy theo tuần. Với mỗi biểu đồ, viết một câu: "Biểu đồ này giúp tôi quyết định điều gì?"
- Thiết kế một alert. Viết ra bằng lời một quy tắc cảnh báo bạn cho là đáng giá nhất cho đội mình, kèm ngưỡng cụ thể và hành động cần làm khi nó kích hoạt. Ví dụ: "Nếu main đỏ quá 30 phút → ping kênh #dev và tag người commit cuối."
Tóm tắt
Pipeline observability là điều kiện tiên quyết để cải tiến CI/CD một cách có kỷ luật — bạn không thể tối ưu cái mình không đo được. Bốn chỉ số nền tảng cần nhớ là Pipeline Duration (đo theo percentile và tách theo stage), Success Rate (tách main vs PR, và tách flaky test ra khỏi lỗi thật), MTTR (thời gian khôi phục main, phản ánh cả kỹ thuật lẫn văn hóa đội), và Deployment Frequency cùng bộ DORA metrics làm khung chuẩn.
Dữ liệu đến từ webhook/API của nền tảng CI, được lưu vào time-series database hay data warehouse, rồi trực quan hóa bằng dashboard gọn gàng nơi mỗi biểu đồ gắn với một quyết định. Ba tình huống thực tế cho thấy: trung bình che giấu nỗi đau ở p95, việc hiển thị công khai một chỉ số như MTTR có thể thay đổi hành vi cả đội, và flaky test âm thầm bào mòn niềm tin nếu không được tách bạch.
Điều quan trọng nhất cần mang theo: đo lường chỉ có giá trị khi nó dẫn tới hành động. Hãy chọn ít chỉ số nhưng đúng trọng tâm, đưa chúng vào nhịp làm việc thường xuyên, và biến pipeline của bạn từ một hộp đen thành một hệ thống mà bạn thật sự nhìn thấy, hiểu, và liên tục làm cho tốt hơn.