SLA là gì?

Mục lục

1. SLA là gì và gồm những gì?
2. SLA khác SLO và SLI ở điểm nào?
3. 99,9% uptime thực sự cho phép ngừng bao lâu?
4. Khi nhà cung cấp không đạt SLA thì bạn nhận được gì?
5. Cách đọc một bản SLA: 8 câu hỏi nên kiểm tra
6. Vì sao SLA tổng của hệ thống thấp hơn SLA từng phần?
7. SLA trong các tình huống thường gặp ở doanh nghiệp Việt Nam
8. Ưu điểm và hạn chế của SLA
9. SLA khác gì với OLA, UC và KPI?
10. Khi nào nên đòi SLA chặt, khi nào không cần?
11. Câu hỏi thường gặp

SLA là gì và gồm những gì?

SLA là viết tắt của Service Level Agreement, dịch là thỏa thuận mức dịch vụ. Theo cách AWS mô tả, đây là hợp đồng quy định mức dịch vụ mà nhà cung cấp cam kết với khách hàng. Nó nêu các chỉ số như thời gian hoạt động, thời gian phản hồi, thời gian xử lý, kèm hướng xử lý khi không đạt, ví dụ hỗ trợ thêm hoặc giảm giá. SLA thường ký giữa khách hàng và nhà cung cấp, nhưng các đơn vị trong cùng một công ty cũng có thể ký với nhau.

Khi nhìn vào một bản SLA thật (ví dụ của dịch vụ đám mây, hosting, đường truyền Internet hoặc phần mềm thuê bao), bạn sẽ thường gặp sáu khối nội dung:

• Phạm vi dịch vụ: SLA áp dụng cho dịch vụ nào, gói nào, khu vực (region) nào. Cùng một nhà cung cấp, mỗi dịch vụ có thể có SLA riêng.
• Chỉ số cam kết: uptime (tỷ lệ thời gian dịch vụ hoạt động), thời gian phản hồi ticket, thời gian khắc phục, độ trễ, tỷ lệ lỗi.
• Cách đo: đo ở đâu, bao lâu một lần, theo tháng hay theo năm, ai cung cấp dữ liệu đo.
• Loại trừ: bảo trì có báo trước, sự cố do phía khách hàng, bất khả kháng, dịch vụ bên thứ ba.
• Bồi hoàn: mức credit theo từng ngưỡng vi phạm, thời hạn và cách gửi yêu cầu.
• Trách nhiệm của khách hàng: cấu hình tối thiểu, báo sự cố đúng kênh, phối hợp chẩn đoán.

Về loại hình, SLA thường chia thành SLA theo khách hàng (gộp mọi dịch vụ một khách hàng dùng), SLA theo dịch vụ (một dịch vụ áp dụng cho mọi khách hàng) và SLA nhiều cấp. Loại SLA nội bộ giữa phòng IT và các phòng ban cũng phổ biến ở doanh nghiệp vừa và lớn.

SLA khác SLO và SLI ở điểm nào?

Ba thuật ngữ này hay bị gộp làm một, nhưng mỗi thứ có người dùng khác nhau. Cách phân biệt gọn nhất: SLI là con số đo được, SLO là đích bạn tự đặt, SLA là lời hứa có hậu quả. Một nguồn kỹ thuật minh họa như sau: SLI là chỉ số thô từ hệ thống giám sát (ví dụ tỷ lệ lỗi HTTP 5xx), SLO là mục tiêu nội bộ (ví dụ tỷ lệ thành công trên 99,95% trong 30 ngày), còn SLA là hợp đồng có hậu quả tài chính.

Vì sao nhà cung cấp tách SLO khỏi SLA? Họ đặt SLO chặt hơn SLA để có “vùng đệm”. Nếu hợp đồng cam kết 99,9% mà đội vận hành nhắm 99,95%, họ sẽ phản ứng trước khi chạm ngưỡng phải bồi hoàn. Nếu bạn là bên mua, hãy hỏi nhà cung cấp có SLO nội bộ nào không, vì đó là dấu hiệu họ đo dịch vụ có hệ thống. Trong vận hành phần mềm, nhóm làm theo văn hóa DevOps và các chỉ số DORA thường theo dõi SLO song song với tần suất triển khai và thời gian khôi phục.

99,9% uptime thực sự cho phép ngừng bao lâu?

Uptime tính theo công thức: (tổng thời gian − thời gian ngừng) / tổng thời gian × 100. Con số nghe rất cao, nhưng phần 0,1% còn lại không nhỏ. Mức 99,9% tương đương khoảng 8 giờ 45 phút ngừng mỗi năm, hoặc 43 phút mỗi tháng. Thêm một chữ số 9 làm giảm 90% lượng ngừng cho phép, nên kéo theo thay đổi về kiến trúc, quy trình xử lý sự cố và kỷ luật đo lường.

