Ý chính: Giám sát chỉ có giá trị khi giúp đội ngũ đưa ra quyết định nhanh hơn.
Thuật ngữ trong bài: SLI: chỉ số đo chất lượng thực tế; SLO: mục tiêu chất lượng dịch vụ; error budget: mức lỗi cho phép trong một giai đoạn.
Bài toán thực tế
CPU và bộ nhớ có thể vẫn bình thường trong khi chức năng thanh toán hoặc xuất bản đang lỗi với một nhóm khách hàng. Quá nhiều dashboard và cảnh báo thiếu ưu tiên còn khiến đội ngũ bỏ qua tín hiệu quan trọng.
Điểm dễ bị bỏ qua
CPU và bộ nhớ chỉ mô tả sức khỏe tài nguyên, không nói người dùng có hoàn tất được công việc hay không. Điểm bắt đầu đúng là một hành trình quan trọng, chỉ số chất lượng của hành trình đó và mục tiêu dịch vụ đã thống nhất.
Từ tín hiệu cấp sản phẩm, đội ngũ mới đi xuống trace, nhật ký và chỉ số hạ tầng để tìm nguyên nhân. Làm ngược lại thường tạo ra rất nhiều dashboard nhưng ít quyết định.
Luồng xử lý
SLI và SLO→Chỉ số
Tín hiệu tổng hợp nhanh→Traces
Quan hệ nhân quả→Nhật ký
Bằng chứng có chọn lọc
Thiết kế và triển khai
Đo tại ranh giới
Đếm kết quả sau authentication và nghiệp vụ kiểm chứng; loại yêu cầu mà contract xác định không hợp lệ.
Kiểm soát cardinality
Giữ endpoint, region và result làm chiều chỉ số. Đưa user, khách hàng, yêu cầu ID vào trace hoặc nhật ký có sampling và chỉ mục phù hợp.
Page theo triệu chứng
Dùng tốc độ tiêu hao ngân sách lỗi cho cảnh báo khẩn. Bất thường component chỉ là tín hiệu chẩn đoán nếu chưa trực tiếp đe dọa SLO.
Đi sâu vào thiết kế
Sampling phải giữ lỗi hiếm
Dùng head sampling để kiểm soát chi phí nền và tail rule giữ lỗi, slow trace cùng journey giá trị cao. Luôn ghi effective sampling rate.
SLO điều phối thay đổi
Khi giới hạn khỏe, đội ngũ phát hành nhanh. Khi burn, phản ứng đã thỏa thuận sẽ chuyển năng lực xử lý sang reliability, thay vì tranh luận ngay trong sự cố.
Cách triển khai
- Định nghĩa SLI về tỷ lệ thành công và độ trễ tại đúng ranh giới người dùng trải nghiệm.
- Truyền mã trace và ngữ cảnh khách hàng theo chính sách giới hạn số lượng nhãn, tránh tạo chỉ số có cardinality vô hạn.
- Cảnh báo theo tốc độ tiêu hao ngân sách lỗi ở nhiều cửa sổ thời gian, kèm runbook và người chịu trách nhiệm.
Mã minh họa: Cảnh báo theo tốc độ tiêu hao ngân sách lỗi
budget = 1 - sloTarget
burnShort = errorRate(5m) / budget
burnLong = errorRate(1h) / budget
if burnShort > 14 and burnLong > 6:
page(owner, runbook, affectedJourney)Kết hợp cửa sổ ngắn và dài để bắt sự cố nhanh mà không đánh thức đội vận hành vì một đợt tăng lỗi ngắn, ít tác động.
Rủi ro cần tính trước
- Ngữ cảnh trace bị mất khi yêu cầu đi qua hàng đợi.
- Đưa mã khách hàng trực tiếp vào nhãn chỉ số tạo ra hàng triệu chuỗi thời gian.
- Nhật ký vô tình chứa token hoặc dữ liệu cá nhân trong lúc xử lý sự cố.
Nên theo dõi gì?
| Tín hiệu | Điều tín hiệu cho biết |
|---|---|
| Tốc độ tiêu hao ngân sách lỗi theo hành trình | Nối độ tin cậy với quyết định phát hành và đầu tư kỹ thuật. |
| P50, P95 và P99 theo khu vực | Phân biệt trải nghiệm thông thường với nhóm yêu cầu chậm bất thường. |
| Tỷ lệ mất dữ liệu giám sát và tỷ lệ lấy mẫu | Cho biết chính bằng chứng dùng để chẩn đoán có đang thiếu hay không. |
Cách kiểm chứng
- Làm hỏng một hành trình người dùng trong khi host vẫn khỏe và chứng minh SLO cảnh báo.
- Gửi identifier cardinality cao và kiểm tra số chỉ số series vẫn hữu hạn.
- Theo một yêu cầu qua HTTP, queue và worker bằng cùng trace ngữ cảnh.
Đưa vào production từng bước
Chọn một hành trình gắn trực tiếp với doanh thu hoặc vận hành. Chạy SLI mới song song với cảnh báo cũ, đối chiếu với sự cố thật trong vài tuần và chỉ thay cảnh báo cũ khi tín hiệu mới chứng minh được giá trị.
Checklist trước khi vận hành
- SLO có người phụ trách và quyết định gắn với mức tiêu thụ ngân sách lỗi.
- Mã khách hàng tìm kiếm được nhưng không trở thành chỉ số label vô hạn.
- Dữ liệu giám sát che secret và áp thời gian lưu giữ theo data class.
Điều cần nhớ
Observability tốt biến tác động tới khách hàng thành quyết định vận hành nhanh và có bằng chứng, thay vì chỉ tạo thêm biểu đồ.