Mở đầu — vì sao bài này quan trọng
Bạn từng nghe câu "hệ thống của tụi mình chạy khá ổn định" chưa? Nghe thì yên tâm, nhưng "khá ổn định" là bao nhiêu phần trăm? 99%? 99,9%? 99,99%? Ba con số này nghe na ná nhau nhưng khoảng cách giữa chúng là cả một thế giới: 99% nghĩa là mỗi năm hệ thống được phép sập tới 3,65 ngày; còn 99,99% chỉ cho phép sập vỏn vẹn 52 phút. Cùng một câu nói "khá ổn định", nhưng đội vận hành hiểu một kiểu, sếp hiểu một kiểu, khách hàng lại kỳ vọng một kiểu khác.
Khi bạn lên vai trò Tech Lead, một trong những trách nhiệm lớn nhất là biến những cảm giác mơ hồ về độ tin cậy thành những con số cụ thể mà cả kỹ sư, quản lý và khách hàng đều đồng thuận. Đó chính là lúc bộ ba SLI, SLO, SLA bước vào cuộc chơi. Đây không phải khái niệm hàn lâm — chúng là công cụ ra quyết định hằng ngày: khi nào được phép ship tính năng mới, khi nào phải dừng lại vá lỗi, khi nào được đánh thức kỹ sư dậy lúc 3 giờ sáng, và khi nào thì không.
Ở bài trước bạn đã học về văn hóa postmortem không đổ lỗi và cách xử lý sự cố. Bài này bổ sung mảnh ghép còn thiếu: làm sao để định lượng độ tin cậy một cách khách quan, để đội của bạn không sống trong cảnh "vá lỗi triền miên" cũng chẳng rơi vào cảnh "quá cẩn thận đến mức không dám release gì". Nắm vững SLI/SLO/SLA là bạn nắm được ngôn ngữ chung giữa engineering và business.
Khái niệm cốt lõi
Ba khái niệm này thường bị dùng lẫn lộn, kể cả bởi kỹ sư nhiều năm kinh nghiệm. Cách dễ nhớ nhất: SLI là thước đo, SLO là mục tiêu bạn tự đặt cho mình, SLA là lời hứa với khách hàng kèm hậu quả nếu thất hứa. Chúng ta đi từng cái.
SLI — Service Level Indicator (Chỉ số mức dịch vụ)
SLI là một con số đo lường được, phản ánh trực tiếp trải nghiệm của người dùng với dịch vụ. Từ khóa quan trọng: đo được và phản ánh trải nghiệm người dùng. Một SLI tốt thường có dạng tỉ lệ: số sự kiện "tốt" chia cho tổng số sự kiện, tính theo phần trăm.
Các họ SLI phổ biến:
- Availability (độ khả dụng): tỉ lệ số request được xử lý thành công. Ví dụ:
số request trả về HTTP 2xx/3xx / tổng số request. - Latency (độ trễ): tỉ lệ số request được phục vụ nhanh hơn một ngưỡng. Lưu ý dùng phân vị (percentile) chứ đừng dùng trung bình. P99 latency = giá trị mà 99% request nhanh hơn nó. Trung bình (average) dễ đánh lừa vì một vài request rất nhanh có thể che giấu những request cực chậm.
- Throughput (thông lượng): số request xử lý được mỗi giây.
- Correctness / Quality (độ đúng đắn): tỉ lệ dữ liệu trả về đúng, không lỗi logic.
- Freshness (độ tươi của dữ liệu): với các hệ thống pipeline dữ liệu, đo dữ liệu cũ tối đa bao nhiêu.
SLO — Service Level Objective (Mục tiêu mức dịch vụ)
SLO là mục tiêu mà bạn đặt ra cho một SLI, trong một khoảng thời gian nhất định. Ví dụ: "99,9% request trong 28 ngày trượt phải có latency dưới 300ms". SLO là lời cam kết nội bộ của đội engineering với chính mình — nó định nghĩa "đủ tốt là bao nhiêu".
Điểm mấu chốt mà nhiều người bỏ qua: SLO không nên đặt 100%. Nghe phản trực giác đúng không? Nhưng 100% availability là mục tiêu bất khả thi và cực kỳ đắt đỏ. Mỗi "số 9" tăng thêm khiến chi phí tăng theo cấp số nhân, trong khi người dùng thường không phân biệt được 99,9% với 99,99%. Việc chấp nhận một tỉ lệ lỗi nhỏ chính là nền tảng của khái niệm quan trọng nhất bài này: error budget (ngân sách lỗi).
Error budget = 100% − SLO. Nếu SLO của bạn là 99,9%, thì error budget là 0,1%. Trong 30 ngày (43.200 phút), 0,1% tương đương khoảng 43 phút được phép "hỏng". Đây là ngân sách mà đội bạn được tiêu. Còn budget thì cứ tự tin release, thử nghiệm, chạy chaos engineering. Hết budget thì đóng băng tính năng mới, dồn toàn lực vào ổn định. Error budget biến cuộc tranh cãi cảm tính "release hay không release" thành một quyết định dựa trên số liệu.
SLA — Service Level Agreement (Thỏa thuận mức dịch vụ)
SLA là một hợp đồng chính thức với khách hàng (thường là khách hàng trả tiền), cam kết một mức dịch vụ tối thiểu, 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. SLA là khái niệm mang tính pháp lý và thương mại, không thuần túy kỹ thuật.
Nguyên tắc vàng: SLA phải 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 đặt ở mức thấp hơn, ví dụ 99,5%. Lý do: bạn cần một vùng đệm. Khi SLI của bạn bắt đầu chạm ngưỡng SLO (99,9%), đội bạn đã có tín hiệu cảnh báo để hành động, trong khi vẫn còn cách xa ngưỡng SLA (99,5%) mà nếu vượt qua sẽ phải đền tiền. SLO là hàng rào cảnh báo sớm; SLA là vực thẳm phải tránh bằng mọi giá.
Tóm gọn mối quan hệ: SLI đo → so với SLO để đội tự quản lý → SLA là mức tối thiểu cam kết ra ngoài, luôn nằm dưới SLO.
Tình huống thực tế
Ví dụ 1 — Sàn thương mại điện tử ShopFast và cú "flash sale" 12/12
ShopFast (giả định) là một sàn TMĐT tại Việt Nam, quy mô tương tự Tiki hồi mới lớn. Trước đây đội engineering chỉ theo dõi "uptime" chung chung và luôn báo cáo "99,95%". Nghe rất đẹp. Nhưng khách hàng vẫn phàn nàn "app lag lúc thanh toán".
Vấn đề: uptime tổng thể che giấu điểm đau thật sự. Server có chạy, trang chủ có load, nên uptime tính là "up". Nhưng riêng service checkout thì P99 latency lên tới 4 giây trong giờ cao điểm. Tech Lead mới về đã định nghĩa lại SLI theo hành trình quan trọng của người dùng: tách riêng SLI cho "thời gian hoàn tất thanh toán". SLO đặt ra: 99% giao dịch thanh toán hoàn tất dưới 2 giây trong cửa sổ 28 ngày.
Với con số này, error budget cho 28 ngày là 1% số giao dịch. Trong đợt sale 12/12, họ theo dõi budget theo thời gian thực. Khi budget cháy tới 70% chỉ trong 3 tiếng đầu, đội lập tức kích hoạt kế hoạch giảm tải: tắt tạm các tính năng gợi ý sản phẩm tốn tài nguyên để nhường CPU cho luồng thanh toán. Nhờ đó họ giữ được SLO tới cuối đợt sale.
Bài học: đo đúng hành trình người dùng quan trọng (critical user journey), đừng đo chỉ số tổng gộp dễ gây ảo giác. Error budget cho phép ra quyết định đánh đổi ngay trong lúc dầu sôi lửa bỏng, thay vì tranh cãi cảm tính.
Ví dụ 2 — Startup fintech PayViet và cái bẫy SLA quá tham vọng
PayViet (giả định) là startup cổng thanh toán. Để giành hợp đồng với một ngân hàng lớn, đội sales đã hứa SLA 99,99% availability — nghe rất oách để chốt deal. Vấn đề: đội engineering chưa từng được hỏi ý kiến, và hạ tầng lúc đó chỉ chạy trên một region duy nhất, không có failover.
99,99% nghĩa là cả năm chỉ được sập tối đa khoảng 52 phút. Nhưng chỉ riêng một lần nâng cấp database có kế hoạch cũng ngốn 30 phút downtime. Cộng thêm vài sự cố ngoài dự kiến, họ vi phạm SLA ngay trong quý đầu và phải trả credit phạt lớn.
Sau bài học đắt giá, Tech Lead thiết lập lại kỷ luật: SLO nội bộ đặt 99,95%, còn SLA cam kết ra ngoài chỉ 99,9% — để có vùng đệm. Đồng thời họ ra một quy tắc bất di bất dịch: không con số SLA nào được ký với khách hàng trước khi engineering xác nhận khả thi về mặt kỹ thuật và chi phí. Họ cũng phân biệt rõ downtime có kế hoạch (maintenance window được thông báo trước) và downtime ngoài ý muốn khi tính SLA.
Bài học: SLA là cam kết pháp lý có tiền thật đằng sau, phải luôn lỏng hơn SLO và phải do engineering xác nhận. Đừng để đội sales tự hứa những con số mà hệ thống không kham nổi.
Ví dụ 3 — Đội nội bộ Grab-style và cuộc chiến "feature vs stability"
Một đội platform tại một công ty gọi xe kiểu Đông Nam Á thường xuyên xảy ra căng thẳng: Product muốn ship nhanh, SRE muốn ổn định. Mỗi lần có sự cố, hai bên lại đổ lỗi cho nhau, cuộc họp nào cũng căng.
Giải pháp: họ áp dụng chính sách error budget một cách chính thức. SLO cho service định vị tài xế: 99,9% trong 30 ngày. Chính sách được cả Product và Engineering ký: còn error budget thì Product toàn quyền quyết định tốc độ release; hết budget thì tự động đóng băng mọi tính năng mới, cả đội chỉ làm việc ổn định hóa cho tới khi budget hồi phục.
Kết quả bất ngờ: các cuộc tranh cãi cảm tính biến mất. Không còn ai phải "cãi nhau" nữa, vì con số error budget đã tự nói. Khi budget còn dồi dào, chính SRE cũng thoải mái cho release. Khi budget cạn, chính Product cũng tự giác dừng lại vì đó là luật chung, không phải ai đó "làm khó".
Bài học: error budget là công cụ chính trị mạnh mẽ, biến mâu thuẫn giữa các bên thành một quyết định dựa trên dữ liệu được thống nhất trước. Đây là giá trị lớn nhất mà SLO mang lại cho một tổ chức.
Hướng dẫn từng bước
Đây là quy trình thực tế để bạn thiết lập SLI/SLO cho một dịch vụ:
Bước 1 — Xác định các critical user journey. Đừng bắt đầu bằng metric, hãy bắt đầu bằng câu hỏi: "Người dùng dùng dịch vụ này để làm gì quan trọng nhất?" Ví dụ với app đọc báo: mở bài viết, xem trang chủ. Với app thanh toán: hoàn tất giao dịch, kiểm tra số dư.
Bước 2 — Chọn SLI cho từng journey. Với mỗi hành trình, chọn 1–3 SLI phản ánh trải nghiệm: thường là cặp availability + latency. Viết rõ công thức: tử số (sự kiện tốt) và mẫu số (tổng sự kiện). Ví dụ: "tỉ lệ request GET /article/* trả về 2xx trong dưới 500ms".
Bước 3 — Đo baseline trước khi đặt mục tiêu. Đừng đặt SLO trên trời. Thu thập dữ liệu 2–4 tuần để biết hệ thống hiện đang chạy ở mức nào. Nếu thực tế đang là 99,5%, đừng đặt SLO 99,99% ngay — hãy đặt mục tiêu thực tế rồi cải thiện dần.
Bước 4 — Đặt SLO và tính error budget. Chọn con số SLO hợp lý dựa trên baseline và kỳ vọng người dùng. Tính ra error budget bằng phút/giờ trong cửa sổ thời gian (thường 28–30 ngày trượt). Ghi con số này ra rõ ràng.
Bước 5 — Thiết lập đo lường và cảnh báo. Dùng công cụ như Prometheus + Grafana, Datadog, hoặc Google Cloud Monitoring để đo SLI liên tục. Cấu hình alert dựa trên tốc độ tiêu hao error budget (burn rate) — cảnh báo khi budget cháy quá nhanh, chứ không phải cảnh báo mỗi lần có một lỗi lẻ.
Bước 6 — Viết error budget policy và SLA (nếu cần). Thống nhất với các bên: điều gì xảy ra khi hết budget. Nếu có khách hàng trả tiền, thiết lập SLA lỏng hơn SLO, có sự phê duyệt của engineering, và định nghĩa rõ hậu quả vi phạm.
Bước 7 — Review định kỳ. Mỗi quý xem lại: SLO có còn hợp lý không? Có đang đặt quá dễ (lúc nào cũng đạt) hay quá khó (lúc nào cũng cháy)? Điều chỉnh cho khớp thực tế.
Lỗi thường gặp & mẹo
Lỗi 1 — Đặt SLO 100%. Đây là sai lầm kinh điển. 100% nghĩa là không có error budget, nghĩa là không được phép release gì cả (mọi thay đổi đều mang rủi ro). Luôn chừa một khoảng error budget.
Lỗi 2 — Dùng trung bình (average) thay vì percentile cho latency. Trung bình che giấu những trải nghiệm tệ nhất. Một service có latency trung bình 100ms nghe rất ổn, nhưng nếu P99 là 5 giây thì 1% người dùng đang khổ sở. Luôn dùng P95, P99.
Lỗi 3 — Nhầm lẫn SLA và SLO, đặt chúng bằng nhau. SLA luôn phải lỏng hơn SLO. Nếu bằng nhau, bạn không có vùng đệm cảnh báo và sẽ đền tiền ngay khi vừa vượt mục tiêu nội bộ.
Lỗi 4 — Đo chỉ số hệ thống thay vì trải nghiệm người dùng. CPU, RAM, disk là metric vận hành, không phải SLI. SLI phải phản ánh cái người dùng cảm nhận.
Lỗi 5 — Có quá nhiều SLO. Nếu mỗi service có 20 SLO, không ai theo dõi nổi và chúng mất ý nghĩa. Tập trung vào vài SLO cho các hành trình quan trọng nhất.
Mẹo hay:
- Chọn cửa sổ trượt (rolling window) 28 ngày thay vì theo tháng lịch — tránh hiệu ứng "reset budget đầu tháng" khiến đội bất cẩn.
- Cảnh báo dựa trên burn rate (tốc độ đốt budget), không phải trên từng lỗi đơn lẻ. Cảnh báo "đang đốt budget nhanh gấp 10 lần bình thường" hữu ích hơn nhiều so với "vừa có 1 request lỗi".
- Phân biệt downtime có kế hoạch và ngoài ý muốn khi tính SLA, và ghi rõ điều này trong hợp đồng.
- SLO là tài liệu sống, không phải bia đá. Điều chỉnh khi hệ thống và kỳ vọng thay đổi.
Bài tập thực hành
- Tính error budget. Một service có SLO availability 99,9% trong cửa sổ 30 ngày. Tính error budget theo phút. (Gợi ý: 30 ngày = 43.200 phút; 0,1% của 43.200 là bao nhiêu?) Sau đó tính lại cho SLO 99,95% và 99,99%, so sánh sự chênh lệch.
- Định nghĩa SLI cho app quen thuộc. Chọn một ứng dụng bạn dùng hằng ngày (ví dụ ví MoMo, app ngân hàng, Shopee). Liệt kê 2 critical user journey, và với mỗi journey viết ra một SLI cụ thể kèm công thức tử số/mẫu số.
- Thiết kế cặp SLO–SLA. Giả sử bạn là Tech Lead của một API cho đối tác doanh nghiệp. Baseline availability đo được là 99,92%. Hãy đề xuất: con số SLO nội bộ nên là bao nhiêu, và SLA cam kết với đối tác nên là bao nhiêu? Giải thích tại sao lại có khoảng cách giữa hai con số.
- Viết error budget policy. Soạn một đoạn chính sách ngắn (5–7 dòng) mô tả: khi error budget còn trên 50% thì đội được làm gì, khi còn dưới 20% thì phải làm gì, và khi cháy sạch thì điều gì xảy ra.
Tóm tắt
- SLI là chỉ số đo được phản ánh trải nghiệm người dùng (availability, latency P99, freshness...). Đo cái người dùng cảm nhận, không đo chỉ số hệ thống.
- SLO là mục tiêu bạn tự đặt cho SLI trong một cửa sổ thời gian. Không bao giờ đặt 100%; phần chênh so với 100% chính là error budget — ngân sách cho phép hỏng, là nền tảng để cân bằng giữa tốc độ và độ ổn định.
- SLA là cam kết pháp lý với khách hàng kèm hậu quả nếu vi phạm. SLA phải luôn lỏng hơn SLO để có vùng đệm, và phải được engineering xác nhận trước khi ký.
- Mối quan hệ: SLI đo → so với SLO (quản lý nội bộ) → SLA là mức tối thiểu ra ngoài, nằm dưới SLO.
- Giá trị lớn nhất: error budget biến những tranh cãi cảm tính "release hay không" thành quyết định dựa trên dữ liệu mà cả Product lẫn Engineering đều đồng thuận từ trước.