Cam kết uptime	Ngừng tối đa / tháng 30 ngày	Ngừng tối đa / năm 365 ngày	Thường gặp ở
99%	khoảng 7,2 giờ	khoảng 87,6 giờ	Gói rẻ, dịch vụ không trọng yếu
99,9%	khoảng 43 phút	khoảng 8 giờ 46 phút	Phần lớn dịch vụ SaaS, cloud tiêu chuẩn
99,95%	khoảng 21,6 phút	khoảng 4 giờ 23 phút	Nền tảng cho bên khác xây dịch vụ
99,99%	khoảng 4,3 phút	khoảng 52,6 phút	Cấu hình nhiều vùng, tự chuyển đổi dự phòng
99,999%	khoảng 26 giây	khoảng 5,3 phút	Hệ thống viễn thông, thanh toán đặc thù

Các số trong bảng do biên tập viên tính từ công thức uptime, làm tròn. Cột “thường gặp ở” chỉ là xu hướng chung, không phải quy định.

Hai chi tiết nhiều người bỏ sót. Thứ nhất là kỳ đo. Cửa sổ đo theo tháng thì phần cho phép được đặt lại mười hai lần mỗi năm, còn cửa sổ đo theo năm cho phép một sự cố dài ăn hết cả ngân sách ngừng. Thứ hai là một tháng có thể luôn nằm trên ngưỡng nhưng tổng cộng lại vẫn mất nhiều giờ, và khi đó bạn không có credit.

Khi nhà cung cấp không đạt SLA thì bạn nhận được gì?

Hầu hết SLA đám mây và phần mềm thuê bao bồi hoàn bằng service credit, tức khoản giảm trừ vào hóa đơn kỳ sau, theo bậc. Ví dụ một bản SLA công khai của Redis Cloud: gói Standard dưới 99,9% nhưng từ 99% trở lên được credit 10%, dưới 99% được credit 25%. Bạn thấy hai điểm đáng chú ý: mức bồi hoàn là phần trăm hóa đơn của chính dịch vụ đó, và nó không phụ thuộc vào thiệt hại thật của bạn.

Một nguồn phân tích SLA mô tả đúng bản chất này: nhà cung cấp có thể hứa 99,9% mà thực tế đạt 98%, và phần bù chỉ là credit do hợp đồng quy định, không theo mức thiệt hại của bạn. Vì vậy, nếu hệ thống của bạn ngừng một giờ vào đợt bán hàng cao điểm, credit có thể thấp hơn nhiều so với doanh thu mất đi. SLA không thay thế kế hoạch dự phòng. Bạn vẫn cần kế hoạch khôi phục sau thảm họa cho các hệ thống trọng yếu.

Cách đọc một bản SLA: 8 câu hỏi nên kiểm tra

Một bản SLA ghi “99,9%” chưa nói được nhiều. Nhận xét từ một bài phân tích cho rằng một SLA hứa 99,9% hầu như chưa cho bạn biết gì cho đến khi bạn hiểu cách đo uptime, cái gì không bị tính, và chuyện gì xảy ra khi hụt. Bạn có thể dùng danh sách sau khi so sánh hai nhà cung cấp:

1. Đơn vị bị đo là gì? Cả nền tảng, hay từng dịch vụ? AWS, chẳng hạn, công bố hơn 300 SLA riêng cho từng dịch vụ thay vì một cam kết chung cho cả nền tảng.
2. Thế nào là “ngừng”? Không truy cập được hoàn toàn, hay chỉ khi tỷ lệ lỗi vượt ngưỡng nào đó? Một dịch vụ chậm nhưng vẫn trả lời có thể không bị tính là ngừng.
3. Kỳ đo là tháng hay năm? Ảnh hưởng trực tiếp đến việc bạn có được credit.
4. Điều kiện kích hoạt cam kết. Ví dụ gói Redis nói trên chỉ áp dụng cho cấu hình có bật sao chép dữ liệu. Cam kết chỉ áp dụng cho triển khai có bật replication và đã chạy tối thiểu 24 giờ. Nhiều SLA đám mây tương tự yêu cầu triển khai nhiều vùng hoặc nhiều bản sao mới được hưởng mức cao.
5. Loại trừ. Bảo trì định kỳ, bất khả kháng, lỗi cấu hình của khách hàng, lỗi của bên thứ ba. Nhà cung cấp hosting công khai ghi rõ 99,9% chỉ bao gồm lỗi mạng và máy chủ do họ kiểm soát, loại trừ bảo trì, lỗi phía khách hàng và sự cố bên thứ ba.
6. Ai cung cấp số liệu đo? Số do nhà cung cấp tự đo hay công cụ giám sát độc lập mà bạn truy cập được.
7. Cách yêu cầu credit. Thời hạn gửi yêu cầu, bằng chứng phải nộp. Thường bạn phải tự khiếu nại, credit không tự áp dụng.
8. Mức trần bồi hoàn. Tổng credit tối đa mỗi tháng, và có được quyền chấm dứt hợp đồng nếu vi phạm lặp lại hay không.

