ベトナムのインフラストラクチャ管理パートナーの選択：SLA、オンコール対応および引き渡しについて何を確認すべきか

Vì sao nên chuẩn hóa bộ câu hỏi trước khi so sánh báo giá

Khi doanh nghiệp thuê ngoài việc vận hành hạ tầng, phần lớn thời gian đánh giá thường dồn vào bảng giá và danh mục dịch vụ. Đó là phần dễ so sánh nhất, nhưng cũng là phần ít quyết định nhất tới trải nghiệm thực tế trong hai năm tiếp theo. Điều thật sự tạo ra khác biệt nằm ở những chỗ khó đọc: cam kết phản hồi được đo từ mốc nào, ai là người nhấc máy lúc hai giờ sáng mùng hai Tết, và khi hợp đồng kết thúc thì bạn nhận lại được những gì.

Bài viết này là một danh sách câu hỏi trung lập. Nó được viết để bạn dùng với bất kỳ nhà cung cấp nào đang có trong danh sách rút gọn, và điều đó bao gồm cả HiTechCloud. Nếu một câu hỏi ở đây khiến một đối tác lúng túng, thì đó là thông tin có giá trị, bất kể tên trên hợp đồng là ai. Mục tiêu không phải là tìm ra đối tác trả lời hay nhất, mà là buộc mọi đối tác trả lời cùng một bộ câu hỏi để bạn so sánh trên cùng một mặt bằng.

Phản hồi và khắc phục là hai cam kết hoàn toàn khác nhau

Rất nhiều bảng SLA chỉ nêu thời gian phản hồi. Phản hồi nghĩa là có người xác nhận đã nhận sự cố, không nói gì về việc hệ thống bao giờ chạy lại. Một cam kết phản hồi mười lăm phút nghe rất mạnh, nhưng nếu sau đó sự cố nằm im ba tiếng vì phải chờ kỹ sư duy nhất hiểu hệ thống thì con số đó không cứu được doanh thu của bạn.

Hãy hỏi ba mốc tách biệt: thời gian phản hồi đầu tiên, thời gian bắt đầu xử lý bởi người có đủ quyền và hiểu biết, và mục tiêu khắc phục. Nếu đối tác không cam kết được thời gian khắc phục, hãy hỏi vì sao và họ thay bằng gì. Câu trả lời hợp lý thường là cam kết về nỗ lực và về nhịp cập nhật, ví dụ cập nhật tình trạng mỗi ba mươi phút cho sự cố nghiêm trọng nhất. Câu trả lời không hợp lý là im lặng.

Hỏi tiếp: đồng hồ bắt đầu chạy từ lúc nào, và có được phép dừng không? Việc dừng khi đang chờ phản hồi từ phía khách hàng là hợp lý, nhưng bạn cần biết ai bấm nút dừng và có thấy được lịch sử đó không.

Định nghĩa mức độ nghiêm trọng phải do bạn kiểm chứng

Toàn bộ giá trị của SLA phụ thuộc vào cách phân loại mức độ nghiêm trọng, vì đó là thứ quyết định cam kết nào được áp dụng. Nếu định nghĩa mơ hồ, bên phân loại nắm quyền quyết định thực tế.

Câu hỏi cần đặt	Vì sao nó quan trọng
Ai phân loại mức độ ban đầu?	Bên phân loại kiểm soát cam kết nào được kích hoạt
Khách hàng có quyền nâng mức không?	Tránh việc sự cố kinh doanh bị coi là kỹ thuật thông thường
Suy giảm hiệu năng có được tính là sự cố không?	Hệ thống chậm mười lần vẫn là hệ thống đang chạy theo cách hiểu hẹp
Một môi trường staging hỏng nằm ở mức nào?	Chặn phát hành cũng là thiệt hại kinh doanh
Mức nghiêm trọng có tự động tăng theo thời gian không?	Ngăn sự cố trung bình nằm im nhiều ngày

Cách kiểm chứng tốt nhất là đưa ra vài kịch bản có thật trong hệ thống của bạn và yêu cầu đối tác gán mức nghiêm trọng kèm cam kết tương ứng cho từng kịch bản. Sự khác biệt giữa các đối tác sẽ lộ ra ngay ở bài tập này.

Khung giờ phục vụ, ngày lễ và cách xử lý dịp Tết

