Bàn giao VPS không nên bắt đầu bằng việc gửi mật khẩu root qua email hoặc ứng dụng nhắn tin. Cách làm đó nhanh, nhưng doanh nghiệp khó biết ai đã nhận được mật khẩu, quyền được dùng cho việc gì và phải thu hồi thế nào khi kết thúc dịch vụ.
Một quy trình bàn giao tốt không cần quá nhiều biểu mẫu. Mục tiêu là giúp đơn vị quản trị hiểu hệ thống trước khi thay đổi, có đủ quyền để làm việc và để doanh nghiệp vẫn kiểm soát được tài sản của mình.
Bàn giao quyền truy cập khác bàn giao quyền sở hữu
Tài khoản nhà cung cấp VPS, domain, DNS và dịch vụ thanh toán nên thuộc quyền kiểm soát của doanh nghiệp. Đơn vị quản trị được cấp quyền phù hợp để thực hiện công việc, không nên trở thành người duy nhất nắm tài khoản gốc hoặc thông tin khôi phục.
Nếu dịch vụ bắt buộc phải đăng ký qua tài khoản của nhà cung cấp, cần ghi rõ chủ sở hữu, email khôi phục, phương thức thanh toán và cách chuyển giao khi hợp đồng kết thúc.
Nguyên tắc này giúp doanh nghiệp đổi nhân sự hoặc đơn vị quản trị mà không bị gián đoạn chỉ vì mất quyền truy cập vào tài sản của chính mình.
Thông tin nên chuẩn bị trước khi cấp quyền
Không cần có một bộ tài liệu hoàn hảo mới bắt đầu bàn giao. Tuy nhiên, tối thiểu nên tập hợp:
- Nhà cung cấp, tên VPS, cấu hình và hệ điều hành.
- Domain, DNS, chứng chỉ SSL và nơi quản lý từng thành phần.
- Ứng dụng, database, container, cron job và dịch vụ đang chạy.
- Cách deploy phiên bản mới và cách quay lại phiên bản trước.
- Vị trí backup, lịch chạy, retention và lần thử khôi phục gần nhất.
- Monitoring hiện có, kênh nhận cảnh báo và người đang phản hồi.
- Các sự cố, thay đổi hoặc vấn đề còn tồn tại gần đây.
- Người có quyền phê duyệt thay đổi, chi phí và thời gian bảo trì.
Nếu thiếu thông tin, hãy đánh dấu là “chưa xác định” thay vì đoán. Đây cũng là đầu vào để lên kế hoạch khảo sát và bổ sung tài liệu sau khi tiếp nhận.
Bước 1: Xác nhận phạm vi bàn giao
Trước khi đăng nhập vào server, hai bên cần thống nhất danh sách tài sản và trách nhiệm. Ví dụ, phạm vi có thể gồm một VPS Linux, Nginx, Docker, SSL, backup và monitoring nhưng không gồm sửa lỗi nghiệp vụ trong source code.
Những nội dung nên được nói rõ:
- Thành phần nào được quản trị.
- Việc nào cần doanh nghiệp phê duyệt trước.
- Giờ hỗ trợ và cách phân loại sự cố.
- Ai chịu trách nhiệm source code, database và nhà cung cấp.
- Chi phí cho công việc ngoài phạm vi.
- Kênh liên hệ chính thức khi có thay đổi hoặc sự cố.
Phạm vi càng rõ thì đơn vị quản trị càng ít phải suy đoán khi hệ thống đang gặp vấn đề.
Bước 2: Ghi nhận hiện trạng trước khi thay đổi
Đơn vị tiếp nhận nên kiểm tra và lập baseline trước khi chỉnh cấu hình. Baseline thường gồm phiên bản hệ điều hành, tài nguyên, cổng public, service, container, dung lượng, tài khoản, firewall, backup và cảnh báo đang có.
Mục đích không phải tìm lỗi của người quản trị trước. Baseline giúp phân biệt vấn đề đã tồn tại với thay đổi mới, đồng thời xác định việc nào cần xử lý sớm và việc nào có thể lên lịch sau.
Nếu chưa có tài liệu đáng tin cậy, checklist kiểm tra VPS trước khi vận hành là danh sách tham khảo phù hợp để bắt đầu.
Bước 3: Cấp quyền theo từng lớp
Tài khoản nhà cung cấp
Ưu tiên tài khoản thành viên hoặc role riêng nếu nhà cung cấp hỗ trợ. Chỉ cấp quyền thanh toán, xóa tài nguyên hoặc thay đổi chủ sở hữu khi công việc thật sự cần.
Truy cập SSH
Tạo tài khoản hoặc SSH key riêng cho đơn vị quản trị. Không dùng chung một key giữa nhiều người và không gửi private key do doanh nghiệp đang sử dụng. Quyền sudo có thể cấp theo nhu cầu sau khi đã kiểm tra đăng nhập cơ bản.
DNS và dịch vụ liên quan
Domain, DNS, CDN, email và kho backup có thể nằm ở nhiều nhà cung cấp. Mỗi dịch vụ nên có quyền riêng và phương thức xác thực nhiều lớp nếu hỗ trợ.
Secret ứng dụng
Chỉ trao đổi secret khi đã xác định người nhận và kênh phù hợp. Không gửi password, token hay private key qua form liên hệ ban đầu. Những secret từng chia sẻ không an toàn nên được xoay sau khi hệ thống ổn định.
Bước 4: Kiểm tra quyền trước khi vô hiệu hóa quyền cũ
Không nên xóa tài khoản hoặc tắt phương thức SSH cũ ngay khi vừa tạo quyền mới. Hãy giữ một phiên đang hoạt động, kiểm tra tài khoản mới đăng nhập được và xác nhận sudo, firewall cùng các cơ chế khôi phục đều dùng được.
Với thay đổi DNS, firewall hoặc SSH, nên có phương án quay lại và người có quyền truy cập console của nhà cung cấp. Một lỗi nhỏ ở bước này có thể khiến cả hai bên bị khóa khỏi server.
Bước 5: Xử lý các tài khoản và quyền tồn đọng
Sau khi quyền mới hoạt động ổn định, rà soát:
- Tài khoản của nhân sự hoặc nhà cung cấp cũ.
- SSH key không còn xác định được chủ sở hữu.
- Token đã hết nhu cầu sử dụng.
- Tài khoản dùng chung không thể truy vết.
- Secret nằm trong repository, tài liệu hoặc lịch sử chat.
- Quyền quản trị cao hơn nhu cầu công việc.
Việc thu hồi nên thực hiện có thứ tự và ghi nhận thời điểm. Nếu một tài khoản vẫn cần giữ cho ứng dụng, cần xác định nó là service account và ai chịu trách nhiệm quản lý.
Bước 6: Thống nhất quy trình thay đổi production
Sau bàn giao, không nên để mọi thay đổi quay lại cách nhắn tin miệng. Một yêu cầu thay đổi tối thiểu cần có mục đích, ảnh hưởng dự kiến, thời gian thực hiện, người phê duyệt và cách rollback khi khả thi.
Với công việc thường xuyên như patch hoặc gia hạn SSL, có thể thống nhất cửa sổ bảo trì và mức quyền chủ động. Với migration database, thay đổi firewall hay nâng phiên bản lớn, nên xác nhận riêng trước khi làm.
Checklist xác nhận sau bàn giao
- ☐ Danh sách VPS, domain và dịch vụ liên quan đã được xác nhận.
- ☐ Doanh nghiệp vẫn kiểm soát tài khoản chủ sở hữu và phương thức khôi phục.
- ☐ Đơn vị quản trị có tài khoản hoặc key riêng.
- ☐ Quyền mới đã được kiểm tra trước khi thu hồi quyền cũ.
- ☐ Baseline, backup và monitoring đã được ghi nhận.
- ☐ Có danh sách vấn đề tồn tại và thứ tự ưu tiên xử lý.
- ☐ Kênh liên hệ, người phê duyệt và giờ hỗ trợ đã rõ.
- ☐ Quy trình thay đổi và xử lý sự cố đã được thống nhất.
- ☐ Cách bàn giao lại khi kết thúc dịch vụ đã được ghi nhận.
Khi kết thúc dịch vụ
Bàn giao an toàn cũng cần một điểm kết thúc rõ. Đơn vị quản trị nên chuyển lại tài liệu, danh sách thay đổi, vấn đề còn mở và trạng thái backup. Sau đó doanh nghiệp thu hồi tài khoản, xóa SSH key, xoay secret cần thiết và xác nhận không còn quyền truy cập ngoài phạm vi.
Nếu hệ thống chưa có baseline hoặc doanh nghiệp không chắc quyền hiện tại đang được quản lý ra sao, Server Health Check có thể giúp ghi nhận hiện trạng trước khi bắt đầu quá trình bàn giao.