Checklist chọn nhà cung cấp máy chủ: 15 câu hỏi trước khi thuê

Chọn nhà cung cấp máy chủ cần đánh giá cả tài nguyên, khả năng vận hành và cách xử lý sự cố. Cấu hình cao không bù được việc backup không khôi phục được hoặc đường truyền không đáp ứng người dùng. Checklist dưới đây dùng cho VPS, Dedicated Server và có thể điều chỉnh cho GPU Server.

Trước khi yêu cầu báo giá, viết một bản yêu cầu ngắn: ứng dụng cần chạy, nơi người dùng truy cập, dữ liệu hiện tại, tốc độ tăng trưởng, thời gian gián đoạn chấp nhận được và nhân sự chịu trách nhiệm vận hành. Dùng cùng một bản yêu cầu để so sánh các nhà cung cấp.

Nhóm 1: tài nguyên và quyền kiểm soát

1. Tài nguyên được cấp riêng hay chia sẻ?

Với VPS, hỏi chính sách CPU: vCPU chia sẻ, giới hạn tải kéo dài hay tài nguyên được bảo đảm theo hợp đồng. Với dedicated, xác nhận máy vật lý dành cho bạn và phần dịch vụ nào vẫn dùng chung. Với GPU, hỏi cấp toàn card, phân vùng hay chia sẻ theo cơ chế nào. Tên gói không thay thế được mô tả tài nguyên.

2. Cấu hình được mô tả đủ chi tiết chưa?

Yêu cầu model CPU, số socket, số nhân/luồng, RAM khả dụng và loại ổ. Dung lượng quảng cáo cần đối chiếu với dung lượng dùng được sau RAID và phần dành cho OS. Nếu ứng dụng cần GPU, kiểm tra model chính xác, VRAM và cấu hình nhiều card thay vì chỉ đọc tổng VRAM.

3. Bạn có quyền quản trị nào?

Hỏi có root/administrator, console khi mất mạng và quyền cài lại OS không. Với máy vật lý, xác nhận cách dùng IPMI/iDRAC qua mạng quản trị. Kênh console giúp xử lý lỗi boot hoặc firewall nhưng vẫn cần bảo vệ bằng kiểm soát truy cập.

4. Có thể nâng cấp và chuyển máy thế nào?

Chốt trước việc tăng RAM, mở rộng ổ đĩa, đổi CPU hoặc chuyển sang máy khác. Hỏi downtime dự kiến, phí di chuyển, yêu cầu sao lưu và khả năng quay lại cấu hình cũ. Một kế hoạch nâng cấp chỉ rõ bước thực hiện hữu ích hơn câu trả lời 'có thể scale'.

Nhóm 2: mạng và phạm vi bảo vệ

5. Băng thông trong nước và quốc tế cam kết bao nhiêu?

Tách tốc độ cổng mạng khỏi băng thông thực tế được cấp. Hỏi mức cam kết, mức chia sẻ, lưu lượng giới hạn và điều kiện giảm tốc. Kiểm thử đến khu vực người dùng hoặc dịch vụ ứng dụng phụ thuộc; tải Docker image và gọi API nước ngoài có thể có đường đi khác truy cập website trong nước.

6. Có bao nhiêu IP và cơ chế routing ra sao?

Xác nhận IPv4/IPv6, phí cấp thêm, reverse DNS nếu cần và các cổng bị chặn theo chính sách. Hệ thống nhiều VM cần làm rõ routed subnet, VLAN hoặc NAT. Đừng mặc định mỗi VM bắt buộc có một IPv4 public.

7. Chống DDoS bảo vệ phần nào?

Hỏi giao thức được bảo vệ, cách kích hoạt lọc, khả năng gián đoạn và chính sách blackhole. WAF cho HTTP không thay thế bảo vệ dịch vụ UDP. Nếu cần game server hoặc API có đặc thù, yêu cầu mô tả profile phù hợp. Tham khảo các lớp chống DDoS và kiểm tra phạm vi thực tế trong hợp đồng.

Nhóm 3: dữ liệu và phục hồi

8. Backup lưu ở đâu và ai quản lý?