Hỏi chính xác khung giờ áp dụng cho từng mức nghiêm trọng. Nhiều gói dịch vụ cam kết hai mươi tư trên bảy cho mức cao nhất nhưng chỉ giờ hành chính cho các mức còn lại, và điều đó có thể chấp nhận được nếu bạn biết trước. Vấn đề chỉ xuất hiện khi bạn cho rằng mình mua trọn ngày còn hợp đồng thì không nói vậy.

Ở Việt Nam, kỳ nghỉ Tết Nguyên đán là phép thử riêng và cần được hỏi thẳng. Nhân sự trực tuần Tết có phải cùng đội ngũ thường ngày không, số người trực giảm bao nhiêu, thời gian phản hồi cam kết có thay đổi không, lịch trực được công bố trước bao lâu, và ai được quyền phê duyệt ngoại lệ trong giai đoạn đóng băng thay đổi?

Với bán lẻ, thương mại điện tử, du lịch hay dịch vụ tài chính, Tết thường là cao điểm chứ không phải thời gian rảnh. Nếu vậy, hãy yêu cầu cam kết riêng cho giai đoạn cao điểm ngay từ khi đánh giá.

Ai thực sự trực, và đường leo thang dừng ở đâu

Đây là câu hỏi hay bị trả lời bằng sơ đồ tổ chức thay vì bằng sự thật. Hãy hỏi cụ thể: ca trực có bao nhiêu người, họ ở múi giờ nào, có phải nhân viên chính thức của đối tác hay là bên thứ ba? Người trực tuyến đầu có quyền thao tác trên hệ thống của bạn, hay chỉ có quyền phân loại và gọi người khác?

Kế đến là đường leo thang. Yêu cầu một sơ đồ có tên vai trò, thời hạn ở mỗi bậc và cách liên hệ. Nếu tuyến đầu không xử lý được trong ba mươi phút thì ai là bậc tiếp theo, và bậc đó cam kết có mặt trong bao lâu? Ai là người có quyền quyết định các hành động rủi ro cao như chuyển đổi dự phòng, khôi phục từ bản バックアップ, hay tạm ngắt một dịch vụ để bảo vệ dữ liệu? Ai là người liên hệ điều hành khi sự cố kéo dài quá một ngưỡng nhất định?

Đừng quên hỏi bạn có kênh liên lạc dự phòng nào khi chính hệ thống ticket của đối tác gặp sự cố.

Báo cáo: nhịp độ và nội dung

Báo cáo là cách duy nhất để bạn biết mình mua được gì trong những tháng không có sự cố. Hãy yêu cầu xem một bản mẫu đã ẩn thông tin khách hàng, thay vì chỉ nghe mô tả.

• Nhịp độ: báo cáo vận hành hằng tháng và rà soát dịch vụ hằng quý, xác nhận trong hợp đồng chứ không chỉ trong lời hứa.
• Số liệu SLA theo từng mức nghiêm trọng, kèm danh sách các trường hợp không đạt và lý do.
• Danh mục sự cố theo nguyên nhân, kèm phân tích nguyên nhân gốc cho sự cố nghiêm trọng, hành động khắc phục có người chịu trách nhiệm và trạng thái của các hành động kỳ trước.
• Tình trạng vá lỗi và bản vá bảo mật, gồm cả những hệ thống chưa được vá và lý do.
• Kết quả kiểm tra khôi phục dữ liệu, không chỉ là báo cáo sao lưu thành công.
• Thay đổi đã thực hiện trong kỳ, tỷ lệ thất bại và số lần quay lui, kèm xu hướng dung lượng và chi phí.
• Danh sách tài khoản và quyền truy cập mà đối tác đang nắm giữ trên hệ thống của bạn.

Mô hình truy cập của đối tác và nguyên tắc quyền tối thiểu

Đối tác quản trị hạ tầng luôn là một trong những rủi ro bảo mật lớn nhất mà bạn tự nguyện nhận vào, đơn giản vì họ cần quyền cao để làm việc. Cách quản lý quyền đó nói lên nhiều điều hơn bất kỳ chứng chỉ nào.

Hỏi xem kỹ sư của đối tác đăng nhập bằng danh tính cá nhân hay bằng tài khoản dùng chung. Tài khoản dùng chung khiến việc truy vết trở nên vô nghĩa. Hỏi xem quyền cao được cấp thường trực hay cấp theo yêu cầu có thời hạn, ai phê duyệt, và bạn có thấy được nhật ký phê duyệt không. Hỏi xem nhật ký thao tác nằm ở đâu, do bên nào lưu, giữ trong bao lâu, và bạn có quyền truy xuất trực tiếp hay phải yêu cầu qua đối tác.

