Bảo trì phần mềm là gì? 4 loại bảo trì và chi phí ẩn

Bảo trì phần mềm là công việc giữ một hệ thống đã bàn giao tiếp tục làm đúng việc: sửa lỗi, thích nghi với môi trường thay đổi, cải thiện phần lỗi thời và phòng ngừa rủi ro. Bốn loại bảo trì có chi phí khác nhau, và phần lớn chi phí ẩn nằm ngoài việc sửa mã.

Tóm tắt nhanh

• Bảo trì phần mềm gồm bốn loại: sửa lỗi, thích nghi, hoàn thiện và phòng ngừa. Mỗi loại có nguồn gốc chi phí riêng, nên gộp tất cả vào một dòng "bảo trì" là cách nhanh nhất để mất kiểm soát ngân sách.
• Loại tốn kém nhất trong đa số hệ thống không phải sửa lỗi mà là thích nghi: nâng cấp thư viện, thay đổi API bên thứ ba, thay đổi quy định về dữ liệu.
• Ba chi phí ẩn lớn nhất là kiểm thử hồi quy, mất kiến thức về mã cũ và thời gian chờ phối hợp. Cả ba đều không xuất hiện trong báo giá ban đầu.
• Cách lập ngân sách đáng tin là tính theo đơn vị công việc dựa trên số bề mặt thay đổi, không dựa trên cảm giác "hệ thống vẫn đang chạy".
• Hợp đồng bảo trì chỉ có giá trị khi định nghĩa được ba thứ: thế nào là một lỗi, thời gian phản hồi bắt đầu từ đâu, và phiên bản nào còn được hỗ trợ.

Bảo trì phần mềm là gì và không phải là gì

Bảo trì là giai đoạn dài nhất trong vòng đời một hệ thống. Một dự án xây dựng có điểm kết thúc rõ ràng: nghiệm thu, bàn giao, thanh lý. Bảo trì thì không có điểm kết thúc tự nhiên, chỉ có điểm dừng do con người quyết định — khi hệ thống bị thay thế, khi nghiệp vụ biến mất, hoặc khi tổ chức chấp nhận ngừng đầu tư.

Chuẩn quốc tế về bảo trì phần mềm, ISO/IEC 14764, chia bảo trì thành bốn nhóm dựa trên lý do phải sửa, không dựa trên khối lượng công việc. Cách chia này hữu ích vì mỗi lý do có một nguồn chi phí khác nhau và một cách kiểm soát khác nhau. Một hệ thống có nhiều yêu cầu sửa lỗi là hệ thống có vấn đề chất lượng. Một hệ thống có nhiều việc thích nghi là hệ thống phụ thuộc vào môi trường bên ngoài. Hai tình huống này cần hai phản ứng hoàn toàn khác nhau.

Điều quan trọng là phân biệt bảo trì với ba khái niệm hay bị dùng lẫn:

Bảo trì khác vận hành. Vận hành là các việc lặp lại hằng ngày để hệ thống chạy: giám sát, sao lưu, xử lý yêu cầu người dùng, mở khoá tài khoản. Bảo trì là thay đổi chính hệ thống: sửa mã, nâng cấp thành phần, điều chỉnh cấu trúc dữ liệu.

Bảo trì khác bảo hành. Bảo hành là nghĩa vụ sửa lỗi trong một thời hạn và phạm vi đã cam kết, thường gắn với hợp đồng xây dựng. Bảo trì là hoạt động tiếp tục sau khi bảo hành hết hạn, và bao gồm cả những việc không phải lỗi: thích nghi, cải thiện, phòng ngừa.

Bảo trì khác phát triển tiếp. Phát triển tiếp là thêm năng lực mới theo yêu cầu kinh doanh. Bảo trì là giữ năng lực hiện có không bị mai một. Trên thực tế hai việc này dùng chung một đội và một kho mã, nên chúng thường bị trộn vào nhau trong báo cáo — và đó là lý do không ai biết tiền đang đi đâu.

Một cách kiểm tra đơn giản: nếu công việc làm hệ thống làm được việc mới, đó là phát triển. Nếu công việc làm hệ thống tiếp tục làm được việc cũ trong điều kiện mới, đó là bảo trì.

Bốn loại bảo trì và dấu hiệu nhận biết

