Cách đánh giá khả năng bảo trì công nghệ

ISO/IEC 25010:2023 đặt khả năng bảo trì trong mô hình đánh giá chất lượng sản phẩm ICT và phần mềm. Với góc nhìn doanh nghiệp, tiêu chuẩn này có thể được chuyển thành bốn câu hỏi thực tế: giải pháp có cập nhật an toàn không, có được hỗ trợ ổn định không, lỗi được khắc phục nhanh đến đâu và tổ chức phụ thuộc vào bên ngoài đến mức nào.

Đánh giá khả năng cập nhật thay vì chỉ hỏi có cập nhật hay không

Một sản phẩm được cập nhật thường xuyên chưa chắc dễ bảo trì. Điều cần kiểm tra là doanh nghiệp có thể đưa phiên bản mới vào hệ thống mà không tạo ra mức rủi ro và công sức bất hợp lý hay không.

Trước hết, cần xem lịch sử phát hành trong khoảng thời gian đủ dài để nhận biết cách nhà cung cấp duy trì sản phẩm: có phát hành bản vá đều đặn, công bố thay đổi rõ ràng và xử lý phiên bản cũ theo một chính sách có thể dự đoán hay không. Release note, changelog, tài liệu nâng cấp và chính sách vòng đời phiên bản có giá trị hơn lời khẳng định chung rằng sản phẩm được “cập nhật liên tục”.

Tiếp theo là cơ chế nâng cấp. Một giải pháp dễ bảo trì nên cho phép doanh nghiệp biết trước thành phần nào sẽ thay đổi, kiểm thử trước khi đưa lên môi trường thật và có phương án rollback hoặc phục hồi khi phiên bản mới gây lỗi. Nếu mỗi lần nâng cấp đều cần chỉnh sửa thủ công nhiều thành phần tích hợp, dừng hệ thống lâu hoặc phụ thuộc vào một chuyên gia cụ thể, chi phí bảo trì thực tế sẽ tăng dù số lượng phiên bản phát hành khá cao.

Doanh nghiệp nên thu thập ít nhất các dữ liệu sau từ những lần cập nhật gần đây:

·         Tần suất phát hành bản vá và phiên bản

·         Thời gian từ khi phiên bản được công bố đến khi có thể triển khai an toàn

·         Tỷ lệ lần cập nhật phải rollback, hotfix hoặc xử lý lại

·         Thời gian gián đoạn cần thiết cho một lần nâng cấp

·         Số tích hợp hoặc tùy chỉnh phải sửa sau mỗi phiên bản

·         Thời hạn hỗ trợ của phiên bản đang sử dụng

·         Khả năng thử nghiệm nâng cấp trên môi trường staging hoặc sandbox

Không có một tần suất cập nhật chung phù hợp cho mọi hệ thống. Một nền tảng nghiệp vụ ổn định có thể không cần phát hành thường xuyên như một dịch vụ trực tuyến. Điều quan trọng hơn là tốc độ thay đổi phải đi cùng khả năng kiểm soát thay đổi.

Kiểm tra năng lực hỗ trợ bằng SLA và dữ liệu thực tế

Hỗ trợ kỹ thuật chỉ có ý nghĩa với khả năng bảo trì khi doanh nghiệp có thể xác định ai chịu trách nhiệm, phản hồi trong bao lâu và sự cố được chuyển cấp như thế nào.

Một SLA hữu ích phải phân biệt ít nhất hai khái niệm: thời gian phản hồi và thời gian xử lý hoặc khôi phục. Nhà cung cấp trả lời ticket nhanh nhưng không đưa ra được chẩn đoán, workaround hay phương án khắc phục thì chưa thể xem là có năng lực bảo trì tốt.

Khi đánh giá, doanh nghiệp nên yêu cầu làm rõ:

·         Khung giờ và ngày cung cấp hỗ trợ

·         Cách phân loại mức độ nghiêm trọng của sự cố

·         Thời gian phản hồi theo từng mức độ

·         Quy trình escalation khi tuyến hỗ trợ đầu tiên không giải quyết được

·         Khả năng tiếp cận chuyên gia sản phẩm khi xảy ra lỗi nghiêm trọng

·         Trách nhiệm hỗ trợ phần tích hợp và tùy chỉnh

·         Kênh thông báo sự cố, bản vá và thay đổi phiên bản

·         Kho tài liệu, knowledge base và hướng dẫn tự xử lý

·         Cách đo mức tuân thủ SLA trong thực tế

Với hệ thống quan trọng, doanh nghiệp không nên chỉ đọc SLA mẫu. Hãy yêu cầu dữ liệu hỗ trợ trong quá khứ hoặc kiểm tra bằng giai đoạn pilot: thời gian phản hồi trung vị, ticket tồn đọng, tỷ lệ phải escalation và thời gian đóng các ticket quan trọng sẽ cho thấy năng lực vận hành thực tế rõ hơn nội dung marketing.

