Tóm tắt: Giám sát chỉ có giá trị khi giúp đội ngũ đưa ra quyết định nhanh hơn.
Thuật ngữ chính: 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
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.
Vì sao cách làm đơn giản chưa đủ
CPU và memory mô tả component, không cho biết khách hàng hoàn tất việc hay chưa. SLI nên đo đúng sự kiện sản phẩm cam kết: phát hành thành công, payment được chấp nhận hoặc import hoàn tất.
Ba trụ cột không phải ba data lake rời nhau. Ngữ cảnh thống nhất giúp đi từ SLO bị burn sang trace rồi tới log evidence an toàn.
Luồng xử lý
SLI và SLO→Metrics
tín hiệu tổng hợp nhanh→Traces
quan hệ nhân quả→Logs
bằng chứng có chọn lọc
Quyết định kiến trúc
Đo tại ranh giới
Đếm kết quả sau authentication và business kiểm tra. Loại yêu cầu mà contract xác định không hợp lệ.
Kiểm soát cardinality
Giữ route, region và result làm chiều metrics. Đưa user, khách hàng, yêu cầu ID vào trace hoặc log có sampling và chỉ mục phù hợp.
Page theo triệu chứng
Dùng error-budget burn cho alert 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.
Phân tích chuyên sâu
Sampling phải giữ lỗi hiếm
Dùng head sampling để kiểm soát chi phí nền và tail rule giữ error, slow trace cùng journey giá trị cao. Luôn ghi effective sampling rate.
SLO điều phối thay đổi
Khi budget 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 incident.
Các bước triển khai
- Định nghĩa availability và độ trễ SLI tại dịch vụ ranh giới khách hàng thực sự trải nghiệm.
- Truyền trace, khách hàng và operation ngữ cảnh theo chính sách cardinality hữu hạn.
- Alert bằng multi-window error-budget burn, kèm runbook và người phụ trách.
Ví dụ kỹ thuật: Quyết định theo multi-window burn rate
budget = 1 - sloTarget
burnShort = errorRate(5m) / budget
burnLong = errorRate(1h) / budget
if burnShort > 14 and burnLong > 6:
page(owner, runbook, affectedJourney)Hai cửa sổ bắt sự cố nhanh nhưng tránh page vì spike ngắn, ít tác động. Ngưỡng cần tinh chỉnh từ sự cố thật.
Các tình huống lỗi cần tính trước
- Trace ngữ cảnh bị mất khi qua queue.
- mã khách hàng label tạo hàng triệu time series.
- Log chứa token hoặc nội dung dữ liệu cá nhân trong lúc sự cố.
Tín hiệu cần giám sát
| Tín hiệu | Ý nghĩa |
|---|---|
| Error-budget burn theo journey | Nối reliability với quyết định phát hành và đầu tư. |
| p50, p95, p99 theo region | Phân biệt trải nghiệm bình thường với tail problem. |
| Tỷ lệ telemetry drop và sampling | Cho biết chính bằng chứng có đang thiếu hay không. |
Cách kiểm chứng thiết kế
- 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 alert.
- Gửi identifier cardinality cao và kiểm tra số metric series vẫn hữu hạn.
- Theo một yêu cầu qua HTTP, queue và tiến trình xử lý bằng cùng trace ngữ cảnh.
Kế hoạch triển khai an toàn
Chọn một journey gắn với doanh thu hoặc vận hành. Chạy SLI cạnh alert cũ vài tuần, so với ticket thật rồi chỉ thay những alert nó làm tốt hơn. Thêm journey tiếp theo khi journey đầu đã có người phụ trách và runbook đáng tin.
Checklist trước khi đưa vào vận hành
- SLO có người phụ trách và quyết định gắn với mức tiêu thụ error budget.
- mã khách hàng tìm kiếm được nhưng không trở thành metrics label vô hạn.
- Telemetry che secret và áp retention theo data class.
Kết luận
Observability tốt biến tác động khách hàng thành quyết định vận hành nhanh, dựa trên bằng chứng.