Sửa lỗi: chi phí nằm ở việc tìm ra nguyên nhân

Chi phí sửa một lỗi gần như không phụ thuộc vào độ khó của đoạn mã phải sửa, mà phụ thuộc vào thời gian tìm ra nó. Một lỗi nằm trong một hàm 20 dòng có thể mất hai ngày nếu không tái hiện được, và mất hai giờ nếu có bản ghi lỗi kèm dữ liệu đầu vào.

Vì vậy biện pháp giảm chi phí hiệu quả nhất không phải là "viết mã tốt hơn" mà là làm cho lỗi tự khai báo: ghi log có mã tương quan, thông báo lỗi có mã tra cứu, và một kênh duy nhất để người dùng gửi báo cáo kèm ảnh chụp. Ba thứ này rẻ hơn nhiều so với việc đoán.

Thích nghi: loại chi phí bị đánh giá thấp nhất

Mỗi thư viện bên ngoài là một lời hứa của người khác rằng họ sẽ không phá vỡ giao diện. Lời hứa đó có thời hạn. Khi thư viện ngừng hỗ trợ phiên bản cũ, hệ thống của bạn không hỏng ngay, nhưng bắt đầu mất khả năng vá bảo mật. Đó là lúc công việc thích nghi xuất hiện, và nó thường không thể trì hoãn quá lâu.

Hai cách kiểm soát: giới hạn số phụ thuộc trực tiếp, và bọc mọi phụ thuộc bên ngoài trong một lớp mỏng của riêng bạn. Lớp bọc này tốn công lúc đầu nhưng biến một cuộc nâng cấp rải rác khắp mã thành một thay đổi ở một tệp.

Hoàn thiện: cần số đo trước khi sửa

Việc hoàn thiện không có điểm dừng tự nhiên, nên rất dễ biến thành sở thích cá nhân của người viết mã. Cách chặn: chỉ nhận việc hoàn thiện khi có số đo trước và số đo mục tiêu. "Trang danh sách đơn hàng tải 6 giây, mục tiêu dưới 2 giây" là một việc. "Làm trang danh sách cho mượt hơn" không phải là một việc, vì không ai xác nhận được nó đã xong.

Phòng ngừa: loại duy nhất không ai đặt hàng

Không khách hàng nào gửi yêu cầu "hãy tách mô-đun thanh toán thành ba phần". Việc phòng ngừa chỉ tồn tại nếu tổ chức chủ động dành thời gian cho nó, thường theo một tỷ lệ cố định trong mỗi chu kỳ làm việc. Không có tỷ lệ đó, phòng ngừa sẽ luôn thua các việc khẩn cấp — và chi phí sẽ chuyển sang loại sửa lỗi, đắt hơn.

Sáu dòng chi phí ẩn không xuất hiện trong báo giá

Báo giá xây dựng thường chỉ tính công việc tạo ra tính năng. Chi phí bảo trì phát sinh từ những thứ không nằm trong danh sách tính năng, nên không ai báo giá chúng.

Kiểm thử hồi quy: chi phí tăng theo bình phương số luồng

Một hệ thống có mười luồng nghiệp vụ không cần mười lần kiểm thử khi sửa một luồng; nó cần kiểm tra cả những luồng dùng chung dữ liệu với luồng đó. Số cặp phụ thuộc tăng nhanh hơn số luồng, nên chi phí kiểm thử tay tăng nhanh hơn quy mô hệ thống. Đây là lý do một hệ thống nhỏ vẫn có thể có chi phí bảo trì cao bất thường.

Mất kiến thức: chi phí chỉ hiện ra khi người rời đi

Mã cũ không khó vì cú pháp. Nó khó vì những quyết định không được ghi lại: vì sao trường này cho phép giá trị rỗng, vì sao có một bảng trùng dữ liệu, vì sao luồng huỷ đơn không trả lại tồn kho. Khi người quyết định rời đi, mỗi câu hỏi như vậy trở thành một ngày điều tra.

Cách giảm rẻ nhất là ghi lại quyết định ngay khi ra quyết định, dưới dạng ngắn: bối cảnh, lựa chọn, lý do, điều gì sẽ khiến ta xem lại. Một tệp văn bản trong kho mã đủ dùng.

Cách lập ngân sách bảo trì bằng số

