Bài 31 — SLI, SLO, SLA — Reliability Targets

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn là DevOps Engineer tại một startup fintech ở TP.HCM. Sáng thứ Hai, CEO gọi bạn vào phòng họp và hỏi: "Hệ thống của chúng ta có ổn định không?". Bạn trả lời: "Dạ ổn ạ, server chạy tốt". CEO hỏi tiếp: "Ổn là bao nhiêu phần trăm? Khách hàng có đang bực bội không? Chúng ta có đang vi phạm cam kết với đối tác ngân hàng không?". Và bạn... im lặng.

Đây chính là lý do bài học này tồn tại. "Ổn định" là một từ mơ hồ. Trong DevOps và đặc biệt là Site Reliability Engineering (SRE), chúng ta không nói chuyện bằng cảm giác — chúng ta nói chuyện bằng con số. Ba khái niệm SLI, SLO, SLA chính là ngôn ngữ chung giúp đội kỹ thuật, đội kinh doanh và khách hàng cùng hiểu nhau về mức độ tin cậy (reliability) của một dịch vụ.

Nếu bạn không định nghĩa được reliability bằng con số, bạn sẽ rơi vào hai cái bẫy kinh điển. Một là chạy theo sự hoàn hảo tuyệt đối (100% uptime) — điều bất khả thi và cực kỳ tốn kém. Hai là để mọi thứ trôi nổi cho đến khi khách hàng rời bỏ bạn. SLI/SLO/SLA giúp bạn tìm ra điểm cân bằng: đủ tin cậy để khách hàng hài lòng, nhưng vẫn còn dư địa để đội phát triển ship tính năng mới nhanh chóng.

Bài học hôm nay sẽ tập trung riêng vào việc định nghĩa các mục tiêu tin cậy (reliability targets): SLI là gì, SLO là gì, SLA là gì, chúng khác nhau ra sao, và làm thế nào để thiết lập chúng cho hệ thống thực tế của bạn.

Khái niệm cốt lõi

Ba khái niệm này thường bị dùng lẫn lộn, nhưng chúng có vai trò rất khác nhau. Cách dễ nhớ nhất: SLI là thước đo, SLO là mục tiêu nội bộ, SLA là lời hứa với khách hàng kèm hậu quả pháp lý/tài chính.

SLI — Service Level Indicator (Chỉ số mức dịch vụ)

SLI là một metric định lượng đo lường một khía cạnh cụ thể của reliability. Nó luôn là một con số, thường được biểu diễn dưới dạng tỷ lệ phần trăm "tốt trên tổng".

Công thức tổng quát:

SLI = (số sự kiện tốt / tổng số sự kiện hợp lệ) × 100%

Các SLI phổ biến nhất trong thực tế:

• Availability (tính sẵn sàng): tỷ lệ request thành công. Ví dụ: (số request trả về HTTP 2xx, 3xx) / (tổng số request) × 100%. Lưu ý ta thường loại HTTP 5xx (lỗi server) khỏi phần "tốt", nhưng giữ nguyên 4xx tùy ngữ cảnh (lỗi phía client thường không tính là lỗi hệ thống).
• Latency (độ trễ): tỷ lệ request được phục vụ nhanh hơn một ngưỡng. Ví dụ: (số request có thời gian phản hồi < 300ms) / (tổng số request). Lưu ý người ta hầu như luôn dùng percentile (p95, p99) chứ không dùng giá trị trung bình (average), vì trung bình che giấu những trải nghiệm tệ của nhóm khách hàng đuôi (tail).
• Throughput / Error rate / Durability: tùy loại dịch vụ mà có thêm các SLI khác như tỷ lệ mất dữ liệu, độ tươi (freshness) của dữ liệu batch, v.v.

Nguyên tắc vàng khi chọn SLI: đo từ góc nhìn của người dùng, không phải từ góc nhìn của máy chủ. CPU 80% không phải là SLI tốt — khách hàng không quan tâm CPU bao nhiêu, họ quan tâm request của họ có thành công và có nhanh hay không.

SLO — Service Level Objective (Mục tiêu mức dịch vụ)

SLO là mục tiêu bạn tự đặt ra cho SLI trong một khoảng thời gian nhất định (thường là 28 hoặc 30 ngày trượt — rolling window). Đây là ngưỡng nội bộ mà đội kỹ thuật cam kết với nhau.

Ví dụ SLO đầy đủ sẽ trông như thế này:

> "99.9% request tới API thanh toán phải trả về thành công, đo trong cửa sổ 30 ngày trượt."

