Cách đánh giá tính tương thích của giải pháp

Với các giải pháp ICT và phần mềm, ISO/IEC 25010:2023 cung cấp mô hình chất lượng dùng cho việc xác định yêu cầu, thiết lập mục tiêu kiểm thử, tiêu chí kiểm soát chất lượng và tiêu chí chấp nhận. Phạm vi của mô hình bao gồm cả phần mềm, phần cứng, firmware, dữ liệu, hạ tầng truyền thông và các thành phần khác của sản phẩm ICT.

Vì vậy, đánh giá tính tương thích của giải pháp phải bắt đầu từ toàn bộ môi trường mà giải pháp sẽ phụ thuộc hoặc tương tác, thay vì chỉ kiểm thử riêng bản thân giải pháp. Ba câu hỏi cần được trả lời là: giải pháp chạy được trên môi trường nào, trao đổi được với hệ thống nào và khi cùng vận hành thì có làm phát sinh xung đột hay không.

Kiểm tra khả năng tương thích với hạ tầng hiện có

Lớp đầu tiên cần đánh giá là môi trường trực tiếp dùng để triển khai giải pháp. Đây có thể là máy chủ vật lý, máy ảo, container, nền tảng cloud, hệ điều hành hoặc thiết bị đầu cuối.

Không nên ghi yêu cầu dưới dạng chung như “tương thích với máy chủ hiện tại”. Cần xác định chính xác cấu hình được hỗ trợ, chẳng hạn:

·         Hệ điều hành và phiên bản

·         Kiến trúc CPU như x86-64 hoặc ARM

·         Dung lượng CPU, RAM và lưu trữ

·         Hypervisor hoặc nền tảng container

·         Runtime, framework và thư viện phụ thuộc

·         Trình duyệt hoặc thiết bị đầu cuối nếu có giao diện người dùng

·         Nền tảng cloud và các dịch vụ cloud liên quan

Điểm quan trọng là kiểm tra đúng tổ hợp cấu hình. Một ứng dụng chạy được trên một phiên bản Linux không có nghĩa mọi phiên bản Linux đều được hỗ trợ; một phần mềm hoạt động với một phiên bản Java, .NET hoặc Node.js cũng không tự động tương thích với phiên bản mới hơn.

Do đó nên lập ma trận gồm các môi trường Supported, Conditionally Supported và Unsupported, sau đó chạy thử trên những cấu hình thực sự xuất hiện trong hệ thống sản xuất. Kiểm tra chỉ trên môi trường phát triển có thể bỏ sót khác biệt về phiên bản, quyền truy cập, tài nguyên và cấu hình vận hành.

Kiểm tra các hệ thống phải trao đổi dữ liệu với giải pháp

Khả năng kết nối chỉ là bước đầu. Hệ thống A mở được kết nối tới hệ thống B nhưng gửi sai cấu trúc dữ liệu, hiểu sai mã trạng thái hoặc xử lý khác quy tắc nghiệp vụ thì vẫn không đạt yêu cầu tương thích.

Các điểm tích hợp cần được kiểm tra bao gồm:

·         API

·         Web service

·         Message queue hoặc event bus

·         Giao thức truyền thông

·         File trao đổi

·         Cơ chế đồng bộ dữ liệu

·         Webhook

·         Middleware hoặc ESB

·         Các connector chuyên dụng

Với từng interface, cần xác định phiên bản giao thức hoặc API, phương thức xác thực, cấu trúc request/response, kiểu dữ liệu, encoding, timeout, giới hạn lưu lượng và quy tắc xử lý lỗi.

Kiểm thử cũng phải bao gồm trường hợp bất thường. Ví dụ, hệ thống đích trả về dữ liệu thiếu trường, timeout, gửi bản ghi trùng hoặc thay đổi thứ tự sự kiện thì giải pháp xử lý thế nào. Nếu chỉ kiểm tra luồng dữ liệu hợp lệ, khả năng tương thích thực tế vẫn chưa được chứng minh.

NIST cũng xem khả năng đánh giá interoperability giữa các implementation và vấn đề backward compatibility khi tiêu chuẩn thay đổi là những yếu tố cần xem xét khi đánh giá tiêu chuẩn kỹ thuật.

