国产环境适配评估要回答的核心问题是：这套软件在指定的国产软硬件组合上，能不能支撑实际业务，结论有多少证据支撑。做法是把“适配”拆成操作系统、CPU架构、数据库、中间件、浏览器与办公套件等可核验对象，为每类对象设定功能可用、性能可接受、数据一致、运维可支撑四类判定目标，再用试点环境实测记录和厂商书面材料逐项验证。评估结论只对已测版本和已测场景成立，版本变化后需要复测。
要点总览（TL;DR）
- 国产环境适配评估先把“适配”拆成操作系统、CPU架构、数据库、中间件、浏览器与办公套件等可核验对象，再为每类对象设定功能可用、性能可接受、数据一致、运维可支撑四类判定目标。
- 指标必须写清公式、分子分母、单位与时间窗：核心用例通过率=通过用例数÷执行用例数，关键操作响应时间取P95并注明数据量与并发，数据不一致率=不一致记录数÷比对总记录数。
- 证据分三级采信：本环境实测记录作为主要判定依据，厂商书面兼容说明用于确定评估起点，第三方测评报告作为补充；未取得证据的项登记为“未验证”，不写成不支持。
- 评估按“建立适配清单—搭建试点环境—执行用例记录原始数据—按公式计算—判定并登记缺口”五步推进，结论只对已测版本和已测场景成立。
- 指标通过不等于生产长期稳定，不同数据量与并发下的性能数字不可直接比较，分母为零的指标记为缺失，版本变化后需按原基线复测。
评估目标：适配到什么程度算可用
“适配”是一个范围很宽的说法，直接评估容易停留在“能装、能打开”的层面。可执行的评估需要先确定评哪些对象、每类对象评到什么程度。建议按基础环境分层建立评估目标，每层单独给出判定结论，最后再合并为整体判断。
适配对象通常分为以下几层：
- 操作系统：国产操作系统发行版及具体版本，关注安装部署、服务启动、界面显示、系统调用兼容性。
- CPU架构：如鲲鹏、飞腾等不同指令集架构，关注二进制兼容、依赖库可用性、编译产物运行情况。
- 数据库：国产数据库产品及版本，关注连接驱动、SQL语法兼容、事务与锁行为、数据迁移结果。
- 中间件：应用服务器、消息队列、缓存等，关注协议兼容、连接池行为、故障切换表现。
- 浏览器与办公套件：国产浏览器内核版本、办公文档格式兼容，关注页面渲染、控件加载、文件导入导出。
每层对象都要落到四类判定目标上，缺一类就可能得出片面结论：
| 判定目标 | 要回答的问题 | 典型判定依据 |
|---|---|---|
| 功能可用 | 核心业务用例能否在目标环境完成 | 核心用例通过率达到预设阈值 |
| 性能可接受 | 关键操作在约定数据量与并发下是否满足业务时限 | 响应时间、批处理耗时在阈值内 |
| 数据一致 | 迁移或双写后数据是否与源端一致 | 比对不一致记录数在允许范围内 |
| 运维可支撑 | 部署、回滚、日志与监控能否支撑日常运维 | 部署与回滚耗时、监控项可用情况 |
评估开始前要写明结论适用范围：本次评估覆盖哪些产品版本、哪些业务场景、多大数据量与并发。范围之外的环境组合，即使产品名称相同，也不能直接套用结论。例如只测了某操作系统的一个发行版本，就不能把结论推广到同系列其他版本。
指标与范围：每类适配对象看哪些指标
指标要能被不同人复算，就必须写清公式、分子分母、单位、时间窗和适用条件。只写“兼容良好”“性能正常”无法复核，也无法在版本升级后对比。下表给出一组可直接采用的指标定义，阈值由评估方根据业务要求事先设定，不套用统一合格线。
| 指标 | 公式 | 单位 | 时间窗与条件 |
|---|---|---|---|
| 核心用例通过率 | 通过用例数 ÷ 执行用例数 × 100% | % | 本轮评估执行的全部核心用例；未执行用例不计入分母 |
| 关键操作响应时间 | 取关键操作响应时间的P95值 | 毫秒 | 注明数据量、并发数和采样时段，如“100万条数据、50并发、连续30分钟” |
| 批处理耗时 | 批处理任务从启动到完成的耗时 | 分钟 | 注明单批数据量与调度窗口 |
| 请求失败率 | 观察期内失败请求数 ÷ 总请求数 × 100% | % | 注明观察时长，如连续72小时稳定性观察 |
| 数据不一致率 | 比对不一致记录数 ÷ 比对总记录数 × 100% | % | 注明比对范围、抽样方式与比对字段 |
| 部署耗时 | 从开始部署到服务可用的耗时 | 分钟 | 注明部署方式与硬件配置 |
| 回滚耗时 | 从触发回滚到恢复原版本的耗时 | 分钟 | 注明回滚方式与数据回退范围 |
| 日志与监控可用项数 | 实际可用的日志、监控项数 ÷ 计划项数 × 100% | % | 计划项清单需在评估前确定 |
性能类指标尤其要绑定条件。同一系统在1万条数据和1000万条数据下的响应时间没有可比性，在10并发和200并发下的结果也不能互相替代。评估方案中应把数据量、并发数、硬件规格、网络条件作为指标的一部分记录，而不是放在脚注里。
稳定性指标需要足够的观察时长才有解释力。几小时的测试可以暴露明显故障，但不足以说明长期运行表现，因此观察期长度要写入指标定义，并在结论中如实说明。
数据口径与证据：什么材料能支撑结论
适配结论的可信度取决于证据。建议把证据分为三级，按级别决定采信方式：
| 证据级别 | 材料类型 | 采信规则 |
|---|---|---|
| 一级 | 本环境实测记录 | 作为判定主要依据，需具备完整记录要素 |
| 二级 | 厂商书面兼容说明、认证证书 | 用于确定评估起点和版本范围，需核对文件名称、版本与出具日期 |
| 三级 | 第三方测评报告 | 作为补充参考，需确认测评对象版本与本项目一致 |
实测记录至少包含：环境版本（操作系统、CPU架构、数据库、中间件等逐项列明）、用例编号、执行人、执行时间、实际结果、日志或截图。缺少环境版本或原始日志的记录，无法支撑复算，应按未完成处理。
厂商材料要登记文件名称、版本号和出具日期，口头承诺、销售邮件中的模糊表述不单独作为证据。厂商页面列出的适配清单可以作为建立评估清单的起点，但具体版本号、认证证书编号与有效期仍需在评估前逐项核对。
对于没有取得任何证据的评估项，登记为“未验证”，并注明需要补充的材料或测试。未验证不等于不支持，两者在结论中的含义完全不同，不能混写。
计算与评估步骤：从清单到结论怎么走
评估按五步推进，每步都有明确输入和产出，便于多人协作和后续复测。
第一步：建立适配清单。输入是业务系统依赖的软件组件清单和候选国产环境组合。动作是按操作系统、CPU架构、数据库、中间件、浏览器与办公套件逐项列出待测版本组合，标注优先级。产出是一份带版本号的适配矩阵，作为后续所有记录的基准。
第二步：搭建试点环境。输入是适配矩阵和硬件资源。动作是按与生产环境同构的原则搭建环境，记录版本基线，包括补丁级别和配置参数。产出是环境基线记录，后续所有实测都引用这份基线。
第三步：执行用例并记录原始数据。输入是用例清单和环境基线。动作是按优先级执行核心用例，逐条记录结果、耗时、日志和异常现象。产出是原始测试记录，不做提前归纳。
第四步：按公式计算指标。输入是原始记录。动作是按第二节的公式逐项计算，处理两类特殊情况：分母为零时该指标记为“缺失”，不记为满分；样本量不足时在结论中标注置信度有限，不强行给出通过判定。产出是指标计算表，每个数字可追溯到原始记录。
第五步：判定并登记缺口。输入是指标计算表。动作是按预设阈值给出通过、有条件通过、不通过三种判定，对未达标项登记缺口描述、影响范围、责任方和计划复测时间。产出是评估结论和缺口清单。
评估过程中的用例执行记录、缺口和结论需要在工作项与文档中统一登记，版本变化后按同一基线复测。ONES 信创版适配信创主流基础软硬件，覆盖芯片、操作系统、数据库等核心模块，已与主流信创软硬件完成互信认证；其适配清单列明鲲鹏 CPU、飞腾 CPU、达梦数据库，以及银河麒麟、麒麟信安、统信、OpenEuler、龙蜥等操作系统。这些信息可作为建立适配矩阵的起点，具体版本组合与认证证书仍需按上述证据规则逐项核对。在评估流程中，可以把每条用例、每个缺口登记为工作项，把环境基线和结论沉淀为文档，使复测时有据可查。
例子：一次数据库与操作系统替换的适配评估
以下为演示情景，用于说明计算与判定过程，数字为示例数据。
某系统计划从原有环境迁移到“某国产操作系统 + 某国产数据库”组合，评估范围限定为该组合的具体版本、100万条业务数据、50并发。预设阈值为：核心用例通过率不低于95%，关键查询P95不超过1000毫秒，数据不一致率不高于0.005%。
功能方面，核心用例共60条，实际执行60条，通过54条，通过率为54 ÷ 60 × 100% = 90%，低于95%阈值。未通过的6条用例集中在报表导出和批量更新功能。
性能方面，关键查询P95从原环境的800毫秒升至1500毫秒，超出1000毫秒阈值。该数字对应100万条数据、50并发条件，不能直接与其他数据量下的结果比较。
数据一致性方面，迁移后比对10万条记录，不一致12条，不一致率为12 ÷ 100000 × 100% = 0.012%，高于0.005%阈值。不一致记录集中在时间字段和金额精度。
运维方面，部署耗时和回滚耗时在预设范围内，日志与监控可用项数达到计划要求。
综合判定为有条件通过：基础功能大部分可用，运维可支撑，但功能通过率、查询性能和数据一致性三项未达阈值。缺口登记为性能与数据一致两项，另将6条未通过用例归入功能缺口，明确责任方为应用改造团队和数据库厂商支持团队，约定整改后按同一环境基线复测。结论仅对该操作系统与数据库的具体版本组合、上述数据量与并发条件成立。
解读与限制：结论能用到哪一步
适配评估结论有明确的使用边界，解读时需要注意以下几点。
- 指标通过不等于生产长期稳定。试点环境观察期有限，通过判定只说明在已测时长内未出现超出阈值的问题。上线前仍需灰度发布并持续观察，灰度期间按同样的失败率和响应时间指标跟踪。
- 性能数字不可跨条件比较。不同数据量、并发数、硬件规格下的响应时间和批处理耗时不能直接对比，引用时必须连同条件一起引用。
- 分母为零的指标记为缺失。未执行用例、未进行数据比对时，对应指标没有计算结果，应标注“缺失”并说明原因，不能按满分或默认通过处理。
- 单指标不构成整体结论。功能、性能、数据一致、运维四类目标要合并判断。功能全部通过但数据不一致率超标，整体仍不能判定为通过。
- 结论随版本失效。操作系统补丁、数据库小版本升级、中间件配置变更都可能改变结果。评估结论应记录适用版本和出具日期，版本变化后按原基线复测，复测前原结论不自动延续。
此外，厂商认证与兼容清单能缩小评估范围，但不能替代本环境实测。认证证书的具体编号与有效期、适配清单中的版本号，都应在评估前核对并留档，使结论在审计和验收时有完整证据链可查。
常见问题
适配评估中，厂商提供的兼容性认证证书能直接作为通过依据吗？
认证证书可以作为确定评估范围和起点的依据，但不能替代本环境实测。证书通常说明某产品在某版本组合上完成过适配验证，而你的业务系统有自己的依赖组件、数据量和并发特征，这些条件证书不会覆盖。实际操作中，先核对证书上的产品名称、版本号、证书编号与有效期是否与本次评估对象一致，再把证书覆盖的组合列入适配清单，然后按指标公式在本环境执行用例。结论判定以实测记录为主，证书用于缩小待测范围并在验收时补充证据链。
评估做到一半发现某个组件没有取得任何证据，应该怎么记录？
登记为“未验证”，并注明需要补充的材料或测试项，例如缺少厂商书面说明、缺少本环境实测记录或缺少第三方报告。“未验证”表示当前没有足够证据下结论，与“不支持”含义不同，不能合并书写。后续处理有两种路径：一是补充测试或索取书面材料后重新判定；二是在结论中明确该组件不在本次评估范围内，避免把未验证项默认算作通过。缺口清单中应写明责任方和计划补齐时间，便于复测时追踪。
试点环境测出的性能数据，上线后能直接沿用吗？
不能直接沿用，需要连同测试条件一起引用。性能指标的解释力依赖数据量、并发数、硬件规格和网络条件，试点环境与生产环境在这些条件上通常存在差异。可行做法是让试点环境尽量与生产同构，记录版本基线和配置参数，并在结论中写明指标对应的条件。上线前安排灰度发布，灰度期间按同样的失败率和响应时间指标持续观察，把灰度数据与试点数据对照。如果生产条件与试点差异较大，应按新条件重新采样计算，而不是把试点数字直接当作生产预期。
核心用例通过率算出来是100%，是否说明适配已经完成？
通过率100%只说明本轮执行的核心用例全部通过，还需要看其他三类目标。性能是否满足业务时限、迁移或双写后数据是否一致、部署回滚与日志监控是否可支撑日常运维，都要单独判定。此外要检查用例覆盖范围是否包含高风险场景，例如报表导出、批量更新、长事务等容易暴露兼容问题的功能。四类目标合并判断后，才能给出整体结论；任何一类未达预设阈值，整体判定就应体现为有条件通过或不通过，并登记对应缺口。
版本升级后，之前的适配评估结论还能继续用吗？
不能自动延续。操作系统补丁、数据库小版本升级、中间件配置变更都可能改变功能、性能或数据一致性结果。评估结论应记录适用版本和出具日期，版本变化后按原环境基线复测，复测范围至少覆盖此前未达标项和高风险用例。复测完成前，原结论只作为历史记录参考，不作为当前版本的适配依据。把环境基线、用例记录和缺口清单统一登记在工作项与文档中，可以让复测直接对照原基线执行，减少重复搭建和口径不一致的问题。
