Đưa website lên được không có nghĩa VPS đã sẵn sàng vận hành. Một hệ thống có thể trả HTTP 200 nhưng vẫn thiếu backup, dùng tài khoản quản trị không phù hợp hoặc không có cảnh báo khi dung lượng đĩa sắp cạn.
Checklist dưới đây giúp chủ doanh nghiệp và đội phát triển rà soát các điểm cơ bản trước khi nhận người dùng thật. Nó không thay thế đánh giá bảo mật chuyên sâu, nhưng đủ để phát hiện nhiều rủi ro vận hành thường gặp.
1. Ghi lại hiện trạng và người chịu trách nhiệm
Trước khi thay đổi cấu hình, hãy xác định VPS đang chạy ở đâu, ai quản lý tài khoản nhà cung cấp và ai có quyền phê duyệt thay đổi trên production. Tối thiểu cần ghi lại:
- Nhà cung cấp, gói tài nguyên, hệ điều hành và phiên bản.
- Domain, DNS, chứng chỉ SSL và ngày hết hạn.
- Các dịch vụ chính: web server, database, Docker và cron job.
- Người giữ tài khoản thanh toán, quyền root và phương thức khôi phục tài khoản.
- Cách triển khai phiên bản mới và cách quay lại phiên bản trước.
Nếu những thông tin này chỉ nằm trong trí nhớ của một người, đó đã là một rủi ro cần xử lý.
2. Kiểm tra tài nguyên thay vì chỉ nhìn cấu hình gói
Thông số “4 CPU, 8 GB RAM” chưa cho biết hệ thống có đủ tài nguyên hay không. Hãy xem mức sử dụng trong một khoảng thời gian có tải thực tế:
- CPU, load average và tiến trình sử dụng nhiều CPU.
- RAM, swap và dấu hiệu tiến trình bị hệ điều hành dừng vì thiếu bộ nhớ.
- Dung lượng đĩa, inode và tốc độ tăng của log hoặc dữ liệu upload.
- Dung lượng database và không gian tạm cần cho backup, update.
Đặc biệt, đừng bỏ qua inode. VPS vẫn có thể báo còn dung lượng nhưng không tạo được file mới nếu đã dùng hết inode. Bài VPS đầy ổ đĩa: nguyên nhân và cách phòng ngừa trình bày kỹ hơn phần này.
3. Rà soát dịch vụ và cổng public
Chỉ những dịch vụ thực sự cần thiết mới nên lắng nghe trên Internet. Kiểm tra danh sách cổng đang mở, firewall của VPS và firewall của nhà cung cấp cloud nếu có.
Database, Redis hoặc dashboard quản trị không nên public chỉ vì việc kết nối sẽ tiện hơn. Nếu cần truy cập từ xa, hãy dùng VPN, private network, SSH tunnel hoặc cơ chế kiểm soát truy cập phù hợp.
Đồng thời kiểm tra các service có tự khởi động sau reboot hay không. Một lần restart có kế hoạch trong staging thường phát hiện được cấu hình phụ thuộc vào thao tác thủ công.
4. Tài khoản, SSH và secret
Các điểm tối thiểu cần rà soát:
- Không dùng chung một tài khoản root cho nhiều người.
- Mỗi người có tài khoản hoặc khóa riêng và quyền đúng với công việc.
- Tắt quyền truy cập cũ ngay khi không còn nhu cầu.
- Có phương án truy cập khẩn cấp nếu cấu hình SSH gặp lỗi.
- Secret không nằm trong repository, image Docker hoặc tài liệu công khai.
- Có kế hoạch xoay secret đã từng chia sẻ qua kênh không an toàn.
Không nên tắt ngay một phương thức truy cập khi chưa kiểm tra phiên đăng nhập thay thế. Với SSH và firewall, luôn giữ một phiên đang hoạt động cho tới khi xác nhận cấu hình mới dùng được.
5. Backup phải đi kèm khả năng khôi phục
Kiểm tra job “thành công” mới chỉ là bước đầu. Cần biết dữ liệu nào được backup, lưu ở đâu, giữ bao lâu và ai nhận cảnh báo khi job lỗi. Ít nhất một bản sao nên nằm ngoài VPS đang chạy.
Quan trọng hơn, hãy thử khôi phục bằng dữ liệu kiểm soát. Nếu chưa từng restore, bạn chưa biết bản backup có đủ file, database, quyền truy cập và hướng dẫn cần thiết hay không. Xem thêm bài Có backup chưa đủ: vì sao cần thử khôi phục để lập kế hoạch kiểm tra.
6. Monitoring cần nhìn từ bên ngoài và bên trong
Một website trả về trang mặc định của Nginx vẫn có thể được công cụ uptime đánh dấu “đang hoạt động”. Ngược lại, server có CPU và RAM bình thường nhưng người dùng không truy cập được vì DNS hoặc SSL.
Vì vậy nên có cả hai lớp:
- Giám sát bên ngoài: domain, HTTPS, endpoint quan trọng và thời gian phản hồi.
- Giám sát bên trong: CPU, RAM, disk, service, container và kết quả backup.
Các cảnh báo phải có người nhận và quy tắc phản hồi. Monitoring không tạo giá trị nếu thông báo bị gửi vào một hộp thư không ai kiểm tra.
7. Ghi lại cách triển khai và quay lui
Trước mỗi lần release, cần biết artifact nào được triển khai, biến môi trường nào cần có, migration nào sẽ chạy và điều kiện để rollback. Với database migration không tương thích ngược, “deploy lại bản cũ” có thể không đủ để khôi phục dịch vụ.
Hãy thử quy trình trên staging hoặc bản sao phù hợp. Ghi rõ ai xác nhận ứng dụng hoạt động sau triển khai và những endpoint nào cần kiểm tra.
Checklist rút gọn trước go-live
- ☐ Có danh sách thành phần, tài khoản và người phụ trách.
- ☐ Tài nguyên và tốc độ tăng dữ liệu đã được kiểm tra.
- ☐ Chỉ các cổng cần thiết được public.
- ☐ Quyền SSH, firewall và secret đã được rà soát.
- ☐ Backup ngoài máy tồn tại và đã thử khôi phục.
- ☐ Có monitoring bên ngoài, bên trong và người nhận cảnh báo.
- ☐ Có quy trình deploy, kiểm tra sau deploy và rollback.
- ☐ Domain, DNS, SSL và ngày gia hạn đã có người theo dõi.
Nếu bạn cần một đánh giá độc lập, Server Health Check của HTS Việt sẽ rà soát hiện trạng và sắp xếp vấn đề theo mức độ ưu tiên trước khi bạn quyết định thay đổi.