SLI, SLO và Error Budget: đo độ tin cậy production bằng số liệu thay vì cảm giác

SLI, SLO và error budget là bộ khung giúp team backend/DevOps nói về reliability bằng số liệu cụ thể: người dùng đang trải nghiệm tốt tới mức nào, mục tiêu ổn định là bao nhiêu, và team còn bao nhiêu “ngân sách lỗi” trước khi phải giảm tốc feature để sửa hệ thống.

Trong hệ thống production, câu “service ổn mà” thường không đủ. Một API có uptime 99.9% vẫn có thể gây khó chịu nếu p95 latency tăng cao, checkout lỗi theo từng vùng, hoặc retry storm làm queue nghẽn. Bài này đi sâu vào cách thiết kế SLI/SLO thực dụng cho engineer: chọn metric, đặt target, tính error budget, thiết kế burn-rate alert và dùng nó để ra quyết định kỹ thuật.

Sơ đồ SLI SLO và error budget cho hệ thống production
SLI đo trải nghiệm, SLO đặt mục tiêu, error budget giúp cân bằng reliability và tốc độ phát triển.

SLI, SLO và error budget là gì?

SLI là chỉ số đo trải nghiệm người dùng

SLI (Service Level Indicator) là metric đại diện cho chất lượng dịch vụ. SLI tốt không chỉ là metric dễ lấy từ server, mà phải gần với trải nghiệm người dùng hoặc client. Ví dụ:

  • Availability: tỷ lệ request thành công trên tổng request hợp lệ.
  • Latency: tỷ lệ request hoàn thành dưới ngưỡng, ví dụ p95 dưới 300ms.
  • Freshness: dữ liệu được cập nhật trong vòng N phút.
  • Durability: tỷ lệ event không mất khi publish qua queue hoặc outbox.
  • Correctness: tỷ lệ response đúng nghiệp vụ, không chỉ HTTP 200.

Một lỗi phổ biến là lấy CPU, memory hoặc số pod healthy làm SLI chính. Chúng hữu ích cho vận hành, nhưng không đủ nói người dùng có đang nhận dịch vụ tốt hay không.

SLO là mục tiêu có thể đo và có thể vi phạm

SLO (Service Level Objective) là target cho SLI trong một khoảng thời gian. Ví dụ: “99.9% request tạo đơn hàng trong 30 ngày phải trả response thành công trong 500ms”. SLO tốt có ba thành phần: chỉ số đo, ngưỡng đạt/không đạt, và cửa sổ thời gian.

Đừng đặt SLO 100%. Mục tiêu tuyệt đối thường khiến alert nhiễu, team sợ deploy và không còn chỗ cho trade-off. Một SLO tốt phải đủ cao để bảo vệ người dùng, nhưng đủ thực tế để team vẫn ship được sản phẩm.

Error budget là ngân sách lỗi được phép tiêu

Error budget là phần còn lại giữa 100% và SLO. Nếu SLO availability là 99.9% trong 30 ngày, error budget là 0.1% request hoặc thời gian không đạt. Khi budget còn nhiều, team có thể ưu tiên feature mạnh hơn. Khi budget cháy nhanh, team cần chuyển sang reliability work: giảm lỗi, tối ưu latency, sửa retry, cải thiện rollout, hoặc thêm guardrail.

Vì sao SLI/SLO tốt hơn alert theo cảm giác?

Nhiều hệ thống có hàng chục alert nhưng vẫn bỏ lỡ incident thật. Lý do là alert được thiết kế từ góc nhìn hạ tầng, không phải từ góc nhìn dịch vụ. CPU 90% có thể không ảnh hưởng người dùng nếu autoscaling xử lý tốt; nhưng 2% request checkout lỗi trong 10 phút có thể là sự cố nghiêm trọng.

SLO ép team trả lời câu hỏi đúng hơn: “người dùng đang mất trải nghiệm ở mức nào?” thay vì “server có đỏ không?”. Đây là cùng tư duy với observability và incident postmortem: đo cái ảnh hưởng tới hệ thống sống, không chỉ cái dễ đo. Anh có thể nối bài này với distributed tracing cho microservices và incident postmortem production engineering để tạo vòng reliability hoàn chỉnh.

