这份清单面向信创环境负责人、平台运维、测试负责人和研发流程代表，用于国产CPU与操作系统组合下研发平台的适配验收。适用时点包括适配环境搭建完成后、正式切换前，以及平台或系统版本升级后的复验。清单不预设任何CPU型号或平台版本已经适配，验收结论只来自本环境的实测证据；它解决的是”这套组合能不能稳定支撑研发工作”，不涉及工具替换或竞品选型决策。
要点总览（TL;DR）
- 验收按“环境基线—安装启动—核心研发流程—性能与稳定性—集成与数据—运维与回退”六个阶段推进，前一阶段阻断项未通过时不进入下一阶段功能验证。
- 每项检查都要写明通过标准、证据形式、负责人和检查时点；证据在检查完成时同步留存，按“阶段编号—检查项—环境标识—日期”归档。
- 阻断项包括平台无法安装或启动、核心流程不可用、数据丢失风险、无可用回退方案；阻断项全部通过且一般问题有整改责任人与期限，方可判定通过。
- 清单不预设任何CPU型号或平台版本已经适配，验收结论只来自本环境实测；工具替换与迁移决策不在本清单判定范围内。
- 检查项可建为工作项承载负责人、状态与证据，验收结论形成文档归档，供版本升级后的复验复用。
谁在什么时点使用这份验收清单
适配验收容易和工具替换混在一起讨论，导致检查项失焦。这份清单的边界是：在既定的国产CPU与操作系统组合上，验证研发平台能否完成日常研发流程并具备运维保障能力。是否更换平台、是否迁移历史数据，属于另一类决策，不在本清单的判定范围内。
使用时点有三个。第一，适配环境搭建完成、平台完成首次部署后，执行完整验收；第二，正式切换前，对阻断项做一次确认性复核；第三，平台版本、操作系统内核或关键中间件升级后，按本清单复验，重点覆盖安装启动、核心流程与集成对接。
| 角色 | 使用时点 | 主要职责 |
|---|---|---|
| 信创环境负责人 | 验收启动前、结论评审时 | 确认验收范围与环境基线，主持阻断项评审，签署最终结论 |
| 平台运维 | 安装部署后、运维与回退阶段 | 执行安装启动检查，提供日志与监控证据，完成备份恢复与回退演练 |
| 测试负责人 | 核心流程与性能阶段 | 设计并执行功能与性能用例，记录响应时间、并发结果与缺陷 |
| 研发流程代表 | 核心流程与集成阶段 | 以真实研发场景验证工作项流转、代码评审、流水线等流程可用性 |
| 集成对接人 | 集成与数据阶段 | 验证账号目录、消息通知、代码仓库、制品库等对接 |
验收前准备：环境基线与检查项
验收结论要可复验，前提是环境信息记录完整。缺少基线记录时，后续出现的异常无法判断是适配问题还是环境差异，复验也无从比对。建议在验收启动会上一次性登记以下字段，并由环境负责人确认。
- 硬件与系统：CPU型号与架构、内存与存储配置、操作系统名称及内核版本、关键依赖库版本（如C库、编译工具链）。
- 平台侧：研发平台版本、部署方式（单机、集群或容器化）、中间件与数据库版本、端口与网络策略。
- 测试资产：测试账号及权限清单、样例项目、样例代码仓库与制品、用于流程验证的工作项模板。
- 回退保障：回退环境是否就绪、备份是否完成并验证可恢复、回退操作步骤与责任人是否明确。
基线登记完成后，将本清单的检查项分配到人，约定每项的检查时点和证据提交方式，再开始逐项执行。基线表本身也是证据的一部分，随验收记录一并归档。
分阶段检查项与通过标准
验收按六个阶段推进，前一阶段的阻断项未通过时，不进入下一阶段的功能验证。下表中”阻断”列标注该项是否属于阻断项，判定规则见后文。
阶段一：安装与启动
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 平台安装 | 安装脚本或部署包在目标环境执行完成，无中断、无缺失依赖报错 | 安装日志、部署清单 | 平台运维 | 是 |
| 服务启动 | 全部核心服务进程处于运行状态，健康检查接口返回正常 | 服务状态截图、健康检查输出 | 平台运维 | 是 |
| 日志检查 | 启动日志中无阻断级错误；警告类信息已记录并说明影响 | 日志片段 | 平台运维 | 是 |
| 基础访问 | 通过浏览器可打开登录页，静态资源加载完整 | 页面截图 | 测试负责人 | 是 |
阶段二：核心研发流程
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 登录与权限 | 测试账号可正常登录，角色权限与预期一致 | 操作截图、权限对照表 | 测试负责人 | 是 |
| 项目创建 | 可创建项目并完成基本配置，成员可加入 | 项目页面截图 | 研发流程代表 | 是 |
| 工作项流转 | 需求、任务、缺陷可创建并按状态流转，字段与流程配置生效 | 工作项流转记录 | 研发流程代表 | 是 |
| 代码托管与评审 | 可推送代码、发起合并请求、完成评审与合并 | 仓库提交记录、评审页面截图 | 研发流程代表 | 是 |
| 构建流水线 | 样例项目可触发构建，构建成功并产出制品 | 流水线运行记录、制品清单 | 测试负责人 | 是 |
阶段三：性能与稳定性
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 关键操作响应 | 登录、打开工作项、加载代码页等操作在约定阈值内完成，阈值由团队按业务预期事先设定 | 测试记录、耗时数据 | 测试负责人 | 否 |
| 并发访问 | 按预期并发用户数压测，无服务崩溃或请求大面积失败 | 压测报告 | 测试负责人 | 是 |
| 连续运行观察 | 连续运行约定时长（如72小时），服务无异常退出，资源占用无持续恶化趋势 | 监控曲线、运行日志 | 平台运维 | 是 |
阶段四：集成与数据
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 账号目录对接 | 目录服务同步或单点登录可用，账号增删与平台一致 | 同步日志、登录截图 | 集成对接人 | 是 |
| 消息通知 | 邮件或即时消息通知可正常送达 | 通知截图 | 集成对接人 | 否 |
| 代码仓库对接 | 外部仓库可导入或双向同步，提交记录完整 | 同步记录 | 集成对接人 | 是 |
| 制品库对接 | 构建产物可推送至制品库并正确拉取 | 制品库记录 | 集成对接人 | 是 |
| 数据完整性 | 样例数据导入导出后字段、附件、关联关系无丢失 | 导入导出比对记录 | 测试负责人 | 是 |
阶段五：运维与回退
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 监控告警 | 核心服务指标可采集，告警规则可触发并送达 | 监控面板截图、告警记录 | 平台运维 | 否 |
| 备份恢复 | 完成一次备份并在测试环境成功恢复，数据可用 | 备份与恢复记录 | 平台运维 | 是 |
| 回退演练 | 按回退方案完成一次演练，可在约定时间内恢复至上一可用状态 | 演练记录、耗时数据 | 平台运维 | 是 |
证据留存与负责人分工
每项检查完成后立即留存证据，避免验收结束后补录。证据形式按检查类型区分：界面类检查用截图，服务与安装类检查用日志片段和命令输出，性能类检查用测试记录与压测报告，流程类检查用操作记录，结论类用签字确认单。
证据命名建议包含”阶段编号—检查项—环境标识—日期”，统一归档到验收文档库的同一目录下，并在检查表中登记证据位置。这样复验时可以按检查项直接定位历史证据，比对差异。
| 归口 | 负责的证据类型 | 签字确认范围 |
|---|---|---|
| 环境归口 | 环境基线登记表、部署配置记录 | 基线信息准确性 |
| 功能归口 | 核心流程操作截图、工作项与仓库记录 | 流程可用性结论 |
| 性能归口 | 响应时间数据、压测报告、稳定性监控 | 性能与稳定性结论 |
| 集成归口 | 对接日志、同步记录、数据比对结果 | 集成与数据完整性结论 |
| 运维归口 | 监控告警记录、备份恢复与回退演练记录 | 运维保障与回退能力结论 |
版本升级后的复验，需重新执行受影响阶段的检查项并更新对应证据；未受影响阶段的旧证据可保留，但要在检查表中注明沿用原因和原证据日期。
阻断项与验收完成条件
阻断项指直接导致平台无法支撑研发工作或带来数据风险的问题，出现任一项即判定本次验收不通过，整改后重新执行该项检查。一般问题指不影响核心流程的问题，可限期整改并在整改计划确认后放行。
| 类别 | 典型情形 | 判定处理 |
|---|---|---|
| 阻断项 | 平台无法安装或核心服务无法启动；登录、工作项流转、代码托管、构建等核心流程不可用；数据导入导出出现丢失或错乱；无可用回退方案或回退演练失败 | 验收不通过，整改后复验该项及相关联检查项 |
| 一般问题 | 界面显示异常、非核心功能受限、通知延迟、监控指标不完整 | 记录问题与整改期限，纳入整改计划后可判为有条件通过 |
整体判定规则：阻断项全部通过，且一般问题均有明确整改责任人与期限，方可判定通过；存在未关闭阻断项时判定不通过。验收完成的条件是检查表全部填写完毕、证据归档到位、各归口负责人签字确认，最终结论由信创环境负责人签署。
把验收清单落到协作流程里
清单要真正被执行，需要让每个检查项都有归属、有状态、有证据。可以把每个检查项建为一条工作项，填写负责人、检查时点、所属阶段和阻断标记，状态按”待检查—检查中—通过—不通过—已复验”流转。这样验收进度可以直接从工作项状态统计，而不依赖人工汇总表格。
证据随检查同步提交：截图、日志和测试记录作为工作项附件上传，或在验收文档中关联对应工作项编号。阻断项单独标记并在评审会上逐条确认，确认结论写入工作项评论，形成可追溯的处理记录。最终验收结论整理为文档，关联全部检查项后归档，后续版本复验时可直接复用这套结构与历史证据。
ONES 的工作项与文档能力可以承载这一流程：检查项作为工作项分配责任人与截止时间，证据以附件或文档关联，阻断项通过标记和评审记录跟踪，验收结论形成文档归档。对于需要按阶段查看进度的场景，可按阶段建立工作项视图，让环境、功能、性能、集成、运维各归口在同一处更新状态，减少验收过程中的信息分散。
常见问题
适配环境搭建完成后，第一次验收应该先做哪一步？
先完成环境基线登记，再开始逐项检查。基线要记录CPU型号与架构、操作系统及内核版本、依赖库版本、平台版本与部署方式、中间件与数据库版本，以及测试账号、样例项目和回退环境状态。基线信息确认后，把检查项分配到人并约定证据提交方式，然后从安装与启动阶段开始执行。缺少基线记录时，后续异常难以判断是适配问题还是环境差异，复验也无从比对。
性能指标没有事先约定阈值，验收时怎么判断？
响应时间类检查需要团队在验收前按业务预期设定阈值，清单本身不提供统一数值。建议在验收启动会上由测试负责人和研发流程代表共同确认关键操作的阈值，例如登录、打开工作项、加载代码页的完成时间，并写入检查表。并发用户数同样按预期使用规模设定。阈值一旦确定，测试记录和压测报告按该口径留存，复验时沿用同一口径比对。连续运行观察的时长也应在验收前约定，例如72小时。
平台版本或操作系统内核升级后，需要全部重验吗？
按受影响范围复验，不必每次全量重跑。升级涉及平台版本、操作系统内核或关键中间件时，重点覆盖安装启动、核心研发流程与集成对接三个阶段；性能与稳定性阶段在升级涉及运行时或资源调度变化时重新执行。未受影响阶段的旧证据可以保留，但要在检查表中注明沿用原因和原证据日期。复验完成后更新对应证据，并由各归口负责人重新签字确认受影响部分的结论。
一般问题较多时，能否先上线再整改？
可以判为有条件通过，前提是阻断项全部通过，且每个一般问题都有明确整改责任人与期限。界面显示异常、非核心功能受限、通知延迟、监控指标不完整这类问题，记录进整改计划后放行，并在计划到期时逐项关闭。存在未关闭阻断项时不能放行，需整改后重新执行该项检查及相关联检查项。最终结论由信创环境负责人签署，整改完成情况在复验时一并核对。
验收过程中的检查项和证据如何避免散落在多个表格里？
把每个检查项建为一条工作项，填写负责人、检查时点、所属阶段和阻断标记，状态按“待检查—检查中—通过—不通过—已复验”流转，验收进度直接从工作项状态统计。截图、日志和测试记录作为工作项附件上传，或在验收文档中关联工作项编号。阻断项单独标记并在评审会上逐条确认，结论写入工作项评论。最终验收结论整理为文档，关联全部检查项后归档，后续复验可直接复用这套结构与历史证据。ONES 的工作项与文档能力可以承载这一流程，按阶段建立工作项视图，让各归口在同一处更新状态。
