SLI, SLO và Error Budget
Đo reliability bằng kết quả người dùng thay vì chỉ Pod Ready.
Nắm bản chất
SLI là chỉ số đại diện trải nghiệm dịch vụ; SLO là mục tiêu định lượng cho SLI theo một khoảng thời gian. Availability theo số request thành công không giống Kubernetes Pod uptime. Nếu đặt SLO 99,9% trên 30 ngày, error budget là 0,1% của mẫu đo hợp lệ trong cửa sổ đó.
SLO cần định nghĩa denominator rõ: request nào được tính, lỗi của client có được tính không, synthetic checks hay real traffic. Theo dõi burn rate sẽ hữu ích hơn chỉ cảnh báo khi SLO đã vi phạm.
Luồng hoạt động
Hãy tự giải thích mỗi mũi tên: dữ liệu, quyền hoặc tín hiệu nào được truyền qua bước này?
Lệnh & cấu hình mẫu
sum(rate(http_requests_total{status!~"5.."}[5m]))
/
clamp_min(sum(rate(http_requests_total[5m])), 0.001)
Example SLO: 99.9% successful server requests over 30 days.
Lệnh có placeholder hoặc phụ thuộc môi trường thì cần thay thông tin thực tế, kiểm tra quyền và chỉ thực hiện trên tài nguyên được phép.
Bài tập 10–20 phút
Thiết kế hai SLIs cho Capstone: HTTP success ratio và job completion delay. Giải thích vì sao HTTP 202 không phải bằng chứng job đã hoàn thành.
Lỗi dễ mắc
Đừng tạo SLO chỉ vì metrics có sẵn; chọn user-critical journeys và đảm bảo sampling/counter labels đúng contract.
Tự kiểm tra
SLO 99,9% có nghĩa mỗi request phải dưới 1ms?Xem đáp án ↗
Không. 99,9% ở ví dụ này là mục tiêu tỉ lệ request thành công, không phải latency.
Học thêm qua lab
Có project thực hành đúng với chương này, kèm README và những giới hạn môi trường cần lưu ý.
↓ Tải mã nguồn thực hành chương 11Đối chiếu tài liệu gốc
Cú pháp và khả năng hỗ trợ có thể thay đổi theo phiên bản. Trước khi dùng Production, hãy kiểm tra tài liệu tương ứng.
Mở tài liệu chính thức ↗