Cách chọn SLI cho backend production

Bắt đầu từ user journey quan trọng nhất

Đừng bắt đầu bằng dashboard có sẵn. Hãy liệt kê các luồng quan trọng nhất của sản phẩm:

  • Đăng nhập
  • Tìm kiếm sản phẩm
  • Tạo đơn hàng hoặc thanh toán
  • Gửi message hoặc notification
  • Đồng bộ dữ liệu sang hệ thống khác

Mỗi luồng nên có 1–3 SLI đại diện. Với API tạo đơn hàng, availability và latency thường quan trọng. Với pipeline đồng bộ dữ liệu, freshness và completeness có thể quan trọng hơn latency từng request.

Dùng good events / total events

Một cách định nghĩa SLI bền là tính tỷ lệ event tốt trên tổng event hợp lệ:

SLI = good_events / total_events

Ví dụ latency SLI:
good_events = số request HTTP 2xx hoàn thành dưới 500ms
total_events = số request hợp lệ tới endpoint /orders

Định nghĩa này dễ tính theo log, metrics hoặc tracing. Nó cũng giúp loại trừ request không hợp lệ, bot traffic hoặc lỗi client-side không thuộc trách nhiệm service.

Phân biệt request-based và window-based SLI

Request-based SLI phù hợp với API traffic cao: mỗi request là một event. Window-based SLI phù hợp với service ít traffic hoặc batch job: chia thời gian thành các cửa sổ nhỏ, cửa sổ nào đạt thì tính tốt. Nếu service chỉ có vài request mỗi giờ, request-based SLI có thể dao động quá mạnh.

Đặt SLO như thế nào để không tự làm khó team?

SLO nên dựa trên dữ liệu lịch sử và kỳ vọng người dùng. Nếu 30 ngày gần nhất service chỉ đạt 99.5%, việc tuyên bố 99.99% ngay lập tức thường không có ý nghĩa. Hãy bắt đầu bằng target thực tế, sau đó nâng dần khi hệ thống tốt hơn.

Loại service SLI nên ưu tiên SLO gợi ý ban đầu
Public API quan trọng Availability + latency 99.9% request tốt / 30 ngày
Admin nội bộ Availability 99.0–99.5%
Async worker Freshness + success rate 99% job xử lý dưới 5 phút
Reporting pipeline Completeness + freshness Dữ liệu cập nhật trước 08:00 mỗi ngày

Quan trọng nhất: SLO phải được product và engineering cùng hiểu. Nếu chỉ DevOps tự đặt, nó dễ trở thành metric trang trí.

Tính error budget và burn rate

Giả sử SLO là 99.9% request tốt trong 30 ngày. Error budget là 0.1% request xấu. Nếu trong tháng có 10 triệu request hợp lệ, budget là 10.000 request xấu. Khi lỗi vượt con số này, team đã vi phạm SLO.

error_budget = total_events * (1 - SLO)
consumed_budget = bad_events / error_budget
burn_rate = error_rate / budget_rate

Burn rate cho biết budget đang cháy nhanh hay chậm. Nếu SLO 99.9% nghĩa là budget rate bình thường là 0.1%. Khi error rate hiện tại là 2%, burn rate là 20x. Nếu giữ tốc độ đó, budget tháng sẽ cháy rất nhanh.

Minh họa burn rate nhanh và chậm khi tiêu error budget
Burn-rate alert giúp phát hiện cả sự cố cháy nhanh lẫn lỗi âm ỉ kéo dài.

Thiết kế alert theo burn rate thay vì ngưỡng tĩnh

Alert tốt cần cân bằng hai mục tiêu: phát hiện incident nhanh và tránh đánh thức team vì nhiễu. Một pattern phổ biến là multi-window multi-burn-rate:

  • Fast burn: 5 phút + 1 giờ, burn rate rất cao, báo động khẩn cấp.
  • Slow burn: 30 phút + 6 giờ, burn rate vừa phải nhưng kéo dài, tạo ticket hoặc cảnh báo nhẹ hơn.

Ví dụ Prometheus-style pseudo rule:

