SLO là gì? đặt SLO theo Latency và Error rate

SLO (Service Level Objective) là mục tiêu định lượng cho chất lượng service, thường được đo bằng một SLI (Service Level Indicator) trong một khoảng thời gian xác định.

Trong DevOps và SRE, SLO giúp team thống nhất thế nào là đủ tốt, ưu tiên reliability work đúng chỗ, và tránh tranh luận cảm tính khi production có incident.

Ví dụ: Bạn chọn SLI là tỉ lệ request thành công cho một API quan trọng, tính theo status code. Bạn đặt SLO là 99.9% trong window 30 ngày.

Nếu trong 30 ngày có tổng 10,000,000 request và có 9,995,000 request thành công, SLI là 99.95% và SLO đang đạt.

Nếu SLI tụt xuống dưới 99.9% trong window, SLO bị vi phạm.

SLO phản ánh mục tiêu reliability gắn với user impact, chứ không phải mục tiêu nội bộ theo cảm giác.

SLO cho biết điều gì?

SLO giúp trả lời nhanh các câu hỏi cơ bản:

Service đang đạt mức reliability mục tiêu hay không?
User impact đang tiêu tốn error budget nhanh hay chậm?
Khi nào nên ưu tiên reliability work thay vì tiếp tục tăng release velocity?

Tuy nhiên, cần lưu ý: SLO không tự tạo ra reliability. Nếu SLI đo sai, window không phù hợp, hoặc target đặt lệch, SLO sẽ dẫn đến quyết định sai.

SLO khác SLI và SLA ra sao?

SLO thường được hiểu cùng các khái niệm sau:

SLI: chỉ số đo service level, ví dụ availability, Latency, Error rate, freshness, correctness.
SLO: mục tiêu cho SLI trong một window, ví dụ 99.9% trong 30 ngày, hoặc p95 Latency dưới 300ms trong 7 ngày.
SLA: cam kết với khách hàng, thường có điều khoản và hậu quả nếu vi phạm.

Gợi ý thực tế: nhiều team bắt đầu với SLI và SLO trước. SLA chỉ nên đặt khi bạn đã đo ổn, vận hành ổn, và hiểu rõ risk.

Cách đặt SLO

Một số nguyên tắc cơ bản khi đặt SLO:

Bắt đầu từ user journey quan trọng, chọn service và endpoint có user impact rõ.
Chọn SLI dễ đo và ít tranh cãi, ví dụ request success rate hoặc Latency theo percentile.
Chọn window phù hợp, ví dụ 7 ngày hoặc 30 ngày, và giữ nhất quán để so sánh theo thời gian.
Target không nên đặt theo mong muốn, mà nên dựa trên baseline và năng lực vận hành hiện tại.

Ví dụ:

SLI là request success rate theo 2xx, 3xx và 4xx hợp lệ, tách 5xx ra làm lỗi server side.
SLI là p95 Latency cho một endpoint quan trọng, đo tại service hoặc đo tại API Gateway tuỳ mục tiêu.

Error budget liên quan gì tới SLO?

Error budget là phần sai số được phép trong window khi bạn đặt SLO.

Ví dụ: SLO 99.9% trong 30 ngày nghĩa là bạn chấp nhận 0.1% request không đạt SLI trong window đó.

Error budget giúp chuyển câu hỏi từ việc có incident hay không sang câu hỏi user impact đang tiêu tốn budget nhanh hay chậm. Từ đó team có cơ sở để:

Freeze release khi budget bị burn quá nhanh
Ưu tiên remediation và reliability work
Chấp nhận rủi ro có kiểm soát khi budget còn dư

Cách hiểu SLO trong production

Một số nguyên tắc cơ bản khi đọc SLO:

Nên xem SLO theo service và theo user journey, không chỉ nhìn một SLO tổng cho cả hệ thống.
Nên breakdown theo endpoint, region, tenant nếu kiến trúc yêu cầu, để tránh bị gộp chung và khó khoanh vùng.
Nên đọc SLO kèm Metrics như RPS, Latency, Error rate để hiểu vì sao budget đang burn.

Ví dụ:

SLO vẫn đạt nhưng error budget burn tăng rõ: có thể có incident nhỏ lặp lại, cần triage sớm.
SLO vi phạm nhưng chỉ ảnh hưởng một endpoint: cần breakdown theo endpoint để xác định scope thật.
SLO ổn nhưng on-call nhiều page: alert rule có thể chưa bám vào user impact, cần chỉnh alerting.

SLO thường được đo ở đâu?

Tuỳ SLI bạn chọn, SLO có thể được đo tại:

Load balancer / Ingress / API Gateway: phản ánh user facing signals, phù hợp cho SLI gắn với trải nghiệm user.
Service level: phù hợp khi bạn cần tách rõ trách nhiệm giữa các service hoặc muốn đo chính xác behavior của service.
Client side telemetry: phù hợp cho một số user journey đặc thù, nhưng cần quản lý sampling và dữ liệu.

Trong vận hành thực tế, nên chọn 1 đến 2 measurement point chính, ghi rõ định nghĩa để tránh tranh cãi.

Những yếu tố có thể làm SLO bị sai hoặc khó dùng

Một số nguyên nhân phổ biến khiến SLO không phát huy tác dụng:

SLI không gắn với user impact, hoặc đo ở điểm không đúng, dẫn đến SLO đẹp nhưng user vẫn complain.
Target quá cao ngay từ đầu, dẫn đến liên tục vi phạm và team bị mệt.
Target quá thấp, SLO luôn đạt nhưng không thúc đẩy cải thiện.
Gộp nhiều endpoint khác nhau vào một SLI chung, làm bạn không thấy endpoint nào đang là nguyên nhân chính.
Không có quy tắc xử lý error budget, dẫn đến SLO chỉ để xem, không ra quyết định.

Vì vậy, SLO nên đi kèm policy rõ ràng về error budget và review định kỳ.

SLO được dùng để làm gì trong DevOps?

Ở mức cơ bản, SLO thường được dùng cho:

Định nghĩa mục tiêu reliability và ưu tiên roadmap.
Làm tiêu chuẩn cho alerting theo burn rate, giảm paging không cần thiết.
Ra quyết định release velocity dựa trên error budget.
Làm nền cho postmortem và action item, tập trung vào giảm user impact.

Kết luận

SLO là cách đặt mục tiêu reliability dựa trên SLI trong một window, giúp team ra quyết định dựa trên dữ liệu và user impact.

Để SLO có giá trị trong production, bạn cần chọn SLI đúng, đo nhất quán, đặt target hợp lý, và dùng error budget như một cơ chế điều phối giữa release velocity và reliability work.