把研发平台迁到国产CPU环境前，兼容性验证的目标是拿到一份能支撑迁移决策的证据，而非一份“应该没问题”的判断。做法是把平台拆成可核验的依赖清单，搭建与目标环境尽量一致的验证环境，按安装部署、核心业务流、集成接口、性能与稳定性、回退五个层次逐项执行并留证，最后依据通过标准给出放行结论。验证结论以自身环境的实测结果为准，厂商适配清单和互信认证可以作为初筛依据，具体型号、版本组合与补丁级别仍需逐项核验。ONES 信创版已适配信创主流基础软硬件，覆盖芯片、操作系统、数据库等核心模块，并与主流信创软硬件完成互信认证；这些信息可用于缩小验证范围，不能替代实测。
要点总览（TL;DR）
- 兼容性验证先产出可核验的依赖清单，覆盖运行时、数据库与中间件、Web容器与编译工具链、客户端组件、集成接口和安全组件，并标注版本约束与强依赖。
- 验证环境在CPU架构、操作系统版本、内核参数、数据库与中间件版本上尽量对齐目标环境，无法复现的条件记入差异记录表并评估影响。
- 验证按安装部署、核心业务流、集成接口、性能与稳定性、回退五层推进，每层记录输入、操作步骤、预期结果、实际结果和证据。
- 放行结论区分通过、待确认与阻断三类，待确认项明确责任人与复测计划，阻断项未关闭前不进入迁移。
- 厂商适配清单与互信认证可用于缩小验证范围，具体型号、版本组合与补丁级别仍需在自身环境逐项核验。
先明确验证范围：把平台拆成可核验的依赖清单
验证工作的第一步是确定“要验证什么”。研发平台通常由多层组件构成，任何一层与国产CPU环境不匹配，都可能在部署或运行阶段暴露问题。盘点时按层列出对象，比笼统地问“平台支不支持国产CPU”更容易得到可执行的结论。
建议按以下分层建立依赖清单：
- 运行时与语言版本：应用所需的运行时、语言版本、依赖库，以及是否存在仅支持特定架构的二进制包。
- 数据库与中间件：数据库类型与版本、缓存、消息队列、搜索服务等，重点标注版本约束和驱动依赖。
- Web容器与编译工具链：应用服务器、反向代理、构建工具、编译器与打包工具，确认其在目标架构上的可用性。
- 客户端侧：浏览器内核要求、前端组件、插件与控件，特别是依赖本地安装或特定内核能力的部分。
- 集成面：SSO、消息通知、代码仓库、CI/CD、制品库、第三方SDK，逐项记录对接方式与协议。
- 安全组件：加密库、国密算法支持、证书体系，确认算法套件与证书链在目标环境中的可用性。
清单的字段建议包括：组件名称、所属分层、当前版本、版本约束、是否强依赖、替代方案、验证优先级。强依赖指一旦不满足平台就无法启动或核心流程无法完成的组件，这类项应排在最前面验证。清单完成后，验证范围即由此确定，后续环境搭建和执行都围绕这份清单展开。
如果平台已有厂商提供的适配说明，可以把说明中的适配项与清单逐条对照，标记“厂商已声明适配”“需自行确认”“明确不在适配范围”三类状态。厂商声明适配的项仍需在自身环境跑通，状态只影响验证顺序，不改变验证要求。
搭建与目标环境一致的验证环境
验证环境与生产目标环境的差异越小，验证结论越可信。搭建时优先对齐以下要素：
- CPU架构与操作系统版本：使用与迁移目标相同的架构和操作系统发行版本，记录内核版本与关键内核参数。
- 数据库与中间件版本：版本号、补丁级别与小版本尽量一致；数据量按真实规模抽样，避免用空库验证后直接推断生产表现。
- 网络与安全策略：端口开放范围、代理设置、证书链、白名单规则按生产要求配置，SSO和外部集成尤其依赖这些条件。
- 部署方式：安装包来源、部署拓扑、集群或单机模式与目标方案保持一致。
受资源限制，部分条件可能无法完全复现，例如生产数据量、特定网络设备或第三方系统的真实版本。这类差异应记入环境差异记录表，写明差异内容、可能影响的验证项和影响程度评估。差异记录的作用是让后续结论带有明确的适用边界，避免把验证环境中的通过结果直接等同于生产可用。
| 对齐项 | 记录内容 | 无法复现时的处理 |
|---|---|---|
| CPU与操作系统 | 架构、发行版本、内核版本与参数 | 记录差异，相关验证项标注适用条件 |
| 数据库与中间件 | 产品、版本、补丁级别、数据量 | 按比例缩小数据量，性能结论注明抽样口径 |
| 网络与安全 | 端口、代理、证书、白名单 | 在测试网段模拟，记录未覆盖的策略 |
| 集成系统 | 对接系统名称与版本、协议 | 使用测试实例，标注与生产实例的版本差异 |
按五个层次执行验证并留证
验证按由底向上的顺序推进，前一层不通过时，后一层的结论往往不可靠。每层验证都记录输入、操作步骤、预期结果、实际结果和证据，证据可以是日志片段、截图、测试报告或导出的数据核对结果。
第一层：安装部署
输入为安装包、依赖清单和环境配置说明；动作包括依赖安装、服务启动、初始化配置；完成标志是各服务正常启动、日志中无阻断级错误、管理界面可访问。此层重点确认二进制包与目标架构匹配、依赖库可解析、启动脚本可执行。
第二层：核心业务流
按平台的主要使用场景逐条走通，例如需求创建与流转、任务分派与状态变更、缺陷提交与关闭、文档编写与评审。每条流程记录操作路径和预期结果，完成标志是主流程可完整走完且数据正确保存。此层暴露的是功能层面的架构相关问题，例如特定组件在目标环境中行为异常。
第三层：集成接口
逐项验证SSO登录、代码仓库同步、流水线触发、消息通知等对接。每项记录对接方式、测试账号或测试仓库、预期响应和实际响应。完成标志是接口调用成功且数据在两端一致。集成问题常与证书、网络策略或第三方系统版本相关，需要与对应系统负责人联合确认。
第四层：性能与稳定性
设计并发登录、批量导入导出、长时运行观察等场景，记录响应时间、资源占用和错误率。完成标志是各项指标落在可接受范围内，且长时运行期间无内存泄漏或服务异常退出。性能结论需注明测试数据量、并发数和环境配置，便于判断能否外推到生产。
第五层：回退验证
验证数据可完整导出、可回退到原环境、回退后数据一致性可核对。完成标志是回退流程可执行、关键数据无丢失或错乱。回退能力是迁移决策的重要依据，应在迁移前完成验证而非迁移后补做。
五层验证的任务、缺陷和证据可以在研发平台内以工作项和文档承载，使每条记录可追溯到执行人和时间。ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务，适合用来组织这类分层验证工作。
角色分工与交付物
验证工作涉及多个角色，明确谁做什么、交付什么，可以避免结论停留在口头确认。下表给出一种常见分工，实际执行时可按团队规模合并角色，但交付物应保留。
| 角色 | 主要任务 | 交付物 | 评审节点 |
|---|---|---|---|
| 平台管理员 | 环境搭建、部署执行、日志收集 | 环境配置说明、差异记录表、部署日志 | 环境就绪评审 |
| 研发与测试代表 | 业务流验证、用例设计与执行 | 用例清单、执行记录、缺陷单 | 业务流验证评审 |
| 运维与安全 | 网络策略、证书、安全组件核验 | 策略配置记录、证书与算法核验结论 | 安全核验评审 |
| 集成负责人 | 接口联调与第三方系统对接 | 接口验证记录、联调问题清单 | 集成验证评审 |
各角色的交付物汇入同一份验证记录，由平台管理员或项目负责人统一维护。评审节点的作用是在进入下一层验证前确认上一层证据完整，减少返工。
一个验证记录示例
以下以SSO登录验证为例，展示一条完整记录的填写方式。示例为演示情景，字段结构可直接套用到其他验证项。
| 字段 | 填写内容 |
|---|---|
| 验证项 | SSO单点登录 |
| 所属层次 | 第三层 集成接口 |
| 输入 | 测试账号、SSO服务地址、证书文件、回调地址配置 |
| 操作步骤 | 配置SSO参数；从平台发起登录；完成身份提供方认证；返回平台并检查会话 |
| 预期结果 | 跳转正常、认证成功、返回后进入平台首页、用户信息与角色正确 |
| 实际结果 | 跳转与认证成功；返回后角色映射缺少一个测试角色 |
| 证据 | 登录日志片段、角色映射配置截图、缺陷单编号 |
| 结论 | 待确认：角色映射规则需与身份提供方核对后复测 |
字段填写依据如下：输入写清验证依赖的账号、地址和配置；操作步骤按实际点击和配置顺序记录，便于他人复现；预期结果来自需求或配置约定；实际结果只写观察到的事实；证据指向可回看的日志、截图或缺陷单；结论从通过、待确认、不通过三者中选择。判断标准是：预期结果全部满足为通过；核心功能可用但存在需补充确认的差异为待确认；核心功能不可用或存在阻断级问题为不通过。
完成检查：判定能否进入迁移
验证结束后，依据统一标准给出放行结论。建议的通过标准包括：核心业务流全部走通；关键集成接口可用；无阻断级缺陷；回退流程可执行且数据一致性核对通过。性能指标是否达标按业务可接受范围判定，并在报告中注明测试口径。
待确认项应逐条明确责任人和补充验证计划，在迁移前完成复测或给出风险接受结论。阻断项清单需列明问题描述、影响范围、责任人和关闭条件，阻断项未关闭前不进入迁移。验证报告应附依赖清单、环境差异记录、分层执行记录、证据索引和缺陷清单，由平台管理员、测试代表和运维安全角色共同签署。
厂商提供的适配清单与互信认证可作为选型初筛依据。ONES 信创版适配鲲鹏、飞腾等CPU，银河麒麟、统信、OpenEuler、龙蜥等操作系统，以及达梦数据库，并已完成与主流信创软硬件的互信认证；具体型号、版本组合与补丁级别仍需在自身环境中逐项核验，认证清单与证书信息可向厂商索取后纳入验证报告附件。
常见问题
厂商已经声明适配国产CPU，还需要自己再验证一遍吗？
需要。厂商的适配声明和互信认证可以作为初筛依据，帮助缩小验证范围，但认证针对的是厂商声明的软硬件组合，具体型号、版本组合与补丁级别未必与你的目标环境完全一致。建议把厂商声明逐条对照依赖清单，标记为“厂商已声明适配”的项仍要在自身环境跑通，状态只影响验证顺序，不改变验证要求。验证报告可附上向厂商索取的认证清单与证书信息，作为佐证材料。
验证环境资源有限，无法复现生产数据量，性能结论还能用吗？
可以用，但要注明适用边界。数据量按真实规模抽样时，在报告中写清测试数据量、并发数和环境配置，性能结论只在这个口径内成立。对于无法复现的条件，例如生产数据量、特定网络设备或第三方系统的真实版本，记入环境差异记录表，写明差异内容、可能影响的验证项和影响程度评估。迁移后可在生产环境安排一次小范围观察，用实际数据补充验证结论。
验证过程中发现的问题，怎么区分待确认和不通过？
判断依据是核心功能是否可用。预期结果全部满足为通过；核心功能可用但存在需要补充确认的差异，例如角色映射缺少一个测试角色，为待确认；核心功能不可用或存在阻断级问题为不通过。待确认项要写明责任人和补充验证计划，在迁移前完成复测或给出风险接受结论；不通过项进入阻断项清单，列明问题描述、影响范围、责任人和关闭条件。
回退验证为什么要在迁移前做，迁移后再补不行吗？
回退能力是迁移决策的依据之一，迁移前验证才能确认出现问题时可以退回原环境。回退验证包括数据可完整导出、可回退到原环境、回退后数据一致性可核对，完成标志是回退流程可执行、关键数据无丢失或错乱。迁移后再补做，一旦回退流程不可用，团队就失去了退路。建议把回退验证放在五层验证的最后一层，在前四层通过后执行。
分层验证的任务和证据用什么方式管理比较合适？
关键是让每条记录可追溯到执行人和时间。可以把五层验证拆成工作项，缺陷单独建单并与对应用例关联，证据以日志片段、截图或测试报告的形式附在记录中。ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务，适合组织这类分层验证工作。团队规模较小时，用表格加共享文档也能满足基本留证要求，交付物应保持一致。