# SLO 99.9%, budget 0.1%
# Fast burn: error rate > 14.4x budget trong 5m và 1h
alert: ApiSloFastBurn
expr: |
  rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.0144
  and
  rate(http_requests_total{status=~"5.."}[1h]) / rate(http_requests_total[1h]) > 0.0144
for: 2m

Con số cụ thể cần điều chỉnh theo traffic và mức độ quan trọng của service. Nhưng nguyên tắc là: alert phải gắn với tốc độ tiêu budget, không chỉ một metric vượt ngưỡng bất kỳ.

Dashboard SLO cần có gì?

Một dashboard reliability tốt nên giúp engineer trả lời nhanh 5 câu hỏi:

  1. SLI hiện tại là bao nhiêu so với SLO?
  2. Error budget còn lại bao nhiêu phần trăm?
  3. Budget đang cháy nhanh hay chậm?
  4. Endpoint, region, dependency hoặc tenant nào gây lỗi chính?
  5. Deploy gần nhất, incident hoặc traffic spike có trùng thời điểm không?
Dashboard SLO theo dõi latency availability error rate và error budget
Dashboard nên nối metric với nguyên nhân: deploy, dependency, endpoint, region và tenant.

Dùng error budget để ra quyết định kỹ thuật

Error budget không chỉ để làm đẹp báo cáo. Nó nên ảnh hưởng tới roadmap kỹ thuật:

  • Budget còn khỏe: có thể chấp nhận rollout feature, thử nghiệm, migration có kiểm soát.
  • Budget cháy nhanh: freeze feature rủi ro cao, tập trung sửa lỗi gây burn rate.
  • Budget cạn: ưu tiên reliability sprint, giảm scope release, thêm guardrail trước khi ship tiếp.

Ví dụ, nếu một service liên tục mất budget vì database connection exhaustion, team nên xử lý connection pooling, timeout và load shedding trước khi thêm feature mới. Các bài backpressure và load shedding, bulkhead pattern và database migration zero downtime đều là các mảnh ghép liên quan.

Checklist triển khai SLO cho team

Checklist triển khai SLO từ user journey tới alert policy
Triển khai SLO nên đi từ user journey, không đi từ dashboard có sẵn.
  • Chọn 1–2 service quan trọng nhất trước, không rollout toàn hệ thống cùng lúc.
  • Định nghĩa user journey và event hợp lệ.
  • Chọn SLI gần trải nghiệm người dùng: availability, latency, freshness, correctness.
  • Đặt SLO dựa trên dữ liệu 30–90 ngày gần nhất.
  • Tạo dashboard có SLI, SLO, error budget remaining và burn rate.
  • Thiết kế alert theo burn rate, chia severity rõ ràng.
  • Viết runbook: khi alert SLO cháy thì ai kiểm tra gì trước.
  • Review SLO sau incident và sau mỗi thay đổi kiến trúc lớn.

Những sai lầm phổ biến khi áp dụng SLO

Đặt quá nhiều SLO

Nếu mỗi service có 20 SLO, không ai còn biết cái nào quan trọng. Hãy bắt đầu ít nhưng đúng.

Chọn metric không gắn với người dùng

CPU, memory, pod count là support metric. Chúng không nên thay thế availability, latency hoặc correctness SLI.

Không có quyền ra quyết định từ error budget

Nếu budget cạn nhưng roadmap vẫn ship như cũ, SLO chỉ là dashboard trang trí. Cần thống nhất trước rule: khi nào giảm tốc feature để trả nợ reliability.

Kết luận

SLI, SLO và error budget giúp team production engineering chuyển reliability từ cảm giác sang cơ chế đo lường và ra quyết định. SLI đo trải nghiệm, SLO đặt mục tiêu, error budget tạo ngôn ngữ chung để cân bằng tốc độ phát triển với độ ổn định hệ thống.

Nếu hệ thống của anh đang có alert nhiều nhưng incident vẫn bất ngờ, hãy bắt đầu bằng một service quan trọng, một user journey rõ ràng và một SLO đủ thực tế. Khi đo đúng, team sẽ biết lúc nào nên ship nhanh, lúc nào cần dừng lại để bảo vệ production.