SLO gồm ba thành phần: một SLI (availability), một ngưỡng mục tiêu (99.9%), và một khung thời gian (30 ngày). Thiếu bất kỳ thành phần nào thì SLO đó vô nghĩa.

Con số 99.9% ("three nines") tưởng chừng gần hoàn hảo, nhưng hãy nhìn vào bảng "ngân sách downtime" tương ứng — đây là kiến thức bạn phải thuộc lòng:

Bảng này cho bạn thấy sự thật phũ phàng: mỗi số 9 tăng thêm khiến chi phí và độ phức tạp kỹ thuật tăng theo cấp số nhân. Từ 99.9% lên 99.99% có thể đòi hỏi multi-region, failover tự động, đội on-call nghiêm ngặt — đắt gấp nhiều lần. Vì vậy đừng bao giờ chọn SLO theo kiểu "càng cao càng tốt".

Error Budget — con đẻ của SLO

Khi bạn đặt SLO = 99.9%, bạn ngầm chấp nhận rằng 0.1% còn lại được phép "hỏng". Phần 0.1% đó chính là error budget (ngân sách lỗi) — tổng lượng lỗi/downtime bạn được phép tiêu trong cửa sổ thời gian. Đây là khái niệm cực kỳ quan trọng, và bài học tiếp theo (Bài 32) sẽ đào sâu về chính sách sử dụng error budget. Ở bài này, bạn chỉ cần nắm: SLO đẻ ra error budget, và error budget là cầu nối giữa reliability và tốc độ ship tính năng.

SLA — Service Level Agreement (Thỏa thuận mức dịch vụ)

SLA là một hợp đồng chính thức giữa nhà cung cấp dịch vụ và khách hàng, trong đó cam kết một mức reliability nhất định, và kèm theo hậu quả nếu vi phạm — thường là hoàn tiền, credit dịch vụ, hoặc phạt hợp đồng.

Điểm mấu chốt cần khắc cốt ghi tâm: SLA luôn lỏng hơn SLO. Nếu SLO nội bộ của bạn là 99.9%, thì SLA cam kết với khách hàng nên là 99.5% chẳng hạn. Tại sao? Vì SLO là "báo động sớm" cho đội kỹ thuật — khi bạn chạm ngưỡng SLO, bạn còn thời gian và dư địa để sửa trước khi thực sự vi phạm SLA và phải đền tiền. Nếu đặt SLA bằng đúng SLO, bạn không còn vùng đệm nào cả.

Một điểm nữa: không phải dịch vụ nào cũng cần SLA. SLA chỉ xuất hiện khi có cam kết pháp lý với khách hàng trả tiền (thường là B2B, enterprise). Còn SLI và SLO thì mọi dịch vụ nghiêm túc đều nên có, kể cả các dịch vụ nội bộ.

Tóm gọn mối quan hệ: SLA (lỏng nhất, có pháp lý) > SLO (mục tiêu nội bộ chặt hơn) > SLI (thước đo thực tế đang chạy).

Tình huống thực tế

Ví dụ 1 — Ví điện tử ở Việt Nam đặt SLO cho API thanh toán

Một ví điện tử giả định tên "PayGo" tại Hà Nội xử lý khoảng 5 triệu giao dịch mỗi ngày. Đội SRE ngồi lại xác định SLI cho API thanh toán: tỷ lệ giao dịch trả về thành công trong dưới 800ms.

Ban đầu đội kỹ thuật muốn đặt SLO 99.99%. Nhưng khi tính toán, họ nhận ra 99.99% chỉ cho phép ~4 phút 23 giây downtime mỗi tháng — với hạ tầng hiện tại (single region ở Singapore, chưa có failover tự động), điều này bất khả thi và sẽ khiến đội on-call kiệt sức. Họ chọn SLO = 99.9% (cho phép ~43 phút downtime/tháng), đủ tốt để khách hàng không cảm nhận sự cố, và SLA với các đối tác merchant lớn = 99.5% để có vùng đệm an toàn.

Bài học: SLO phải khớp với năng lực hạ tầng thực tế và sức chịu đựng của đội on-call, không phải khớp với mong muốn viển vông. Và luôn đặt SLA lỏng hơn SLO một bậc.

Ví dụ 2 — Sàn TMĐT đo latency sai bằng average

Một sàn thương mại điện tử ở Đông Nam Á (giả định tên "ShopSEA") báo cáo với ban lãnh đạo rằng "thời gian phản hồi trung bình của trang sản phẩm là 250ms, rất tốt". Nhưng bộ phận chăm sóc khách hàng liên tục nhận than phiền rằng trang tải chậm, đặc biệt vào giờ cao điểm sale.