Vì sao SLA tổng của hệ thống thấp hơn SLA từng phần?

Ứng dụng của doanh nghiệp hiếm khi chạy trên một dịch vụ duy nhất. Nó dùng máy chủ, cơ sở dữ liệu, dịch vụ gửi email, đăng nhập, mạng phân phối nội dung. Nếu các thành phần nối tiếp nhau và thiếu một cái là hệ thống hỏng, uptime tổng bằng tích các uptime thành phần. Ba dịch vụ cùng 99,9% cho ra 0,999 × 0,999 × 0,999 ≈ 0,997, tức 99,7%.

Con số khoảng 130 phút một tháng là ước tính cho trường hợp xấu nhất, khi các sự cố không trùng thời điểm. Thực tế, SLA chuỗi còn phụ thuộc cách bạn thiết kế dự phòng. Nếu bạn cần mức cao hơn từng thành phần, bạn thường phải thêm bản sao ở vùng khác hoặc nhà cung cấp khác, xem thêm ở bài về chiến lược đa đám mây. Một phân tích về cloud cũng lưu ý rằng giữa tháng 8/2024 và tháng 8/2025, AWS, Azure và Google Cloud ghi nhận hơn 100 sự cố dịch vụ, và tất cả đều nằm trong phạm vi có SLA. SLA không ngăn sự cố, nó chỉ quyết định phần bồi hoàn.

SLA trong các tình huống thường gặp ở doanh nghiệp Việt Nam

Thuê chỗ đặt máy chủ hoặc đám mây

Với dịch vụ điện toán đám mây hoặc thuê chỗ đặt máy chủ, SLA thường nói về uptime hạ tầng (nguồn, làm mát, mạng, máy ảo). Mô hình trách nhiệm chia sẻ làm phần ứng dụng, cấu hình và sao lưu của bạn nằm ngoài cam kết. Nhà cung cấp trung tâm dữ liệu thường chia mức dịch vụ theo cấp độ hạ tầng, bạn có thể tìm hiểu thêm ở bài về trung tâm dữ liệu.

Mua phần mềm thuê bao (SaaS)

SLA của SaaS thường gồm uptime theo tháng, cửa sổ bảo trì và thời gian phản hồi hỗ trợ theo mức độ nghiêm trọng (P1, P2…). Điều cần hỏi là SLA áp dụng cho mọi gói hay chỉ gói doanh nghiệp. Khi cân nhắc giữa thuê bao và tự vận hành, hãy xem so sánh SaaS và on-premise, vì với on-premise bạn tự gánh uptime và SLA trở thành SLA nội bộ.

SLA hỗ trợ kỹ thuật và vận hành thuê ngoài

Ở dịch vụ IT thuê ngoài hoặc helpdesk, SLA thường xoay quanh thời gian phản hồi và xử lý. Ví dụ minh họa: ticket mức khẩn “máy chủ kế toán không đăng nhập được” cần phản hồi trong 15 phút và có phương án tạm thời trong 2 giờ; ticket “đổi màu giao diện báo cáo” xử lý trong 5 ngày làm việc. Khi mức khẩn và mức thường cùng một tốc độ, SLA không giúp nhà cung cấp ưu tiên đúng việc. Hãy ghi rõ ai phân loại mức độ, vì đây là chỗ hay tranh cãi nhất.

SLA nội bộ giữa các phòng ban

Phòng IT có thể cam kết với phòng kế toán về thời gian cấp tài khoản hay khôi phục dữ liệu. Loại này không có credit tiền, nhưng giúp ưu tiên nguồn lực và là nền để sau này đàm phán SLA với nhà cung cấp bên ngoài.

Ưu điểm và hạn chế của SLA

Ưu điểm	Hạn chế
Biến kỳ vọng mơ hồ thành chỉ số có thể kiểm tra	Credit thường nhỏ hơn thiệt hại thật của bạn
Cơ sở so sánh các nhà cung cấp theo cùng tiêu chí	Loại trừ có thể làm cam kết yếu hơn vẻ ngoài
Căn cứ để leo thang và khiếu nại khi có sự cố	Thường phải tự yêu cầu, mất thời gian và bằng chứng
Buộc nhà cung cấp đầu tư giám sát, dự phòng	Chỉ đo thứ đã ghi, trải nghiệm thực có thể kém hơn

SLA khác gì với OLA, UC và KPI?

