Error budget trong SRE: cân bằng thay đổi và độ tin cậy
Từ chỉ số chất lượng dịch vụ đến một quy tắc ra quyết định chung cho đội phát triển và vận hành.
Giọng tiếng Việt phụ thuộc trình duyệt và gói giọng nói trên thiết bị.
Mục lục bài viết

Điểm chính
- SLI mô tả điều được đo; SLO đặt mục tiêu cho một cửa sổ đánh giá.
- Error budget là phần chất lượng cho phép nằm ngoài mục tiêu.
- Chính sách phản ứng cần được thống nhất trước khi ngân sách cạn.
Đo điều người dùng thực sự trải nghiệm
Một máy chủ còn hoạt động không có nghĩa người dùng hoàn tất được tác vụ. Với ứng dụng web, có thể chọn tỷ lệ yêu cầu hợp lệ được phục vụ thành công làm chỉ báo; một dịch vụ khác có thể cần chỉ báo về thời gian phản hồi. Xác định rõ dữ liệu đo, phạm vi yêu cầu và điều kiện được coi là tốt.
Mục tiêu dịch vụ cần phù hợp với bối cảnh sử dụng. Không nên chọn một con số chỉ vì nhìn có vẻ cao; hãy thảo luận giá trị của độ tin cậy, mức phức tạp và công sức vận hành tương ứng.
Tính ngân sách theo cùng đơn vị đo
Trong mô hình dựa trên yêu cầu, ngân sách lỗi là tổng số yêu cầu hợp lệ nhân với phần tỷ lệ nằm ngoài SLO. Với mục tiêu 99,9% và một triệu yêu cầu, ví dụ minh họa cho phép tối đa 1.000 yêu cầu không tốt trong cửa sổ được chọn.
Đây là ví dụ dựa trên số yêu cầu, không phải phép quy đổi sang thời gian downtime. Với mục tiêu dựa trên thời gian hoặc nhiều chỉ báo, phải xác định cách tính riêng và tránh cộng các đại lượng khác đơn vị.
Ngân sách còn lại = số yêu cầu lỗi cho phép − số yêu cầu lỗi đã ghi nhận.
Thử tính ngân sách lỗi
Ví dụ dựa trên số yêu cầu trong cùng một cửa sổ đánh giá.
Thiết kế chính sách trước khi có sự cố
Theo cách tiếp cận trong tài liệu Google SRE, ngân sách lỗi tạo cơ sở chung để cân bằng tốc độ thay đổi và độ tin cậy. Hai đội cần thống nhất hành động khi ngân sách giảm nhanh: xem lại bản phát hành, thu hẹp phạm vi thay đổi hoặc dành thời gian xử lý nguyên nhân mất ổn định.
Chính sách không nên là một hình phạt tự động. Cần phân biệt thay đổi thông thường với bản vá cần thiết và thống nhất người có quyền quyết định trong từng trường hợp.
Từ góc nhìn đến giải pháp của bạn.
Chọn cửa sổ và cách theo dõi
Một cửa sổ cố định và một cửa sổ trượt có cách phản ánh sự cố khác nhau. Đội ngũ cần biết dữ liệu nào đi vào và ra khỏi phép tính, cách xử lý dữ liệu thiếu và thời điểm cập nhật dashboard. Gắn phép đo với bản phát hành để điều tra khi chất lượng thay đổi.
Bên cạnh tổng ngân sách, quan sát tốc độ tiêu thụ để nhận biết sự cố đang diễn ra. Ngưỡng cảnh báo phải được thử nghiệm với luồng xử lý và người trực phù hợp.
Ba cách tổ chức ngân sách lỗi
Các cách tổ chức dưới đây giúp đội ngũ lựa chọn nhịp đánh giá và quy tắc phản ứng. Chúng cần dùng chung định nghĩa SLI, SLO và đơn vị tính; việc chọn cách tổ chức không làm thay đổi ý nghĩa của phép đo.
- Theo ngưỡng: thống nhất hành động khi phần ngân sách đã sử dụng chạm các mức đã chọn. Cần xét cả tốc độ tiêu thụ để nhận biết diễn biến nhanh.
- Theo kỳ cố định: đánh giá trong một kỳ đã thống nhất, chẳng hạn một tháng. Cần biết ranh giới kỳ và cách một sự cố gần thời điểm chuyển kỳ được phản ánh.
- Theo cửa sổ trượt: tính lại trên khoảng thời gian gần nhất. Ngân sách thay đổi khi dữ liệu cũ rời cửa sổ, nên dashboard cần hiển thị cả mẫu số và phạm vi thời gian.
Đưa vào vận hành từng bước
Bắt đầu với một luồng người dùng, một bộ định nghĩa và một nguồn đo có thể kiểm tra. Chạy thử cách tính trên dữ liệu lịch sử, đối chiếu với những sự cố đội ngũ đã biết và điều chỉnh phạm vi trước khi áp dụng chính sách.
AQPTech có thể cùng doanh nghiệp xây dựng nguyên mẫu dashboard và luồng quan sát trong phạm vi thống nhất. Các con số trên trang chỉ phục vụ minh họa, không phải cam kết SLA của dịch vụ AQPTech.
Tài liệu tham khảo
Nguồn cho các khái niệm kỹ thuật trong bài; hướng tiếp cận triển khai là đề xuất biên soạn của AQPTech.



