SLA uptime là gì? Cách tính và mức cam kết hợp lý

SLA uptime là cam kết về tỷ lệ thời gian hệ thống phục vụ được, tính bằng thời gian phục vụ chia tổng thời gian đo. Cùng một con số 99,9% có thể cho phép vài phút hoặc vài giờ mất dịch vụ, tuỳ cách đo và cách loại trừ bảo trì.

Tóm tắt nhanh

• Uptime chỉ có nghĩa khi đi kèm ba thứ: cửa sổ đo, định nghĩa "không phục vụ được", và danh sách khoản loại trừ.
• Chênh lệch giữa 99,9% và 99,99% là gấp mười lần thời gian được phép mất dịch vụ, không phải một phần trăm.
• Đo theo phút che mất sự cố ngắn; đo theo yêu cầu phản ánh đúng trải nghiệm người dùng hơn.
• Bốn khoản loại trừ phổ biến có thể biến một cam kết 99,9% thành hiệu lực thấp hơn nhiều.
• Mức cam kết hợp lý phụ thuộc thiệt hại mỗi giờ gián đoạn, không phụ thuộc mong muốn.

Công thức và chỗ nó bắt đầu sai

Công thức chuẩn là thời gian hệ thống phục vụ được chia cho tổng thời gian trong cửa sổ đo, nhân một trăm. Công thức này không sai về toán học; nó chỉ không nói gì về ba biến số quyết định kết quả.

Biến số thứ nhất là định nghĩa "phục vụ được". Một trang trả về mã 200 nhưng mất 12 giây vẫn tính là phục vụ được theo phép đo chỉ kiểm tra mã phản hồi, trong khi người dùng đã bỏ đi từ giây thứ ba. Biến số thứ hai là mẫu đo: kiểm tra mỗi phút một lần bỏ lọt sự cố 40 giây, kiểm tra mỗi giây lại tạo ra hàng triệu điểm dữ liệu cần lưu. Biến số thứ ba là khoản loại trừ, và đây là nơi phần lớn tranh chấp phát sinh.

Một cách kiểm tra nhanh: lấy ba sự cố gần nhất trong log, tính lại uptime theo định nghĩa trong hợp đồng, rồi tính lại theo định nghĩa mà người dùng cảm nhận. Nếu hai con số lệch nhau nhiều, cam kết đang đo hệ thống chứ không đo dịch vụ.

Cửa sổ đo quyết định ý nghĩa của con số

Cùng một tỷ lệ, cửa sổ càng dài thì thời gian được phép mất dịch vụ càng lớn. Đây là lý do một cam kết "99,9% mỗi năm" dễ chịu hơn nhiều so với "99,9% mỗi tháng", dù chữ số giống nhau.

Bảng này cho thấy hai điều thường bị bỏ qua. Thứ nhất, 99,9% theo tháng chỉ cho phép khoảng 43 phút, nghĩa là một sự cố lớn đã dùng hết hạn mức của cả tháng. Thứ hai, để giữ 99,99% theo tháng, hệ thống phải xử lý sự cố trong vòng vài phút, kể cả ban đêm, và điều đó cần người trực chứ không chỉ cần công cụ.

Cửa sổ đo cũng quyết định cách tính điểm. Cửa sổ trượt 30 ngày liên tục công bằng hơn cửa sổ tháng dương lịch, vì sự cố ngày 31 không bị đẩy sang tháng sau và không tự biến mất khi sang tháng mới.

Bốn khoản loại trừ biến 99,9% thành con số khác

Khoản loại trừ là phần thời gian không được tính vào mẫu số. Viết rộng, chúng biến cam kết thành hình thức. Bảng dưới so sánh cách viết thường gặp với cách viết nên đàm phán.

Điểm cần nhớ: một khoản loại trừ hợp lý vẫn nên có, vì không ai chịu trách nhiệm được cho sự cố của đường truyền quốc tế. Vấn đề là khoản loại trừ phải có điều kiện kiểm chứng được, không phải một câu miễn trừ chung.

Độ chi tiết phép đo: theo phút, theo yêu cầu, theo người dùng

Ba cách đo cho ba con số khác nhau trên cùng một sự cố, và không cách nào đúng tuyệt đối. Chọn theo thiệt hại bạn muốn phát hiện.

Đo theo phút phù hợp với hệ thống nội bộ, nơi gián đoạn vài chục giây không ảnh hưởng giao dịch. Nó rẻ, dễ giải thích và dễ đối chiếu, nhưng che mất các sự cố ngắn lặp lại nhiều lần trong ngày.

Đo theo yêu cầu phù hợp với hệ thống bán hàng, nơi mỗi lần lỗi là một đơn hàng có thể mất. Tỷ lệ lỗi yêu cầu thường nhạy hơn uptime theo phút, vì một thành phần phụ hỏng có thể làm 8% yêu cầu thất bại trong khi máy chủ vẫn "đang chạy".

Đo theo người dùng phù hợp với hệ thống có nhiều nhóm người dùng khác nhau. Một lỗi chỉ ảnh hưởng nhóm kế toán vẫn là sự cố nghiêm trọng với nhóm đó, dù tỷ lệ lỗi toàn hệ thống rất thấp. Cách đo này đắt hơn vì cần gắn sự kiện với nhóm người dùng, nhưng nó là cách duy nhất nhìn thấy sự cố cục bộ.

Trong thực tế, nên chọn một chỉ số chính ghi vào hợp đồng và hai chỉ số phụ để theo dõi nội bộ. Ghi cả ba vào hợp đồng sẽ tạo ra ba cách tranh luận khi có sự cố.