Hỏi chu kỳ, thời gian lưu, vị trí lưu, mã hóa và quyền xóa bản sao. RAID và snapshot tại chỗ chưa thay thế bản sao độc lập. Cần xác định bên nào chịu trách nhiệm backup OS, database và dữ liệu ứng dụng.

9. Có kiểm thử restore và mục tiêu phục hồi không?

RPO là mức mất dữ liệu theo thời gian có thể chấp nhận; RTO là thời gian mục tiêu để phục hồi. Ví dụ cần mất tối đa một giờ dữ liệu thì chỉ backup một lần mỗi ngày chưa đáp ứng yêu cầu. Hỏi bằng chứng thử restore, dung lượng đã thử và phụ thuộc ảnh hưởng thời gian khôi phục.

10. Trách nhiệm bảo mật được chia ra sao?

Làm rõ ai cập nhật OS, cấu hình firewall, quản lý khóa SSH, giám sát đăng nhập và ứng phó sự cố. 'Managed' cần có danh sách công việc cụ thể. Dùng tài khoản riêng, quyền tối thiểu và MFA khi dịch vụ quản trị hỗ trợ; hạn chế chia sẻ một mật khẩu cho nhiều người.

Nhóm 4: hỗ trợ, SLA và điều kiện thương mại

11. Hỗ trợ 24/7 có phạm vi gì?

Xác nhận kênh khẩn cấp, thời gian tiếp nhận, thời gian phản hồi và quy trình escalation. Phản hồi ticket nhanh không đồng nghĩa khôi phục ứng dụng nhanh. Hỗ trợ mạng và phần cứng có thể không bao gồm sửa code hoặc truy vấn database.

12. SLA đo gì và bồi hoàn thế nào?

Đọc đối tượng được đo: nguồn điện, mạng, host hay toàn bộ dịch vụ. Hỏi thời điểm bắt đầu tính sự cố, ngoại lệ bảo trì, cách gửi yêu cầu và mức service credit. Kiến trúc chịu lỗi của ứng dụng vẫn cần được thiết kế theo yêu cầu riêng.

13. Các công bố về data center có bằng chứng không?

Yêu cầu tên site và tài liệu phù hợp nếu chứng nhận là tiêu chí lựa chọn. Uptime Institute mô tả Tier III theo khả năng bảo trì đồng thời; điều đó không tự chứng minh SLA của ứng dụng. Không dùng PUE hoặc một sơ đồ dự phòng đơn lẻ để kết luận một site có chứng nhận.

14. Tổng chi phí và gia hạn có rõ không?

Kiểm tra backup, quản trị, giấy phép, mạng, IP, triển khai và các khoản thuế áp dụng. Yêu cầu điều kiện tăng giá, gia hạn, dừng dịch vụ và hoàn phí. Xem bảng giá thuê server để bắt đầu so sánh cấu hình cùng phạm vi dịch vụ.

15. Khi chuyển đi, bạn lấy dữ liệu bằng cách nào?

Xác nhận định dạng xuất dữ liệu, băng thông di chuyển, phí hỗ trợ, thời hạn truy cập sau khi dừng dịch vụ và quy trình xóa dữ liệu. Nên giữ một bản sao và tài liệu triển khai do chính bạn kiểm soát trước khi chuyển production.

Cách đánh giá sau khi có câu trả lời

Đánh dấu từng tiêu chí là đạt, cần làm rõ hoặc không đạt. Những yêu cầu bắt buộc như khôi phục dữ liệu và quyền truy cập cần được xử lý trước; giá thấp không nên bù trừ cho một điều kiện bắt buộc chưa đạt.

Kiểm thử trước khi chuyển production

• Chạy ứng dụng với dữ liệu thử gần thực tế; ghi CPU, RAM, I/O và độ trễ ở tải mục tiêu.
• Đo mạng đến khu vực người dùng vào nhiều khung giờ.
• Tạo backup và khôi phục vào môi trường tách biệt.
• Kiểm tra console, ticket hỗ trợ và quy trình xử lý khi mất kết nối.
• Chốt tiêu chí nghiệm thu, kế hoạch chuyển dữ liệu và phương án quay lại.

Nếu đang lựa chọn giữa nhiều loại dịch vụ, đọc Dedicated Server hay VPS, rồi gửi yêu cầu cấu hình tại Cloud VPS, máy chủ GPU hoặc Colocation.