Khi đội SRE đổi cách đo từ average sang percentile, sự thật lộ ra: p50 = 250ms (nên average trông đẹp), nhưng p99 = 4.2 giây. Nghĩa là cứ 100 lượt xem trang thì có 1 lượt phải chờ hơn 4 giây — với hàng triệu lượt xem mỗi ngày, đó là hàng chục nghìn khách hàng bực bội, nhiều người bỏ giỏ hàng. Họ định nghĩa lại SLI latency theo p95 và đặt SLO: "95% request trang sản phẩm phải hoàn tất dưới 1 giây".

Bài học: Không bao giờ dùng average để đo latency. Average che giấu nhóm đuôi (tail latency). Luôn dùng percentile (p95, p99) vì đó mới phản ánh trải nghiệm của những khách hàng khổ nhất.

Ví dụ 3 — Google và triết lý "reliability vừa đủ"

Google là nơi khai sinh ra khái niệm SRE và error budget. Một nguyên tắc nổi tiếng từ cuốn sách SRE của họ: các dịch vụ tiêu dùng phổ biến như Gmail hay Search không đặt mục tiêu 100% uptime. Lý do rất thực tế: điện thoại của người dùng, mạng WiFi ở quán cà phê, nhà mạng di động — những thứ này đã có độ tin cậy chỉ khoảng 99% đến 99.9%. Nếu dịch vụ của Google đạt 99.999% trong khi thiết bị người dùng chỉ 99%, thì người dùng chẳng cảm nhận được sự khác biệt, mà Google lại tốn kém khủng khiếp để đạt số 9 vô ích đó.

Bài học: Reliability chỉ cần "vừa đủ tốt" so với kỳ vọng và bối cảnh của người dùng. Đặt SLO cao hơn mức người dùng có thể cảm nhận là lãng phí tiền bạc và làm chậm tốc độ đổi mới.

Hướng dẫn từng bước

Đây là quy trình thực tế để thiết lập SLI/SLO cho một dịch vụ của bạn.

Bước 1 — Xác định hành trình người dùng quan trọng (Critical User Journey). Đừng đo mọi thứ. Hãy hỏi: người dùng làm gì quan trọng nhất trên dịch vụ này? Với ví điện tử là "thực hiện giao dịch"; với sàn TMĐT là "xem sản phẩm" và "thanh toán". Chọn 2-3 hành trình cốt lõi.

Bước 2 — Chọn loại SLI phù hợp. Với mỗi hành trình, chọn SLI đo từ góc nhìn người dùng. Thường là availability (tỷ lệ thành công) và latency (tốc độ). Với hệ thống dữ liệu thì thêm freshness hoặc correctness.

Bước 3 — Định nghĩa chính xác "sự kiện tốt". Đây là bước dễ sai nhất. Viết rõ ra: request nào tính vào tổng, response nào tính là "tốt". Ví dụ: "HTTP 200-499 tính là tốt (lỗi 4xx là lỗi client), chỉ 5xx tính là xấu; đo tại load balancer; loại trừ các endpoint health-check".

Bước 4 — Đo baseline trước khi đặt mục tiêu. Đừng bịa số. Hãy để hệ thống chạy và đo SLI thực tế trong vài tuần. Nếu availability thực tế đang là 99.5%, đừng nhảy vọt lên đặt SLO 99.99% — bạn sẽ vi phạm ngay lập tức.

Bước 5 — Chọn SLO dựa trên baseline + kỳ vọng người dùng. Đặt SLO cao hơn baseline một chút để tạo động lực cải thiện, nhưng thực tế. Đối chiếu với bảng downtime để hiểu cam kết vận hành đi kèm.

Bước 6 — Nếu có khách hàng B2B, đặt SLA lỏng hơn SLO. Chừa vùng đệm. SLA 99.5% khi SLO 99.9% là một tỷ lệ đệm hợp lý.

Bước 7 — Đo, theo dõi và review định kỳ. Dựng dashboard hiển thị SLI so với SLO theo thời gian thực. Review lại SLO mỗi quý — nếu bạn luôn vượt SLO quá dễ dàng, có thể SLO quá lỏng; nếu luôn suýt vi phạm, có thể quá chặt hoặc hệ thống cần đầu tư.

Lỗi thường gặp & mẹo

Lỗi 1 — Nhầm lẫn SLA và SLO. Rất nhiều người dùng "SLA" để chỉ mục tiêu nội bộ. Hãy nhớ: SLA là hợp đồng có hậu quả tài chính; SLO là mục tiêu nội bộ. Đặt SLA = SLO là tự đưa mình vào thế nguy hiểm vì không còn vùng đệm.

