Bảo trì app sau bàn giao giúp ứng dụng Android/iOS tiếp tục hoạt động ổn định khi hệ điều hành, thiết bị hoặc phần mềm kết nối thay đổi. Công việc có thể gồm sửa lỗi, kiểm tra bảo mật và cập nhật theo phạm vi hợp đồng.
Cần phân biệt bảo hành, bảo trì, hỗ trợ sự cố và nâng cấp: không phải mọi yêu cầu sau bàn giao đều được sửa miễn phí.
Trả lời nhanh: Hãy kiểm tra phạm vi hỗ trợ, giờ làm việc, thời gian phản hồi, cách khôi phục, quyền sở hữu và chi phí ngoài gói. App liên quan doanh thu hoặc dữ liệu nhạy cảm cần mức hỗ trợ phù hợp rủi ro.
Vì sao app vẫn cần bảo trì sau khi đã nghiệm thu?
Nghiệm thu xác nhận phiên bản đã bàn giao đáp ứng những gì hai bên thống nhất tại thời điểm đó. Sau khi app hoạt động thực tế, các thay đổi dưới đây vẫn có thể tạo ra lỗi hoặc nhu cầu cập nhật:
- Hệ điều hành hoặc thiết bị mới khiến app hoạt động khác trước.
- Dịch vụ thanh toán, đăng nhập, bản đồ hoặc máy chủ thay đổi.
- Lượng người dùng tăng gây lỗi chậm, mất dữ liệu hoặc đồng bộ.
- Lỗ hổng mới cần rà soát và khắc phục.
Các công cụ theo dõi lỗi và thử nghiệm phiên bản mới giúp phát hiện rủi ro, nhưng vẫn cần người phân loại sự cố, sửa lỗi, kiểm thử và theo dõi sau khi cập nhật. Với bản sửa khẩn cấp, cần có phương án hạn chế tác động nếu cập nhật không thành công.
Doanh nghiệp chuẩn bị phát hành có thể đối chiếu checklist ra mắt app và quy trình phát triển ứng dụng di động để đưa vận hành sau bàn giao vào kế hoạch từ sớm.
Phân biệt bảo hành, bảo trì, hỗ trợ và nâng cấp
| Hình thức | Bản chất | Ví dụ |
|---|---|---|
| Bảo hành | Sửa lỗi so với yêu cầu đã nghiệm thu, theo hợp đồng. | Tính sai giá. |
| Bảo trì sửa lỗi | Sửa lỗi khi sử dụng. | App bị thoát. |
| Bảo trì tương thích | Điều chỉnh theo hệ điều hành, phần mềm kết nối mới. | Cập nhật thư viện. |
| Bảo trì phòng ngừa | Giảm rủi ro trước sự cố. | Vá lỗi, thử khôi phục. |
| Hỗ trợ sự cố | Tiếp nhận và khôi phục hoạt động. | Không nhận được đơn. |
| Nâng cấp | Thêm chức năng ngoài phạm vi cũ. | Tích điểm mới. |
Ví dụ, từ 31/08/2026, Google Play có yêu cầu phiên bản Android mục tiêu mới đối với ứng dụng điện thoại khi gửi bản mới hoặc cập nhật, kèm ngoại lệ theo loại thiết bị. Đây là việc cần lên kế hoạch bảo trì kỹ thuật, không nên để sát ngày phát hành mới kiểm tra. Xem quy định Google Play và bài chi phí đưa app lên kho ứng dụng để xem các điều kiện phát hành chi tiết.
Ví dụ: tính tiền sai so với tài liệu đã duyệt là lỗi cần đối chiếu điều khoản bảo hành; yêu cầu thêm phương thức thanh toán mới là nâng cấp. Việc có tính phí hay không phụ thuộc phạm vi và nguyên nhân đã xác nhận, không chỉ dựa vào cách gọi của một bên.
Nhận bảo trì app do đơn vị khác viết: cần kiểm tra gì?
Nếu đổi đơn vị bảo trì, cần kiểm tra hiện trạng app trước khi cam kết thời gian xử lý lỗi. Đơn vị mới phải xác định có nhận được mã nguồn, tài khoản, tài liệu, dữ liệu và cách tạo bản cập nhật hay không. Bước này thường gọi là kiểm tra tiếp nhận hệ thống.
| Kiểm tra | Thông tin cần có | Mục đích |
|---|---|---|
| Mã nguồn | Kho mã, thư viện, cách tạo bản cập nhật. | Xác minh có thể sửa app. |
| Tài khoản | Google/Apple, máy chủ, tên miền. | Kiểm soát quyền. |
| Dữ liệu | Kết nối phần mềm, tài liệu, bản sao lưu. | Biết phần phụ thuộc. |
| Vận hành | Lỗi tồn đọng, báo cáo, cách thử và phát hành. | Ưu tiên việc cần làm. |
| Bảo mật | Người có quyền, thư viện cũ, lịch cập nhật. | Xác định rủi ro. |
Sau khi kiểm tra, hai bên mới nên thống nhất hệ thống nào được bảo trì, lỗi tồn đọng nào phải sửa riêng và thời gian hỗ trợ khả thi. Nếu thiếu mã nguồn, tài khoản quản trị hoặc dữ liệu sao lưu, cần xử lý những điểm này trước khi hứa sẽ khôi phục app trong một thời gian cố định.
Các mô hình gói hỗ trợ sau bàn giao
Gói bảo hành sau nghiệm thu
Sửa lỗi thuộc yêu cầu đã nghiệm thu, theo thời hạn và ngoại lệ trong hợp đồng; không bao gồm tính năng mới nếu chưa thỏa thuận.
Gói bảo trì định kỳ
Kiểm tra lỗi, cập nhật tương thích, sao lưu và phát hành bản sửa theo phạm vi định kỳ đã ký.
Gói hỗ trợ theo số giờ hoặc nhân sự
Thống nhất số giờ hoặc người hỗ trợ, cách duyệt việc và xử lý phần vượt gói.
Gói hỗ trợ vận hành có cam kết thời gian
Áp dụng khi gián đoạn app ảnh hưởng lớn tới doanh thu hoặc công việc. Cam kết phản hồi, khôi phục và giờ phục vụ phải ghi cụ thể trong hợp đồng.
Gói nâng cấp tính năng theo từng giai đoạn
Thêm chức năng mới nên có báo giá, tiến độ và nghiệm thu riêng, không trộn với thời gian sửa lỗi.
Doanh nghiệp nên chọn gói bảo trì app nào?
| App đang dùng | Gói nên cân nhắc | Điều cần hỏi |
|---|---|---|
| Mới bàn giao | Bảo hành và bảo trì cơ bản. | Hỗ trợ lỗi nào? |
| Đặt lịch, bán hàng | Bảo trì có cam kết thời gian. | Gián đoạn giao dịch xử lý thế nào? |
| App nội bộ thiết yếu | Hỗ trợ trong giờ hoạt động. | Có phương án làm việc tạm? |
| Dữ liệu nhạy cảm | Kiểm tra bảo mật kèm bảo trì. | Ai phụ trách sự cố dữ liệu? |
| Thường xuyên thêm chức năng | Gói giờ hoặc nâng cấp riêng. | Việc nào tính thêm? |
| Không có đội kỹ thuật | Hỗ trợ vận hành dài hạn. | Quyền tài khoản thuộc ai? |
Nên chọn theo hậu quả nếu app ngừng hoạt động, không chỉ theo số người dùng. Ví dụ, lỗi trang giới thiệu có thể chờ giờ làm việc; lỗi không nhận được thanh toán cần được ưu tiên cao hơn. Thời gian phản hồi cụ thể phải được thương lượng và ghi trong hợp đồng.
Cam kết thời gian hỗ trợ (SLA) cần hiểu thế nào?
SLA là thỏa thuận về mức hỗ trợ giữa khách hàng và đơn vị bảo trì. Không nên chỉ ghi “xử lý trong 4 giờ” mà thiếu giải thích: 4 giờ là bắt đầu trả lời, khôi phục tạm thời hay sửa xong? Các mốc này khác nhau:
| Cam kết | Ý nghĩa |
|---|---|
| Tiếp nhận | Xác nhận đã nhận lỗi. |
| Phản hồi | Có người phụ trách và thông báo ban đầu. |
| Khôi phục | Đưa dịch vụ hoạt động lại, có thể tạm thời. |
| Sửa dứt điểm | Khắc phục nguyên nhân. |
| Báo tiến độ | Chu kỳ cập nhật khi lỗi chưa xong. |
| Giờ hỗ trợ | Giờ hành chính, cuối tuần hay 24/7? |
Nên phân loại sự cố theo mức ảnh hưởng đến người dùng, doanh thu, dữ liệu và bảo mật. Ví dụ, không nhận được đơn hàng thường nghiêm trọng hơn lỗi căn lề giao diện. Mức ưu tiên cuối cùng cần được người phụ trách của hai bên xác nhận.
Quy trình bảo trì và cập nhật ứng dụng
- Nhận và phân loại lỗi, xác định mức ảnh hưởng.
- Thống nhất phương án và chi phí ngoài gói nếu có.
- Sửa và kiểm thử những phần liên quan.
- Phát hành có kiểm soát và theo dõi lỗi.
- Báo cáo kết quả, nguyên nhân và phòng ngừa.
Khi cần sửa lỗi khẩn cấp, có thể rút gọn bước kiểm tra nhưng không nên bỏ hoàn toàn. Cần biết ai duyệt, đã thử các thao tác quan trọng nào và xử lý thế nào nếu bản cập nhật gây lỗi mới.
KPI của gói bảo trì
| Theo dõi | Chỉ số tiêu biểu | Ý nghĩa |
|---|---|---|
| Ổn định | App thoát, đứng, không truy cập. | Người dùng có thao tác được? |
| Sự cố | Thời gian phản hồi, khôi phục. | Hỗ trợ có kịp thời? |
| Cập nhật | Lỗi phát sinh sau bản mới. | Cập nhật có an toàn? |
| Hỗ trợ | Yêu cầu tồn đọng, phải xử lý lại. | Có đáp ứng cam kết? |
| Bảo mật | Lỗ hổng, quyền truy cập, sao lưu. | Rủi ro đã được kiểm soát? |
| Kinh doanh | Đơn hàng hoặc nhiệm vụ hoàn thành. | Sự cố ảnh hưởng kết quả nào? |
Không có một mức chỉ số phù hợp cho mọi ứng dụng. Doanh nghiệp nên chọn vài chỉ số liên quan trực tiếp đến hoạt động của mình và so sánh theo thời gian. Xem bài các chỉ số sức khỏe ứng dụng nếu cần cách theo dõi chi tiết.
Bảo trì App cần kiểm tra bảo mật những gì?
- Kiểm tra thư viện và vá lỗ hổng theo rủi ro.
- Rà tài khoản, quyền truy cập và các mã bí mật.
- Thử khôi phục dữ liệu từ bản sao lưu.
- Có quy trình tiếp nhận, xử lý và thông báo sự cố dữ liệu.
Mức kiểm tra cần tương xứng với dữ liệu và rủi ro của app. Có thể đối chiếu tiêu chuẩn bảo mật ứng dụng di động OWASP MASVS và bài checklist bảo mật ứng dụng di động. Đây là tài liệu tham khảo, không có nghĩa ứng dụng đã được chứng nhận an toàn.
Hợp đồng bảo trì App cần ghi rõ điều gì?
- Phạm vi và giờ hỗ trợ: app, máy chủ nào; kênh và giờ liên hệ?
- Thời gian: phản hồi, khôi phục và báo tiến độ thế nào?
- Chi phí: công việc bao gồm và việc phát sinh được duyệt ra sao?
- Cập nhật: ai kiểm thử và gửi phiên bản mới?
- Quyền và bảo mật: mã nguồn, tài khoản, dữ liệu do ai giữ?
- Chấm dứt: bàn giao, thu hồi quyền và chuyển tiếp thế nào?
Khi nào chuyển từ bảo trì sang nâng cấp?
Bảo trì tập trung giữ ứng dụng hoạt động ổn định, tương thích và an toàn. Nâng cấp nhằm thêm chức năng hoặc thay đổi cách sử dụng. Nên báo giá riêng khi yêu cầu vượt khỏi phạm vi bảo trì đã thỏa thuận, ví dụ:
- Thêm chức năng chưa có trong hợp đồng cũ.
- Thiết kế lại phần quan trọng của ứng dụng.
- Thay đổi lớn cách vận hành hoặc kết nối hệ thống.
Các yêu cầu nâng cấp nên được gom thành kế hoạch riêng, có mục tiêu và điều kiện nghiệm thu. Xem kế hoạch phát triển phiên bản tiếp theo hoặc cách thuê đội phát triển app nếu cần hỗ trợ dài hạn.
Sai lầm thường gặp
- Cam kết xử lý khi chưa biết mã nguồn, hạ tầng.
- Nhầm bảo hành với tính năng mới.
- Cập nhật không kiểm thử hoặc không có phương án khôi phục.
- Giao toàn bộ tài khoản, dữ liệu cho nhà cung cấp.
App đã bàn giao nhưng thiếu người chịu trách nhiệm vận hành?
WebsiteHCM có thể tiếp nhận yêu cầu kiểm tra app đã bàn giao, rà mã nguồn, tài khoản Google Play/App Store, máy chủ, lỗi hiện tại và khả năng cập nhật trước khi đề xuất phạm vi hỗ trợ. Việc kiểm tra hiện trạng và các mức thời gian hỗ trợ cần được thống nhất riêng. Nếu cần bổ sung chức năng lớn, tham khảo dịch vụ phát triển ứng dụng di động.
Câu hỏi thường gặp
App ít người dùng có cần gói bảo trì không?
Có. Gói nhẹ vẫn cần theo dõi lỗi quan trọng, cập nhật cần thiết và sao lưu, nhất là app có dữ liệu hoặc giao dịch.
Thời gian phản hồi có phải thời gian sửa xong không?
Không. Phản hồi là tiếp nhận và bắt đầu hỗ trợ; khôi phục là giúp app hoạt động lại; sửa dứt điểm là xử lý nguyên nhân.
Cập nhật SDK là bảo trì hay nâng cấp?
Thường là bảo trì khi để app tương thích, an toàn. Thay đổi lớn hoặc tính năng mới có thể tính riêng.
Có thể giao bảo trì cho đội khác đội phát triển ban đầu không?
Có. Nên kiểm tra mã nguồn, tài khoản và khả năng tạo bản cập nhật trước khi cam kết thời gian hỗ trợ.
Gói theo giờ hay retainer tốt hơn?
Theo giờ hợp nhu cầu không đều; gói định kỳ hợp app cần theo dõi và cập nhật thường xuyên.
Kết luận
Gói bảo trì app sau bàn giao nên giúp doanh nghiệp biết rõ: khi có lỗi cần liên hệ ai, khi nào được phản hồi, phần nào được sửa trong gói và app sẽ được cập nhật ra sao. Với ứng dụng do đơn vị khác phát triển, hãy kiểm tra mã nguồn và quyền quản trị trước khi chốt cam kết. Đừng chọn gói chỉ dựa vào số giờ hoặc giá thấp; hãy đối chiếu rủi ro vận hành và tài sản cần bàn giao.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.