Kiểm tra khả năng tương thích với dữ liệu và hệ quản trị dữ liệu

Hai hệ thống có thể kết nối thành công nhưng không tương thích về dữ liệu. Đây là nguyên nhân phổ biến của lỗi tích hợp vì khác biệt thường nằm ở ý nghĩa dữ liệu thay vì đường truyền.

Cần kiểm tra ít nhất:

·         Database engine và phiên bản

·         Schema

·         Kiểu dữ liệu

·         Độ dài trường

·         Encoding và collation

·         Múi giờ và định dạng thời gian

·         Đơn vị đo

·         Quy tắc NULL

·         Khóa định danh

·         Quan hệ dữ liệu

·         Quy tắc validation

·         Mapping giữa các trường

Ví dụ, hai hệ thống cùng có trường customer_id không đồng nghĩa chúng sử dụng cùng một định danh. Một hệ thống có thể dùng ID nội bộ, trong khi hệ thống còn lại sử dụng mã khách hàng nghiệp vụ. Ghép hai trường chỉ dựa vào tên có thể tạo ra dữ liệu hợp lệ về cú pháp nhưng sai hoàn toàn về ngữ nghĩa.

Vì vậy cần kiểm thử cả syntactic compatibility và semantic compatibility: dữ liệu phải đọc được, đồng thời phải được hiểu theo cùng một ý nghĩa.

Khi có migration hoặc đồng bộ hai chiều, nên đối soát số bản ghi, khóa định danh, giá trị bắt buộc và quy tắc chuyển đổi trước và sau quá trình truyền. Sai lệch phải được xác định bằng tiêu chí định lượng thay vì đánh giá trực quan.

Kiểm tra hệ thống xác thực, phân quyền và bảo mật

Một giải pháp thường không tự quản lý toàn bộ danh tính người dùng. Nó có thể phải làm việc với Active Directory, LDAP, hệ thống IAM, SSO hoặc một Identity Provider khác.

Các yếu tố cần xác minh gồm:

·         Cơ chế đăng nhập

·         Giao thức xác thực

·         Phiên bản giao thức

·         Token và vòng đời token

·         Mapping tài khoản

·         Mapping role và permission

·         Cơ chế cấp và thu hồi quyền

·         Chứng thư số

·         TLS

·         Quản lý secret và key

Không nên coi việc “SSO đăng nhập thành công” là kết quả đủ. Người dùng sau khi đăng nhập còn phải nhận đúng quyền, tài khoản bị khóa phải mất quyền đúng thời điểm và các token hết hạn phải được xử lý đúng.

Tương thích bảo mật cũng có tính hai chiều. Một giải pháp có thể hoạt động về chức năng nhưng yêu cầu mở cổng, sử dụng thuật toán hoặc cấu hình quyền không phù hợp với chính sách bảo mật hiện tại. Trong trường hợp đó, giải pháp không đáp ứng đầy đủ môi trường mục tiêu dù chức năng riêng lẻ vẫn chạy.

Kiểm tra khả năng tương thích với mạng và kiến trúc triển khai

Các môi trường phát triển thường đơn giản hơn nhiều so với hệ thống sản xuất. Trong thực tế, luồng kết nối có thể phải đi qua firewall, proxy, VPN, NAT, load balancer, DNS, API gateway hoặc mạng phân vùng.

Do đó cần xác minh:

·         IP và DNS

·         Port

·         Protocol

·         Firewall rule

·         Proxy

·         Certificate

·         Load balancer

·         Network segmentation

·         Latency

·         Timeout

·         Băng thông cần thiết

Một bài kiểm thử chỉ thành công khi hai máy nằm cùng mạng chưa chứng minh giải pháp sẽ hoạt động trong kiến trúc sản xuất.

Đặc biệt với các tích hợp đồng bộ, latency và timeout cần được kiểm thử dưới tải thực tế. Nếu hệ thống phụ thuộc thường phản hồi trong hai giây nhưng giải pháp đặt timeout một giây, vấn đề không phải ở khả năng kết nối mà ở sự không tương thích giữa hai đặc tính vận hành.