Lỗi 2 — Đặt SLO 100%. 100% là bất khả thi và cực kỳ tốn kém. Nó cũng loại bỏ hoàn toàn error budget, khiến đội phát triển không dám ship gì cả. Luôn để lại "ngân sách lỗi".

Lỗi 3 — Dùng metric hệ thống làm SLI. CPU, RAM, disk là metric hạ tầng, không phải SLI. SLI phải phản ánh trải nghiệm người dùng. CPU 90% mà request vẫn nhanh và thành công thì khách hàng chẳng quan tâm.

Lỗi 4 — Dùng average cho latency. Như ví dụ ShopSEA, average che giấu tail latency. Luôn dùng percentile.

Lỗi 5 — Đặt quá nhiều SLO. Nếu bạn có 50 SLO, thực chất bạn chẳng có SLO nào — không ai theo dõi nổi. Tập trung vào vài SLO quan trọng nhất cho các hành trình cốt lõi.

Mẹo: Dùng cửa sổ trượt (rolling window) 28 hoặc 30 ngày thay vì theo tháng lịch. Cửa sổ lịch tạo hiệu ứng "reset ngày mùng 1" khiến sự cố cuối tháng bị lãng quên. Cửa sổ trượt phản ánh trung thực hơn.

Mẹo: Viết SLO ra thành văn bản rõ ràng, có người sở hữu (owner), và được cả đội kinh doanh đồng thuận. SLO không phải bí mật của riêng đội kỹ thuật.

Bài tập thực hành

• Tính downtime: Dịch vụ của bạn đặt SLO availability = 99.95% trong cửa sổ 30 ngày. Hãy tính xem bạn được phép có tối đa bao nhiêu phút downtime trong tháng đó. (Gợi ý: 30 ngày = 43.200 phút; đáp án xấp xỉ 21 phút 54 giây.)

• Viết một SLO hoàn chỉnh: Cho một API đăng nhập của app học trực tuyến. Hãy viết ra một SLO đầy đủ ba thành phần (SLI + ngưỡng + khung thời gian) cho cả availability và latency. Định nghĩa rõ "request tốt" là gì.

• Phân biệt tình huống: Với mỗi phát biểu sau, xác định đó là SLI, SLO hay SLA:

(a) "Tuần này API của chúng ta đạt tỷ lệ thành công 99.93%." (b) "Chúng tôi cam kết với khách hàng Enterprise mức uptime 99.5%, nếu vi phạm sẽ hoàn 10% phí tháng." (c) "Đội đặt mục tiêu p95 latency dưới 500ms trong 30 ngày."

• Thiết kế đệm SLA: Đội bạn có SLO nội bộ 99.9%. Hãy đề xuất một con số SLA hợp lý để cam kết với khách hàng và giải thích tại sao lại chừa vùng đệm đó.

• Phản biện: Sếp bạn yêu cầu đặt SLO 99.999% cho một dịch vụ nội bộ chỉ dùng cho báo cáo hàng tuần. Hãy viết một đoạn ngắn phản biện, dựa trên chi phí và kỳ vọng người dùng, đề xuất con số hợp lý hơn.

Tóm tắt

• SLI là thước đo định lượng reliability từ góc nhìn người dùng (tỷ lệ thành công, latency p95/p99). Luôn tính theo "sự kiện tốt / tổng sự kiện".
• SLO là mục tiêu nội bộ bạn tự đặt cho SLI, gồm ba thành phần: SLI + ngưỡng + khung thời gian. SLO đẻ ra error budget.
• SLA là hợp đồng với khách hàng, kèm hậu quả tài chính khi vi phạm. Luôn đặt SLA lỏng hơn SLO để có vùng đệm.
• Mỗi số 9 tăng thêm khiến chi phí tăng theo cấp số nhân; hãy thuộc lòng bảng downtime tương ứng.
• Đừng đặt SLO 100%, đừng dùng average cho latency, đừng dùng metric hệ thống làm SLI, và đừng lẫn lộn SLA với SLO.
• Reliability chỉ cần "vừa đủ tốt" so với kỳ vọng người dùng — cao hơn là lãng phí và làm chậm đổi mới.

Nắm vững ba khái niệm này, bạn đã có ngôn ngữ chung để nói chuyện về độ tin cậy với cả kỹ thuật lẫn kinh doanh. Ở bài tiếp theo, chúng ta sẽ đi sâu vào Error Budget Policy — cách biến 0.1% "được phép hỏng" đó thành một công cụ quản trị mạnh mẽ điều phối giữa tốc độ và ổn định.