Cũng cần xác định ranh giới trách nhiệm. Một nhà cung cấp có thể hỗ trợ rất tốt sản phẩm lõi nhưng không chịu trách nhiệm khi lỗi phát sinh ở plugin, hạ tầng, API bên thứ ba hoặc phần tùy chỉnh. Nếu những thành phần đó chiếm tỷ trọng lớn trong kiến trúc của doanh nghiệp, SLA của sản phẩm lõi không phản ánh đầy đủ khả năng bảo trì của toàn giải pháp.

Đo khả năng sửa lỗi bằng thời gian phục hồi và lượng công việc làm lại

Khả năng sửa lỗi nên được đánh giá bằng dữ liệu lịch sử thay vì câu hỏi “nhà cung cấp có sửa lỗi nhanh không?”.

DORA hiện sử dụng năm chỉ số để đánh giá hiệu năng phân phối phần mềm. Trong đó, failed deployment recovery time đo thời gian cần để phục hồi sau một lần triển khai gây suy giảm dịch vụ; change fail rate phản ánh tỷ lệ các lần triển khai cần can thiệp ngay như rollback hoặc hotfix; và deployment rework rate phản ánh tỷ lệ triển khai ngoài kế hoạch nhằm xử lý vấn đề phát sinh. Các chỉ số này không phải thước đo duy nhất của maintainability nhưng rất hữu ích khi doanh nghiệp cần kiểm tra năng lực khắc phục thay đổi lỗi bằng dữ liệu.

Doanh nghiệp có thể xây dựng bộ dữ liệu bảo trì từ các incident và ticket trong 6–12 tháng gần nhất, gồm:

·         Thời gian từ lúc phát hiện lỗi đến khi được phân loại

·         Thời gian từ lúc xác nhận lỗi đến khi có workaround

·         Thời gian đến khi bản sửa chính thức được triển khai

·         Tỷ lệ lỗi tái phát sau khi đã xử lý

·         Tỷ lệ thay đổi gây lỗi production

·         Tỷ lệ triển khai phát sinh chỉ để sửa lỗi ngoài kế hoạch

·         Số lỗi nghiêm trọng còn tồn đọng và tuổi của backlog lỗi

·         Số lần phải rollback hoặc khôi phục phiên bản trước

Các số liệu phải được phân tách theo mức độ nghiêm trọng. Gộp một lỗi giao diện nhỏ với sự cố khiến quy trình kinh doanh ngừng hoạt động sẽ tạo ra chỉ số trung bình ít giá trị.

Doanh nghiệp cũng cần kiểm tra cơ chế sửa lỗi. Một hệ thống có test tự động, môi trường thử nghiệm, quy trình release rõ ràng và khả năng rollback thường cho phép thay đổi được xác minh trước khi đưa vào production. Ngược lại, nếu mỗi bản sửa đều phải thao tác trực tiếp trên môi trường thật hoặc chỉ một cá nhân hiểu cách triển khai, thời gian xử lý có thể tăng mạnh khi hệ thống phức tạp hơn.

Vì vậy, “sửa lỗi nhanh” không nên được đánh giá bằng một con số riêng lẻ. Kết quả tốt phải đồng thời cho thấy thời gian phục hồi phù hợp với mức độ quan trọng của hệ thống và tỷ lệ lỗi do thay đổi không ở mức khiến đội ngũ liên tục phải làm lại.

Đo mức phụ thuộc để nhận biết rủi ro bảo trì dài hạn

Một giải pháp có thể được nhà cung cấp bảo trì tốt nhưng vẫn tạo rủi ro nếu doanh nghiệp gần như không có khả năng vận hành, sửa đổi hoặc chuyển giao nó cho bên khác.

Mức phụ thuộc nên được kiểm tra ở nhiều lớp.

Phụ thuộc nhà cung cấp xuất hiện khi chỉ một đơn vị có quyền truy cập, công cụ hoặc kiến thức cần thiết để thay đổi hệ thống. Doanh nghiệp cần xem hợp đồng có cho phép lấy dữ liệu, chuyển cấu hình, tiếp nhận tài liệu và sử dụng nhà cung cấp thay thế hay không.

Phụ thuộc nhân sự xuất hiện khi kiến thức vận hành tập trung ở một vài cá nhân. Có tài liệu kiến trúc, runbook, hướng dẫn triển khai và lịch sử thay đổi giúp giảm rủi ro khi người phụ trách nghỉ việc hoặc chuyển vai trò.

