Bảo trì phần mềm bao gồm những hoạt động nào? Danh mục việc và tần suất

Bảo trì phần mềm bao gồm bốn nhóm việc theo bốn nhịp: hằng ngày để hệ thống tiếp tục phục vụ, hằng tuần để phát hiện xu hướng, hằng quý để nâng cấp và kiểm chứng khả năng phục hồi, hằng năm để rà soát toàn bộ. Mỗi việc cần tần suất, người chịu trách nhiệm và bằng chứng.

Tóm tắt nhanh

• Danh mục bảo trì chia theo nhịp, không chia theo chức danh. Cách chia theo nhịp giúp phát hiện việc bị bỏ quên vì không ai đặt lịch.
• Mỗi dòng trong danh mục cần bốn thông tin: tần suất, người làm, thời lượng dự kiến, và bằng chứng để lại.
• Uptime chỉ đo được khi định nghĩa rõ ba thứ: thời gian nào được tính, trạng thái nào là "đang phục vụ", và bảo trì có bị trừ hay không.
• Sao lưu không phải bằng chứng. Bằng chứng là một lần phục hồi thử thành công có ghi lại thời gian và số bản ghi khôi phục được.
• Việc không có bằng chứng thì coi như chưa làm, kể cả khi người phụ trách khẳng định đã làm.

Vì sao phải lập danh mục thay vì làm theo phản xạ

Hệ thống đang chạy tạo ra một ảo giác nguy hiểm: nếu không có sự cố, nghĩa là mọi việc đang ổn. Thực tế, phần lớn công việc bảo trì không tạo ra tín hiệu khi bị bỏ qua. Không ai nhận được thông báo rằng bản sao lưu tháng trước đã hỏng, rằng chứng chỉ sắp hết hạn, rằng một thư viện đã ngừng nhận bản vá.

Danh mục công việc là cách duy nhất để biến những việc vô hình thành việc có lịch. Nguyên tắc lập danh mục gồm ba điểm:

Chia theo nhịp, không theo chức danh. Cùng một người có thể làm việc hằng ngày và việc hằng năm. Nếu danh mục chia theo chức danh, khi người đó nghỉ phép sẽ không ai biết việc nào còn thiếu.

Mỗi việc phải sinh ra bằng chứng. Bằng chứng có thể là một tệp log, một ảnh chụp bảng điều khiển, một bản ghi thời gian chạy kiểm thử, hoặc một dòng trong nhật ký vận hành. Không có bằng chứng thì không phân biệt được "đã làm" với "nghĩ là đã làm".

Việc nào cũng phải có thời lượng dự kiến. Một danh mục không có thời lượng sẽ bị đánh giá là "không tốn thời gian", và đến khi cần thì không ai dành đủ thời gian cho nó.

Việc hằng ngày: giữ hệ thống phục vụ

Nhóm này ngắn, lặp lại và phải làm được trong trạng thái nửa tỉnh. Nếu một việc hằng ngày cần suy nghĩ nhiều, nó nên được tự động hoá hoặc chuyển sang nhóm khác.

Điểm dễ sai nhất ở nhóm này là coi việc xem bảng điều khiển là việc đã xong. Xem không phải là làm. Nếu bảng điều khiển hiện một chỉ số bất thường và không ai ghi lại hành động, thì lần sau chỉ số đó vẫn bất thường và không ai nhớ đã thấy nó.

Việc hằng tuần: phát hiện xu hướng

Việc hằng ngày phát hiện sự kiện. Việc hằng tuần phát hiện xu hướng — những thứ chưa đủ để gây sự cố nhưng đang đi sai hướng.

Phân vị 95 và 99 quan trọng hơn giá trị trung bình. Trung bình che mất nhóm người dùng chậm: nếu 95% yêu cầu mất 300 mili giây và 5% mất 8 giây, giá trị trung bình có thể vẫn đẹp trong khi một nhóm người dùng thật đang gặp vấn đề mỗi ngày.

Việc hằng quý và hằng năm: nâng cấp và chứng minh khả năng phục hồi

Đây là nhóm dễ bị hoãn nhất, vì không có gì đang cháy. Cũng chính vì vậy, nhóm này cần được đưa vào lịch từ đầu quý chứ không chờ đến khi rảnh.

