研发平台国产化适配是一项分阶段推进的工程工作：先盘点现有平台的技术栈与外部依赖，再确定信创目标环境，随后按环境准备、依赖替换、数据与集成迁移、性能与兼容验证、灰度切换的顺序逐项推进，最后用可复核的证据确认适配完成。适配任务和验证记录需要由工作项与文档承载，跨角色交接才有据可查。
要点总览（TL;DR）
- 适配从依赖盘点开始：按服务器与芯片、操作系统、数据库、中间件、运行时与工具链、浏览器六类逐项记录当前版本、使用位置、强依赖程度和替代方案，盘点结果直接转为验证任务。
- 实施按五个阶段推进：环境准备、依赖替换、数据与集成迁移、性能与兼容验证、灰度切换，每阶段以完成标志作为进入下一阶段的条件。
- 角色分工要落到阶段动作和交接物：平台负责人、运维、DBA、开发、测试、安全与合规、业务方代表各自明确在盘点、替换、验证、切换中的职责。
- 适配完成以证据判定：核心研发流程回归通过、性能达到约定阈值、数据与权限核验一致、回退方案演练完成、证据完整归档，缺一项即视为未完成。
- 多角色协作时把盘点项、替换任务和验证用例登记为工作项，验证记录与评审结论沉淀在文档中，状态流转作为交接信号。
适配前先盘清哪些依赖：现状盘点表怎么填
适配工作的起点是一张能落到具体版本的依赖盘点表。盘点越细，后续替换和验证越少返工。盘点范围应覆盖研发平台从底层到用户访问的完整链路，避免只记录服务器和数据库而漏掉编译工具链、浏览器等容易被忽视的环节。
盘点对象建议按以下六类展开：
- 服务器与芯片架构：物理机、虚拟机或云主机的 CPU 架构（如 x86、ARM），以及承载平台的计算资源规格。
- 操作系统：服务器端与客户端操作系统的发行版和版本。
- 数据库：平台使用的数据库类型、版本、部署形态（单机、主备、集群）。
- 中间件：应用服务器、消息队列、缓存、反向代理等组件的类型与版本。
- 运行时与编译工具链：JDK/运行时版本、包管理工具、构建工具及其插件依赖。
- 浏览器与客户端：用户访问平台使用的浏览器类型与版本，以及桌面客户端、插件等。
每个依赖项在表中记录六个字段，形成可追踪的记录：
| 字段 | 填写要求 |
|---|---|
| 依赖项 | 组件名称，精确到产品与用途，如“数据库—业务主库” |
| 当前版本 | 实际运行版本号，不以采购合同版本代替 |
| 使用位置 | 该依赖被哪些模块、服务或流程调用 |
| 强依赖程度 | 分为强依赖（不可替换或替换成本高）、可替换、可移除三档 |
| 目标替代方案 | 信创环境下的候选组件及版本，暂未确定的标注“待选型” |
| 负责人 | 对该依赖替换与验证结果负责的具体人员 |
盘点结果要直接转化为验证任务，而不是停留在表格里。做法是：对每个“强依赖”和“可替换”项，生成一条对应的替换或兼容验证任务，写明验证动作和通过标准；对“可移除”项，登记清理任务。这样盘点表就成为后续实施计划的输入，每一项都有对应的动作和责任人。
分阶段实施步骤：从环境准备到灰度切换
适配按五个阶段推进，每个阶段明确输入、动作、输出和完成标志，阶段之间以完成标志作为进入下一阶段的条件。以下计划表可直接作为实施计划的骨架：
| 阶段 | 输入 | 主要动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、环境准备 | 依赖盘点表、目标环境选型结论 | 搭建信创基础环境，部署最小可用实例，验证操作系统、芯片、数据库、中间件的基础连通 | 环境搭建记录、最小可用验证结果 | 平台核心服务可在目标环境启动并完成一次基础读写 |
| 二、依赖替换 | 替换清单、替代组件版本 | 按依赖项逐项替换数据库、中间件、运行时，每替换一项执行对应回归 | 替换记录、单项回归结果 | 全部强依赖项替换完成且单项回归通过 |
| 三、数据与集成迁移 | 历史数据范围、账号权限清单、外部接口清单 | 迁移历史数据，重建账号与权限，联调外部系统接口 | 数据迁移报告、权限核对记录、接口联调记录 | 数据量与关键字段核对一致，接口联调全部通过 |
| 四、性能与兼容验证 | 功能清单、性能阈值约定、浏览器清单 | 执行功能回归，压测并发与响应时间，逐浏览器验证 | 功能回归报告、性能测试报告、兼容性记录 | 核心功能全部通过，性能达到约定阈值，目标浏览器无阻断问题 |
| 五、灰度切换 | 验证报告、回退预案 | 小范围用户切换，观察运行指标，逐步扩大范围 | 切换记录、回退预案演练记录 | 灰度期无严重问题，回退预案演练通过，切换审批完成 |
阶段二需要强调替换顺序：先替换影响面小、可独立验证的组件，再处理与业务耦合深的数据库和中间件。每替换一项立即回归，避免多项变更叠加后难以定位问题来源。
阶段五的回退预案要在切换前完成演练，明确回退触发条件、回退操作步骤和决策人。灰度范围从小到大，观察期内的运行指标与问题记录作为扩大范围的依据。
角色分工与各阶段交付物
适配涉及多个专业角色，职责边界不清会导致验证任务悬空。建议按下表明确每个角色在各阶段的具体动作和交接物：
| 角色 | 盘点阶段 | 替换阶段 | 验证阶段 | 切换阶段 |
|---|---|---|---|---|
| 平台负责人 | 确定盘点范围，审定盘点表 | 排定替换优先级，协调资源 | 确认验证范围与通过标准 | 签署切换审批单，决策回退 |
| 运维/基础设施 | 登记服务器、操作系统、中间件信息 | 搭建目标环境，执行组件替换 | 配合压测，监控运行指标 | 执行切换操作与回退演练 |
| DBA | 登记数据库版本与部署形态 | 执行数据库替换与数据迁移 | 核验数据完整性与性能 | 切换期间值守数据库 |
| 应用开发 | 标注依赖在代码中的使用位置 | 改造不兼容的接口与配置 | 修复回归缺陷，配合接口联调 | 处理灰度期应用问题 |
| 测试 | 梳理核心流程用例范围 | 执行单项回归 | 执行功能回归与浏览器兼容验证 | 灰度期问题复测 |
| 安全与合规 | 提出安全基线要求 | 核查替换组件的安全配置 | 复核权限与数据安全 | 确认切换符合合规要求 |
| 业务方代表 | 确认关键业务流程清单 | — | 参与核心流程验收 | 确认灰度范围与切换时间窗 |
交接物按阶段沉淀：盘点阶段交付依赖盘点表，替换阶段交付替换记录，验证阶段交付测试报告，切换阶段交付切换审批单。每份交接物都要有明确的接收人和确认动作，避免文档写完无人复核。
一个适配示例：从依赖清单到切换评审
以下为演示情景，用于说明盘点表如何驱动替换与评审，具体版本与认证以实际厂商资料为准。
某研发平台计划迁移到信创环境。盘点表识别出两项强依赖：业务主库使用的数据库，以及应用服务器中间件。数据库承载需求、任务、缺陷等核心数据，替换风险最高；中间件影响应用部署方式，但改造范围相对可控。
据此确定替代顺序：先替换中间件，完成部署验证和基础功能回归，确认应用可在新中间件上稳定运行；再替换数据库，先做数据迁移演练，核对数据量与关键字段，再执行正式迁移和全量回归。两项替换均完成后，进入性能与兼容验证，压测并发与响应时间，逐浏览器验证核心页面。
验证记录按依赖项归档：每项替换记录替换前后的版本、回归用例通过情况、遗留问题及处理结论。切换评审时，评审人依据这些记录判断是否满足切换条件，而不是依据整体口头汇报。评审结论写入切换审批单，明确灰度范围、观察期和回退触发条件。
示例的边界在于：替代组件的具体版本、与信创基础软硬件的兼容认证状态，需以厂商正式资料核实，盘点表中的“目标替代方案”在核实前应标注待确认。
完成检查：适配是否真的做完
“已部署”与“已验证”是两种状态。适配完成的判定以证据为准，以下清单可逐项核对：
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 核心研发流程功能回归 | 需求、任务、代码、构建、测试、发布各环节核心用例全部通过 | 功能回归报告 | 测试 |
| 性能指标 | 并发与响应时间达到项目约定的阈值 | 性能测试报告 | 运维/测试 |
| 数据完整性 | 迁移前后数据量一致，关键字段抽样核对无差异 | 数据核对记录 | DBA |
| 权限一致性 | 账号、角色、权限与迁移前一致，越权访问测试通过 | 权限核对记录 | 安全与合规 |
| 浏览器兼容 | 目标浏览器清单内核心页面无阻断问题 | 兼容性验证记录 | 测试 |
| 回退方案演练 | 按预案完成一次回退演练，恢复时间在可接受范围 | 演练记录 | 运维 |
| 适配证据归档 | 盘点表、替换记录、测试报告、审批单完整归档，可追溯 | 归档目录与索引 | 平台负责人 |
清单中任何一项缺少证据，都应视为适配尚未完成。证据归档不仅服务本次验收，也为后续版本升级和同类平台适配提供参照。
适配过程中的协作管理：把验证任务落到工作项
适配工作横跨多个角色和阶段，任务分散在表格、邮件和会议纪要中容易丢失。更稳妥的做法是把盘点项、替换任务和验证用例登记为可追踪的工作项，每个工作项写明负责人、截止时间和通过标准，状态随进展流转。
验证结果与评审结论沉淀在文档中，与对应工作项关联，形成从任务到证据的完整记录。跨角色交接时，工作项状态的变化即为交接信号：替换完成转入验证、验证通过转入评审、评审通过转入切换。评审节点作为状态流转的卡点，未通过评审的任务不进入下一阶段。
ONES 信创版已完成全栈信创适配，适配信创主流基础软硬件，覆盖芯片、操作系统、数据库等核心模块，已与主流信创软硬件完成互信认证；页面列出的适配对象包括鲲鹏 CPU、飞腾 CPU、达梦数据库，以及银河麒麟、麒麟信安、统信、OpenEuler、龙蜥等操作系统。在适配推进过程中，可以用 ONES 的工作项承载盘点项与替换任务，用文档沉淀验证记录和评审结论，让每个依赖项的适配状态可查、可交接。具体适配版本与认证清单以厂商正式资料为准。
常见问题
适配过程中，某个依赖项暂时找不到合适的信创替代方案，应该怎么处理？
在盘点表中将该依赖项标注为“待选型”，并记录当前使用方式和强依赖程度。实施时可以先推进其他可替换项，同时为该依赖项单独设立选型验证任务，明确候选范围、验证动作和决策时间点。如果该依赖项影响核心流程，需要在切换评审前给出结论：完成替换、采用过渡方案或调整上线范围。未确定替代方案的依赖项不应默认视为已适配。
灰度切换阶段发现严重问题，回退需要满足什么条件、由谁决策？
回退预案应在切换前明确触发条件、操作步骤和决策人。常见触发条件包括核心流程阻断、性能明显低于约定阈值、数据异常等。决策人通常为平台负责人，运维负责执行回退操作。灰度期间一旦触发条件成立，按预案执行回退并记录问题现象、影响范围和回退耗时，作为后续修复和再次切换的依据。回退演练应在正式切换前完成，确认恢复时间在可接受范围内。
性能验证的阈值怎么定？没有历史基线怎么办？
性能阈值应结合业务实际约定，而不是套用统一数值。有历史基线时，以迁移前在相似负载下的响应时间和并发能力作为参照，允许合理波动范围。没有历史基线时，可以在旧环境上补做一次基准测试，或在信创环境上先做小规模压测，结合用户规模、高峰时段和核心流程的响应要求确定阈值。阈值确定后写入验证任务，作为切换评审的通过条件之一。
适配任务用工作项管理时，工作项粒度多细比较合适？
建议以“一个可独立验证的依赖项或一个可独立验收的验证场景”为粒度。例如“替换应用服务器中间件并完成基础功能回归”可以作为一条工作项，而不是把整个替换阶段做成一条。每条工作项写明负责人、截止时间、通过标准和关联的验证记录。粒度过粗会导致状态无法反映真实进展，粒度过细则增加管理成本。盘点项、替换任务和验证用例分别登记，通过关联关系保持追溯。
ONES 信创版在适配中能承担什么角色？
ONES 信创版已完成全栈信创适配，适配信创主流基础软硬件，覆盖芯片、操作系统、数据库等核心模块，已与主流信创软硬件完成互信认证；页面列出的适配对象包括鲲鹏 CPU、飞腾 CPU、达梦数据库，以及银河麒麟、麒麟信安、统信、OpenEuler、龙蜥等操作系统。在适配推进过程中，可以用 ONES 的工作项承载盘点项与替换任务，用文档沉淀验证记录和评审结论，让每个依赖项的适配状态可查、可交接。具体适配版本与认证清单以厂商正式资料为准。
