国产CPU研发平台适配验收，需要把“能装能跑”拆成可逐项判断的检查表：先锁定适配范围与目标环境，再按基础环境、平台部署、核心研发流程、集成与数据、性能与稳定性、运维与回退六个阶段逐项核验。每项写明通过标准、证据、负责人和检查时点，影响上线的项目标为阻断项，阻断项关闭并复验后才能签字。这份清单适合信创环境负责人、平台管理员、研发流程负责人及安全运维代表在适配方案确认后、试运行前和上线切换前使用。
要点总览（TL;DR）
- 验收前先用一张范围表锁定CPU架构、服务器型号、操作系统与平台模块，明确本次验收覆盖与不覆盖的内容，避免现场临时扩大口径。
- 按基础环境、平台部署、核心研发流程、集成与数据、性能与稳定性、运维与回退六个阶段逐项检查，每项写明通过标准、证据、负责人和检查时点。
- 影响核心流程、数据完整性或安全合规的未通过项列为阻断项，关闭并复验后才能进入上线切换，非阻断项进入遗留问题清单。
- 清单在适配方案确认后、试运行前、上线切换前三个时点使用，由验收负责人统一收口，结论按阶段累加。
- 验收结论以实测记录和证据为准，性能与安全指标对照方案阶段约定的阈值，不引用未经核实的认证结论。
谁在什么时点使用这份验收清单
验收清单的价值在于把“适配是否完成”变成一组有人填、有人核、有人签字的记录。使用对象通常包括四类角色：信创环境负责人负责整体组织与对外协调；平台管理员负责环境、部署与运维类检查项；研发流程负责人负责核心研发流程走查；安全与运维代表负责安全合规、监控告警与回退方案。角色可以兼任，但每项检查都要落到具体姓名。
清单在三个时点介入。第一是适配方案确认后，用S2锁定范围，避免后续验收口径漂移；第二是试运行前，完成基础环境、平台部署与核心流程的初检，提前暴露阻断问题；第三是上线切换前，完成集成数据、性能安全、运维回退的全量核验并形成结论。三个时点使用同一份清单，结论按阶段累加，不重复推翻已确认项。
验收组织上，应指定一名验收负责人统一收口。每项检查记录“结论、证据位置、检查人、检查日期”四项信息，结论只填通过、不通过、不适用三种。阻断项未关闭，不得进入下一阶段；确需带条件推进的，由验收负责人书面记录条件与复验时点。
| 角色 | 主要职责 | 介入时点 | 签字范围 |
|---|---|---|---|
| 信创环境负责人 | 组织验收、协调资源、裁定阻断项 | 方案确认后至上线切换前 | 总体结论 |
| 平台管理员 | 环境、部署、运维回退类检查 | 试运行前、上线切换前 | 基础环境、部署、运维章节 |
| 研发流程负责人 | 核心研发流程走查与结果确认 | 试运行前 | 核心流程章节 |
| 安全与运维代表 | 安全合规、监控告警、回退演练核验 | 上线切换前 | 安全与运维章节 |
适配范围与目标环境确认
范围确认不评价环境是否达标，只回答“这次验收覆盖什么”。范围表建议分三块填写：环境项、模块项、范围外项。环境项逐条列出CPU架构与服务器型号，例如ARM、x86、LoongArch等实际采购环境，写明服务器型号与数量；同时列出操作系统及版本、数据库、中间件、浏览器与终端环境。每一项都要有明确的版本号，避免用“最新版”这类无法核验的表述。
模块项按研发平台的实际构成勾选：代码托管、流水线、制品库、需求与缺陷管理、文档协作，以及统一认证、消息通知等支撑模块。对每个模块标注“本次验收”或“后续批次”，并说明理由。范围外项同样要写清楚，例如暂不纳入的旧系统、尚未采购的终端型号、由其他项目组负责的周边系统，避免验收时被临时追加。
| 范围类别 | 填写内容 | 确认要点 |
|---|---|---|
| CPU与服务器 | 架构、型号、数量、部署位置 | 与实际采购和机房记录一致 |
| 操作系统与基础软件 | OS版本、数据库、中间件、浏览器 | 版本号可核验，注明终端类型 |
| 平台模块 | 代码托管、流水线、制品、需求缺陷、文档等 | 逐模块标注本次或后续批次 |
| 范围外系统 | 不纳入本次验收的系统与模块 | 写明归属项目或后续计划 |
范围表由信创环境负责人起草，平台管理员与研发流程负责人会签。范围一旦确认，后续新增环境或模块需走变更记录，不能在现场口头扩大验收内容。
基础环境与依赖检查项
基础环境是后续所有阶段的前置条件，检查目标是确认平台运行所依赖的底层资源在目标架构上就绪。每项检查都要给出可观察的通过标准和证据位置，例如命令输出、截图、配置文件路径或巡检记录编号。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| CPU与操作系统组合启动 | 系统正常启动，CPU型号、核数、内存被正确识别 | 系统信息命令输出截图 | 平台管理员 | 是 |
| 依赖组件可用 | 数据库、缓存、消息、对象存储等在目标架构上安装并可连通 | 组件版本与连通性测试记录 | 平台管理员 | 是 |
| 网络与访问策略 | 域名解析、证书有效期、端口开放与防火墙策略符合部署方案 | 策略配置截图与连通性测试 | 平台管理员 | 是 |
| 时钟同步 | 各节点时间偏差在组织约定范围内 | 时间同步状态输出 | 平台管理员 | 否 |
| 日志与磁盘容量 | 日志目录可写，磁盘剩余容量满足运行与增长预估 | 目录权限与容量检查记录 | 平台管理员 | 是 |
依赖组件的检查要覆盖平台实际使用的组件清单，不能只测其中一项。网络项应同时验证研发终端到平台的访问路径，以及平台到周边系统的出站连通。时钟不同步通常不直接阻断上线，但会影响日志排查与审计追溯，建议在试运行前修正。
平台部署与启动检查项
这一阶段核验平台在国产CPU环境中完成安装、启动并达到可用状态，不涉及业务流程走查。检查重点是安装介质与目标架构匹配、服务健康、管理员可用和基础配置可持久化。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 安装包与镜像架构匹配 | 安装介质与目标CPU架构一致，安装过程无阻断错误 | 安装日志与介质校验记录 | 平台管理员 | 是 |
| 服务进程启动 | 各服务进程正常运行，健康检查接口返回正常 | 进程状态与健康检查输出 | 平台管理员 | 是 |
| 管理员登录与配置 | 管理员账号可登录，基础配置项保存后生效且重启不丢失 | 操作截图与重启后复核记录 | 平台管理员 | 是 |
| 授权信息核验 | 授权信息与合同约定一致，按实际合同核验，不预设具体版本 | 授权页面截图或合同对应页 | 信创环境负责人 | 是 |
安装过程出现可绕过的告警时，应记录告警内容与处理方式，由平台管理员判断是否影响后续功能。配置持久化检查建议至少做一次服务重启后的复核，避免配置只存在于内存中。
核心研发流程检查项
这一阶段从研发人员实际使用角度出发，核验关键流程在国产CPU环境中能完整走通。走查应使用真实项目或与生产结构一致的测试项目，记录操作步骤、结果和证据，避免只由管理员在后台确认功能存在。
| 流程 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 代码提交与合并请求 | 提交、创建合并请求、代码评审、合入均可完成 | 合并请求链接与评审记录 | 研发流程负责人 | 是 |
| 流水线构建与制品 | 构建、测试任务可执行，制品产出并可下载，执行记录留痕 | 流水线运行记录与制品清单 | 研发流程负责人 | 是 |
| 需求、任务与缺陷流转 | 状态流转符合配置，权限控制按角色生效 | 工作项截图与权限测试记录 | 研发流程负责人 | 是 |
| 文档协作 | 文档创建、编辑、附件上传下载正常 | 文档页面与附件校验记录 | 研发流程负责人 | 否 |
权限控制建议用不同角色账号分别验证，至少覆盖普通研发、项目负责人和管理员三类。流水线检查要包含一次完整构建到制品下载的闭环，仅看到任务启动不算通过。文档附件应验证中文文件名和大文件场景，这两类问题在环境切换时较常见。
集成、数据与迁移检查项
集成与数据核验回答两个问题：平台能否与周边系统正常对接，历史数据迁移后是否完整一致。集成点按实际清单逐项测试，接口调用要记录请求、返回结果和错误定位方式。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 代码仓库与CI工具对接 | 触发、回调、状态同步正常 | 集成测试记录与日志 | 平台管理员 | 是 |
| 消息通知 | 关键事件可送达约定渠道 | 通知截图与发送日志 | 平台管理员 | 否 |
| 统一认证 | 登录、注销、角色映射符合预期 | 认证流程测试记录 | 安全与运维代表 | 是 |
| 接口返回与错误定位 | 返回结果符合接口约定，异常时有可读错误信息 | 接口测试用例与返回样例 | 平台管理员 | 是 |
| 历史数据迁移 | 条数、附件、权限关系与迁移前核对一致 | 迁移前后比对表与抽样记录 | 平台管理员 | 是 |
数据核对建议采用“总量比对加抽样比对”两层：总量核对工作项、用户、附件数量；抽样选取若干项目，逐项核对字段、附件可打开性和权限继承关系。抽样记录要写明抽样规则和样本编号，便于复验时复现。
性能、稳定性与安全合规检查项
这一阶段用实测记录回答平台在目标环境中的承载能力、长时间运行表现和安全要求是否满足约定。阈值应在适配方案阶段就与业务方约定，验收时直接对照，避免事后临时定标准。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 典型并发响应 | 约定并发场景下关键操作响应时间在阈值内 | 压测方案与结果记录 | 平台管理员 | 是 |
| 连续运行观察 | 观察期内无服务异常退出，内存无持续增长 | 监控曲线与运行日志 | 平台管理员 | 是 |
| 账号与权限 | 账号权限分配符合组织安全要求 | 权限矩阵与抽查记录 | 安全与运维代表 | 是 |
| 审计日志 | 关键操作可追溯，日志保留周期符合要求 | 日志样例与保留策略配置 | 安全与运维代表 | 是 |
| 传输加密 | 访问链路按组织要求启用加密 | 配置截图与扫描结果 | 安全与运维代表 | 是 |
性能结论以本次实测为准，不引用未经核实的认证结论或厂商宣传数据。连续运行观察期长度由组织根据上线风险确定，观察期内出现的异常退出要记录时间、现象和处理结果，不能只写“已处理”。
运维、回退与阻断项完成条件
上线前要确认运维手段和回退路径真实可用。备份与恢复应做一次演练，从备份恢复到可用状态并验证数据可读；监控告警要在目标环境中实际触发一次，确认通知能到达值班人；回退方案要写明触发条件、操作步骤、预计耗时和责任人。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 备份与恢复演练 | 按方案完成恢复，恢复后数据可验证 | 演练记录与恢复后校验结果 | 平台管理员 | 是 |
| 监控告警 | 关键指标可采集，告警可触发并送达 | 告警触发截图与通知记录 | 安全与运维代表 | 是 |
| 日志采集 | 平台日志进入统一采集，可检索 | 日志平台检索截图 | 安全与运维代表 | 否 |
| 回退方案 | 触发条件、步骤、耗时、责任人明确 | 回退方案文档与确认记录 | 信创环境负责人 | 是 |
阻断项指影响核心研发流程、数据完整性或安全合规的未通过项。典型包括：核心流程无法走通、迁移数据不一致、统一认证失败、备份无法恢复、回退方案缺失。阻断项须关闭并复验，复验记录写明复验人、复验时间和结果，之后才能进入上线切换。非阻断项可列入遗留问题，但要有责任人和计划完成时间。
验收过程中的检查结果、阻断项状态和遗留问题，如果分散在邮件和表格里，容易出现状态不同步。可以在ONES中为每个检查项建立工作项，记录结论、证据附件、负责人和复验时间，阻断项用状态字段控制流转，验收负责人按看板汇总各阶段进度。这样签字前的结论汇总直接来自工作项记录，减少人工对表。
验收结论与签字确认
结论汇总按阶段给出“通过、有条件通过、不通过”三种结论，并附遗留问题清单。有条件通过要写明条件内容、责任人和复验时点；不通过要写明原因和重新验收的计划时间。汇总表与各阶段检查表一并归档，归档位置在验收方案中提前约定。
| 汇总项 | 填写内容 | 确认人 |
|---|---|---|
| 阶段结论 | 六个阶段各自的结论与依据 | 验收负责人 |
| 阻断项关闭情况 | 阻断项编号、关闭时间、复验结果 | 验收负责人 |
| 遗留问题 | 问题描述、责任人、计划完成时间 | 对应模块负责人 |
| 签字与归档 | 签字人、签字日期、归档位置 | 信创环境负责人 |
签字确认意味着验收范围内的检查项已有结论和证据支撑，遗留问题已有安排。有条件通过的，在约定复验时点完成复验并更新结论；复验仍未通过的，按不通过处理并重新排期。验收记录建议保留到下一次平台重大变更，便于回溯当时的适配基线与判断依据。
常见问题
验收时发现某项检查在目标环境中无法执行，应该怎么记录？
先判断无法执行的原因属于环境未就绪、方案未覆盖还是操作条件不具备。属于环境未就绪的，记录当前状态、阻塞原因和预计就绪时间，该项按“不通过”处理；属于方案未覆盖的，由验收负责人确认是否纳入本次范围，纳入的走变更记录，不纳入的写入范围外项。结论栏只填通过、不通过、不适用三种，不适用要写明理由，避免用“待定”长期挂起。
试运行前初检通过，上线切换前还需要重新检查哪些内容？
试运行前的初检主要覆盖基础环境、平台部署和核心流程，上线切换前需要补齐集成与数据、性能与稳定性、运维与回退三部分，并对初检中标记为不通过或带条件通过的项做复验。试运行期间发生过配置变更、版本升级或数据迁移的，相关检查项应重新执行并更新证据，不能沿用变更前的记录。
阻断项关闭后由谁复验，复验记录要写什么？
复验由原检查项的负责人执行，验收负责人确认结果。复验记录写明阻断项编号、原不通过原因、处理措施、复验时间、复验人和复验结果，并附新的证据位置。复验仍不通过的，按不通过处理并重新排期，不能以“已处理”作为关闭依据。涉及多个阶段的阻断项，复验时同步检查关联阶段是否受影响。
性能阈值在验收阶段才提出，怎么处理？
阈值应在适配方案阶段与业务方约定，验收时直接对照。如果验收阶段才提出，先由业务方、平台管理员和验收负责人共同确认阈值口径，包括并发数、操作类型、统计方法和观察时长，形成书面记录后再执行压测。未形成书面约定的指标，不作为阻断判定依据，可列入遗留问题跟踪。
验收记录和遗留问题用什么方式跟踪比较稳妥？
关键是让检查结论、证据和责任人保持同一份记录。可以用表格逐项登记，也可以在ONES中为每个检查项建立工作项，记录结论、证据附件、负责人和复验时间，阻断项用状态字段控制流转，验收负责人按看板汇总各阶段进度。无论用哪种方式，签字前的结论汇总都应直接来自这些记录，减少人工对表带来的状态不一致。