Điểm quan trọng ở nhóm này: kiểm thử phục hồi phải chạy trên môi trường tách biệt. Khôi phục thử lên chính hệ thống đang chạy không phải là kiểm thử, đó là một sự cố có chủ đích. Môi trường tách biệt cũng cho phép đo thời gian khôi phục thật, thứ không đo được khi đang vội.

Cách định nghĩa uptime để đo được

Uptime là chỉ số bị tranh cãi nhiều nhất trong hợp đồng vận hành, vì mỗi bên có một cách tính. Ba câu hỏi phải trả lời trước khi cam kết bất kỳ con số nào:

Một — Thời gian nào được tính vào mẫu số? Toàn bộ 24 giờ mỗi ngày trong kỳ, hay chỉ giờ làm việc? Một cam kết 99,5% tính trên 24 giờ cho phép ít thời gian hỏng hơn nhiều so với cùng con số tính trên 8 giờ mỗi ngày.

Hai — Trạng thái nào là "đang phục vụ"? Một trang trả về HTTP 200 nhưng hiển thị dữ liệu rỗng có được tính là đang phục vụ? Một chức năng thanh toán hỏng trong khi phần còn lại chạy bình thường thì tính là hỏng toàn bộ hay hỏng một phần? Cần định nghĩa bằng một phép kiểm tra cụ thể, ví dụ: một yêu cầu đăng nhập và một yêu cầu đọc dữ liệu chính phải trả về kết quả hợp lệ trong thời gian dưới ngưỡng.

Ba — Bảo trì có bị trừ không? Bảo trì theo kế hoạch thường được loại khỏi mẫu số, nhưng chỉ khi có thông báo trước và nằm trong khung giờ đã thoả thuận. Nếu không ghi rõ, mọi lần hệ thống ngừng đều có thể được gọi là "bảo trì".

Công thức cơ bản:

uptime (%) = (tổng phút trong kỳ − số phút không phục vụ) / tổng phút trong kỳ × 100

Công thức này đơn giản, nhưng ba biến trong đó đều có thể bị định nghĩa khác nhau. Vì vậy trong hợp đồng, phần định nghĩa quan trọng hơn phần con số.

Bảng dưới đây cho thấy cùng một con số cam kết tương ứng bao nhiêu phút hỏng mỗi tháng, để thấy mức chênh lệch thực tế:

Hai điều bảng này cho thấy. Thứ nhất, chênh lệch giữa 99,5% và 99,9% không phải "nửa phần trăm" mà là gấp năm lần lượng thời gian được phép hỏng. Thứ hai, cam kết càng cao thì chi phí kiến trúc càng tăng không tuyến tính, vì phải loại bỏ điểm hỏng đơn lẻ và có phương án chuyển đổi dự phòng.

Sao lưu và kiểm thử phục hồi: bằng chứng phải sinh ra

Ba khái niệm hay bị dùng lẫn: sao lưu, khôi phục và kiểm thử phục hồi. Sao lưu là tạo bản sao. Khôi phục là đưa dữ liệu trở lại. Kiểm thử phục hồi là chứng minh việc khôi phục hoạt động và đo được thời gian.

Hai chỉ số cần định nghĩa trước khi thiết kế:

RPO (thời điểm dữ liệu tối đa có thể mất) — khoảng thời gian dữ liệu có thể bị mất nếu hệ thống hỏng ngay lúc này. Sao lưu mỗi đêm cho RPO khoảng một ngày. Sao lưu mỗi giờ cho RPO khoảng một giờ. Con số này do nghiệp vụ quyết định, không do kỹ thuật quyết định: mất một ngày đơn hàng có chấp nhận được không.

RTO (thời gian tối đa để phục vụ trở lại) — khoảng thời gian từ lúc hỏng đến lúc hệ thống phục vụ bình thường. RTO quyết định kiến trúc: phục hồi từ bản sao lưu mất hàng giờ, chạy song song hai môi trường có thể mất vài phút.

Quy trình kiểm thử phục hồi gồm sáu bước, và bước thứ sáu là bước sinh ra bằng chứng:

