Deploy thủ công rủi ro không chỉ là vấn đề kỹ thuật — nó là rủi ro kinh doanh. Mỗi lần một developer SSH vào server lúc 2h sáng, copy file bằng FTP, chạy vài lệnh, rồi “hy vọng” mọi thứ hoạt động — doanh nghiệp đang đặt cược doanh thu, uy tín và dữ liệu khách hàng vào một quy trình không kiểm soát được. Bài viết này phân tích tại sao deploy thủ công nguy hiểm và cách chuyển đổi sang automated deployment.
Thực trạng deploy tại SME Việt Nam
Khảo sát nhanh
Nếu team dev của bạn deploy theo 1 trong các cách sau, bạn đang gặp rủi ro:
- FTP upload file lên server
- SSH vào server, git pull, restart app
- Copy file qua USB/email rồi upload lên hosting
- Remote desktop vào server Windows, copy paste
- Deploy vào ban đêm/cuối tuần “cho ít ảnh hưởng”
- Chỉ 1 người biết cách deploy
- Không có checklist deploy
Tick 3+ mục: Doanh nghiệp bạn đang mang rủi ro deploy nghiêm trọng.
Tại sao vẫn deploy thủ công?
| Lý do | Thực tế |
|---|---|
| ”Team nhỏ, không cần CI/CD” | Team càng nhỏ, càng không đủ người fix khi deploy lỗi |
| ”CI/CD phức tạp, tốn tiền” | GitHub Actions miễn phí, setup 1 giờ |
| ”Deploy thủ công nhanh hơn” | Nhanh deploy, nhưng chậm fix khi lỗi |
| ”Chưa từng gặp vấn đề” | Chưa gặp ≠ không có vấn đề. 30% deploy thủ công gây lỗi |
| ”Chỉ tôi biết deploy” | Đó chính là rủi ro — 1 người nghỉ = không ai deploy |
5 rủi ro nghiêm trọng
Rủi ro 1: Con người sai — Máy không sai
Thực tế: Tỷ lệ lỗi deploy thủ công là 20-30%. Tỷ lệ lỗi deploy tự động: < 2%.
Lỗi phổ biến khi deploy thủ công:
| Lỗi | Hậu quả | Tần suất |
|---|---|---|
| Quên upload 1 file | Feature không hoạt động | Rất phổ biến |
| Upload nhầm file cũ | Bug đã fix quay lại | Phổ biến |
| Quên chạy migration database | App crash vì database schema sai | Phổ biến |
| Quên clear cache | User thấy giao diện cũ | Rất phổ biến |
| Quên restart service | Code mới không load | Phổ biến |
| Upload file config production vào staging | Staging dùng production database | Nguy hiểm |
| Nhầm server staging và production | Deploy test code lên production | Rất nguy hiểm |
Câu chuyện thật: Dev tại một công ty e-commerce ở TP.HCM deploy lúc 1h sáng. Mệt, nhầm cửa sổ terminal — chạy lệnh trên production thay vì staging. Database production bị xóa 1 bảng. 5,000 đơn hàng mất. Khôi phục từ backup mất 6 giờ. Thiệt hại: ~200 triệu VND doanh thu + overtime team + khách hàng khiếu nại.
Rủi ro 2: Single Point of Failure — “Anh X nghỉ là chết”
Tình huống: Chỉ 1 developer/admin biết cách deploy. Quy trình deploy nằm trong đầu người đó, không có documentation.
Kịch bản worst case:
- Thứ 6: Phát hiện bug nghiêm trọng trên production (checkout không hoạt động)
- Anh X (người duy nhất biết deploy) đang đi du lịch, không có sóng
- Cả team ngồi nhìn nhau — không ai deploy được hotfix
- Website lỗi suốt cuối tuần → mất 2 ngày doanh thu
Giải pháp CI/CD: Deploy = click 1 nút hoặc merge code. BẤT KỲ AI trong team đều deploy được.
Rủi ro 3: Không rollback được
Deploy thủ công: Lỗi → “file cũ đâu rồi?” → “backup lần cuối là… 3 ngày trước?” → khôi phục mất 2-4 giờ.
Deploy tự động: Lỗi → click “Rollback to previous version” → 2 phút trở lại bản cũ.
So sánh thời gian rollback:
| Phương pháp | Thời gian rollback | Rủi ro mất data |
|---|---|---|
| FTP (tìm file cũ, upload lại) | 30-60 phút | Cao |
| SSH git pull (git revert) | 10-20 phút | Trung bình |
| CI/CD (re-deploy previous build) | 2-5 phút | Thấp |
| Blue-Green deployment | 30 giây | Rất thấp |
Rủi ro 4: Bảo mật — FTP là “cánh cửa mở”
FTP truyền dữ liệu không mã hóa. Password, source code, config files — tất cả gửi plaintext qua internet. Bất kỳ ai trên cùng mạng (đặc biệt WiFi công cộng) có thể đọc được.
Rủi ro bảo mật khi deploy thủ công:
| Rủi ro | Giải thích |
|---|---|
| FTP password bị sniff | Hacker đọc password trên mạng |
| SSH key share giữa nhiều người | 1 người mất key = tất cả bị ảnh hưởng |
| Server credentials trong chat/email | Zalo, email bị hack = server bị hack |
| No audit trail | Không biết ai deploy gì lúc nào |
| Forgotten test accounts on production | Deploy code test lên production với debug mode on |
Rủi ro 5: Mất đồng bộ — “Production khác staging”
Kịch bản: Dev test trên staging OK → deploy production → lỗi. Tại sao? Staging và production không giống nhau:
- Staging có Node.js 18, production vẫn Node.js 16
- Staging database schema đã update, production chưa
- Staging có environment variable, production thiếu
- Staging OS đã patch, production chưa
CI/CD + Docker giải quyết: Ứng dụng chạy trong Docker container — giống nhau 100% trên staging và production. “Chạy trên staging = chạy trên production.”
Chi phí thực sự của deploy thủ công
Bảng chi phí ẩn
| Hạng mục | Deploy thủ công | Deploy tự động |
|---|---|---|
| Thời gian deploy/lần | 2-4 giờ | 10-15 phút |
| Deploys/tháng | 2-4 (vì sợ) | 20-60 (vì tin tưởng) |
| Thời gian fix deploy lỗi | 2-8 giờ | 5-30 phút |
| Deploy lỗi/tháng | 1-2 lần | 0-1 lần |
| Overtime deploy ban đêm | 5-10 giờ/tháng | 0 |
| Tổng giờ lãng phí/tháng | 20-40 giờ | 2-5 giờ |
| Chi phí (dev 40tr/tháng) | 5-10 triệu/tháng | 500K-1.5tr/tháng |
Chi phí downtime
| Doanh thu/ngày | Downtime 1 giờ | Downtime 4 giờ | Downtime 1 ngày |
|---|---|---|---|
| 10 triệu | 417K | 1.7 triệu | 10 triệu |
| 50 triệu | 2.1 triệu | 8.3 triệu | 50 triệu |
| 200 triệu | 8.3 triệu | 33 triệu | 200 triệu |
1 lần deploy lỗi gây downtime 4 giờ có thể tốn nhiều hơn cả năm chi phí CI/CD.
Chuyển từ thủ công sang tự động — Lộ trình 2 tuần
Tuần 1: Setup CI (test tự động)
- Ngày 1: Chuyển tất cả code lên GitHub (nếu chưa)
- Ngày 2: Tạo GitHub Actions workflow: auto build + lint
- Ngày 3: Thêm automated tests vào pipeline
- Ngày 4-5: Fix tests fail, adjust workflow
Tuần 2: Setup CD (deploy tự động)
- Ngày 1: Setup staging environment
- Ngày 2: Tạo CD workflow: auto deploy staging khi merge develop
- Ngày 3: Tạo CD workflow: auto deploy production khi merge main
- Ngày 4: Test toàn bộ flow: code → test → staging → production
- Ngày 5: Documentation + đào tạo team
Checklist chuyển đổi
- Toàn bộ code trên GitHub/GitLab
- Branch protection: không push trực tiếp vào main
- CI pipeline: auto test khi push
- CD pipeline: auto deploy staging
- CD pipeline: auto deploy production (sau approval)
- Rollback process documented
- Monitoring sau deploy
- Notification (Slack/email) khi deploy
- Cả team biết quy trình mới
So sánh chi phí: Thủ công vs Tự động
| Hạng mục | Thủ công (12 tháng) | Tự động (12 tháng) |
|---|---|---|
| Giờ deploy lãng phí | 240-480 giờ | 24-60 giờ |
| Chi phí nhân sự (quy đổi) | 60-120 triệu | 6-15 triệu |
| Downtime do deploy lỗi | 24-96 giờ | 2-6 giờ |
| Chi phí downtime | 20-200 triệu | 2-20 triệu |
| CI/CD tools | 0 | 0 (GitHub Actions free) |
| Setup cost | 0 | 10-30 triệu (1 lần) |
| Tổng | 80-320 triệu | 18-65 triệu |
Trinh Digital giúp chuyển đổi
Tại Trinh Digital, chúng tôi giúp team dev:
- CI/CD Setup Express — Setup pipeline trong 1-2 ngày, từ 15 triệu VND
- DevOps Audit — Đánh giá quy trình deploy hiện tại, đề xuất cải thiện
- Training — Đào tạo team sử dụng CI/CD, Git workflow
- Managed DevOps — Quản trị pipeline hàng tháng
FAQ — Câu hỏi thường gặp
1. Deploy thủ công có khi nào OK không?
Chỉ khi: (1) Website tĩnh HTML, không có backend, (2) Deploy 1 lần rồi không thay đổi, (3) Side project cá nhân không quan trọng. Mọi website/app kinh doanh đều nên có CI/CD.
2. Chuyển sang CI/CD có ảnh hưởng doanh nghiệp không?
Không, nếu làm đúng. Setup CI/CD trên branch develop trước, test 1-2 tuần, rồi mới áp dụng cho production. Zero downtime chuyển đổi.
3. Team chỉ có 1 developer, có cần CI/CD?
Đặc biệt cần. 1 developer = không có ai backup. CI/CD đảm bảo deploy nhất quán dù bạn mệt, bận hay đang đi du lịch. Merge code → tự động deploy → không cần SSH vào server.
Vẫn đang deploy bằng FTP? Liên hệ Trinh Digital để chuyển sang automated deployment trong 2 ngày.