Ngân sách bảo trì thường được lập theo một trong hai cách: tỷ lệ phần trăm của chi phí xây dựng ban đầu, hoặc số ngày công cố định mỗi tháng. Cả hai đều là quy ước, không phải chân lý. Cách thứ nhất dễ giải trình với người duyệt ngân sách; cách thứ hai dễ kiểm soát năng lực thực tế. Nên dùng cách thứ nhất để xin ngân sách và cách thứ hai để phân công.

Quy trình gồm bốn bước, và bước thứ hai là bước quyết định.

Bước 1 — Xác định đơn vị gốc. Với hệ thống mới, đơn vị gốc là chi phí xây dựng ban đầu. Với hệ thống đã chạy nhiều năm, đơn vị gốc nên là số bề mặt thay đổi: số màn hình, số tích hợp, số bảng dữ liệu chính, số quy tắc nghiệp vụ đặc thù.

Bước 2 — Đếm yếu tố điều chỉnh. Đây là phần quyết định. Bốn yếu tố làm chi phí bảo trì tăng nhanh hơn quy mô:

• Số tích hợp bên ngoài, đặc biệt là tích hợp không có tài liệu ổn định.
• Tuổi của nền tảng: phiên bản ngôn ngữ, phiên bản cơ sở dữ liệu, phiên bản thư viện chính.
• Mức độ tập trung kiến thức: số mô-đun mà chỉ một người hiểu.
• Mức độ phủ kiểm thử tự động trên các luồng chính.

Bước 3 — Ước lượng theo đơn vị công, không theo tiền. Ví dụ với một hệ thống có 6 tích hợp, nền tảng ba năm tuổi, 4 mô-đun chỉ một người hiểu và chưa có kiểm thử tự động: mỗi quý cần khoảng 8 đến 12 ngày công cho thích nghi, 6 đến 10 ngày cho sửa lỗi, 5 đến 8 ngày cho phòng ngừa, và phần hoàn thiện tuỳ nhu cầu. Con số này là ví dụ minh hoạ cách tính, không phải định mức áp dụng cho mọi hệ thống.

Bước 4 — Đối chiếu với thực tế đã xảy ra. Lấy nhật ký công việc ba tháng gần nhất, phân loại từng việc vào bốn nhóm, rồi so với ước lượng. Chênh lệch lớn thường nằm ở nhóm thích nghi, vì loại việc này hay bị ghi nhầm vào "sửa lỗi".

Cách lập ngân sách này không cho ra một con số đẹp để trình bày. Nó cho ra một mô hình có thể cập nhật mỗi quý, và đó là thứ giúp ngân sách không bị cắt vào đúng quý hệ thống cần nâng cấp nhất.

Bảng quyết định: việc bảo trì nào làm ngay, việc nào chờ

Không phải mọi việc bảo trì đều khẩn cấp như nhau. Bảng dưới đây xếp theo mức thiệt hại khi chờ, không theo mức khó của việc.

Nguyên tắc đằng sau bảng này: việc bảo trì được xếp theo khả năng phục hồi, không theo mức độ khó chịu. Một lỗi giao diện gây khó chịu mỗi ngày nhưng có thể chờ hai tuần. Một lỗi hiếm gặp làm mất một bản ghi thì phải xử lý ngay, dù nó chỉ xảy ra một lần mỗi tháng.

Kiến trúc quyết định chi phí bảo trì

Hai hệ thống cùng số tính năng có thể có chi phí bảo trì chênh nhau vài lần. Khác biệt gần như luôn nằm ở kiến trúc, không ở chất lượng từng dòng mã.

Phụ thuộc chéo giữa các mô-đun. Khi mọi mô-đun đọc trực tiếp bảng dữ liệu của nhau, một thay đổi nhỏ có thể ảnh hưởng ở nơi không ai ngờ. Triệu chứng: mỗi lần sửa phải đọc nhiều tệp. Hệ quả: thời gian review tăng, số lỗi hồi quy tăng. Cách giảm: đặt ranh giới rõ giữa các mô-đun và chỉ cho phép giao tiếp qua giao diện đã định nghĩa.

