Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được giao vận hành một hệ thống production đang phục vụ hàng chục nghìn người dùng. Câu hỏi đầu tiên và tưởng chừng đơn giản nhất là: "Hệ thống có đang khỏe không?". Nhưng khi mở dashboard giám sát lên, bạn thấy 200 biểu đồ, 500 metric, CPU của từng container, số connection của từng database, tỉ lệ cache hit của từng tầng... Bạn nhìn vào một biển số liệu mà vẫn không trả lời được câu hỏi cốt lõi: người dùng của tôi có đang gặp vấn đề không?
Đây chính là bài toán mà đội SRE của Google gặp phải cách đây hơn một thập kỷ, và câu trả lời của họ đã trở thành một trong những nguyên tắc nền tảng nhất của ngành vận hành hiện đại: 4 Golden Signals — bốn tín hiệu vàng. Ý tưởng cực kỳ mạnh mẽ: thay vì cố đo mọi thứ, hãy tập trung vào bốn metric tối thiểu mà nếu bạn chỉ được phép theo dõi bốn con số cho mỗi service, thì đây là bốn con số đó.
Trong Chương 6 của cuốn "Site Reliability Engineering" (thường gọi là SRE Book), Google viết một câu đáng để in ra dán lên tường: "If you can only measure four metrics of your user-facing system, focus on these four." Bốn tín hiệu đó là Latency, Traffic, Errors, và Saturation. Bài học hôm nay sẽ đi sâu vào từng tín hiệu, giải thích tại sao chính bốn cái này chứ không phải bốn cái khác, và quan trọng nhất là cách bạn áp dụng chúng vào một service thực tế. Ở các bài trước bạn đã hiểu SLI/SLO và cách đo lường độ tin cậy; 4 Golden Signals chính là bộ khung cụ thể giúp bạn biết đo cái gì để bắt đầu.
Khái niệm cốt lõi
4 Golden Signals là bốn nhóm metric mô tả sức khỏe của một service từ góc nhìn của người dùng và của tài nguyên. Điểm mấu chốt cần nắm ngay từ đầu: đây là monitoring hướng triệu chứng (symptom-based), không phải hướng nguyên nhân. Bạn theo dõi những gì người dùng cảm nhận được, chứ không sa lầy vào từng chi tiết bên trong.
1. Latency — Độ trễ
Latency là thời gian để service xử lý một request. Nghe đơn giản, nhưng có một cạm bẫy chết người mà Google nhấn mạnh: bạn phải tách latency của request thành công và request lỗi.
Vì sao? Vì một request lỗi thường trả về rất nhanh. Ví dụ, khi database sập, service của bạn có thể trả về lỗi HTTP 500 chỉ trong 5ms — nhanh hơn cả request thành công. Nếu bạn gộp chung, latency trung bình của bạn trông đẹp một cách giả tạo, che giấu sự thật là hệ thống đang cháy. Ngược lại, một lỗi timeout có thể mất 30 giây mới trả về, kéo latency lên trời và làm bạn tưởng service chậm trong khi thực chất nó đang chết.
Một điểm nữa: đừng bao giờ dùng latency trung bình (average/mean). Trung bình che giấu đuôi phân phối. Thay vào đó dùng percentile: p50 (median), p95, p99. Nếu p50 là 100ms nhưng p99 là 4 giây, nghĩa là cứ 100 người dùng thì có 1 người đang chờ 4 giây — và họ thường là những khách hàng có nhiều dữ liệu nhất, tức nhóm giá trị cao nhất.
2. Traffic — Lưu lượng
Traffic đo mức độ nhu cầu đang đặt lên hệ thống. Với một web service, đó thường là số request per second (RPS/QPS). Với một hệ thống streaming, có thể là số byte truyền mỗi giây. Với một database, có thể là số transaction mỗi giây.
Traffic quan trọng vì nó là bối cảnh cho ba tín hiệu còn lại. Latency tăng lúc 12h trưa có bình thường không? Chỉ khi bạn biết traffic lúc đó tăng gấp ba thì bạn mới hiểu. Errors tăng có đáng sợ không? Nếu traffic cũng tăng tương ứng thì tỉ lệ lỗi vẫn ổn. Traffic còn là đầu vào cho việc dự báo dung lượng — chủ đề bạn sẽ gặp lại ở các bài về capacity planning.
3. Errors — Tỉ lệ lỗi
Errors là tỉ lệ request thất bại. Nghe dễ, nhưng "thất bại" phức tạp hơn bạn nghĩ. Có ba loại lỗi cần phân biệt:
- Lỗi rõ ràng (explicit): HTTP 500, 503, exception — dễ đếm.
- Lỗi ngầm (implicit): trả về HTTP 200 nhưng nội dung sai, ví dụ trả về trang trống, JSON thiếu field, hoặc kết quả tính toán sai. Đây là loại lỗi nguy hiểm nhất vì monitoring thông thường không bắt được.
- Lỗi theo chính sách (policy): ví dụ bạn cam kết trả về trong 1 giây, một response đúng nhưng mất 3 giây có thể bị tính là "lỗi" theo tiêu chuẩn của bạn.
4. Saturation — Độ bão hòa
Saturation là tín hiệu khó nhất và thường bị bỏ quên. Nó đo mức độ "đầy" của hệ thống — tài nguyên bị ràng buộc nhất (most constrained resource) đang được dùng bao nhiêu phần trăm khả năng của nó. Với service tính toán nặng thì đó là CPU; với service bộ nhớ nhiều thì đó là RAM; với service I/O thì đó là băng thông đĩa hoặc mạng.
Điểm cốt lõi: saturation là tín hiệu dự báo tương lai (leading indicator). Latency và errors nói cho bạn biết hệ thống đã có vấn đề; saturation cảnh báo hệ thống sắp có vấn đề. Hầu hết hệ thống bắt đầu xuống cấp về hiệu năng trước khi đạt 100% — thường quanh 80% một tài nguyên nào đó đã đủ làm latency tăng vọt. Vì vậy người ta thường đặt ngưỡng cảnh báo saturation ở mức 70-80%, chừa thời gian để phản ứng.
Vì sao đúng bốn cái này?
Bốn tín hiệu bao phủ hai câu hỏi lớn. Người dùng có hài lòng không? — trả lời bằng Latency và Errors (request có nhanh và có đúng không). Hệ thống có bền vững không? — trả lời bằng Traffic và Saturation (nhu cầu bao nhiêu và tài nguyên còn lại bao nhiêu). Bốn góc này khép kín đủ để phát hiện gần như mọi sự cố nghiêm trọng mà không cần theo dõi hàng trăm metric nội bộ.
Tình huống thực tế
Ví dụ 1: Sàn thương mại điện tử ngày sale 12.12
Một sàn TMĐT lớn ở Việt Nam (tạm gọi ShopViet) chuẩn bị cho đợt flash sale lúc 0h ngày 12/12. Đội SRE dựng một dashboard chỉ gồm 4 Golden Signals cho service checkout — service quan trọng nhất vì nó trực tiếp tạo ra doanh thu.
Đúng 0h, traffic nhảy từ 2.000 RPS lên 18.000 RPS. Latency p99 vẫn giữ ở 400ms, errors dưới 0,1% — mọi thứ ổn. Nhưng saturation của connection pool tới database đã chạm 88%. Đây chính là giá trị của saturation như tín hiệu dự báo: latency và errors chưa hề xấu, nhưng đội trực đã biết họ chỉ còn khoảng 12% dư địa. Họ lập tức scale thêm read replica và tăng pool size trước khi sự cố xảy ra. Đến 0h07, nếu không hành động, saturation đã cán 100% và checkout sẽ bắt đầu timeout hàng loạt đúng lúc doanh thu cao nhất.
Bài học: Nếu chỉ nhìn Latency và Errors, đội SRE sẽ chỉ phản ứng sau khi khách hàng bắt đầu thất bại. Saturation cho họ 7 phút vàng để hành động trước. Một service không đo saturation là một service luôn phản ứng trễ một nhịp.
Ví dụ 2: Cái bẫy latency trung bình ở một fintech
Một ví điện tử tại Đông Nam Á (tạm gọi PayNow) có dashboard hiển thị latency trung bình của API xác thực giao dịch. Con số luôn đẹp: trung bình 120ms. Ban lãnh đạo hài lòng, không ai lo lắng.
Nhưng bộ phận chăm sóc khách hàng liên tục nhận than phiền: "App treo khi tôi thanh toán". Khi đội SRE chuyển từ latency trung bình sang percentile, sự thật lộ ra: p50 là 90ms, nhưng p99 là 6,2 giây. Nghĩa là cứ 100 giao dịch có 1 giao dịch mất hơn 6 giây. Với 2 triệu giao dịch mỗi ngày, đó là 20.000 khách hàng mỗi ngày trải nghiệm sự chậm chạp không thể chấp nhận — bị latency trung bình "làm loãng" và giấu đi hoàn toàn.
Nguyên nhân sâu xa: một truy vấn thiếu index chỉ chậm khi tài khoản có lịch sử giao dịch dài — tức là những khách hàng trung thành và giá trị nhất. Sau khi thêm index, p99 giảm về 350ms.
Bài học: Trung bình là kẻ nói dối tử tế. Luôn đo Latency bằng percentile, và ưu tiên nhìn vào đuôi phân phối (p95, p99), vì đó là nơi khách hàng thực sự đau.
Ví dụ 3: Lỗi ngầm ở một dịch vụ giao đồ ăn
Một app giao đồ ăn (tạm gọi FoodFast) có service gợi ý nhà hàng gần bạn. Sau một lần deploy, tất cả 4 Golden Signals đều xanh: latency ổn, traffic bình thường, saturation thấp, và errors gần như 0% — vì service vẫn trả HTTP 200 cho mọi request.
Vấn đề: một thay đổi ở tầng geolocation khiến service trả về danh sách rỗng cho khoảng 15% người dùng ở khu vực ngoại thành. Về mặt kỹ thuật, đây là "thành công" (HTTP 200), nên metric errors không hề nhúc nhích. Nhưng với người dùng, đó là hỏng hoàn toàn: mở app ra không thấy nhà hàng nào.
Đội chỉ phát hiện sau khi doanh thu khu vực đó giảm 15% và có người kiểm tra thủ công. Bài học rút ra: họ bổ sung một metric error ngầm — "tỉ lệ response trả về danh sách rỗng" — vào định nghĩa Errors của service này.
Bài học: Errors không chỉ là HTTP 5xx. Bạn phải định nghĩa "thành công" theo góc nhìn nghiệp vụ, và đo cả những lỗi ngầm mà mã trạng thái HTTP không phản ánh.
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để áp dụng 4 Golden Signals cho một service bất kỳ.
Bước 1 — Xác định ranh giới service và người dùng của nó. Trước khi đo, hãy trả lời: "Ai là người dùng của service này?". Có thể là người dùng cuối, cũng có thể là một service khác gọi tới. Điều này quyết định "success" và "latency" nghĩa là gì.
Bước 2 — Đo Latency đúng cách. Instrument code để ghi lại thời gian xử lý mỗi request, và tách riêng theo trạng thái thành công/thất bại. Xuất ra dưới dạng histogram để tính được percentile. Trên dashboard, hiển thị p50, p95, p99 — không hiển thị average.
Bước 3 — Đo Traffic. Đếm số request per second, chia theo endpoint hoặc theo loại nếu cần. Đây thường là metric dễ nhất vì đa số framework và load balancer đã có sẵn.
Bước 4 — Đo Errors. Bắt đầu với lỗi rõ ràng (5xx, exception). Sau đó ngồi lại với đội sản phẩm để liệt kê các lỗi ngầm và lỗi theo chính sách. Tính errors dưới dạng tỉ lệ (error rate = lỗi / tổng request), không phải số tuyệt đối, để nó có ý nghĩa khi traffic thay đổi.
Bước 5 — Xác định và đo Saturation. Tìm ra tài nguyên bị ràng buộc nhất của service (làm load test để biết cái gì "đụng trần" trước). Đo mức sử dụng của tài nguyên đó theo phần trăm khả năng tối đa. Đây thường là bước tốn công nhất nhưng đáng giá nhất.
Bước 6 — Dựng dashboard "một màn hình". Đặt cả bốn tín hiệu trên cùng một màn hình, cùng trục thời gian, để bạn tương quan chúng bằng mắt. Khi latency tăng, bạn liếc sang thấy ngay traffic có tăng không, saturation có cao không.
Bước 7 — Đặt alert dựa trên tín hiệu triệu chứng. Ưu tiên cảnh báo trên Latency và Errors (ảnh hưởng người dùng ngay), cộng với Saturation như cảnh báo sớm. Tránh cảnh báo trên từng metric nội bộ vụn vặt — chủ đề chiến lược alert bạn sẽ học sâu ở bài Signal vs Noise.
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng latency trung bình. Đây là lỗi phổ biến nhất và tai hại nhất. Luôn dùng percentile. Mẹo: khi báo cáo, hãy nói "p99 là X" thay vì "trung bình là Y".
Lỗi 2 — Gộp latency của request lỗi và thành công. Một request 500 trả về trong 3ms sẽ kéo latency của bạn xuống một cách giả tạo. Luôn tách hai luồng.
Lỗi 3 — Bỏ quên Saturation. Vì saturation khó đo nhất, nhiều đội chỉ theo dõi ba tín hiệu đầu. Kết quả là họ luôn phản ứng trễ, không bao giờ ngăn được sự cố trước khi nó xảy ra.
Lỗi 4 — Chỉ đếm lỗi HTTP 5xx. Bỏ sót lỗi ngầm (200 nhưng nội dung sai) là nguyên nhân của những sự cố "im lặng" nguy hiểm nhất.
Lỗi 5 — Quá tải dashboard. Nghịch lý là nhiều đội "áp dụng" 4 Golden Signals bằng cách thêm chúng vào một dashboard đã có 200 biểu đồ. Tinh thần của Golden Signals là tối giản. Mỗi service nên có một màn hình gọn với đúng bốn tín hiệu ở trên cùng.
Mẹo — Nhân bốn tín hiệu cho từng service quan trọng. 4 Golden Signals không phải bốn con số cho toàn hệ thống, mà là bốn con số cho mỗi service. Một kiến trúc microservices có 20 service thì có 20 bộ Golden Signals.
Mẹo — Dùng saturation để lập kế hoạch, không chỉ để cảnh báo. Xu hướng saturation theo tuần/tháng cho bạn biết khi nào cần scale trước khi chạm trần.
Bài tập thực hành
- Chọn một service. Lấy một service thật bạn đang vận hành (hoặc một API công khai bạn quen thuộc). Viết ra: ai là người dùng của nó, và "một request thành công" nghĩa là gì.
- Thiết kế bốn tín hiệu. Với service đó, liệt kê cụ thể: Latency đo bằng gì và ở percentile nào; Traffic đo bằng đơn vị gì; Errors gồm những loại lỗi nào (kể cả ít nhất một lỗi ngầm); Saturation đo tài nguyên nào và vì sao đó là tài nguyên bị ràng buộc nhất.
- Phân tích tình huống. Giả sử dashboard cho thấy: Latency p99 tăng gấp đôi, Traffic không đổi, Errors không đổi, Saturation CPU nhảy từ 40% lên 95%. Bạn suy luận nguyên nhân khả dĩ là gì? (Gợi ý: traffic không tăng nhưng CPU tăng — điều gì có thể gây ra?)
- Thiết kế alert. Với service của bạn, đề xuất ba ngưỡng cảnh báo dựa trên Golden Signals: một cho latency, một cho error rate, một cho saturation. Giải thích vì sao chọn ngưỡng đó.
Tóm tắt
4 Golden Signals của Google là bộ khung tối giản mà mạnh mẽ để trả lời câu hỏi "service của tôi có khỏe không?" mà không chết chìm trong hàng trăm metric. Bốn tín hiệu đó là:
- Latency — thời gian xử lý request; luôn tách thành công/lỗi, luôn dùng percentile chứ không dùng trung bình.
- Traffic — mức nhu cầu đặt lên hệ thống; là bối cảnh cho ba tín hiệu còn lại.
- Errors — tỉ lệ request thất bại; nhớ đếm cả lỗi ngầm và lỗi theo chính sách, không chỉ HTTP 5xx.
- Saturation — mức đầy của tài nguyên bị ràng buộc nhất; là tín hiệu dự báo sớm quý giá nhất, thường cảnh báo ở 70-80%.