Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là kỹ sư vận hành của một sàn thương mại điện tử lớn ở Việt Nam. Sáng thứ Hai, sếp gọi bạn vào phòng và hỏi: "Hệ thống mình có ổn định không?". Bạn trả lời: "Dạ, em thấy nó chạy khá ổn ạ". Sếp cau mày: "Khá ổn là bao nhiêu phần trăm? Tuần trước có bị chậm không? Nếu tháng này mình downtime thêm 2 tiếng nữa thì có vi phạm cam kết với đối tác không?". Lúc này bạn ú ớ, vì "khá ổn" không phải là một con số, và không thể ra quyết định dựa trên cảm giác.
Đây chính là lý do SLI, SLO, SLA ra đời. Ba khái niệm này là ngôn ngữ chung để đội kỹ thuật, đội kinh doanh và khách hàng cùng nói về độ tin cậy của hệ thống bằng con số cụ thể, thay vì cảm tính. Nếu ở Bài 7 bạn đã hiểu SRE là gì và triết lý "coi độ tin cậy như một tính năng", thì Bài 8 chính là bộ công cụ đo lường cốt lõi để biến triết lý đó thành hành động. Không có SLI/SLO, bạn không thể biết hệ thống có "đủ tốt" hay chưa, không thể biết khi nào nên đầu tư vào ổn định và khi nào nên tăng tốc phát triển tính năng mới.
Nắm vững ba khái niệm này, bạn sẽ trả lời được câu hỏi của sếp một cách tự tin, và quan trọng hơn, bạn sẽ có căn cứ khoa học để ra quyết định vận hành hằng ngày. Đây là kiến thức nền tảng mà bất kỳ SRE, DevOps hay Platform Engineer nào cũng phải thuộc nằm lòng.
Khái niệm cốt lõi
Ba chữ viết tắt nghe rất giống nhau nhưng bản chất khác biệt. Hãy hình dung theo một trình tự logic: bạn đo cái gì đó (SLI), bạn đặt mục tiêu nội bộ cho con số đó (SLO), và bạn cam kết pháp lý với khách hàng dựa trên mục tiêu đó (SLA).
SLI — Service Level Indicator (Chỉ số mức dịch vụ)
SLI là một con số đo lường thực tế về chất lượng dịch vụ, thường được biểu diễn dưới dạng tỷ lệ phần trăm. Nó là "cái nhiệt kế" đo sức khỏe hệ thống. Ví dụ điển hình:
- Availability (tính khả dụng): "Tỷ lệ request HTTP trả về mã 200 trong 5 phút qua". Nếu trong 10.000 request có 9.995 request thành công, SLI = 99,95%.
- Latency (độ trễ): "Tỷ lệ request được phục vụ dưới 300ms". Nếu 98% request nhanh hơn 300ms thì SLI latency = 98%.
- Throughput, Error rate, Durability cũng có thể là SLI tùy loại dịch vụ.
> SLI = (số sự kiện "tốt") / (tổng số sự kiện hợp lệ) × 100%
SLO — Service Level Objective (Mục tiêu mức dịch vụ)
SLO là mục tiêu nội bộ mà bạn đặt ra cho SLI trong một khoảng thời gian nhất định. Nó trả lời câu hỏi: "SLI của tôi cần đạt bao nhiêu thì được coi là đủ tốt?".
Ví dụ: "SLO availability của API thanh toán là 99,9% trong mỗi 30 ngày". Nghĩa là trong 30 ngày, tỷ lệ request thành công phải đạt tối thiểu 99,9%. Nếu SLI thực tế đo được là 99,95% thì bạn đang đạt SLO. Nếu chỉ đạt 99,7% thì bạn đang vi phạm SLO và cần hành động.
SLO là thỏa thuận nội bộ giữa đội kỹ thuật với nhau và với đội sản phẩm. Nó chưa có ràng buộc pháp lý, nhưng nó là "kim chỉ nam" để đội vận hành biết khi nào cần dừng lại sửa hệ thống, khi nào được phép tiếp tục ra tính năng mới. Chính từ SLO mà khái niệm Error Budget (ngân sách lỗi) ra đời — phần này sẽ được đào sâu ở Bài 9, nên ở đây chúng ta chỉ dừng ở mức nhận biết.
Một mẹo quan trọng về "số 9": mỗi số 9 thêm vào đắt hơn số trước rất nhiều.
- 99% = được phép downtime ~7,2 giờ/tháng
- 99,9% ("three nines") = ~43 phút/tháng
- 99,99% ("four nines") = ~4,3 phút/tháng
- 99,999% ("five nines") = ~26 giây/tháng
SLA — Service Level Agreement (Cam kết mức dịch vụ)
SLA là hợp đồng pháp lý giữa nhà cung cấp dịch vụ và khách hàng, kèm theo hậu quả nếu vi phạm — thường là hoàn tiền, giảm giá (service credit) hoặc bồi thường. Ví dụ: "Chúng tôi cam kết availability 99,9% mỗi tháng. Nếu không đạt, khách hàng được hoàn 10% phí dịch vụ tháng đó".
Điểm cần khắc cốt ghi tâm: SLA luôn lỏng hơn SLO. Nếu bạn cam kết SLA 99,9% với khách hàng, thì SLO nội bộ của bạn nên đặt cao hơn, ví dụ 99,95%. Vùng đệm giữa SLO và SLA chính là "phao cứu sinh" — khi bạn vi phạm SLO nội bộ, bạn có thời gian phản ứng trước khi chạm đến ngưỡng vi phạm hợp đồng và mất tiền. Nếu SLO = SLA thì mỗi lần đội kỹ thuật trượt mục tiêu nội bộ là công ty lập tức mất tiền — một thiết kế cực kỳ rủi ro.
Tóm lại mối quan hệ: SLI đo → SLO đặt mục tiêu cho SLI → SLA cam kết với khách (lỏng hơn SLO).
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT "ShopViet" và bài học "số 9 đắt đỏ"
ShopViet (giả định) là một sàn thương mại điện tử tại TP.HCM, xử lý khoảng 2 triệu request/ngày. Ban đầu, đội kỹ thuật nghe theo lời sếp kinh doanh: "Đối thủ cam kết 99,99%, mình phải cam kết 99,99% mới cạnh tranh được". Họ ký SLA 99,99% với các đối tác lớn.
Vấn đề: 99,99% chỉ cho phép ~4,3 phút downtime/tháng. Với hạ tầng hiện tại chạy trên một cụm server ở một data center duy nhất tại Việt Nam, mỗi lần deploy hay bảo trì đã ngốn vài phút. Tháng đầu tiên họ vi phạm ngay, phải hoàn tiền cho ba đối tác, thiệt hại hơn 200 triệu đồng.
Sau khi ngồi lại, đội SRE đo SLI thực tế trong 6 tháng gần nhất: availability trung bình chỉ đạt 99,92%. Họ nhận ra mình đã cam kết một con số hoàn toàn phi thực tế so với năng lực hạ tầng. Giải pháp: hạ SLA xuống 99,9% (an toàn và trung thực hơn), đồng thời đặt SLO nội bộ 99,95% để có vùng đệm. Từ đó, số lần vi phạm hợp đồng giảm về 0 trong suốt năm sau.
Bài học rút ra: Đừng đặt SLA theo cảm hứng marketing hay chạy đua với đối thủ. Hãy đo SLI thực tế trước, rồi mới đặt SLO và SLA dựa trên năng lực thật. Mỗi số 9 tăng thêm có thể đòi hỏi đầu tư gấp nhiều lần về hạ tầng (multi-region, redundancy...).
Ví dụ 2 — Ứng dụng gọi xe "GoRide" và bài học chọn đúng SLI
GoRide (giả định, mô phỏng bối cảnh các ứng dụng gọi xe Đông Nam Á như Grab, Gojek) ban đầu chỉ theo dõi một SLI duy nhất: "tỷ lệ server trả về mã 200". Con số này luôn đẹp, 99,97%, nên đội vận hành rất yên tâm.
Nhưng bộ phận chăm sóc khách hàng liên tục nhận phàn nàn: "Đặt xe xong app quay vòng vòng, mãi không thấy tài xế". Nghịch lý: server trả 200 (thành công về mặt kỹ thuật) nhưng thời gian phản hồi lên tới 8-10 giây — người dùng thực tế đang khổ sở. SLI cũ đo sai thứ cần đo.
Đội SRE bổ sung một SLI mới: latency SLI — tỷ lệ request "tìm tài xế" hoàn tất dưới 3 giây. Khi đo, con số này chỉ đạt 91% — thấp thảm hại so với cảm nhận "mọi thứ đều ổn" trước đó. Họ đặt SLO latency 95% dưới 3 giây, tối ưu lại thuật toán matching và hạ tầng, sau 2 tháng đưa con số lên 96%. Tỷ lệ phàn nàn giảm 40%.
Bài học rút ra: Một SLI availability đẹp không có nghĩa người dùng hài lòng. Hãy chọn SLI phản ánh trải nghiệm thật của người dùng — thường cần cả availability và latency, đôi khi cần cả correctness (kết quả đúng). Đo sai chỉ số thì tối ưu cả năm cũng không giải quyết được nỗi đau của khách.
Ví dụ 3 — Startup fintech và bài học SLO khác nhau cho từng dịch vụ
Một startup fintech tại Hà Nội có nhiều dịch vụ: API thanh toán, trang blog marketing, và hệ thống báo cáo nội bộ. Ban đầu họ áp dụng một SLO chung 99,95% cho tất cả, khiến đội kỹ thuật kiệt sức vì phải chăm sóc cả cái blog như thể nó quan trọng ngang API thanh toán.
Sau khi tư vấn, họ phân tầng SLO theo mức độ quan trọng (criticality):
- API thanh toán: SLO 99,95% availability, latency 99% dưới 500ms. Đây là dịch vụ sống còn, ngừng là mất tiền và mất niềm tin.
- Hệ thống báo cáo nội bộ: SLO 99,5%. Chậm một chút nhân viên vẫn chịu được.
- Blog marketing: SLO 99% là quá đủ. Không ai gọi điện lúc 2 giờ sáng vì blog down.
Bài học rút ra: Không phải dịch vụ nào cũng cần cùng một mức SLO. Phân tầng theo mức độ quan trọng với người dùng và với doanh thu giúp bạn phân bổ nguồn lực hợp lý, tránh over-engineering những thứ không đáng.
Hướng dẫn từng bước
Đây là quy trình thực tế để thiết lập SLI/SLO/SLA cho một dịch vụ.
Bước 1 — Xác định "user journey" quan trọng nhất. Hỏi: người dùng dùng dịch vụ này để làm gì? Với API thanh toán, journey cốt lõi là "gửi yêu cầu thanh toán và nhận xác nhận thành công". Đừng cố đo mọi thứ, hãy tập trung vào vài journey then chốt.
Bước 2 — Chọn SLI phản ánh journey đó. Với mỗi journey, chọn 1-3 SLI. Thường bắt đầu với availability và latency. Viết rõ công thức: cái gì là sự kiện "tốt", cái gì là "tổng số sự kiện". Ví dụ: "SLI = số request thanh toán trả mã 2xx và dưới 500ms / tổng số request thanh toán hợp lệ".
Bước 3 — Đo SLI thực tế trước khi đặt mục tiêu. Thu thập dữ liệu SLI trong ít nhất 2-4 tuần. Đây là bước bị bỏ qua nhiều nhất và cũng là bước gây hại nhất khi bỏ qua. Bạn cần biết mình đang ở đâu trước khi đặt mục tiêu mình muốn tới.
Bước 4 — Đặt SLO dựa trên dữ liệu và kỳ vọng người dùng. Nếu SLI hiện tại là 99,92%, đừng đặt SLO 99,99% ngay — vừa phi thực tế vừa gây áp lực vô ích. Đặt một SLO hơi cao hơn hiện trạng một chút (ví dụ 99,95%) làm mục tiêu cải thiện, hoặc bằng hiện trạng nếu người dùng đã hài lòng.
Bước 5 — Đặt SLA lỏng hơn SLO. Nếu SLO nội bộ là 99,95%, hãy cam kết SLA với khách hàng ở mức 99,9%. Vùng đệm này bảo vệ bạn khỏi việc mất tiền mỗi khi trượt mục tiêu nội bộ.
Bước 6 — Thiết lập đo lường và cảnh báo. Dùng công cụ monitoring (Prometheus, Datadog, Grafana...) để đo SLI liên tục và cảnh báo khi SLI có nguy cơ trượt SLO. Chi tiết về alerting sẽ được học ở Bài 18.
Bước 7 — Review định kỳ. SLO không phải đặt một lần rồi quên. Hằng quý, xem lại xem SLO còn phù hợp không: quá dễ thì thắt chặt, quá khó thì nới lỏng hoặc đầu tư thêm. (Chủ đề SLO Review được đào sâu ở Bài 52.)
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm lẫn SLA với SLO. Rất nhiều người dùng lẫn lộn ba chữ này. Hãy nhớ: SLI là con số đo được, SLO là mục tiêu nội bộ, SLA là cam kết pháp lý có phạt. SLA luôn lỏng hơn SLO.
Lỗi 2 — Đặt SLO = 100%. Không hệ thống nào đạt 100% mãi mãi. Đặt SLO 100% nghĩa là bạn không cho phép bất kỳ lỗi nào, dẫn đến đội sợ deploy, không dám thay đổi gì, và cuối cùng là trì trệ. Một chút "không hoàn hảo" là cần thiết và lành mạnh.
Lỗi 3 — Chọn SLI từ góc nhìn server thay vì người dùng. Đo CPU, RAM, disk là monitoring hạ tầng — hữu ích nhưng không phải SLI. SLI phải đo trải nghiệm người dùng: request có thành công không, có nhanh không, kết quả có đúng không.
Lỗi 4 — Đặt quá nhiều SLI/SLO. Nếu bạn có 30 SLO thì thực chất bạn không có SLO nào cả, vì không ai theo dõi nổi. Bắt đầu với 2-3 SLO cho các journey quan trọng nhất.
Lỗi 5 — Dùng trung bình (average) cho latency. Trung bình che giấu nỗi đau. Nếu 99 request nhanh 100ms và 1 request chậm 10 giây, trung bình vẫn "đẹp". Hãy dùng percentile (p95, p99): "95% request dưới 300ms" phản ánh thực tế tốt hơn nhiều.
Mẹo — Bắt đầu đơn giản, đừng cầu toàn. Một SLO đơn giản được theo dõi thật sự còn giá trị hơn mười SLO hoàn hảo trên giấy mà không ai nhìn tới. Ra mắt phiên bản đầu tiên, rồi tinh chỉnh dần.
Bài tập thực hành
- Phân biệt khái niệm: Với mỗi phát biểu sau, xác định đó là SLI, SLO hay SLA:
- Tính toán "số 9": Nếu SLO của bạn là 99,9% mỗi 30 ngày, tổng thời gian được phép downtime trong tháng là bao nhiêu phút? Nếu nâng lên 99,95% thì còn bao nhiêu?
- Thiết kế SLI: Bạn vận hành API tra cứu điểm thi của một trường đại học. Hãy đề xuất 2 SLI phù hợp (viết rõ công thức "sự kiện tốt / tổng sự kiện") và đề xuất mức SLO hợp lý cho mỗi cái. Giải thích vì sao bạn chọn mức đó.
- Tình huống ra quyết định: Startup của bạn đang cam kết SLA 99,99% nhưng SLI thực tế 3 tháng qua chỉ đạt 99,9%. Bạn sẽ đề xuất gì với ban lãnh đạo và vì sao?
Tóm tắt
- SLI là chỉ số đo lường thực tế chất lượng dịch vụ từ góc nhìn người dùng (ví dụ tỷ lệ request thành công, tỷ lệ request dưới ngưỡng latency). Công thức chuẩn: sự kiện tốt / tổng sự kiện.
- SLO là mục tiêu nội bộ đặt ra cho SLI trong một khoảng thời gian. Nó là kim chỉ nam để đội vận hành ra quyết định.
- SLA là cam kết pháp lý với khách hàng, có hậu quả tài chính khi vi phạm. SLA luôn lỏng hơn SLO để tạo vùng đệm an toàn.
- Quan hệ cốt lõi: SLI đo → SLO đặt mục tiêu → SLA cam kết (lỏng hơn SLO).
- Mỗi "số 9" thêm vào đắt hơn nhiều: 99,9% cho phép ~43 phút downtime/tháng, 99,99% chỉ còn ~4,3 phút.
- Đo SLI thực tế trước khi đặt SLO; phân tầng SLO theo mức độ quan trọng của dịch vụ; tránh SLO = 100%; dùng percentile thay vì average cho latency.