Phụ thuộc kỹ thuật đến từ thư viện, framework, plugin, API, dịch vụ cloud và các thành phần khác mà giải pháp dựa vào. NIST coi Software Bill of Materials (SBOM) là bản ghi các thành phần và quan hệ chuỗi cung ứng của phần mềm; SBOM có thể giúp tổ chức nhận biết dependency, phiên bản và thành phần bị ảnh hưởng khi xuất hiện lỗ hổng.

NIST cũng khuyến nghị khi đánh giá nhà cung cấp cần xem xét các thực hành hỗ trợ và bảo trì phần mềm trong chuỗi cung ứng, đồng thời chú ý tới năng lực quản lý lỗ hổng và khả năng xử lý các thành phần của nhà cung cấp phụ.

Doanh nghiệp có thể kiểm tra mức phụ thuộc bằng các câu hỏi thực nghiệm:

·         Có thể xuất toàn bộ dữ liệu ở định dạng sử dụng được hay không

·         API và giao diện tích hợp có được tài liệu hóa hay không

·         Có danh mục các dependency và phiên bản đang dùng hay không

·         Ai có quyền truy cập mã nguồn, cấu hình, pipeline và tài liệu triển khai

·         Một đội kỹ thuật khác có thể dựng lại môi trường từ tài liệu hiện có hay không

·         Hệ thống có thể thay một dịch vụ bên thứ ba mà không phải xây dựng lại phần lớn kiến trúc hay không

·         Khi một dependency hết hỗ trợ, quy trình nâng cấp hoặc thay thế đã được xác định hay chưa

·         Khi chấm dứt hợp đồng, doanh nghiệp nhận lại được những tài sản kỹ thuật nào

Một phép thử có giá trị là thử chuyển giao có giới hạn: để một nhóm không trực tiếp xây dựng hệ thống thực hiện một tác vụ bảo trì thông thường chỉ dựa trên tài liệu và quyền truy cập được cung cấp. Những điểm nhóm này bị mắc kẹt thường chính là dependency vận hành mà hồ sơ dự án không thể hiện.

Chấm khả năng bảo trì bằng scorecard thay vì một nhận xét chung

Bốn nhóm tiêu chí không nên được gộp thành đánh giá “tốt”, “trung bình” hoặc “kém” ngay từ đầu. Doanh nghiệp nên thiết lập scorecard và trọng số theo mức độ quan trọng của hệ thống.

Một mô hình có thể sử dụng:

Trọng số cần phản ánh hậu quả kinh doanh. Với hệ thống vận hành cốt lõi, thời gian phục hồi và năng lực hỗ trợ có thể quan trọng hơn tần suất phát hành tính năng. Với một nền tảng dự kiến phải tích hợp và thay đổi liên tục, khả năng nâng cấp, kiểm thử và mức phụ thuộc kỹ thuật có thể cần trọng số cao hơn.

Ngoài điểm số, nên đặt một số tiêu chí dưới dạng điều kiện loại trừ. Ví dụ, một giải pháp đạt điểm tổng cao vẫn có thể không phù hợp nếu không cho phép lấy dữ liệu khi chấm dứt hợp đồng, không có chính sách hỗ trợ phiên bản rõ ràng hoặc toàn bộ hoạt động bảo trì quan trọng phụ thuộc vào một cá nhân duy nhất.

Trước khi ký hợp đồng hoặc mở rộng triển khai, doanh nghiệp nên yêu cầu bằng chứng cho từng nhóm: release history cho cập nhật, SLA và ticket history cho hỗ trợ, incident record cho sửa lỗi, tài liệu kiến trúc và dependency inventory cho mức phụ thuộc. Với nhà cung cấp ICT, thẩm định rủi ro trước quyết định mua cũng phù hợp với cách tiếp cận due diligence mà NIST SP 1326 công bố năm 2026.

Khả năng bảo trì công nghệ không thể được xác định bằng việc sản phẩm “có đội hỗ trợ” hay “được cập nhật thường xuyên”. Doanh nghiệp cần kiểm tra liệu thay đổi có thể được triển khai và khôi phục có kiểm soát, hỗ trợ có trách nhiệm và SLA rõ ràng, lỗi được xử lý với tốc độ có thể đo được, đồng thời kiến thức và dependency không bị khóa vào một nhà cung cấp hoặc một cá nhân.

Khi bốn yếu tố này được đo bằng dữ liệu lịch sử, điều khoản hỗ trợ và thử nghiệm chuyển giao thực tế, khả năng bảo trì công nghệ trở thành một tiêu chí có thể kiểm chứng. Điều đó giúp doanh nghiệp đánh giá không chỉ chi phí triển khai ban đầu mà cả khả năng giữ giải pháp hoạt động, thay đổi và phục hồi trong suốt vòng đời sử dụng.