SLA (thoả thuận mức dịch vụ) của nhà cung cấp đám mây là cam kết về độ sẵn sàng của từng dịch vụ, thường nêu bằng phần trăm thời gian hoạt động mỗi tháng, kèm mức bồi hoàn bằng tín dụng nếu không đạt. Mức 99,9% nghe gần hoàn hảo, nhưng tương đương khoảng 43 phút ngừng mỗi tháng, gần 9 giờ mỗi năm.
Hai điều thường bị hiểu sai. Thứ nhất, SLA là cam kết của từng dịch vụ, không phải của hệ thống bạn ghép từ nhiều dịch vụ; độ sẵn sàng của hệ thống thường thấp hơn từng thành phần. Thứ hai, SLA là cơ chế bồi hoàn tài chính có giới hạn, không phải bảo hiểm thiệt hại kinh doanh: khi dịch vụ ngừng, bạn nhận lại một phần phí của dịch vụ đó, không phải doanh thu đã mất.
Bài này đưa ra bảng quy đổi phần trăm sang thời gian, cách tính độ sẵn sàng khi ghép nối tiếp và song song, những điều khoản cần đọc kỹ, và cách đặt mục tiêu nội bộ cho hệ thống của bạn.
Bảng quy đổi: mỗi "số 9" đáng bao nhiêu phút
Bảng tính theo năm 365 ngày và tháng trung bình khoảng 30,4 ngày. Con số đã làm tròn.
| Độ sẵn sàng | Ngừng tối đa mỗi năm | Ngừng tối đa mỗi tháng | Ngừng tối đa mỗi tuần |
|---|---|---|---|
| 99% | khoảng 3,65 ngày | khoảng 7,3 giờ | khoảng 1,7 giờ |
| 99,5% | khoảng 1,83 ngày | khoảng 3,65 giờ | khoảng 50 phút |
| 99,9% | khoảng 8,76 giờ | khoảng 43,8 phút | khoảng 10 phút |
| 99,95% | khoảng 4,38 giờ | khoảng 21,9 phút | khoảng 5 phút |
| 99,99% | khoảng 52,6 phút | khoảng 4,4 phút | khoảng 1 phút |
| 99,999% | khoảng 5,3 phút | khoảng 26 giây | khoảng 6 giây |
Mỗi số 9 thêm vào giảm thời gian ngừng cho phép xuống mười lần, và chi phí để đạt được thường tăng nhiều hơn mười lần. Từ 99,9% lên 99,99% thường đòi hỏi chạy trên nhiều vùng sẵn sàng, chuyển đổi dự phòng tự động, không có thao tác thủ công nào trong đường khôi phục, và quy trình phát hành không gây ngừng. Đây là lý do mục tiêu độ sẵn sàng nên là quyết định kinh doanh có tính tiền, không phải con số đẹp trên slide.
Một điểm tinh tế: 43 phút mỗi tháng có thể là một sự cố dài 43 phút hoặc 43 lần ngừng mỗi lần một phút. Với hệ thống thanh toán, một lần ngừng dài vào giờ cao điểm tối thứ Sáu gây thiệt hại khác hẳn nhiều lần chập chờn lúc 3 giờ sáng. Phần trăm không nói hết câu chuyện.
Độ sẵn sàng của hệ thống ghép nối: phép nhân làm bạn bất ngờ
Một ứng dụng web điển hình phụ thuộc vào nhiều dịch vụ cùng lúc: cân bằng tải, máy ảo hoặc container, cơ sở dữ liệu, bộ nhớ đệm, dịch vụ tên miền. Khi các thành phần nối tiếp, tức hệ thống ngừng nếu bất kỳ thành phần nào ngừng, độ sẵn sàng tổng xấp xỉ bằng tích độ sẵn sàng của từng phần. Ví dụ giả định: bốn thành phần, mỗi phần 99,9%, cho độ sẵn sàng tổng khoảng 0,999 mũ 4, xấp xỉ 99,6%, tức gần 3 giờ ngừng mỗi tháng thay vì 43 phút.
Khi các thành phần song song, tức hệ thống chỉ ngừng khi mọi bản sao cùng ngừng, phép tính đảo lại: xác suất ngừng của cả nhóm bằng tích xác suất ngừng của từng bản. Hai bản sao độc lập, mỗi bản 99%, cho độ sẵn sàng 1 trừ 0,01 nhân 0,01, tức 99,99%. Đây là nguyên lý của mọi thiết kế chịu lỗi: nhân bản các thành phần nối tiếp để mỗi mắt xích trở thành một nhóm song song.
Chữ quan trọng trong phép tính song song là độc lập. Hai máy ảo trên cùng một máy chủ vật lý, hai bản cơ sở dữ liệu trong cùng một trung tâm dữ liệu, hay hai dịch vụ dùng chung một cấu hình bị lỗi đều không độc lập; chúng có thể ngừng cùng lúc vì cùng một nguyên nhân. Nhiều sự cố lớn trên đám mây trong thập kỷ qua bắt nguồn từ thay đổi cấu hình hoặc lỗi ở một thành phần dùng chung như dịch vụ danh tính, dịch vụ tên miền nội bộ, khiến các bản sao tưởng như độc lập cùng ngừng.
Vùng, vùng sẵn sàng và cam kết đi kèm
Vùng (region). Một khu vực địa lý của nhà cung cấp, gồm nhiều trung tâm dữ liệu. Các vùng được thiết kế độc lập với nhau ở mức cao, để sự cố ở một vùng ít khi lan sang vùng khác.
Vùng sẵn sàng (availability zone). Một hay nhiều trung tâm dữ liệu trong một vùng, có nguồn điện, làm mát và mạng tách biệt, nối với các vùng sẵn sàng khác bằng đường truyền độ trễ thấp. Chạy ứng dụng trên ít nhất hai vùng sẵn sàng là cách phổ biến để chịu được sự cố của một trung tâm dữ liệu.
SLA thường gắn với cách triển khai. Nhiều nhà cung cấp đưa ra mức cam kết khác nhau tuỳ cách bạn triển khai: một máy ảo đơn lẻ có cam kết thấp hơn, một nhóm máy trải trên nhiều vùng sẵn sàng có cam kết cao hơn. Nếu bạn chỉ chạy một máy, bạn không được hưởng con số cao mà nhà cung cấp quảng bá.
Chạy đa vùng là một bước nhảy về độ phức tạp. Đa vùng sẵn sàng trong một vùng tương đối dễ vì độ trễ thấp, cơ sở dữ liệu nhân bản đồng bộ được. Đa vùng địa lý đòi hỏi xử lý nhân bản không đồng bộ, khả năng mất một ít dữ liệu khi chuyển đổi, và chi phí truyền dữ liệu giữa vùng. Chỉ nên làm cho hệ thống thật sự cần.
Phụ thuộc ẩn ngoài vùng của bạn. Một số thành phần dùng chung của nhà cung cấp, như dịch vụ danh tính, bảng điều khiển hay hệ thống tên miền, có thể vận hành tập trung ở một vùng nhất định. Khi thành phần đó gặp sự cố, ứng dụng ở vùng khác vẫn có thể bị ảnh hưởng, nhất là thao tác tạo mới hay thay đổi tài nguyên. Báo cáo sau sự cố công khai của các nhà cung cấp là nguồn tốt để hiểu những phụ thuộc này; thiết kế khôi phục không nên giả định luôn tạo được tài nguyên mới đúng lúc đang có sự cố diện rộng.
Những điều khoản phải đọc trong một SLA
SLA của các nhà cung cấp lớn thường công khai. Trước khi dựa vào một con số, đọc kỹ các điểm dưới đây.
- Định nghĩa "không khả dụng". Thường là tỷ lệ yêu cầu lỗi vượt một ngưỡng trong một khoảng thời gian, hoặc không kết nối được. Dịch vụ chậm nhưng vẫn trả lời có thể không được tính là ngừng.
- Cách đo và ai đo. Phần lớn dựa trên số liệu của nhà cung cấp; một số yêu cầu bạn tự chứng minh bằng nhật ký của mình.
- Loại trừ. Bảo trì có thông báo, sự cố do phần mềm hay cấu hình của khách hàng, sự kiện bất khả kháng, dịch vụ đang trong giai đoạn thử nghiệm thường không được tính.
- Mức bồi hoàn. Thường là tín dụng bằng một tỷ lệ phần trăm phí tháng của riêng dịch vụ bị ảnh hưởng, tăng theo mức vi phạm, có trần, và chỉ dùng để trừ vào hoá đơn sau.
- Thủ tục yêu cầu. Tín dụng thường không tự động; bạn phải gửi yêu cầu trong một thời hạn nhất định kèm thông tin sự cố. Quá hạn là mất quyền.
- Phạm vi. Cam kết cho dịch vụ quản lý hay chỉ cho hạ tầng; cho mặt phẳng điều khiển hay chỉ cho phần chạy ứng dụng.
Đọc xong các điểm này, phần lớn doanh nghiệp nhận ra SLA là công cụ tạo động lực cho nhà cung cấp và cơ sở đàm phán, không phải phương án quản trị rủi ro. Phương án quản trị rủi ro là thiết kế hệ thống của chính bạn và kế hoạch liên tục kinh doanh.
SLI, SLO và SLA: đặt mục tiêu cho hệ thống của bạn
Phương pháp kỹ thuật độ tin cậy (site reliability engineering) do Google phổ biến, được trình bày trong cuốn sách cùng tên xuất bản năm 2016, tách ba khái niệm. SLI là chỉ số đo được, ví dụ tỷ lệ yêu cầu thành công hay tỷ lệ yêu cầu phản hồi dưới 300 mili giây. SLO là mục tiêu nội bộ cho chỉ số đó, ví dụ 99,5% yêu cầu thành công trong 28 ngày. SLA là cam kết với khách hàng có hệ quả tài chính, thường được đặt thấp hơn SLO để có khoảng an toàn.
Khái niệm hữu ích nhất trong khung này là ngân sách lỗi: nếu SLO là 99,5%, hệ thống được phép lỗi 0,5% yêu cầu trong kỳ. Còn ngân sách thì đội được phát hành tính năng mới, chấp nhận rủi ro; hết ngân sách thì tạm dừng tính năng, tập trung sửa độ ổn định. Cơ chế này biến cuộc tranh luận muôn thuở giữa đội phát triển muốn đi nhanh và đội vận hành muốn ổn định thành một quy tắc dựa trên số liệu.
Đặt SLO nên bắt đầu từ trải nghiệm người dùng, không từ khả năng của hạ tầng. Một hệ thống chấm công nội bộ ở nhà máy có thể chỉ cần 99% trong giờ làm việc; một cổng thanh toán của sàn thương mại điện tử trong mùa khuyến mãi cần cao hơn nhiều. Đặt mục tiêu quá cao lãng phí tiền và làm chậm đổi mới; quá thấp làm mất khách. Cũng cần nhớ: người dùng truy cập qua mạng di động và Internet, vốn tự nó không đạt 100%, nên vượt quá một mức nào đó người dùng không còn cảm nhận được sự khác biệt.
Quy trình đặt mục tiêu độ sẵn sàng cho một hệ thống
Áp dụng cho từng hệ thống quan trọng, cùng với chủ nghiệp vụ.
- Ước tính thiệt hại khi hệ thống ngừng theo giờ và theo thời điểm: giờ cao điểm, giờ thường, ban đêm.
- Chọn SLI phản ánh trải nghiệm thật, đo từ phía người dùng hoặc từ cân bằng tải, không chỉ từ máy chủ.
- Đặt SLO đầu tiên gần mức hệ thống đang đạt, rồi điều chỉnh sau vài kỳ đo.
- Liệt kê các thành phần nối tiếp, tra SLA của từng dịch vụ, tính độ sẵn sàng tổng theo phép nhân để xem kiến trúc hiện tại có đạt SLO không.
- Nếu không đạt, xác định mắt xích yếu nhất và chi phí nhân bản nó; so với thiệt hại ước tính để quyết định có đầu tư hay chấp nhận.
- Xác định thời gian khôi phục mục tiêu (RTO) và lượng dữ liệu tối đa chấp nhận mất (RPO), rồi diễn tập khôi phục định kỳ để kiểm tra con số đó là thật.
Câu hỏi thường gặp
Tín dụng SLA có bù được thiệt hại kinh doanh không?
Gần như không. Tín dụng thường chỉ là một phần phí tháng của dịch vụ bị ảnh hưởng, trừ vào hoá đơn sau, trong khi thiệt hại kinh doanh có thể lớn hơn nhiều lần. Muốn chuyển rủi ro tài chính, doanh nghiệp xem xét bảo hiểm gián đoạn kinh doanh hoặc thiết kế hệ thống chịu lỗi.
Bảo trì có kế hoạch có tính vào thời gian ngừng không?
Tuỳ điều khoản. Nhiều SLA loại trừ bảo trì có thông báo trước. Với SLO nội bộ, nên tính cả bảo trì vào ngân sách lỗi, vì với người dùng, hệ thống không vào được là không vào được, bất kể lý do.
Làm sao tự đo độ sẵn sàng thay vì tin số liệu nhà cung cấp?
Dùng giám sát tổng hợp gọi định kỳ vào các chức năng chính từ nhiều vị trí bên ngoài, kết hợp đếm tỷ lệ lỗi từ nhật ký cân bằng tải. Số liệu tự đo vừa phản ánh trải nghiệm thật, vừa là bằng chứng khi yêu cầu tín dụng.
RTO và RPO khác độ sẵn sàng thế nào?
Độ sẵn sàng đo tỷ lệ thời gian hoạt động trong một kỳ. RTO là thời gian tối đa để khôi phục sau một sự cố cụ thể, RPO là khoảng dữ liệu tối đa chấp nhận mất. Một hệ thống có thể đạt độ sẵn sàng cao nhưng RPO kém nếu sao lưu thưa.
Có nên yêu cầu nhà cung cấp phần mềm dịch vụ cam kết 99,99%?
Chỉ khi nghiệp vụ thật sự cần và bạn sẵn sàng trả giá cao hơn. Quan trọng hơn con số là định nghĩa ngừng, cách đo, mức bồi hoàn, lịch sử sự cố công khai của nhà cung cấp và quy trình thông báo khi có sự cố.