- SLI đo, SLO nhắm, SLA hứa.
- Đặt SLO = SLA nghĩa là giây phút bạn miss mục tiêu nội bộ cũng là giây phút hợp đồng khách hàng bị vi phạm.
- Đây là cách ba con số này khác nhau, cách tính error budget, và những cạm bẫy thường gặp.
TL;DR
Ba chữ viết tắt nghe giống nhau nhưng vai trò hoàn toàn khác:
- SLI (Service Level Indicator) — bạn đo cái gì. Một số thực, ví dụ tỉ lệ request thành công / tổng request.
- SLO (Service Level Objective) — bạn nhắm tới đâu. Mục tiêu nội bộ, ví dụ 99.95% trong 28 ngày.
- SLA (Service Level Agreement) — bạn hứa gì với khách hàng. Hợp đồng có điều khoản bồi thường khi miss.
Quy tắc vàng: SLO phải chặt hơn SLA. Nếu bạn đặt SLO = SLA = 99.9%, thì đúng cái giây phút availability tụt xuống dưới 99.9%, bạn đã vi phạm hợp đồng — không còn chỗ nào để xoay sở.
Mổ từng khái niệm
SLI — cái bạn đo
SLI là một phép đo định lượng, thường dưới dạng tỉ lệ: good events / total events, cho ra một con số từ 0% đến 100%. Ví dụ cho service login:
- Số login request thành công / tổng login request hợp lệ
- 95th percentile của response latency trong cửa sổ 5 phút
- Tỉ lệ HTTP 5xx trên tổng response
SLI không phải là mục tiêu, cũng không phải là lời hứa. Nó là hiện thực — con số nói lên service đang chạy ra sao ngay lúc này.
SLO — mục tiêu nội bộ
SLO là một ngưỡng bạn gắn lên SLI: "availability phải ≥ 99.9% trong cửa sổ lăn 28 ngày". Khi SLI tụt dưới SLO, đó là tín hiệu để điều tra và sửa trước khi khách hàng nhận ra.
SLO là công cụ ưu tiên nội bộ: team engineer dùng nó để cân giữa shipping tính năng mới và giữ hệ thống ổn định. Google SRE khuyến nghị mỗi service có không quá 5 SLO — chọn đủ để phủ hành vi chính, không phân tán focus.
SLA — hợp đồng với khách hàng
SLA là văn bản pháp lý. Nó liệt kê mức service được bảo đảm (uptime, latency, response time) và hậu quả khi nhà cung cấp miss — thường là service credit, hoàn tiền hoặc phạt tài chính. Cách nhanh nhất để phân biệt SLO và SLA: hỏi "Nếu miss thì sao?". Không có hậu quả cụ thể = đó là SLO, không phải SLA.
Vì sao gap giữa SLO và SLA là tất cả
Đây là bài học gốc của toàn bộ chủ đề: SLO phải tighter hơn SLA. Ví dụ điển hình:
- SLA công bố với khách hàng: 99.9% uptime/tháng
- SLO nội bộ team: 99.95%
- Gap: 0.05% — khoảng 21.6 phút mỗi tháng
21.6 phút đó là khoảng thở. Khi SLI tụt xuống dưới 99.95%, SLO bị miss — cờ vàng bật lên, team freeze deploy và sửa. Nhưng khách hàng vẫn chưa bị ảnh hưởng hợp đồng, vì SLA là 99.9% và vẫn chưa bị phá.
Nếu bạn đặt SLO = SLA = 99.9%, bạn đã xoá sạch cờ vàng đó. Mỗi lần miss SLO cũng là một lần breach SLA — đồng nghĩa service credits, báo cáo khách hàng, tổn hại niềm tin. Đó là lý do snippet gốc nhấn mạnh điểm này.
Error budget: đặt một lần, xài cả tháng
Từ SLO suy ra error budget = 100% − SLO. Đây là lượng "lỗi được phép" bạn có thể xài trước khi miss mục tiêu.
| SLO | Error budget | Downtime/tháng | Downtime/năm |
|---|---|---|---|
| 99.0% | 1% | ~7.2 giờ | ~3.65 ngày |
| 99.5% | 0.5% | ~3.6 giờ | ~1.83 ngày |
| 99.9% (ba số 9) | 0.1% | ~43–44 phút | ~8.76 giờ |
| 99.95% | 0.05% | ~21.6 phút | ~4.38 giờ |
| 99.99% (bốn số 9) | 0.01% | ~4.3 phút | ~52 phút |
| 99.999% (năm số 9) | 0.001% | ~26 giây | ~5.26 phút |
Ví dụ thực từ Google SRE: service có SLO 99.9%, xử lý 3 triệu request trong 4 tuần → budget là 3,000 lỗi. Một outage gây 1,500 lỗi → đã xài 50% budget trong một lần.
Burn rate = số lỗi quan sát / số lỗi cho phép. > 1 nghĩa là đang xài budget nhanh hơn dự kiến — dùng làm tín hiệu alert. Burn rate cao bất thường → alert gấp, phản ứng ngay. Burn rate thấp nhưng liên tục → ticket thường, sửa từ từ.
Ví dụ thực tế theo loại service
Web API:
- SLI: tỉ lệ request thành công; p95 latency trong cửa sổ 5 phút
- SLO: 99.95% availability + p95 < 200ms trong 30 ngày lăn
- SLA: 99.9% uptime tháng, credit 10% mỗi 1% thiếu hụt
Database:
- SLI: tỉ lệ query thành công; p95 read latency; durability (record đọc được / record đã ghi)
- SLO: 99.9% query thành công + < 50ms read trong 7 ngày lăn; 99.9999999% (9 số 9) durability/năm
- SLA: 99.99% uptime + < 100ms latency (phổ biến trong fintech)
E-commerce — kịch bản Black Friday:
- SLI đo được trong giờ peak: 99.2% availability
- SLO đặt: 99.5% → đã miss, error budget cháy sạch, team phải freeze deploy
- SLA cam kết: 99.0% → vẫn OK, không phải trả credit cho khách
Đây chính xác là lý do SLO phải chặt hơn SLA. Gap 0.5% kia là cái cứu bạn khỏi một buổi sáng thứ Hai trả lời email của legal.
Cạm bẫy thường gặp
- Đặt mục tiêu 100% — bất khả thi, và không còn chỗ để deploy, patch, maintenance. Mỗi con số 9 tăng thêm tốn theo cấp số nhân; lợi ích biên cho user tiến về 0.
- Vanity metrics — đo CPU server thay vì latency user nhìn thấy. Đo cái user cảm nhận, không đo cái dễ thu thập.
- Server-side bias — chỉ instrument backend, bỏ qua lỗi mạng và client-side. Phải có telemetry tại browser/app.
- Trung bình thay cho percentile — mean che mất long tail. 50ms trung bình có thể đi kèm 5% user bị 1,000ms. Dùng p95, p99. Câu của Google SRE: "nếu p99.9 tốt thì trải nghiệm điển hình chắc chắn tốt".
- Quá nhiều SLO — Google khuyến nghị tối đa 5/service. Defense cho từng SLO: nếu không thể thắng một cuộc tranh luận priority bằng cách dẫn SLO đó, thì bỏ nó đi.
- Đặt SLO bằng hiệu năng hiện tại — khoá bạn vào con số cần "heroic effort" để giữ. Bắt đầu lỏng, thắt dần theo thời gian.
- Bỏ qua third-party dependency — không thể hứa 99.99% khi phụ thuộc vào API upstream chỉ có 99.9%, trừ khi engineer xung quanh nó (cache, graceful degradation, store-and-forward).
- Overachieving — nếu thực tế chạy 99.999% nhưng SLO là 99.9%, user sẽ quen với mức thực tế. Google Chubby từng cố tình tạo outage có kế hoạch để user không phụ thuộc quá.
Kết luận
Ba câu để nhớ:
- SLI tells you where you stand.
- SLO tells you where you should be.
- SLA tells your customers what they can expect.
Đặt SLI trước (dựa trên Golden Signals của Google: latency, traffic, errors, saturation), rồi đặt SLO chặt hơn SLA một chút để có safety margin, rồi viết SLA dựa trên SLO. Đừng bao giờ đặt SLO = SLA, và đừng bao giờ hứa 100%.
Nguồn: Google Cloud SRE Blog, Google SRE Book, Google SRE Workbook, Nobl9 — Error Budgets Guide, Hyperping, @alexxubyte.