Kiểm tra các hệ thống phía trước và phía sau trong chuỗi nghiệp vụ

Tương thích phải được đánh giá theo chuỗi phụ thuộc, không chỉ từng kết nối riêng biệt.

Một giao dịch có thể đi theo luồng:

Hệ thống nguồn → middleware → giải pháp mới → hệ thống nghiệp vụ → database → hệ thống báo cáo.

Nếu từng cặp kết nối đều vượt qua kiểm thử nhưng toàn bộ transaction không hoàn tất đúng, giải pháp vẫn chưa đạt yêu cầu.

Cần xác định:

·         Upstream system cung cấp dữ liệu hoặc kích hoạt giao dịch

·         Downstream system nhận kết quả

·         Middleware trung gian

·         Dịch vụ dùng chung

·         Hệ thống bên thứ ba

·         Các batch job hoặc scheduler liên quan

Sau đó kiểm thử end-to-end với một giao dịch đại diện từ điểm bắt đầu tới kết quả cuối cùng.

Cách kiểm tra này đặc biệt quan trọng với những lỗi chỉ xuất hiện khi kết hợp nhiều hệ thống, chẳng hạn mất transaction ID, thay đổi encoding, xử lý trùng message hoặc một hệ thống trung gian tự động biến đổi dữ liệu.

Kiểm tra khả năng cùng tồn tại với các hệ thống khác

Một giải pháp có thể tự hoạt động bình thường nhưng gây vấn đề khi triển khai cùng những ứng dụng hiện có. Vì vậy compatibility còn phải được đánh giá dưới góc độ cùng tồn tại.

Cần quan sát các khả năng xung đột như:

·         Tranh chấp CPU, RAM hoặc I/O

·         Trùng port

·         Xung đột thư viện hoặc dependency

·         Xung đột agent

·         Cạnh tranh kết nối database

·         Xung đột cấu hình hệ thống

·         Ảnh hưởng tới băng thông

·         Ảnh hưởng tới thời gian xử lý của ứng dụng khác

Bài kiểm tra phù hợp là đo trạng thái baseline của môi trường trước khi triển khai, sau đó đo lại dưới các mức tải đại diện sau khi giải pháp được đưa vào.

Ví dụ, nếu giải pháp mới đáp ứng SLA của riêng mình nhưng làm thời gian phản hồi của một hệ thống nghiệp vụ hiện hữu tăng vượt ngưỡng chấp nhận, không thể kết luận giải pháp đã tương thích với môi trường vận hành.

Kiểm tra công cụ vận hành, giám sát, sao lưu và khôi phục

Tương thích không kết thúc tại thời điểm triển khai thành công. Giải pháp còn phải phù hợp với hệ sinh thái vận hành của tổ chức.

Cần đánh giá khả năng làm việc với:

·         Monitoring system

·         Centralized logging

·         SIEM

·         Backup

·         Restore

·         Disaster recovery

·         Scheduler

·         Configuration management

·         Patch management

·         Công cụ triển khai tự động

Nếu tổ chức yêu cầu log tập trung nhưng giải pháp chỉ lưu log cục bộ theo định dạng mà hệ thống giám sát không tiếp nhận được, một phần yêu cầu vận hành vẫn chưa được đáp ứng.

Tương tự, backup thành công chưa đủ. Cần thử restore và xác nhận hệ thống sau khôi phục vẫn nhất quán với database, cấu hình, khóa mã hóa và các thành phần phụ thuộc.

Đánh giá tương thích theo phiên bản và thay đổi trong tương lai

Một lỗi thường gặp là đánh giá compatibility tại đúng một thời điểm rồi coi kết quả đó có hiệu lực lâu dài.

Trên thực tế, hệ điều hành được cập nhật, API phát hành phiên bản mới, database nâng cấp, chứng thư hết hạn và hệ thống bên thứ ba có thể thay đổi chính sách.

Vì vậy ma trận tương thích cần thể hiện:

·         Phiên bản hiện tại được hỗ trợ

·         Phiên bản tối thiểu

·         Phiên bản tối đa nếu có

·         Backward compatibility

·         Điều kiện nâng cấp

·         Phiên bản đã hết hỗ trợ

