CI/CDError budget = 1 − SLO quy ra lượng lỗi được phép trong chu kỳ. SLO 99.9% trong 30 ngày cho phép khoảng 43 phút không đạt. Giá trị của nó không nằm ở con số mà ở chỗ nó biến tranh luận "có nên đẩy tính năng này không" thành một quyết định dựa trên dữ liệu.
Error budget dùng để quyết định:
- Nhịp phát hành. Còn budget → tiếp tục đẩy tính năng, chấp nhận rủi ro. Cạn budget → dừng tính năng mới, chuyển sang việc độ tin cậy (sửa bug, thêm test, vá điểm yếu) cho tới khi budget hồi.
- Ưu tiên công việc. Budget tiêu hết vào đâu thì đầu tư vào đó, thay vì gia cố chỗ chưa bao giờ hỏng.
- Mức độ khẩn của alert. Đây chính là nền của burn-rate alerting.
- Mức đầu tư hạ tầng. Nếu tháng nào cũng còn dư nhiều budget, có thể SLO đang đặt thấp hơn nhu cầu thật, hoặc đang chi quá nhiều cho dự phòng.
Không đặt SLO 100%. Ba lý do:
1. Không đạt được. Mạng, phần cứng, phụ thuộc bên thứ ba, cả nhà cung cấp cloud đều có SLA dưới 100%.
2. Chi phí phi tuyến. Từ 99.9% lên 99.99% thường tốn gấp nhiều lần, trong khi người dùng qua mạng di động không phân biệt được — độ tin cậy của đường truyền phía họ còn thấp hơn thế.
3. Triệt tiêu thay đổi. Budget bằng 0 nghĩa là mọi lần deploy đều là vi phạm tiềm tàng, dẫn tới đóng băng phát triển.
Đặt SLO nên đi từ kỳ vọng người dùng, không từ con số đẹp: đo mức hiện tại, xem mức nào người dùng đã hài lòng, rồi chốt hơi trên mức đó. SLO cũng cần hệ quả đã thỏa thuận trước với bên sản phẩm — không có hệ quả thì nó chỉ là một con số trên dashboard.