Bàn giao website production không phải là gửi một file zip và một mật khẩu. Đó là quá trình chuyển quyền sở hữu, thông tin vận hành, khả năng khôi phục và trách nhiệm xử lý sự cố từ người xây dựng sang khách hàng hoặc đội vận hành. Một website chỉ được coi là bàn giao hoàn tất khi bên nhận có thể hiểu hệ thống, kiểm tra trạng thái và khôi phục dịch vụ mà không cần phụ thuộc vào một cá nhân.
Checklist dưới đây phù hợp cho website doanh nghiệp, blog, landing page, CMS, ứng dụng web và hệ thống Nginx nhỏ. Bạn có thể rút gọn cho dự án đơn giản, nhưng không nên bỏ qua ownership, backup/restore, security, DNS/SSL, rollback và biên bản nghiệm thu. Các hạng mục security được đối chiếu với nhóm Configuration and Deployment Management Testing của OWASP WSTG [1].
Nguyên tắc bàn giao: bàn giao quyền kiểm soát chứ không bàn giao một bộ credential cố định. Mỗi quyền phải có chủ sở hữu, phạm vi, phương thức cấp, thời hạn và cách thu hồi. Mọi backup quan trọng phải có bằng chứng restore, không chỉ có trạng thái “đã chạy”.
1. Xác định phạm vi và tiêu chí hoàn tất
Trước khi bàn giao, ghi rõ website nào, môi trường nào, domain nào, tính năng nào và phần nào không nằm trong phạm vi. Production, staging, repository, database, email, analytics, CDN và bên thứ ba thường bị trộn lẫn nếu không lập inventory. Tiêu chí hoàn tất nên đo được: URL chính trả 200, form gửi được, email đến đúng, SSL hợp lệ, backup restore được, người nhận đăng nhập được và tài liệu đủ để xử lý các thao tác thường ngày.
| Hạng mục | Bằng chứng hoàn tất |
|---|---|
| Phạm vi | Danh sách domain, môi trường, tính năng và phần không bao gồm |
| Owner | Tên tổ chức/người sở hữu domain, hosting, code, dữ liệu và tài khoản bên thứ ba |
| Nghiệm thu | Test case có người thực hiện, thời gian, kết quả và issue còn mở |
| Vận hành | Runbook cho deploy, rollback, backup, restore, SSL, DNS và incident |
| Sign-off | Biên bản bàn giao có ngày hiệu lực và trách nhiệm sau bàn giao |
2. Bàn giao ownership và quyền truy cập
Lập danh sách tài sản và đổi chủ sở hữu sang email hoặc tổ chức của khách hàng khi phù hợp. Domain registrar, DNS provider, hosting/cPanel, repository, CI/CD, email transactional, CDN, analytics, Search Console, database, object storage và tài khoản thanh toán phải có owner rõ ràng. Không dùng email cá nhân của freelancer làm owner production.
Không gửi password production trong tài liệu Markdown, ticket hoặc chat. Dùng password manager, secret sharing có thời hạn hoặc quy trình reset trực tiếp. Tạo tài khoản riêng theo vai trò thay vì dùng chung một tài khoản admin; bật MFA nếu dịch vụ hỗ trợ; kiểm tra session cũ và thu hồi quyền tạm thời của người triển khai sau sign-off.
Access register
- Asset: hosting/cPanel
- Owner: operations@example.com
- Role: owner / admin / deploy / read-only
- Delivery channel: password manager item
- MFA: enabled / pending
- Temporary access expiry: YYYY-MM-DD
- Revocation evidence: ticket or audit log reference3. Inventory kỹ thuật cần bàn giao
Bên nhận cần có một bản đồ hệ thống ngắn gọn. Ghi domain và subdomain, DNS record, IP hoặc hostname, web server, runtime, framework/CMS, database, storage, queue, cron, mail, CDN, third-party API, repository và pipeline. Với mỗi thành phần, ghi version, vị trí cấu hình, owner, dependency và cách kiểm tra health.
- Domain, registrar, DNS zone, TTL, record A/AAAA/CNAME/MX/TXT và nơi quản lý nameserver.
- Hosting hoặc VPS, OS, web server, runtime, database, filesystem media, log và khu vực backup.
- Repository, branch production, build command, environment variables, secret store và quy trình deploy.
- Cron, queue, worker, webhook, email transactional, analytics, Search Console và các tích hợp ngoài.
- Đầu mối liên hệ, SLA nội bộ, lịch bảo trì và kênh báo sự cố.
4. Backup và kiểm tra restore
Backup phải trả lời ba câu hỏi: backup cái gì, lưu ở đâu và restore trong bao lâu. Với website, tối thiểu cần xem xét database, uploads/media, theme hoặc source code, cấu hình deploy và dữ liệu bên thứ ba trong phạm vi kiểm soát. Bản backup chỉ nằm trên cùng server không bảo vệ được khi disk, account hoặc toàn máy chủ gặp sự cố.
Tạo một bản restore thử trên môi trường tách biệt hoặc thư mục tạm, kiểm tra số lượng record, media, quyền file, URL, encoding, cron và các secret cần cấp lại. Ghi thời điểm backup, retention, kích thước, checksum nếu có, người test và kết quả. Đừng ghi secret thật vào checklist; chỉ ghi vị trí secret manager và quy trình cấp lại.
# Ví dụ kiểm tra backup ở mức file, thay đường dẫn theo hệ thống
sha256sum backup-2026-08-22.tar.gz
tar -tzf backup-2026-08-22.tar.gz | head
# Restore thử vào thư mục hoặc database staging, không ghi đè production
# Sau restore: kiểm tra URL, media, quyền file và health check5. DNS, SSL và đường đi request
Kiểm tra DNS record thực tế từ bên ngoài, không chỉ nhìn cấu hình trong panel. Xác minh domain chính, www, subdomain ứng dụng, MX email, TXT xác thực và các record CDN. Ghi TTL hiện tại và người có quyền thay đổi DNS. Với SSL, kiểm tra certificate chain, ngày hết hạn, auto-renew, redirect HTTP sang HTTPS và các domain có trong certificate.
- `dig` hoặc công cụ DNS trả đúng record cho domain chính và subdomain quan trọng.
- HTTP chuyển sang HTTPS đúng host, không tạo redirect loop hoặc redirect về domain cũ.
- Certificate còn hạn, chain hợp lệ và auto-renew có log hoặc cảnh báo lỗi.
- Sitemap, canonical, robots.txt và URL tuyệt đối dùng đúng domain production.
- Email MX/SPF/DKIM/DMARC được kiểm tra riêng, không đánh đồng email hosting với web hosting.
6. Deploy, rollback và thay đổi cấu hình
Bàn giao phải có một đường deploy lặp lại được. Ghi branch hoặc tag production, lệnh build, migration database, cách reload Nginx, cách restart service, nơi lưu environment variables và bước verify sau deploy. Nếu deploy bằng tay, ghi rõ từng bước và giới hạn quyền; nếu có CI/CD, ghi owner token, runner, secret và cách disable pipeline khi có sự cố.
# Mẫu verify sau deploy
nginx -t
systemctl is-active nginx
curl -fsS https://example.com/health
curl -fsSI https://example.com/important-page
# Nếu lỗi: dừng rollout, xem error log, rollback artifact và kiểm tra lạiRollback không nên chỉ là “restore bản cũ”. Ghi artifact hoặc commit có thể quay lại, migration database có tương thích ngược không, media đã đồng bộ chưa và ai có quyền quyết định rollback. Với DNS cutover, chuẩn bị TTL, thông báo, snapshot và thời gian giữ môi trường cũ để giảm rủi ro.
7. Security checklist theo OWASP
OWASP WSTG phân tách nhiều nhóm kiểm tra cấu hình và triển khai: network infrastructure, application platform, file nhạy cảm, backup cũ, admin interface, HTTP methods, HSTS, file permission, subdomain takeover, cloud storage, CSP, path confusion và HTTP security headers [1]. Khi chuyển thành checklist bàn giao, hãy ghi kết quả và bằng chứng thay vì chỉ đánh dấu “đã kiểm tra”.
| Nhóm kiểm tra | Checkpoint bàn giao |
|---|---|
| File và artifact | Không để `.env`, backup zip, dump database, source map hoặc file cũ trong web root nếu không cần |
| Admin | Liệt kê admin URL, MFA, role, session cũ, tài khoản tạm và cách thu hồi |
| HTTP | Chỉ bật method cần thiết; kiểm tra HSTS, CSP, X-Content-Type-Options và các header phù hợp |
| Permission | Web user chỉ có quyền cần thiết; thư mục upload không thực thi script ngoài policy |
| DNS/cloud | Kiểm tra subdomain cũ, bucket/storage public và record trỏ về tài nguyên không còn sở hữu |
| Platform | Patch runtime, dependency, CMS/plugin/theme và ghi version tại thời điểm bàn giao |
Các checkpoint không thay thế pentest hoặc audit chuyên sâu. Với dữ liệu nhạy cảm, thanh toán, tài khoản thành viên hoặc API công khai, cần đánh giá threat model và yêu cầu tuân thủ riêng. Bàn giao an toàn phải nêu giới hạn của checklist để bên nhận không hiểu nhầm rằng website đã được chứng nhận bảo mật.
8. Monitoring, log và xử lý sự cố
Bên nhận cần biết website đang khỏe hay không trước khi người dùng báo lỗi. Bàn giao URL health check, dashboard, log access/error, log deploy, cảnh báo SSL, disk, memory, database, queue và job thất bại. Ghi retention và timezone của log. Nếu chưa có monitoring, ghi rõ gap và người chịu trách nhiệm bổ sung; không đánh dấu hoàn tất chỉ vì website hiện đang trả 200.
- Health check kiểm tra status, latency và dependency quan trọng ở mức phù hợp.
- Alert có owner, kênh nhận và mức độ; thử một alert mẫu để chứng minh đường truyền hoạt động.
- Log không chứa secret hoặc dữ liệu cá nhân không cần thiết; quyền đọc log được giới hạn.
- Có runbook cho 403, 404, 502, disk full, database down, SSL sắp hết hạn và deploy lỗi.
- Ghi timezone, retention, cách export log và cách phối hợp với nhà cung cấp hosting.
9. SEO, analytics và nghiệm thu frontend
Kiểm tra các URL quan trọng từ góc nhìn người dùng và công cụ tìm kiếm. Xác minh status code, title, meta description, H1, canonical, robots, sitemap, internal link, Open Graph, structured data nếu có, analytics và Search Console. Khi migration server, không để thay đổi hạ tầng vô tình đổi slug, redirect hoặc môi trường indexable.
# Một số kiểm tra URL sau bàn giao
curl -sS -o /dev/null -w '%{http_code} %{url_effective}
' https://example.com/
curl -sSI https://example.com/robots.txt
curl -sSI https://example.com/sitemap.xml
# Kiểm tra redirect cũ và URL quan trọng theo bảng nghiệm thuTạo bảng test có URL, expected status, actual status, title, canonical, screenshot và người kiểm tra. Các form liên hệ, upload, login, thanh toán hoặc webhook cần test bằng dữ liệu an toàn, không dùng dữ liệu khách hàng thật nếu không cần. Ghi issue còn mở và mức độ ảnh hưởng trước khi ký nhận.
Khi bàn giao hệ thống Nginx, có thể đối chiếu thêm hướng dẫn xử lý Nginx 403 Forbidden và xử lý Nginx 502 Bad Gateway để bổ sung runbook sự cố cho đội vận hành.
10. Biên bản bàn giao mẫu
Biên bản nên ghi ngày hiệu lực, bên giao, bên nhận, phạm vi, tài sản, access register, backup/restore evidence, test result, issue còn mở, thời hạn hỗ trợ chuyển tiếp và điều kiện kết thúc hỗ trợ. Đính kèm link tài liệu vận hành và ticket thay vì chép password hoặc secret vào biên bản.
Handover acceptance
Project: ____________________
Production domains: __________
Owner after handover: ________
Backup restore tested at: ____
Security checks reviewed: ____
Open issues and severity: ____
Support window ends: _________
Accepted by / date: __________Kết luận
Một checklist bàn giao tốt phải giúp người khác tiếp quản mà không cần “hỏi người cũ mọi thứ”. Hãy ưu tiên quyền sở hữu, inventory, backup có restore test, DNS/SSL, deploy/rollback, security, monitoring và nghiệm thu có bằng chứng. Nếu còn gap, ghi rõ owner và deadline. Bàn giao minh bạch như vậy giảm downtime, giảm tranh chấp và tạo nền tảng để website được vận hành lâu dài.
Nguồn tham khảo
[1] OWASP WSTG — Configuration and Deployment Management Testing; [2] NGINX Beginner’s Guide; [3] CloudLinux Features — resource isolation and account controls.