Thiếu khả năng quan sát. Hệ thống không có log có cấu trúc, không có số đo thời gian phản hồi, không có mã tương quan giữa các dịch vụ sẽ khiến mỗi sự cố thành một cuộc điều tra từ đầu. Triệu chứng: sự cố lặp lại mà không ai biết nguyên nhân. Hệ quả: chi phí sửa lỗi tăng gấp nhiều lần so với hệ thống có quan sát tốt.

Mô hình dữ liệu không theo nghiệp vụ. Khi bảng dữ liệu được thiết kế theo màn hình thay vì theo thực thể nghiệp vụ, mỗi màn hình mới cần một bảng mới, và dữ liệu bị trùng ở nhiều nơi. Triệu chứng: cùng một con số xuất hiện ở ba báo cáo với ba giá trị khác nhau. Hệ quả: mọi thay đổi báo cáo đều phải đối chiếu thủ công.

Ba vấn đề này đều có chung một đặc điểm: chúng không làm hệ thống hỏng, nên không ai đặt hàng sửa. Chúng chỉ làm mỗi thay đổi sau đó đắt hơn. Nếu bạn đang chuẩn bị nhận một hệ thống từ nhà cung cấp, hãy đọc thêm kiến trúc phần mềm là gì để biết cách kiểm tra ba điểm này trước khi ký nghiệm thu.

Hợp đồng bảo trì: năm điều khoản quyết định chi phí thật

Hợp đồng bảo trì thường được viết ngắn, và đó là nguồn gốc của phần lớn tranh chấp. Năm điều khoản dưới đây quyết định chi phí thực tế nhiều hơn mọi con số trong hợp đồng.

Một — Định nghĩa "lỗi". Nếu hợp đồng chỉ ghi "sửa lỗi", hai bên sẽ hiểu khác nhau. Cần ghi rõ: lỗi là hành vi khác với tài liệu đặc tả đã nghiệm thu, hoặc khác với hành vi đã được chấp nhận bằng văn bản. Mọi thứ không thuộc hai phạm vi này là yêu cầu thay đổi, và được xử lý theo quy trình riêng.

Hai — Thời điểm bắt đầu tính thời gian phản hồi. "Phản hồi trong 4 giờ" là cam kết vô nghĩa nếu không nói đồng hồ chạy từ lúc nào: từ lúc người dùng gửi báo cáo, từ lúc bộ phận hỗ trợ xác nhận, hay từ lúc hai bên thống nhất đó là lỗi. Mỗi cách hiểu cho ra một cam kết khác nhau về bản chất.

Hai điểm này nên đọc cùng quy trình bảo trì phần mềm, nơi mô tả cách phân loại và cách tính đồng hồ theo từng mức nghiêm trọng.

Ba — Phiên bản và môi trường được hỗ trợ. Hệ thống chạy trên phiên bản nào, trình duyệt nào, thiết bị nào. Nếu hợp đồng không ghi, nhà cung cấp có thể từ chối sửa một lỗi chỉ xảy ra trên phiên bản cũ — và về mặt kỹ thuật họ có lý.

Bốn — Phạm vi thích nghi. Nâng cấp thư viện, đổi API đối tác, đổi định dạng dữ liệu đầu vào: đây là bảo trì hay là dự án mới? Nếu không ghi, mỗi lần nâng cấp sẽ thành một cuộc thương lượng.

Năm — Bàn giao tri thức khi chấm dứt. Khi hợp đồng kết thúc, ai nhận tài liệu, ở định dạng nào, trong bao lâu? Điều khoản này quyết định chi phí chuyển đổi sang nhà cung cấp khác, và thường bị bỏ trống cho đến khi cần.

Một hợp đồng bảo trì tốt không cần dài. Nó cần năm điều khoản trên được viết bằng ngôn ngữ mà cả người kỹ thuật và người mua đều kiểm tra được.

Khi nào nên viết lại thay vì bảo trì

Đây là câu hỏi bị đặt sai nhiều nhất trong các cuộc thảo luận về hệ thống cũ. Câu hỏi đúng không phải "hệ thống cũ đến mức nào thì viết lại", mà là "phần nào đang chặn việc kinh doanh, và viết lại phần đó có rẻ hơn sửa không".

Nguyên tắc thực dụng: viết lại theo từng phần có ranh giới rõ, không viết lại toàn bộ. Một mô-đun được thay thế có thể kiểm chứng bằng cách so kết quả với mô-đun cũ trên cùng dữ liệu. Một hệ thống được viết lại toàn bộ thì không có gì để so, và đó là lý do phần lớn các dự án viết lại lớn bị trễ hoặc bị bỏ.