·         Dependency có thể gây breaking change

ISO/IEC 25010:2023 hiện là phiên bản được ISO công bố cho mô hình chất lượng sản phẩm; bản ISO/IEC 25010:2011 đã được ghi nhận là withdrawn. Điều này cũng cho thấy chính tiêu chuẩn tham chiếu có vòng đời phiên bản và không nên mặc định tài liệu cũ vẫn là chuẩn hiện hành.

Với các dependency quan trọng, khả năng tương thích nên được kiểm tra lại mỗi khi nâng phiên bản chứ không suy luận rằng “bản mới hơn chắc chắn vẫn chạy”.

Dùng ma trận tương thích để đánh giá thay vì kiểm tra cảm tính

Một ma trận tương thích giúp biến yêu cầu chung thành các trường hợp có thể kiểm chứng.

Không có một con số phần trăm tương thích chung áp dụng hợp lý cho mọi giải pháp. Tiêu chí phải xuất phát từ những tổ hợp môi trường thực sự được yêu cầu.

Nếu có 40 tổ hợp trong ma trận nhưng môi trường sản xuất chỉ sử dụng 8 tổ hợp bắt buộc, việc đạt 35/40 trường hợp chưa chứng minh khả năng triển khai nếu một trong 8 tổ hợp bắt buộc thất bại. Vì vậy nên phân loại test case theo mức Critical, Required và Optional, đồng thời quy định rõ điều kiện pass/fail cho từng nhóm.

Quy trình đánh giá tính tương thích trước khi chấp nhận giải pháp

Có thể thực hiện đánh giá theo một chuỗi thống nhất:

1.    Lập inventory môi trường mục tiêu: Ghi nhận hệ thống, phiên bản, giao diện, dữ liệu và dependency mà giải pháp phải làm việc cùng

2.    Xác định dependency: Phân biệt dependency bắt buộc, tùy chọn và dependency gián tiếp

3.    Lập ma trận tương thích: Ghép giải pháp với từng nền tảng, phiên bản và interface cần hỗ trợ

4.    Xác định tiêu chí nghiệm thu: Chuyển “phải tương thích” thành kết quả có thể quan sát hoặc đo lường

5.    Kiểm thử từng interface: Xác minh giao thức, dữ liệu, xác thực, lỗi và giới hạn vận hành

6.    Kiểm thử end-to-end: Chạy giao dịch qua toàn bộ chuỗi hệ thống liên quan

7.    Kiểm thử cùng tồn tại: Đo ảnh hưởng của giải pháp lên tài nguyên và hệ thống hiện hữu

8.    Kiểm thử tình huống lỗi: Mô phỏng timeout, mất kết nối, dependency không sẵn sàng, dữ liệu lỗi và phiên bản không phù hợp

9.    Ghi nhận giới hạn: Nêu rõ cấu hình được hỗ trợ, không được hỗ trợ và các điều kiện cần thiết

10.  Đưa compatibility vào regression test: Chạy lại các trường hợp quan trọng sau upgrade hoặc thay đổi dependency

Điểm quyết định là tiêu chí nghiệm thu phải được thiết lập trước khi thử nghiệm. Nếu chỉ chạy hệ thống rồi đánh giá bằng nhận xét “hoạt động ổn”, rất khó phân biệt giữa tương thích hoàn toàn, tương thích có điều kiện và một cấu hình tình cờ chưa phát sinh lỗi.

Một giải pháp được xem là tương thích khi nó không chỉ vận hành độc lập mà còn hoạt động đúng trong toàn bộ môi trường mục tiêu: từ hạ tầng, runtime, dữ liệu và mạng đến IAM, API, hệ thống upstream/downstream, công cụ vận hành và các dependency bên thứ ba.

Vì vậy, câu hỏi cần đặt ra không chỉ là “giải pháp có chạy không?” mà là “giải pháp chạy với phiên bản nào, interface nào, dữ liệu nào, điều kiện nào và giới hạn nào?”. Khi những yếu tố đó được chuyển thành ma trận tương thích và tiêu chí nghiệm thu có thể kiểm thử, quyết định chấp nhận giải pháp sẽ dựa trên bằng chứng thay vì giả định.