Mở đầu — vì sao bài này quan trọng
Trong đời làm kỹ thuật, gần như ai cũng từng nghe câu quảng cáo hùng hồn: "Hệ thống của chúng tôi đạt uptime 99,99%." Nghe rất oai. Nhưng nếu tôi hỏi bạn: "99,99% uptime nghĩa là hệ thống có đáng tin cậy không?" — thì câu trả lời trung thực phải là: chưa chắc. Một hệ thống có thể "sống" gần như suốt ngày đêm nhưng vẫn làm hỏng 5% giao dịch của khách hàng. Ngược lại, một hệ thống thỉnh thoảng sập vài phút lúc nửa đêm nhưng khi chạy thì gần như không bao giờ trả sai kết quả.
Hai câu chuyện đó nói về hai đại lượng hoàn toàn khác nhau: Availability (tính sẵn sàng) và Reliability (độ tin cậy). Rất nhiều kỹ sư — kể cả người đã đi làm nhiều năm — vẫn dùng lẫn lộn hai từ này, dẫn đến việc thiết kế sai, cam kết SLA sai, và tệ nhất là hứa với sếp hoặc khách hàng những con số mình không thực sự hiểu.
Ở vị trí một người ra quyết định kiến trúc, bạn không được phép lẫn lộn. Khi bạn ký vào một tài liệu ADR nói rằng "hệ thống thanh toán phải đạt 99,95% availability và reliability tối thiểu 99,9%", bạn đang cam kết ngân sách, con người và độ phức tạp vận hành. Bài này sẽ giúp bạn phân biệt rạch ròi hai khái niệm, biết cách tính chúng bằng công thức cụ thể, và quan trọng nhất là biết khi nào nên đầu tư vào cái nào. Đây là kỹ năng nền tảng để sau này bạn đọc được các bài về CAP, về multi-region, về circuit breaker một cách có chiều sâu.
Khái niệm cốt lõi
Availability — hệ thống có đang phục vụ được không
Availability trả lời câu hỏi rất đơn giản: Tại một thời điểm bất kỳ, hệ thống có đang hoạt động và sẵn sàng phục vụ hay không? Nó là tỷ lệ phần trăm thời gian hệ thống ở trạng thái "up" (còn sống) so với tổng thời gian.
Công thức cơ bản nhất:
Availability = Uptime / (Uptime + Downtime)
Ví dụ trong một tháng có 30 ngày (tương đương 43.200 phút), nếu hệ thống chết tổng cộng 43 phút thì:
Availability = (43.200 - 43) / 43.200 = 99,9%
Bảng "số 9" mà bạn cần thuộc lòng — vì nó là ngôn ngữ chung khi bàn về SLA:
| Availability | Downtime mỗi năm | Downtime mỗi tháng |
|---|---|---|
| 99% (hai số 9) | ~3,65 ngày | ~7,2 giờ |
| 99,9% (ba số 9) | ~8,76 giờ | ~43 phút |
| 99,99% (bốn số 9) | ~52,6 phút | ~4,3 phút |
| 99,999% (năm số 9) | ~5,26 phút | ~26 giây |
Availability còn được suy ra từ hai chỉ số vận hành:
- MTBF (Mean Time Between Failures) — thời gian trung bình giữa hai lần hỏng.
- MTTR (Mean Time To Recovery) — thời gian trung bình để phục hồi sau mỗi lần hỏng.
Availability = MTBF / (MTBF + MTTR)
Công thức này cực kỳ hữu ích vì nó cho thấy hai con đường để tăng availability: hoặc làm cho hệ thống ít hỏng hơn (tăng MTBF), hoặc làm cho hệ thống phục hồi nhanh hơn (giảm MTTR). Trong thực tế, giảm MTTR thường rẻ hơn và khả thi hơn nhiều so với việc cố gắng không bao giờ hỏng. Đây là lý do cả ngành đổ tiền vào tự động hóa deploy, health check, auto-restart, alerting nhanh — tất cả đều nhắm vào MTTR.
Reliability — mỗi lần dùng có đúng không
Reliability trả lời một câu hỏi khác hẳn: Khi tôi gửi một request, xác suất nó được xử lý thành công và cho kết quả đúng là bao nhiêu? Reliability là xác suất một thao tác (request, giao dịch, tác vụ) hoàn thành đúng trong một khoảng thời gian xác định, dưới điều kiện xác định.
Cách đo phổ biến nhất trong hệ thống web hiện đại là success rate (tỷ lệ thành công):
Reliability = Số request thành công / Tổng số request
Giả sử trong một giờ hệ thống nhận 1.000.000 request, có 500 request trả về lỗi (HTTP 5xx, timeout, sai kết quả) thì:
Reliability = (1.000.000 - 500) / 1.000.000 = 99,95%
Lưu ý sự khác biệt tinh tế nhưng cực kỳ quan trọng: hệ thống này có thể "up" 100% thời gian — server không bao giờ sập — nhưng vẫn chỉ đạt reliability 99,95% vì 0,05% request bị lỗi do bug, do quá tải cục bộ, do một node trong cụm trả sai. Availability không bắt được vấn đề này, nhưng reliability thì có.
Sự khác biệt cốt lõi trong một câu
Hãy khắc ghi cách phân biệt này:
- Availability đo theo thời gian — hệ thống có sống không, đo bằng đồng hồ.
- Reliability đo theo request/sự kiện — mỗi lần dùng có đúng không, đo bằng đếm.
Vì sao không thể chỉ nhìn một con số
Hai hệ thống cùng availability 99,9% có thể mang lại trải nghiệm hoàn toàn khác nhau, tùy vào hình dạng của downtime:
- Hệ thống A: chết đúng một lần 8,76 giờ liên tục trong năm.
- Hệ thống B: chết 87 lần, mỗi lần 6 phút, rải đều cả năm.
Tình huống thực tế
Tình huống 1 — Ví điện tử Việt Nam: server sống nhưng tiền không tới
Hãy hình dung một ví điện tử lớn ở Việt Nam, tạm gọi là "PayViet", trong đợt cao điểm chương trình hoàn tiền cuối tháng. Đội vận hành nhìn dashboard và tự hào: tất cả server đều xanh, load balancer khỏe, uptime tháng này 99,98%. Về mặt availability, gần như hoàn hảo.
Nhưng bộ phận chăm sóc khách hàng lại ngập trong khiếu nại: "Tôi chuyển tiền, app báo lỗi, thử lại thì bị trừ hai lần." Điều tra ra thì trong giờ cao điểm, service kết nối tới ngân hàng đối tác bị timeout khoảng 0,4% số giao dịch. Server PayViet vẫn "sống" — nó nhận request, chạy code — nhưng đầu ra là sai hoặc thất bại.
Đo lại bằng lăng kính reliability: tỷ lệ giao dịch thành công chỉ đạt 99,6%. Với 5 triệu giao dịch mỗi ngày, 0,4% nghĩa là 20.000 giao dịch lỗi mỗi ngày — một con số đủ để tạo khủng hoảng truyền thông.
Bài học rút ra: Availability cao che giấu hoàn toàn vấn đề reliability. Nếu đội PayViet chỉ đặt SLO (mục tiêu) theo uptime, họ sẽ ngủ ngon trong khi khách hàng đang khóc. Bài học là với các hệ thống giao dịch tiền bạc, reliability là chỉ số phải theo dõi hàng đầu, đo bằng success rate của giao dịch nghiệp vụ, không phải bằng việc server có ping được hay không.
Tình huống 2 — Sàn thương mại điện tử Đông Nam Á: một cú sập lớn vs. nhiều cú nhỏ
Một sàn thương mại điện tử khu vực Đông Nam Á, tạm gọi "ShopSEA", ký hợp đồng với đối tác logistics cam kết availability 99,9% cho API tra cứu vận đơn. Nghe thì đủ tốt. Nhưng đối tác chọn cách "tiêu" 0,1% ngân sách downtime bằng một lần bảo trì 8 tiếng liên tục vào ngày thứ Sáu — trùng đúng ngày ShopSEA chạy flash sale 10.10.
Kết quả: trong 8 tiếng vàng của flash sale, khách không tra được đơn hàng, tổng đài quá tải, tỷ lệ hủy đơn tăng vọt. Về mặt hợp đồng, đối tác không vi phạm — họ vẫn giữ đúng 99,9% cả năm. Nhưng thiệt hại kinh doanh cho ShopSEA là khổng lồ.
Sau vụ này, ShopSEA viết lại điều khoản: không chỉ yêu cầu 99,9% availability, mà còn quy định downtime tối đa mỗi lần không quá 5 phút và cấm bảo trì trong khung giờ và ngày cao điểm đã liệt kê. Họ cũng thêm điều khoản về reliability: tỷ lệ response thành công phải trên 99,95%.
Bài học rút ra: Một con số availability trần trụi không đủ để bảo vệ nghiệp vụ. Bạn phải quan tâm tới hình dạng của downtime (frequency và duration), tới khung giờ, và phải ghép thêm reliability vào cam kết. MTTR thấp (mỗi lần hỏng chỉ vài phút) đôi khi quan trọng hơn con số availability tổng.
Tình huống 3 — Startup SaaS: chọn giảm MTTR thay vì đuổi theo "năm số 9"
Một startup SaaS ở TP.HCM cung cấp phần mềm quản lý bán hàng cho các cửa hàng nhỏ. Khách hàng bắt đầu đòi hỏi "uptime 99,99%". Đội kỹ thuật ban đầu định xây multi-region, active-active, thuê thêm người trực đêm — dự toán chi phí tăng gấp ba.
Một kỹ sư có kinh nghiệm ngồi lại và phân tích bằng công thức Availability = MTBF / (MTBF + MTTR). Số liệu quá khứ cho thấy hệ thống hỏng trung bình mỗi 30 ngày một lần (MTBF ≈ 720 giờ), nhưng mỗi lần mất tới 2 giờ để có người phát hiện và khắc phục (MTTR ≈ 2 giờ). Availability khi đó là 720 / (720 + 2) ≈ 99,72%.
Thay vì đổ tiền vào multi-region để tăng MTBF, đội tập trung giảm MTTR: thêm health check tự động, alert qua Telegram trong 30 giây, script auto-restart, và runbook rõ ràng. MTTR giảm từ 2 giờ xuống còn 10 phút (≈ 0,167 giờ). Availability mới: 720 / (720 + 0,167) ≈ 99,977% — đạt gần bốn số 9 mà gần như không tốn thêm hạ tầng.
Bài học rút ra: Khi cần tăng availability, đừng phản xạ ngay lập tức là "thêm redundancy". Hãy phân tích xem bạn đang thua ở MTBF hay MTTR. Giảm MTTR thường rẻ hơn nhiều, và đó là "trái ngọt hái thấp" mà nhiều đội bỏ quên.
Hướng dẫn từng bước
Đây là quy trình để bạn định lượng và đặt mục tiêu cho một hệ thống cụ thể.
- Xác định "đơn vị thành công" của hệ thống. Trước khi tính bất cứ thứ gì, hãy định nghĩa rõ: với hệ thống này, "thành công" nghĩa là gì? Với API là response 2xx trong ngưỡng thời gian cho phép. Với hệ thống thanh toán là giao dịch được ghi nhận đúng một lần. Định nghĩa sai đơn vị này thì mọi con số sau đều vô nghĩa.
- Đo Availability. Thu thập uptime/downtime từ monitoring (Prometheus, CloudWatch, Datadog…). Tính
Availability = Uptime / (Uptime + Downtime). Đồng thời ghi lại số lần hỏng và thời lượng mỗi lần, đừng chỉ giữ con số tổng.
- Đo Reliability. Từ log hoặc metric, đếm tổng request và số request lỗi trong cùng khoảng thời gian. Tính
Reliability = (Tổng - Lỗi) / Tổng. So sánh với availability — nếu reliability thấp hơn availability đáng kể, bạn có vấn đề chất lượng ẩn mà uptime không phát hiện.
- Tính MTBF và MTTR.
MTBF = Tổng thời gian hoạt động / Số lần hỏng.MTTR = Tổng thời gian downtime / Số lần hỏng. Hai con số này cho bạn biết nên đầu tư vào "ít hỏng hơn" hay "phục hồi nhanh hơn".
- Đặt SLO tách biệt cho Availability và Reliability. Đừng gộp làm một. Ví dụ: "Availability ≥ 99,9%, mỗi lần downtime ≤ 10 phút" và "Reliability ≥ 99,95% success rate". Đây là hai cam kết độc lập.
- Xác định error budget và cách tiêu nó. Với SLO 99,9%, ngân sách lỗi là 0,1%. Quyết định trước: được phép bảo trì bao lâu, khung giờ nào, chấp nhận bao nhiêu incident nhỏ. Error budget biến các cuộc tranh cãi cảm tính thành quyết định dựa trên số.
- Đối chiếu chi phí với giá trị nghiệp vụ. Trước khi cam kết thêm một số 9, ước tính chi phí (hạ tầng, con người, độ phức tạp) và so với thiệt hại thực tế nếu không đạt. Nhiều khi 99,9% là quá đủ, và tiền nên dồn vào reliability thay vì availability.
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng lẫn lộn hai từ. Nói "hệ thống reliable 99,99%" trong khi ý thực là uptime. Hệ quả: đặt mục tiêu và đo lường sai. Mẹo: mỗi khi nói tới một con số, tự hỏi "cái này đo theo thời gian hay theo request?" — câu trả lời quyết định đó là availability hay reliability.
Lỗi 2 — Chỉ theo dõi availability, bỏ quên reliability. Rất phổ biến vì availability dễ đo hơn (chỉ cần ping). Nhưng như tình huống PayViet, đây là nơi che giấu những thảm họa tồi tệ nhất. Mẹo: luôn có một dashboard success rate của nghiệp vụ, không chỉ của hạ tầng.
Lỗi 3 — Nhân availability của các thành phần một cách ngây thơ, hoặc quên nhân. Nếu request phải đi qua 5 service nối tiếp, mỗi service 99,9%, thì availability tổng là 0,999^5 ≈ 99,5% — thấp hơn nhiều so với mỗi thành phần. Càng nhiều mắt xích nối tiếp, độ tin cậy tổng càng giảm. Mẹo: dùng redundancy (song song) ở các điểm nghẽn để bù lại; hai bản sao 99% song song cho availability 1 - (0,01 × 0,01) = 99,99%.
Lỗi 4 — Đuổi theo "năm số 9" theo cảm tính. Mỗi số 9 thêm vào có thể tăng chi phí theo cấp số nhân. Mẹo: hỏi "thiệt hại thực tế của một phút downtime là bao nhiêu tiền?" trước khi cam kết. Với đa số hệ thống nội bộ, 99,9% là điểm ngọt.
Lỗi 5 — Bỏ qua hình dạng của downtime. 99,9% bằng một cú sập 8 tiếng khác hoàn toàn 99,9% bằng nhiều cú 5 phút. Mẹo: luôn kèm ràng buộc về thời lượng tối đa mỗi lần và khung giờ cấm bảo trì vào SLA.
Mẹo vàng: Khi cần tăng availability, phân tích Availability = MTBF / (MTBF + MTTR) trước. Giảm MTTR (phát hiện và phục hồi nhanh) hầu như luôn rẻ hơn tăng MTBF (không bao giờ hỏng).
Bài tập thực hành
- Tính availability. Một hệ thống trong 30 ngày (43.200 phút) chết 3 lần, lần lượt 12, 8 và 5 phút. Tính availability, MTBF và MTTR. Hệ thống này đạt mấy số 9? (Gợi ý: tổng downtime 25 phút; availability ≈ 99,942%.)
- Phân biệt hai chỉ số. Một API có uptime 100% trong tháng nhưng trong 2 triệu request có 3.000 request trả về HTTP 500. Availability là bao nhiêu, reliability là bao nhiêu? Giải thích trong 2–3 câu vì sao con số availability lại "đánh lừa" người quản lý.
- Chuỗi nối tiếp. Một luồng thanh toán đi qua 4 service nối tiếp, mỗi service availability 99,95%. Tính availability tổng của luồng. Nếu bạn muốn luồng tổng đạt tối thiểu 99,9%, mỗi service cần đạt tối thiểu bao nhiêu?
- Ra quyết định. Cho một hệ thống MTBF = 240 giờ, MTTR = 4 giờ. Tính availability hiện tại. Bạn có 2 phương án: (A) tăng MTBF lên 480 giờ, hoặc (B) giảm MTTR xuống 1 giờ. Phương án nào cho availability cao hơn? Viết một đoạn ngắn (kiểu ghi chú ADR) lý giải lựa chọn của bạn, có tính tới chi phí thực tế.
- Thiết kế SLO. Cho một hệ thống đặt lịch khám bệnh trực tuyến. Hãy viết một bộ SLO đầy đủ gồm: mục tiêu availability, ràng buộc thời lượng downtime tối đa mỗi lần, mục tiêu reliability, và error budget. Giải thích vì sao bạn chọn các con số đó.
Tóm tắt
Availability và Reliability là hai đại lượng khác nhau và bạn không được phép nhầm lẫn. Availability đo theo thời gian — hệ thống có đang sống và sẵn sàng phục vụ không, tính bằng Uptime / (Uptime + Downtime) hoặc MTBF / (MTBF + MTTR). Reliability đo theo request — mỗi lần dùng có thành công và đúng không, tính bằng tỷ lệ request thành công.
Một hệ thống có thể availability rất cao mà reliability thấp (server sống nhưng trả lỗi), như câu chuyện ví điện tử PayViet — và đó là nơi ẩn giấu những thảm họa nghiệp vụ. Ngược lại, cùng một con số availability nhưng hình dạng downtime khác nhau (một cú lớn vs. nhiều cú nhỏ) cho trải nghiệm hoàn toàn khác, như bài học từ ShopSEA.
Ba nguyên tắc mang về:
- Luôn đặt SLO tách biệt cho availability và reliability, kèm ràng buộc về thời lượng và khung giờ downtime.
- Khi cần tăng availability, phân tích MTBF và MTTR trước; giảm MTTR thường rẻ hơn nhiều so với đuổi theo redundancy để tăng MTBF.
- Đừng đuổi theo "năm số 9" theo cảm tính — mỗi số 9 tốn kém theo cấp số nhân, hãy đối chiếu với giá trị nghiệp vụ thực tế.