Câu hỏi thường gặp

Bảo trì phần mềm có bắt buộc phải trả phí hằng năm không?

Không bắt buộc, nhưng chi phí bảo trì tồn tại dù bạn có hợp đồng hay không. Nếu không có hợp đồng, chi phí xuất hiện dưới dạng thời gian của nhân sự nội bộ, thời gian chờ sửa, hoặc thiệt hại khi sự cố kéo dài. Hợp đồng chỉ là cách chuyển chi phí đó thành một dòng ngân sách nhìn thấy được, kèm cam kết về thời gian phản hồi.

Bảo trì phần mềm khác bảo hành phần mềm ở điểm nào?

Bảo hành là nghĩa vụ sửa lỗi trong một thời hạn và phạm vi cụ thể, thường đi kèm hợp đồng xây dựng. Bảo trì là hoạt động diễn ra sau đó và rộng hơn: ngoài sửa lỗi còn có thích nghi với môi trường mới, cải thiện phần chưa tốt và phòng ngừa rủi ro. Một hệ thống hết bảo hành không có nghĩa là hết nhu cầu bảo trì, và ngược lại, bảo hành còn hiệu lực không có nghĩa là mọi thay đổi đều miễn phí.

Làm sao biết chi phí bảo trì của hệ thống đang cao hay thấp?

Hãy phân loại nhật ký công việc ba tháng gần nhất vào bốn nhóm: sửa lỗi, thích nghi, hoàn thiện, phòng ngừa. Nếu nhóm sửa lỗi chiếm phần lớn thời gian, vấn đề nằm ở chất lượng và kiểm thử. Nếu nhóm thích nghi chiếm phần lớn, vấn đề nằm ở số phụ thuộc bên ngoài và tuổi nền tảng. Hai nguyên nhân này cần hai cách xử lý khác nhau, nên việc phân loại quan trọng hơn con số tổng.

Có nên tự bảo trì hay thuê ngoài?

Phụ thuộc vào ba yếu tố: hệ thống có phải lợi thế cạnh tranh hay không, đội nội bộ có người hiểu mã cũ hay không, và mức độ cần phản hồi nhanh. Hệ thống là lợi thế cạnh tranh và cần thay đổi liên tục thì nên giữ năng lực nội bộ. Hệ thống là công cụ hỗ trợ, thay đổi ít, thì thuê ngoài thường rẻ hơn vì không phải duy trì kiến thức thường trực. Điều cần tránh là mô hình nửa vời: thuê ngoài nhưng không có ai nội bộ đủ hiểu để kiểm tra chất lượng.

Nên dành bao nhiêu thời gian cho việc phòng ngừa?

Đủ để mỗi chu kỳ có ít nhất một thay đổi cấu trúc nhỏ được hoàn thành và kiểm chứng. Con số cụ thể phụ thuộc vào mức nợ kỹ thuật hiện tại, nhưng nguyên tắc là phải có một khoảng thời gian được bảo vệ trước khi bị việc khẩn cấp lấp đầy. Nếu việc phòng ngừa chỉ diễn ra khi "rảnh", nó sẽ không bao giờ diễn ra.

Cập nhật và kiểm chứng

Cập nhật tháng 10/2026. Nội dung được rà soát theo bốn loại bảo trì trong ISO/IEC 14764 và theo thông lệ vận hành hệ thống đang áp dụng. Bài viết không nêu cam kết thời gian phản hồi hay mức sẵn sàng của bất kỳ nhà cung cấp nào, không công bố giá dịch vụ và không sử dụng số liệu khách hàng.

Danh mục công việc bảo trì kèm tần suất và bằng chứng nằm trong bảo trì phần mềm bao gồm những hoạt động nào. Cách tiếp nhận, phân loại và phát hành từng yêu cầu bảo trì nằm trong quy trình bảo trì phần mềm. Nếu bạn cần một đội tiếp nhận hệ thống đang chạy và lập kế hoạch bảo trì theo đúng bốn loại trên, xem dịch vụ vận hành sau bàn giao của WinSell. Báo giá sau khi chốt phạm vi.