SLI, SLO & Error Budget cho website biến độ tin cậy hệ thống (reliability) thành mục tiêu đo được dựa trên trải nghiệm người dùng thay vì chỉ nhìn uptime chung chung.
Tóm tắt: SLI (Service Level Indicator — chỉ số mức dịch vụ) đo chất lượng dịch vụ thực tế; SLO (Service Level Objective — mục tiêu mức dịch vụ) đặt mục tiêu cho SLI trong một khoảng thời gian; còn Error Budget — phần sai lệch cho phép là mức hệ thống có thể không đạt SLO trước khi phải ưu tiên ổn định. Bộ ba này giúp đội vận hành biết khi nào có thể tiếp tục thay đổi hệ thống và khi nào cần giảm rủi ro.
Hiểu SLI, SLO và Error Budget như một hệ thống quyết định
| Khái niệm | Câu hỏi | Ví dụ |
|---|---|---|
| SLI | Dịch vụ đang hoạt động tốt tới mức nào? | Tỷ lệ request thành công, độ trễ dưới ngưỡng, checkout completion, độ mới dữ liệu. |
| SLO | Mức “đủ tốt” trong kỳ đo là bao nhiêu? | Tỷ lệ thành công hoặc latency target theo critical journey. |
| Error Budget | Còn bao nhiêu phần sai lệch trước khi vượt SLO? | Phần failure/latency vượt target được phép trong kỳ đo. |
SRE (Site Reliability Engineering — kỹ thuật độ tin cậy hệ thống) của Google khuyến nghị chọn SLI dựa trên hành vi dịch vụ mà người dùng thực sự cảm nhận và đặt SLO theo nhu cầu thực tế thay vì copy một con số “chuẩn” cho mọi hệ thống. Xem Google SRE Workbook – Implementing SLOs.
Chọn SLI theo critical journey, không theo metric dễ lấy
Critical journey là luồng người dùng quan trọng như gửi form, đăng nhập hoặc checkout. Một website có thể trả HTTP 200 nhưng form không tạo lead hoặc checkout không hoàn tất. Vì vậy availability — khả năng dịch vụ sẵn sàng chỉ là một SLI khả dĩ, không phải SLI duy nhất. Hãy bắt đầu từ việc người dùng đang cố hoàn thành điều gì.
| Hành trình | SLI gợi ý | Failure người dùng cảm nhận |
|---|---|---|
| Browse | HTTP success, latency, page availability | Trang không mở hoặc quá chậm. |
| Lead form | Submit success + lead received | Form báo thành công nhưng CRM không nhận lead. |
| Checkout | Checkout/payment completion | Không hoàn tất đơn hoặc payment callback lỗi. |
| API | Valid response rate + latency | Dependency trả sai/chậm dù website vẫn online. |
| Data sync | Freshness + reconciliation success | Dữ liệu cũ hoặc lệch hệ thống. |
| Background job | On-time completion + backlog age | Job trễ dù scheduler vẫn chạy. |
Để đo các journey này liên tục, nối SLI với Website Monitoring và Website Observability thay vì tạo một dashboard SLO tách biệt khỏi telemetry — dữ liệu quan sát hệ thống — thực tế.
Đặt SLO theo nhu cầu kinh doanh, không phản xạ chọn 100%
SLO cần có chỉ số + mục tiêu + khoảng thời gian đo + phạm vi. Mục tiêu phải phản ánh kỳ vọng người dùng, mức quan trọng của dịch vụ, dependency và chi phí. Google SRE lưu ý mục tiêu 100% thường không thực tế và có thể dẫn tới chi phí hoặc mức bảo thủ không cần thiết. Xem Google SRE – Service Level Objectives.
SLO khác SLA: SLO là mục tiêu kỹ thuật để điều hành reliability; SLA (Service Level Agreement — thỏa thuận mức dịch vụ) là cam kết dịch vụ/kinh doanh có thể đi kèm điều khoản với khách hàng. Intent SLA đã có owner tại SLA vận hành website.
Dùng Error Budget và burn rate để điều hành thay đổi
Error Budget biến SLO thành cơ chế quyết định. Nếu budget còn khỏe, đội có thể tiếp tục release trong mức rủi ro chấp nhận; nếu budget đang cạn nhanh, ưu tiên giảm rủi ro thay đổi, xử lý reliability backlog hoặc sửa nguyên nhân gốc thay vì tiếp tục tăng tốc độ release.
- release mới có thể tiếp tục hay cần tạm dừng/giảm rủi ro;
- loại incident nào đang tiêu budget nhiều nhất;
- reliability backlog nào cần ưu tiên;
- instrumentation — phần đo lường/ghi nhận telemetry — nào đang thiếu để đo đúng SLI;
- có cần giảm rủi ro của deploy/change hiện tại.
Burn rate — tốc độ tiêu Error Budget giúp phát hiện budget đang bị dùng quá nhanh trước khi chờ đến cuối kỳ đo. Google SRE có hướng dẫn alerting theo SLO/burn rate tại Alerting on SLOs.
Khi error budget bị tiêu nhanh ngay sau deploy, nối quyết định đó với Change Management WordPress. Nếu budget bị tiêu bởi exception/regression, xem thêm Application Error Monitoring.
Quy trình triển khai SLI/SLO gọn nhưng đủ
- Chọn critical journey: đừng bắt đầu từ metric có sẵn.
- Chọn SLI: đo kết quả người dùng nhìn thấy hoặc proxy đủ gần.
- Đặt SLO: target + kỳ đo + scope có lý do.
- Tính error budget: xác định phần cho phép không đạt target.
- Đặt policy: budget cạn thì ai quyết định tạm dừng hoặc giảm rủi ro change?
- Alert theo impact/burn rate: tránh alert cho mọi metric drift nhỏ.
- Review: SLO phải thay đổi khi product, traffic hoặc business criticality thay đổi.
Checklist tránh biến SLO thành dashboard trang trí
- SLI bám critical journey.
- SLO có kỳ đo và phạm vi rõ.
- Không biến mọi metric thành SLO.
- Error budget có policy hành động.
- Alert nối với owner/runbook.
- Telemetry đủ để giải thích vì sao SLI xấu.
- Review khi product/business thay đổi.
Kết luận
SLI, SLO & Error Budget giúp reliability trở thành cơ chế điều hành có mục tiêu và sự đánh đổi rõ. Thay vì hỏi “website có đủ ổn định chưa?”, đội vận hành có thể nhìn critical journey → SLI → SLO → budget → burn rate → quyết định change trong một flow thống nhất.
Nguồn tham khảo: Google SRE Workbook – Implementing SLOs; Error Budget Policy; Alerting on SLOs; OpenTelemetry Observability Primer.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.
