SLA (Service Level Agreement – thoả thuận mức dịch vụ) là phần hợp đồng định nghĩa bằng con số chất lượng dịch vụ mà nhà cung cấp cam kết, cách đo, và hậu quả khi không đạt. Với phần mềm, SLA thường gồm độ sẵn sàng của hệ thống, thời gian phản hồi và khắc phục sự cố theo mức ưu tiên, khả năng khôi phục dữ liệu, và khoản tín dụng hoặc giảm phí khi vi phạm.
Một SLA tốt không phải SLA có con số cao nhất, mà là SLA khớp với mức độ quan trọng của hệ thống đối với hoạt động kinh doanh và được đo một cách cả hai bên tin. "Hỗ trợ 24/7, sẵn sàng 99,99%" trên trang giới thiệu không có giá trị nếu không có định nghĩa sự cố, cách đo và điều khoản bồi hoàn. Bài này giải thích các chỉ số, cách đọc những con số chín, cách phân mức ưu tiên và mẫu điều khoản cần có.
Độ sẵn sàng: mỗi con số chín nghĩa là bao nhiêu phút
Độ sẵn sàng là tỷ lệ thời gian hệ thống hoạt động trong một kỳ đo. Quy đổi ra thời gian ngừng cho phép giúp thấy rõ khác biệt giữa các mức:
| Độ sẵn sàng | Ngừng tối đa mỗi tháng (30 ngày) | Ngừng tối đa mỗi năm | Thường thấy ở |
|---|---|---|---|
| 99% | khoảng 7 giờ 12 phút | khoảng 3,65 ngày | Ứng dụng nội bộ không quan trọng |
| 99,5% | khoảng 3 giờ 36 phút | khoảng 1,8 ngày | Phần mềm quản lý trong giờ hành chính |
| 99,9% | khoảng 43 phút | khoảng 8,8 giờ | Phần lớn dịch vụ SaaS doanh nghiệp |
| 99,95% | khoảng 22 phút | khoảng 4,4 giờ | Hệ thống bán hàng, thanh toán |
| 99,99% | khoảng 4,3 phút | khoảng 53 phút | Hạ tầng cốt lõi, đòi kiến trúc dự phòng nhiều lớp |
Mỗi con số chín thêm vào đòi chi phí tăng mạnh: máy chủ dự phòng, nhiều vùng dữ liệu, quy trình triển khai không ngừng hệ thống, đội trực ca. Hãy hỏi doanh nghiệp mất bao nhiêu khi hệ thống ngừng một giờ, rồi chọn mức có chi phí tương xứng. Một phần mềm quản lý nhân sự dùng trong giờ hành chính hiếm khi cần 99,99%; một hệ thống thu ngân của chuỗi bán lẻ thì có thể cần.
Những chi tiết làm con số sẵn sàng có nghĩa hoặc vô nghĩa
Kỳ đo. Đo theo tháng hay năm khác nhau nhiều. Theo năm, nhà cung cấp có thể ngừng nguyên một ngày trong tháng cao điểm mà vẫn đạt 99,9%. Theo tháng chặt hơn.
Định nghĩa "không sẵn sàng". Chỉ khi toàn hệ thống không truy cập được, hay cả khi một chức năng chính lỗi, hay khi chạy chậm quá ngưỡng? Hệ thống mở được trang chủ nhưng không tạo được đơn thì với bạn là ngừng, với SLA lỏng thì vẫn "sẵn sàng".
Loại trừ. Bảo trì có kế hoạch, sự cố do bên thứ ba, do khách hàng, do bất khả kháng thường bị loại trừ. Loại trừ hợp lý là bình thường, nhưng bảo trì có kế hoạch nên giới hạn số giờ, báo trước và ngoài giờ cao điểm.
Cách đo. Ai đo, bằng công cụ gì, từ đâu. Đo từ bên trong trung tâm dữ liệu của nhà cung cấp sẽ không thấy sự cố mạng mà người dùng gặp. Tốt nhất là giám sát tổng hợp từ bên ngoài, gọi các giao dịch chính định kỳ.
Khung giờ áp dụng. Hai mươi bốn giờ mỗi ngày hay chỉ giờ làm việc. Với hệ thống nội bộ, cam kết cao trong giờ làm việc và thấp hơn ngoài giờ giúp giảm chi phí mà không ảnh hưởng nhiều.
Mức ưu tiên sự cố và thời gian xử lý
Thực hành phổ biến, kế thừa từ khung quản lý dịch vụ CNTT như ITIL, xác định mức ưu tiên theo hai yếu tố: tác động (bao nhiêu người, chức năng nào bị ảnh hưởng) và mức khẩn cấp (cần khắc phục nhanh đến đâu). Ví dụ giả định cho một hệ thống bán hàng:
| Mức | Định nghĩa | Phản hồi | Khắc phục tạm | Khắc phục triệt để |
|---|---|---|---|---|
| P1 – Nghiêm trọng | Toàn hệ thống ngừng hoặc mất dữ liệu; không bán hàng được | 15–30 phút, 24/7 | 4 giờ | Theo kế hoạch sau phân tích nguyên nhân |
| P2 – Cao | Chức năng chính lỗi cho nhiều người, có cách làm tạm khó khăn | 1 giờ | 1 ngày làm việc | 5 ngày làm việc |
| P3 – Trung bình | Chức năng phụ lỗi hoặc lỗi chính ảnh hưởng ít người, có cách làm tạm | 4 giờ làm việc | 3 ngày làm việc | Bản phát hành kế tiếp |
| P4 – Thấp | Lỗi giao diện, câu hỏi hướng dẫn, yêu cầu nhỏ | 1 ngày làm việc | Không áp dụng | Theo kế hoạch |
Phân biệt ba mốc thời gian là chỗ SLA hay bị viết mơ hồ. Phản hồi là khi có người thật tiếp nhận và bắt đầu xử lý, không phải email tự động. Khắc phục tạm là khi người dùng làm việc lại được, có thể bằng cách vòng. Khắc phục triệt để là khi nguyên nhân gốc được sửa. Cam kết chỉ "phản hồi trong 15 phút" mà không có mốc khắc phục thì gần như không ràng buộc gì.
RTO, RPO và sao lưu: cam kết khi điều tệ nhất xảy ra
Độ sẵn sàng nói về vận hành thường ngày; RTO và RPO nói về thảm hoạ như hỏng phần cứng, mất trung tâm dữ liệu, mã độc tống tiền. RPO (mục tiêu điểm khôi phục) là lượng dữ liệu tối đa có thể mất, đo bằng thời gian: RPO một giờ nghĩa là khôi phục xong, bạn mất tối đa dữ liệu nhập trong một giờ cuối. RTO (mục tiêu thời gian khôi phục) là thời gian tối đa để hệ thống chạy lại.
Hai con số này quyết định kiến trúc và chi phí. RPO một ngày có thể đạt bằng sao lưu hằng đêm; RPO vài phút đòi sao chép dữ liệu liên tục sang nơi khác. RTO vài ngày có thể dựng lại từ bản sao lưu; RTO dưới một giờ đòi hệ thống dự phòng chạy sẵn. Đừng đòi con số thấp cho mọi hệ thống; hãy xếp hạng hệ thống theo mức quan trọng và đặt mức tương ứng.
Điều khoản quan trọng không kém là kiểm thử khôi phục. Bản sao lưu chưa từng được khôi phục thử là bản sao lưu chưa được chứng minh. SLA nên yêu cầu diễn tập khôi phục định kỳ, có biên bản ghi thời gian thực tế, và quyền của bạn được tham dự hoặc nhận báo cáo. Với dữ liệu quan trọng, giữ thêm một bản sao ở nơi bạn kiểm soát, ngoài hệ thống của nhà cung cấp.
Tín dụng dịch vụ và hậu quả khi vi phạm
Hậu quả phổ biến nhất khi vi phạm SLA là tín dụng dịch vụ: giảm một phần phí tháng theo mức độ vi phạm. Ví dụ giả định: dưới 99,9% giảm 10% phí tháng, dưới 99,5% giảm 25%, dưới 99% giảm 50%. Cần hiểu đúng bản chất: tín dụng dịch vụ hiếm khi bù được thiệt hại kinh doanh thật. Một giờ ngừng bán hàng có thể thiệt hại hơn cả năm phí phần mềm. Mục đích của nó là tạo động lực, không phải bồi thường.
Vì vậy, ngoài tín dụng, nên có các hậu quả mạnh hơn cho vi phạm lặp lại: quyền chấm dứt hợp đồng không bị phạt nếu vi phạm SLA nghiêm trọng trong một số tháng liên tiếp hoặc tổng số tháng trong năm; nghĩa vụ nộp báo cáo phân tích nguyên nhân gốc và kế hoạch khắc phục cho mọi sự cố P1; họp rà soát với cấp quản lý cao hơn của nhà cung cấp.
Một chi tiết hay bị bỏ qua: nhiều SLA yêu cầu khách hàng tự yêu cầu tín dụng trong thời hạn nhất định, quá hạn coi như từ bỏ. Hãy đọc kỹ điều kiện, hoặc đàm phán để nhà cung cấp tự động áp dụng dựa trên báo cáo giám sát hằng tháng.
Viết SLA cho hệ thống của bạn trong sáu bước
Gộp các phần trên thành trình tự làm việc cụ thể trước khi ngồi vào bàn đàm phán với nhà cung cấp:
- Liệt kê các giao dịch nghiệp vụ chính mà hệ thống phục vụ, như tạo đơn, thanh toán, xuất kho, và ước tính thiệt hại khi mỗi giao dịch ngừng một giờ trong giờ cao điểm.
- Từ mức thiệt hại, chọn khung giờ áp dụng, độ sẵn sàng, RTO và RPO tương xứng; ghi lại lý do để về sau giải thích được với lãnh đạo.
- Định nghĩa thế nào là "không sẵn sàng" bằng chính các giao dịch đó, kèm ngưỡng hiệu năng; không dừng ở việc trang chủ có mở được hay không.
- Viết định nghĩa bốn mức ưu tiên bằng ví dụ thật của doanh nghiệp, kèm ba mốc phản hồi, khắc phục tạm, khắc phục triệt để cho từng mức.
- Quy định cách đo, báo cáo hằng tháng, tín dụng dịch vụ, quyền chấm dứt khi vi phạm lặp lại và nghĩa vụ phân tích nguyên nhân sau sự cố P1.
- Đối chiếu với năng lực nội bộ: ai phía bạn tiếp nhận báo cáo, ai trực ngoài giờ để báo sự cố, kênh liên lạc khẩn cấp là gì.
Bước cuối thường bị quên. SLA là cam kết hai chiều: nhà cung cấp không thể phản hồi trong mười lăm phút nếu sự cố được báo qua email gửi một người đang nghỉ phép. Danh sách liên hệ khẩn cấp hai phía, kèm người dự phòng, nên là một phụ lục được cập nhật định kỳ.
SLA, SLO và SLI: ngôn ngữ của đội vận hành
Trong cộng đồng vận hành phần mềm, đặc biệt sau khi Google công bố cuốn Site Reliability Engineering năm 2016, ba thuật ngữ được phân biệt rõ. SLI là chỉ số đo được, chẳng hạn tỷ lệ yêu cầu trả về thành công hoặc thời gian phản hồi ở bách phân vị thứ 95. SLO là mục tiêu nội bộ cho chỉ số đó. SLA là cam kết hợp đồng với khách hàng, thường thấp hơn SLO để có vùng đệm.
Hiểu cách phân biệt này giúp bên đặt hàng đặt câu hỏi đúng: nhà cung cấp đang đo chỉ số gì, mục tiêu nội bộ của họ là bao nhiêu, và lịch sử đạt được trong mười hai tháng qua thế nào. Một nhà cung cấp trưởng thành có số liệu này sẵn; không có thì cam kết SLA của họ là lời hứa chưa được kiểm chứng.
Khái niệm "ngân sách lỗi" trong cùng tài liệu cũng hữu ích: nếu mục tiêu là 99,9%, thì 0,1% còn lại là ngân sách được phép tiêu cho rủi ro như phát hành tính năng mới. Hết ngân sách thì ưu tiên ổn định hơn tính năng. Bên đặt hàng có thể dùng ý này để thảo luận cân bằng giữa tốc độ phát triển và độ ổn định, thay vì đòi cả hai ở mức tối đa.
Câu hỏi thường gặp
SLA của gói SaaS chuẩn có đàm phán được không?
Với khách hàng nhỏ, gói SaaS thường áp SLA chuẩn không đàm phán. Khách hàng lớn hoặc hợp đồng nhiều năm thường đàm phán được một số điểm như kỳ đo, định nghĩa sự cố, quyền chấm dứt khi vi phạm lặp lại. Dù không đàm phán được, vẫn phải đọc kỹ để biết rủi ro mình đang chấp nhận và chuẩn bị phương án dự phòng.
Phần mềm cài tại máy chủ của doanh nghiệp thì SLA khác gì?
Khi hạ tầng do bạn quản lý, nhà cung cấp phần mềm không thể cam kết độ sẵn sàng của toàn hệ thống. SLA khi đó chủ yếu về thời gian phản hồi và khắc phục lỗi phần mềm. Phần sẵn sàng phụ thuộc đội hạ tầng của bạn hoặc nhà cung cấp hạ tầng riêng, và cần thoả thuận nội bộ hoặc hợp đồng riêng tương ứng.
Hệ thống chạy chậm có tính là vi phạm SLA không?
Chỉ khi SLA định nghĩa ngưỡng hiệu năng. Nhiều SLA chỉ cam kết sẵn sàng, nên hệ thống chậm đến mức không dùng được vẫn tính là sẵn sàng. Nên bổ sung chỉ số thời gian phản hồi cho các giao dịch chính, đo ở bách phân vị như 95 phần trăm yêu cầu dưới một ngưỡng, và coi vượt ngưỡng kéo dài là không sẵn sàng.
Có nên yêu cầu nhà cung cấp gửi báo cáo SLA hằng tháng?
Nên. Báo cáo gồm độ sẵn sàng đo được, danh sách sự cố theo mức ưu tiên, thời gian phản hồi và khắc phục thực tế, tín dụng phát sinh, các bảo trì đã làm. Báo cáo đều đặn giúp phát hiện xu hướng xấu trước khi thành khủng hoảng và là cơ sở cho buổi rà soát quý giữa hai bên.
SLA nội bộ giữa phòng CNTT và các phòng ban có cần không?
Với doanh nghiệp có phòng CNTT phục vụ nhiều bộ phận, thoả thuận mức dịch vụ nội bộ, đôi khi gọi là OLA, giúp thống nhất kỳ vọng và ưu tiên nguồn lực. Nó cũng cần thiết để SLA với nhà cung cấp bên ngoài khớp với cam kết nội bộ: không thể hứa khắc phục trong bốn giờ nếu nhà cung cấp chỉ cam kết một ngày.
Ai quyết định mức ưu tiên của một sự cố khi hai bên không đồng ý?
SLA nên quy định người báo sự cố đề xuất mức, nhà cung cấp có thể đề nghị điều chỉnh kèm lý do, và khi bất đồng thì tạm áp mức cao hơn trong lúc trao đổi. Định nghĩa từng mức bằng ví dụ cụ thể theo nghiệp vụ của bạn giúp giảm bất đồng. Tranh chấp lặp lại nên đưa lên buổi rà soát định kỳ.