• OLA (Operational Level Agreement): thỏa thuận nội bộ giữa các nhóm của nhà cung cấp để họ đạt được SLA ngoài. Ví dụ đội mạng cam kết với đội ứng dụng thời gian xử lý sự cố đường truyền.
• UC (Underpinning Contract): hợp đồng của nhà cung cấp với bên thứ ba (ví dụ nhà cung cấp đường truyền) làm nền cho SLA bạn nhận được.
• KPI: chỉ số đo hiệu suất, dùng để quản lý nội bộ mà không nhất thiết có hậu quả hợp đồng. Nhiều chỉ số trong SLA cũng là KPI, nhưng KPI không phải SLA nếu không có cam kết với bên kia.

Tên gọi cũng hay nhầm với SLA là hợp đồng dịch vụ chính (MSA): MSA quy định điều khoản pháp lý chung, SLA là phụ lục kỹ thuật về mức dịch vụ. Khi có mâu thuẫn, hãy xem hợp đồng quy định thứ tự ưu tiên giữa các văn bản.

Khi nào nên đòi SLA chặt, khi nào không cần?

Mức uptime nên theo hậu quả của một lần ngừng, không theo con số nghe ấn tượng. Một nguồn khuyến nghị cho thấy 99,99% là cam kết về hạ tầng dự phòng và tự động chuyển đổi, chứ không chỉ là một con số lớn hơn. Từ đó, bạn có thể tự hỏi ba điều trước khi trả thêm tiền cho mức cao:

• Một giờ ngừng trong giờ cao điểm làm bạn mất bao nhiêu doanh thu hoặc phát sinh việc phải làm lại?
• Phần còn lại của hệ thống (đường truyền nội bộ, ứng dụng của bạn) có đạt mức tương đương không? Nếu không, mua mức cao ở một mắt xích là lãng phí.
• Bạn có thể chịu được ngừng theo dạng bảo trì có báo trước vào ban đêm không? Nếu có, thương lượng cửa sổ bảo trì cố định rẻ hơn mua thêm số 9.

Với công cụ nội bộ ít dùng, báo cáo cuối tháng hoặc môi trường thử nghiệm, SLA 99% hoặc 99,5% thường đủ. Với hệ thống thanh toán, đặt hàng, hoặc sản xuất phụ thuộc phần mềm, hãy yêu cầu SLA theo tháng, đo độc lập, và hỏi cả chính sách sao lưu. Hệ thống đang chạy trên đám mây có thể cân nhắc bản sao lưu độc lập, xem sao lưu đám mây.

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

SLA là gì trong tiếng Việt?

SLA là Service Level Agreement, gọi là thỏa thuận mức dịch vụ hoặc cam kết chất lượng dịch vụ. Đây là văn bản hoặc điều khoản trong hợp đồng, ghi các chỉ số nhà cung cấp phải đạt và cách bồi hoàn khi không đạt.

SLA 99,9% có nghĩa là gì?

Nghĩa là trong kỳ đo (thường là một tháng), dịch vụ được phép không khả dụng tối đa khoảng 0,1% thời gian. Trong tháng 30 ngày, con số này tương đương khoảng 43 phút. Thời gian bảo trì hoặc sự cố thuộc phần loại trừ có thể không bị tính.

Nhà cung cấp vi phạm SLA thì có được hoàn tiền không?

Thường bạn nhận service credit, tức giảm trừ vào hóa đơn sau, chứ không phải tiền mặt, và phải gửi yêu cầu trong thời hạn quy định. Mức bồi thường vượt credit chỉ có khi hợp đồng ghi rõ và tuân thủ giới hạn pháp luật.

SLA khác SLO thế nào?

SLO là mục tiêu nội bộ của đội vận hành, không nhất thiết có hậu quả tài chính. SLA là cam kết với khách hàng trong hợp đồng, có bồi hoàn. Nhà cung cấp thường đặt SLO cao hơn SLA để có vùng đệm.

Doanh nghiệp nhỏ có cần SLA không?

Có khi thuê dịch vụ ảnh hưởng đến hoạt động bán hàng hoặc kế toán, như hosting, phần mềm quản lý, đường truyền. Tối thiểu bạn nên biết mức uptime, thời gian phản hồi hỗ trợ và cách đo. Nếu nhà cung cấp không có SLA bằng văn bản, hãy hỏi lý do và cân nhắc rủi ro.

SLA có áp dụng nếu sự cố do lỗi cấu hình của tôi?

Thường là không. Lỗi do cấu hình, mật khẩu, mã ứng dụng của khách hàng hoặc dịch vụ bên thứ ba thuộc phần loại trừ trong nhiều bản SLA. Vì vậy cần đọc kỹ phần trách nhiệm của khách hàng và phần loại trừ trước khi ký.