1. Chọn bộ dữ liệu đối chiếu. Ghi lại số bản ghi của ba bảng chính và tổng tiền của một kỳ báo cáo đã chốt.
2. Chọn bản sao lưu mục tiêu. Không chọn bản mới nhất, vì bản mới nhất thường là bản đã được kiểm tra. Chọn ngẫu nhiên một bản trong 30 ngày gần nhất.
3. Khôi phục lên môi trường tách biệt. Ghi lại thời điểm bắt đầu và kết thúc.
4. Đối chiếu số liệu. So số bản ghi và tổng tiền với bộ đã ghi ở bước 1.
5. Chạy một luồng nghiệp vụ chính trên bản khôi phục. Đăng nhập, tạo một bản ghi thử, đọc lại bản ghi đó.
6. Ghi biên bản. Thời gian khôi phục thực tế, số bản ghi đối chiếu, lỗi gặp phải, và người thực hiện.

Biên bản ở bước 6 là thứ duy nhất chứng minh hệ thống có thể phục hồi. Không có biên bản, câu "chúng tôi có sao lưu hằng đêm" là một niềm tin, không phải một sự kiện đã kiểm chứng.

Ai chịu trách nhiệm việc nào

Danh mục chỉ hoạt động khi mỗi dòng có một người chịu trách nhiệm cuối cùng. Bảng dưới đây là cách gán trách nhiệm theo vai trò, không theo tên người.

Điều dễ bỏ sót là cột "người được thông báo". Phần lớn sự cố kéo dài không phải vì không ai sửa, mà vì người ra quyết định kinh doanh không biết để điều chỉnh kỳ vọng với khách hàng.

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

Bảo trì phần mềm có nhất thiết phải làm hằng ngày không?

Không phải mọi việc, nhưng phải có một người chịu trách nhiệm nhìn vào hệ thống mỗi ngày làm việc. Nếu không ai nhìn, một sự cố nhỏ có thể kéo dài đến khi người dùng phàn nàn. Các việc còn lại có thể theo tuần, quý hoặc năm, miễn là có lịch và có bằng chứng.

Uptime bao nhiêu là đủ cho một hệ thống nội bộ?

Phụ thuộc vào mức thiệt hại khi hệ thống ngừng. Hệ thống nội bộ dùng trong giờ hành chính có thể chấp nhận mức thấp hơn nhiều so với hệ thống nhận đơn của khách. Cách xác định đúng là hỏi: nếu hệ thống ngừng hai giờ vào giờ cao điểm, thiệt hại là gì, và ai phải biết. Con số cam kết nên suy ra từ câu trả lời đó, không nên chọn theo thói quen.

Sao lưu bao nhiêu lần một ngày là đủ?

Đủ khi khoảng dữ liệu có thể mất (RPO) nằm trong mức nghiệp vụ chấp nhận. Nếu mất một ngày đơn hàng là không chấp nhận được, sao lưu hằng đêm không đủ, cần sao lưu tăng dần theo giờ hoặc ghi nhật ký thay đổi liên tục. Điều quan trọng là quyết định RPO trước, rồi chọn tần suất sao lưu sau.

Việc bảo trì nào hay bị bỏ quên nhất?

Ba việc: kiểm thử phục hồi, rà soát quyền truy cập và rà soát lịch ngừng hỗ trợ của phụ thuộc bên ngoài. Cả ba đều không gây sự cố ngay khi bị bỏ qua, nên không có tín hiệu nhắc nhở. Cách chặn là đưa chúng vào lịch quý với người chịu trách nhiệm cụ thể và bằng chứng bắt buộc.

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 mức sẵn sàng, thời gian phản hồi hay khung hỗ trợ của bất kỳ nhà cung cấp nào.

Bốn loại bảo trì và sáu dòng chi phí ẩn nằm trong bảo trì phần mềm là gì. Cách tiếp nhận, phân loại và phát hành từng yêu cầu nằm trong quy trình bảo trì phần mềm. Cách nối các hoạt động này thành một vòng lặp tự động nằm trong phát triển vận hành bảo trì phần mềm. Nếu bạn cần một đội nhận bàn giao hệ thống kèm danh mục công việc và lịch kiểm thử phục hồi, 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.