Ở nhiều công ty phần mềm và doanh nghiệp nhỏ, developer là người hiểu ứng dụng rõ nhất nên cũng được giao luôn VPS, deployment, backup và xử lý sự cố. Cách tổ chức này có thể hoạt động tốt trong giai đoạn đầu, khi hệ thống còn đơn giản và số người dùng chưa nhiều.
Vấn đề xuất hiện khi sản phẩm lớn dần nhưng phần vận hành vẫn được xử lý như một việc phụ. Đây không phải câu chuyện developer có đủ giỏi hay không. Phát triển sản phẩm và giữ production ổn định là hai nhóm công việc có nhịp độ, ưu tiên và cách đo kết quả khác nhau.
1. Sự cố chỉ được xử lý sau khi người dùng bị ảnh hưởng
Developer thường làm việc theo backlog, sprint và thời hạn tính năng. Trong khi đó, monitoring cần được kiểm tra đều, kể cả lúc không có thay đổi source code.
Khi không ai chịu trách nhiệm trực tiếp cho hệ thống, các dấu hiệu như disk tăng nhanh, chứng chỉ sắp hết hạn, backup lỗi hoặc container restart có thể bị bỏ qua. Đến lúc khách hàng báo website chậm hay không truy cập được, thời gian xử lý đã chuyển từ bảo trì có kế hoạch sang chữa cháy.
Cách giảm rủi ro là xác định rõ ai nhận cảnh báo, cảnh báo nào cần phản hồi và trong khung giờ nào. Công cụ chạy liên tục không có nghĩa con người tự nhiên sẽ có mặt để xử lý.
2. Backup và monitoring có cấu hình nhưng thiếu người kiểm tra
Nhiều hệ thống đã cài monitoring hoặc có cron backup, nhưng không ai theo dõi kết quả. Email cảnh báo gửi vào hộp thư ít mở, dung lượng kho backup đầy hoặc job thất bại nhiều ngày mà không được phát hiện.
Monitoring cần có ngưỡng phù hợp, người nhận và hành động tiếp theo. Backup cần được kiểm tra nội dung, retention và khả năng khôi phục. Nếu chưa từng restore, doanh nghiệp chưa biết bản sao có đủ database, file upload, secret và hướng dẫn cần thiết hay không.
Đây là những việc ít tạo cảm giác cấp bách khi hệ thống đang chạy tốt, nên rất dễ bị nhường chỗ cho tính năng mới.
3. Thay đổi production thiếu chuẩn bị và rollback
Khi developer vừa viết code vừa tự deploy, một thay đổi nhỏ có thể được đưa thẳng lên server vì người thực hiện đã hiểu bối cảnh. Cách này nhanh, nhưng phụ thuộc nhiều vào trí nhớ và trạng thái của một người.
Rủi ro thường gặp gồm:
- Không ghi lại image hoặc commit đang chạy trước khi deploy.
- Database migration không tương thích với phiên bản cũ.
- Sửa trực tiếp file trên production nhưng không đưa thay đổi về repository.
- Không kiểm tra dung lượng trước khi build hoặc pull image.
- Rollback ứng dụng nhưng quên cấu hình, secret hoặc dữ liệu đã thay đổi.
Một quy trình release gọn chỉ cần nêu phiên bản, thời điểm, người phê duyệt, kiểm tra sau triển khai và cách quay lui. Mục tiêu không phải tạo thêm thủ tục mà là tránh phải nhớ mọi thứ khi sự cố đang diễn ra.
4. Quyền truy cập và secret tích tụ theo thời gian
Developer cần nhiều quyền để xử lý nhanh: tài khoản cloud, SSH, DNS, registry, database và API key. Nếu không có lịch rà soát, quyền của nhân sự cũ và token thử nghiệm sẽ tồn tại lâu hơn nhu cầu thực tế.
Tài khoản dùng chung cũng khiến doanh nghiệp khó xác định ai đã thay đổi cấu hình. Secret gửi qua chat, đặt trong .env trên nhiều máy hoặc ghi vào tài liệu không phù hợp có thể bị quên nhưng vẫn còn hiệu lực.
Quyền truy cập nên được cấp riêng, giới hạn theo công việc và có ngày rà soát. Khi bàn giao cho người khác, không nên gửi lại private key đang dùng mà cần tạo quyền mới. Bài Quy trình bàn giao VPS an toàn trình bày chi tiết hơn phần này.
5. Công việc phát triển bị gián đoạn và khó đo chi phí
Một lần kiểm tra server có thể chỉ mất 15 phút, nhưng developer phải dừng mạch suy nghĩ, chuyển ngữ cảnh, xử lý rồi quay lại công việc cũ. Nếu việc này xảy ra nhiều lần trong tuần, chi phí không chỉ nằm ở số phút thao tác trên VPS.
Sự cố nghiêm trọng còn kéo theo họp, trao đổi với khách hàng, kiểm tra log, khôi phục dữ liệu và theo dõi sau xử lý. Roadmap sản phẩm bị chậm nhưng doanh nghiệp khó nhìn thấy nguyên nhân vì “developer vẫn đang làm việc”.
Ghi nhận thời gian vận hành trong một tháng sẽ giúp đánh giá đúng hơn. Hãy tính cả thời gian phản hồi cảnh báo, backup, patch, deployment và điều tra sự cố, không chỉ thời gian gõ lệnh.
Không phải lúc nào cũng cần tách thành hai vị trí toàn thời gian
Đội nhỏ có thể phân chia trách nhiệm mà chưa cần tuyển ngay một DevOps riêng. Một mô hình thực tế là:
- Developer sở hữu source code, kiểm thử chức năng và yêu cầu runtime.
- Một người hoặc dịch vụ vận hành sở hữu monitoring, backup, VPS, Docker Engine, reverse proxy và SSL.
- Hai bên cùng thống nhất release, health check, migration và rollback.
- Chủ doanh nghiệp hoặc người phụ trách sản phẩm phê duyệt thay đổi có ảnh hưởng lớn.
Điều quan trọng là mỗi nhóm việc có người nhận trách nhiệm, lịch kiểm tra và kết quả có thể xem lại.
Cách chuyển giao dần mà không làm chậm đội phát triển
Bắt đầu bằng danh sách công việc đang có
Trong hai đến bốn tuần, ghi lại những lần developer phải xử lý server: cảnh báo, backup, deploy, SSL, disk, tài khoản và incident. Danh sách này phản ánh nhu cầu thật tốt hơn một mẫu mô tả công việc chung.
Ghi nhận hiện trạng và tài sản
Lập danh sách VPS, domain, service, quyền truy cập và cách deploy. Những phần chưa rõ được đưa vào danh sách cần khảo sát, không cần dừng mọi công việc để hoàn thiện tài liệu ngay một lần.
Chuyển các việc lặp lại trước
Monitoring, kiểm tra backup, patch theo lịch và báo cáo là nhóm dễ tách khỏi phát triển. Developer vẫn tham gia khi cần hiểu ứng dụng, nhưng không phải tự nhớ lịch hoặc kiểm tra thủ công mỗi ngày.
Thống nhất điểm giao giữa ứng dụng và hạ tầng
Health endpoint, log, migration, secret và yêu cầu tài nguyên là các điểm hai bên cần phối hợp. Nêu rõ người xác nhận ứng dụng hoạt động sau deployment và người quyết định rollback khi có lỗi.
Đánh giá lại sau một chu kỳ vận hành
Sau một hoặc hai tháng, xem số cảnh báo, thời gian xử lý, sự cố lặp lại và lượng thời gian developer đã lấy lại được. Từ đó điều chỉnh phạm vi thay vì cố định một mô hình ngay từ đầu.
Khi nào nên giữ developer tham gia trực tiếp?
Developer vẫn cần có mặt khi lỗi liên quan logic nghiệp vụ, database migration, hiệu năng code hoặc hành vi chỉ đội sản phẩm hiểu rõ. Người vận hành không thể thay thế kiến thức về ứng dụng.
Ngược lại, các việc như theo dõi tài nguyên, SSL, backup, Docker host, reverse proxy và cập nhật hệ điều hành không nên phụ thuộc vào thời gian rảnh của developer. Phân chia đúng giúp cả hai bên xử lý nhanh hơn khi sự cố đi qua nhiều lớp.
Nếu đội phát triển đang mất nhiều thời gian cho những việc vận hành lặp lại, Application Ops giúp HTS Việt phối hợp cùng developer ở lớp VPS, Docker, deployment và monitoring, trong khi đội của bạn tiếp tục chịu trách nhiệm về sản phẩm và source code.