Tiếp theo là quy trình nhân sự: khi một kỹ sư rời dự án, quyền của họ bị thu hồi trong bao lâu và ai kiểm chứng? Truy cập thực hiện từ thiết bị do đối tác quản lý hay thiết bị cá nhân? 認証 đa yếu tố có bắt buộc ở mọi lối vào, kể cả kênh khẩn cấp? Có tài khoản phá kính không, và việc sử dụng nó có cảnh báo tới bạn không?

Cuối cùng, hãy hỏi ai giữ quyền quản trị gốc trên tài khoản đám mây và tên miền. Câu trả lời bạn nên hướng tới là doanh nghiệp của bạn giữ quyền gốc và cấp quyền vận hành cho đối tác.

Tài liệu thuộc về ai

Tài liệu là tài sản dễ bị bỏ quên nhất cho tới ngày bạn cần nó nhất. Hãy làm rõ ngay từ đầu rằng sơ đồ kiến trúc, runbook xử lý sự cố, quy trình vận hành, kịch bản tự động hóa và mã hạ tầng viết cho hệ thống của bạn thuộc quyền sở hữu của bạn, và bạn được nhận bản cập nhật liên tục chứ không phải một lần vào cuối hợp đồng.

Hỏi tài liệu được lưu ở đâu. Nếu nó nằm trong hệ thống nội bộ của đối tác mà bạn không truy cập được, thì trên thực tế bạn không sở hữu nó. Cách xử lý phổ biến và lành mạnh là tài liệu nằm trong kho lưu trữ do bạn kiểm soát, đối tác có quyền ghi, và mọi thay đổi đều để lại lịch sử.

Hỏi thêm về công cụ. Nếu đối tác dùng nền tảng giám sát hay tự động hóa của riêng họ, khi rời đi bạn mất những gì, và cấu hình cảnh báo cùng lịch sử số liệu có xuất ra được ở định dạng dùng lại không?

Nghĩa vụ tiếp nhận và nghĩa vụ trả lại

Bàn giao có hai chiều và cả hai đều cần nằm trong hợp đồng. Chiều tiếp nhận cần một kế hoạch có thời hạn, có tiêu chí hoàn thành, và quan trọng nhất là làm rõ SLA bắt đầu có hiệu lực từ thời điểm nào. SLA có hiệu lực ngay ngày ký, khi đối tác chưa hiểu hệ thống, không có ý nghĩa thực tế.

1. Sản phẩm bàn giao khi tiếp nhận: kiểm kê tài sản, sơ đồ kiến trúc đã xác minh, danh sách rủi ro, kế hoạch giám sát và runbook cho các kịch bản thường gặp.
2. Tiêu chí chuyển sang vận hành chính thức, ai ký xác nhận, và chi phí giai đoạn này nằm trong phí dịch vụ hay tính riêng.
3. Chiều trả lại: thời gian hỗ trợ chuyển tiếp tối thiểu sau khi chấm dứt, tính theo tháng chứ không phải theo ngày.
4. Nội dung trả lại: dữ liệu ở định dạng mở, tài liệu bản mới nhất, mã tự động hóa, và một khoảng thời gian dành cho việc chuyển giao tri thức trực tiếp giữa hai đội kỹ thuật.
5. Nghĩa vụ hỗ trợ chuyển tiếp phải áp dụng cho mọi lý do chấm dứt, kể cả khi hai bên không hài lòng với nhau.

Một câu hỏi kiểm chứng rất hiệu quả: nếu chúng tôi báo chấm dứt vào tháng tới, trong chín mươi ngày kế tiếp các anh chị giao lại những gì, ai làm và chúng tôi trả thêm bao nhiêu?

HiTechCloud có thể hỗ trợ gì

HiTechCloud cung cấp dịch vụ quản trị hạ tầng cho hệ thống chạy trên AWS, Google Cloud và hạ tầng đặt trong nước, với tư cách đối tác của AWS và Google Premier Partner. Nếu bạn đang xây dựng bộ tiêu chí lựa chọn nhà cung cấp, chúng tôi sẵn sàng trả lời toàn bộ các câu hỏi trong bài này bằng văn bản để bạn đưa vào bảng so sánh cùng các đối tác khác, và trao đổi về cách thiết kế phụ lục SLA, đường leo thang và kế hoạch bàn giao phù hợp với hệ thống cụ thể của bạn.