Cách đọc một cam kết uptime trong hợp đồng

Đọc theo thứ tự sau, và dừng ở điểm đầu tiên không rõ ràng.

1. Tỷ lệ cam kết và cửa sổ đo: bao nhiêu phần trăm, tính theo tháng dương lịch hay cửa sổ trượt.
2. Định nghĩa "không phục vụ được": dựa trên mã phản hồi, thời gian phản hồi, hay tỷ lệ yêu cầu thất bại.
3. Nguồn dữ liệu: ai đo, bằng công cụ nào, dữ liệu lưu bao lâu và có được cung cấp khi có tranh chấp không.
4. Danh sách khoản loại trừ, kèm điều kiện kiểm chứng cho từng khoản.
5. Chế tài khi vi phạm: giảm phí, gia hạn dịch vụ, hay chỉ ghi nhận. Một cam kết không có chế tài là tuyên bố, không phải nghĩa vụ.
6. Quy trình báo cáo: báo cáo hằng tháng hay chỉ khi bạn yêu cầu, và ai xác nhận số liệu.

Nếu hợp đồng không nói rõ mục 3 và mục 5, hai bên sẽ tranh luận đúng vào lúc không nên tranh luận nhất. Bổ sung hai mục này rẻ hơn nhiều so với xử lý một sự cố kéo dài.

Sai lầm thường gặp khi tự đặt mục tiêu uptime

Sai lầm đầu tiên là đặt mục tiêu theo cảm giác "càng cao càng tốt". Mục tiêu cao hơn năng lực vận hành tạo ra hai hệ quả: hoặc đội ngũ che giấu sự cố để giữ số đẹp, hoặc mọi người bỏ qua báo cáo vì biết nó không phản ánh thực tế.

Sai lầm thứ hai là đo bằng công cụ đặt bên ngoài nhưng lại đối chiếu với log bên trong khi có tranh chấp. Hai nguồn dữ liệu luôn lệch nhau vài phút, đủ để thay đổi kết luận của một sự cố sát ngưỡng.

Sai lầm thứ ba là không tách uptime của từng thành phần. Một hệ thống gồm ba thành phần, mỗi thành phần 99,9%, có uptime tổng thấp hơn 99,9% nếu chúng phụ thuộc tuần tự. Tính theo xác suất, ba thành phần nối tiếp cho khoảng 99,7%, và đó là con số nên ghi vào cam kết nếu kiến trúc chưa có dự phòng.

Sai lầm thứ tư là quên rằng uptime không nói gì về hiệu năng. Hệ thống phản hồi trong 8 giây vẫn đạt uptime cao nhưng không dùng được. Cần một cam kết riêng cho thời gian phản hồi, và nên đọc nó cùng lúc với cam kết uptime.

Cách chọn mức hợp lý là tính thiệt hại mỗi giờ gián đoạn, nhân với số giờ được phép mất ở từng mức, rồi so với chi phí vận hành tăng thêm. Nếu thiệt hại một giờ thấp hơn nhiều so với chi phí duy trì mức cao, cam kết cao chỉ tạo áp lực cho cả hai bên.

Câu hỏi thường gặp

Uptime 99,9% có nghĩa là mỗi tháng được phép mất dịch vụ bao lâu?

Khoảng 43 phút 12 giây nếu tính trên tháng 30 ngày, tương đương 0,1% của 43.200 phút. Con số này ít hơn nhiều so với cảm nhận thông thường, nên một sự cố kéo dài nửa giờ đã dùng gần hết hạn mức của tháng.

Bảo trì định kỳ có được tính vào uptime không?

Thông thường không, nhưng chỉ khi hợp đồng quy định rõ cửa sổ bảo trì, thời lượng tối đa và nghĩa vụ báo trước. Nếu không có ba điều kiện đó, nhà cung cấp có thể đưa bất kỳ lần gián đoạn nào vào diện bảo trì và cam kết mất giá trị thực tế.

Nên chọn cửa sổ đo theo tháng hay theo năm?

Theo tháng nếu bạn cần bảo vệ dòng tiền hằng tháng, ví dụ hệ thống bán hàng. Theo năm nếu hệ thống ít giao dịch và bạn muốn tránh tranh chấp vụn vặt. Cửa sổ trượt 30 ngày là lựa chọn trung dung, công bằng hơn tháng dương lịch vì không có điểm cắt tạo lợi thế cho một bên.

Uptime cao có bảo đảm hệ thống chạy đúng nghiệp vụ không?

Không. Uptime chỉ đo khả năng phản hồi, không đo tính đúng của kết quả. Một hệ thống có thể phản hồi 200 trong 40 mili giây nhưng tính sai tồn kho hoặc ghi sai đơn hàng, và chỉ số uptime sẽ không phát hiện điều đó.

Cập nhật và kiểm chứng

Cập nhật tháng 11/2026. Nội dung được rà soát theo thông lệ vận hành hệ thống và cách diễn giải cam kết dịch vụ thường gặp trong hợp đồng phần mềm. Các phép tính trong bài là số học thuần tuý từ tỷ lệ phần trăm và độ dài cửa sổ đo, không phải cam kết của một nhà cung cấp cụ thể.

Nếu bạn đang cần một cam kết vận hành có định nghĩa rõ và đo được, WinSell nhận vận hành sau bàn giao theo phạm vi đã chốt. Báo giá sau khi chốt phạm vi.

Bài viết liên quan: SLA downtime, SLA trong IT, bảo trì phần mềm là gì, kiến trúc phần mềm là gì và SLA trong phần mềm là gì.