研发平台上线验收要回答的核心问题是：这套私有化部署的环境能否稳定运行、安全可控、数据可用、出了问题能恢复，并且责任已经交到运维和业务方手里。本文按六个阶段给出一份可逐项核验的检查清单，每项写明通过标准、证据和负责人，并标出必须阻断上线的问题。业务配置规则的设计与治理不在本文范围内，只在移交阶段核验动作是否完成。验收项较多时，可以用 ONES 的工作项和文档承载检查记录与遗留问题闭环。
要点总览（TL;DR）
- 验收对象是私有化部署的研发平台环境本身，按基础设施、部署启动、账号安全、数据集成、备份运维、业务配置移交六个阶段逐项核验，业务配置规则治理不在本文范围。
- 每项检查写明通过标准、证据、负责人和阻断标记；通过标准写成可观察结果，证据限定为截图、日志片段、测试记录和签字确认，负责人落到岗位。
- 影响登录、数据完整性、安全基线或恢复能力的问题判为阻断项，整改复检通过后才能放行；其余问题可登记为带条件上线项，写明责任人和关闭期限。
- 上线完成条件是阻断项清零、带条件上线项全部登记、联合验收各方签字、检查表与证据归档，观察期结束后再做一次复核。
- 清单在部署完成自检、上线前联合验收、上线后观察期复核三个时点使用同一份表，避免自检与验收口径不一致。
谁在什么时点使用这份验收清单
这份清单的验收对象是私有化部署的研发平台环境本身，包括基础设施、平台组件、账号权限、数据与集成、备份恢复能力和运维交接状态。它不评价业务流程设计是否合理，也不覆盖业务配置规则的制定与治理，这些内容属于相邻主题，本文只在移交阶段确认边界。
参与验收的角色通常有四类：实施方负责部署执行与自检记录，运维负责人接收环境并确认可运维性，平台管理员负责账号权限与平台配置，业务方代表确认数据、集成和配置移交结果。角色可以兼任，但每项检查的负责人必须落到具体岗位。
清单在三个时点使用：部署完成后的实施方自检，逐项填写证据；上线前的联合验收，由各方共同确认阻断项是否清零；上线后观察期内的复核，检查带条件上线项是否按期关闭、运行是否出现新问题。三个时点使用同一份表，避免自检和验收口径不一致。
| 角色 | 部署完成自检 | 上线前联合验收 | 观察期复核 |
|---|---|---|---|
| 实施方 | 逐项执行检查并留存证据 | 解释未通过项与整改方案 | 完成遗留问题整改 |
| 运维负责人 | 参与基础设施与备份恢复项确认 | 确认可运维性并接收文档 | 反馈运行告警与故障处理情况 |
| 平台管理员 | 核对账号权限与平台配置 | 演示关键操作与审计查询 | 确认权限与配置稳定 |
| 业务方代表 | 确认数据与集成测试结果 | 签署配置移交确认单 | 确认业务使用无阻断问题 |
环境与基础设施阶段检查项
基础设施是后续所有检查的前提，这一阶段只核对资源与规划是否一致、依赖组件是否记录在案、网络通道是否真正开通。任何一项不满足，后续部署结果都不可信，因此本阶段问题原则上按阻断处理。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 服务器与存储资源 | CPU、内存、磁盘容量和节点数量与规划清单逐项一致，无临时借用资源 | 资源清单与现场核对截图 | 实施方 |
| 操作系统与数据库、中间件版本 | 实际版本记录在案，与实施资料要求的版本范围一致 | 版本查询命令输出或截图 | 实施方 |
| 域名、证书与端口 | 访问域名可解析，证书在有效期内，所需端口已开放且防火墙策略与清单一致 | 解析结果、证书有效期截图、策略导出 | 运维负责人 |
| 时间同步 | 各节点时间与统一时间源同步，偏差在约定范围内 | 时间同步状态截图 | 运维负责人 |
| 日志采集通道 | 平台日志可被采集端接收，在日志系统中能查到测试记录 | 日志检索结果截图 | 运维负责人 |
平台部署与启动阶段检查项
这一阶段确认平台各组件完成部署并能稳定启动，重点是可复现：换人按记录能说清部署了什么版本、改了什么参数。ONES 私有化部署采用 K3s 容器化部署方式，验收时应把容器与集群状态纳入检查范围。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 服务组件启动状态 | 全部组件处于运行状态，健康检查接口返回正常 | 组件状态列表与健康检查返回截图 | 实施方 |
| 部署版本与配置留档 | 安装包或部署脚本版本号、关键配置参数已记录，可据此复现部署 | 部署记录文档 | 实施方 |
| 重启恢复 | 按约定方式重启节点后，服务自动恢复且健康检查通过 | 重启前后状态截图与时间记录 | 实施方、运维负责人 |
| 部署日志检查 | 部署日志中的错误项已处理或已记录原因与影响 | 日志片段与问题记录 | 实施方 |
采用高可用集群部署时，还应增加节点故障转移的验证项，确认单节点异常后服务仍可用。具体切换时间和容灾指标以项目实施方案约定为准，验收时按约定值判断。
账号权限与安全阶段检查项
安全阶段的判断口径是：谁能登录、能做什么、做过的事能否追溯。三项都要有可演示的结果，不能只停留在配置说明。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 管理员账号与初始密码 | 初始密码已修改或按约定处置，管理员账号清单明确 | 账号清单与处置记录 | 平台管理员 |
| 身份源对接 | 与既有身份源（如 LDAP）对接后，测试账号可正常登录，异常账号被拒绝 | 登录成功与失败截图 | 平台管理员、实施方 |
| 角色与权限分配 | 按最小化原则分配，抽查若干角色确认权限范围与岗位职责一致 | 角色权限配置截图 | 平台管理员 |
| 审计日志 | 关键操作可在审计日志中查询，并能按条件导出 | 查询结果与导出文件 | 平台管理员 |
数据与集成连通阶段检查项
这一阶段验证的是真实可用性：数据导入后能查到、字段对得上，外部系统连接在成功和失败两种情况下都有符合预期的表现。只做一次成功调用不足以作为通过依据。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 初始数据与样例数据 | 导入记录数与源数据一致，抽样字段值正确 | 导入报告与抽样比对记录 | 实施方、业务方代表 |
| 外部系统连接 | 与代码仓库、流水线等系统的连接测试成功，凭据有效 | 连接测试结果截图 | 实施方 |
| 接口调用与回调 | 成功场景返回正确结果，失败场景有明确错误提示且不产生脏数据 | 接口测试记录 | 实施方 |
| 数据量与关键字段比对 | 总量核对一致，关键字段抽样比对无差异或差异已说明 | 比对表 | 业务方代表 |
备份恢复与运维交接阶段检查项
可运维性的判断依据是演练结果和文档移交，而不是口头承诺。备份没有做过恢复演练，只能算配置完成，不能算验收通过。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 备份策略与备份文件 | 备份按策略执行，备份文件存在且可读取 | 备份任务记录与文件清单 | 运维负责人 |
| 恢复演练 | 在测试环境完成一次恢复，恢复后数据可访问、关键数据完整 | 演练记录与恢复后核对结果 | 运维负责人、实施方 |
| 监控告警配置 | 约定的监控项已启用，告警能通过指定渠道送达 | 告警触发测试截图 | 运维负责人 |
| 文档移交 | 运维手册、部署文档、故障处理流程已交付并完成讲解 | 文档清单与签收记录 | 实施方、运维负责人 |
| 遗留问题清单 | 每个遗留问题有描述、责任人、关闭期限和影响说明 | 遗留问题清单 | 实施方 |
业务配置移交阶段检查项
本阶段只核验移交动作是否完成，不评价配置规则本身是否合理。配置规则的设计与治理属于相邻主题，验收时以边界确认为目标。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 业务配置清单 | 已配置的项目、空间、流程等对象列成清单，每项有对应责任人 | 配置清单 | 平台管理员 |
| 配置变更流程说明 | 业务方知晓后续配置变更的申请入口和审批方式 | 流程说明文档或培训记录 | 平台管理员、业务方代表 |
| 范围书面确认 | 业务方对本次移交的配置范围签字确认，未覆盖部分明确列出 | 移交确认单 | 业务方代表 |
通过标准、证据与负责人如何填写
检查表能否用起来，取决于每一栏是否可判断。填写时把握一条原则：换一个没参与实施的人拿着表，也能独立判断这一项是通过还是不通过。
- 通过标准写成可观察的结果，例如“健康检查接口返回正常”“重启后服务自动恢复且检查通过”“抽样 20 条记录字段值一致”。避免“运行良好”“配置合理”这类无法判断的表述。
- 证据限定为截图、日志片段、测试记录、签字确认四类，每项证据要能定位到具体时间或对象，便于归档和复核。
- 负责人写到岗位，例如“运维负责人”“平台管理员”，不写“相关同事”。同一项涉及两方时，写明主责与配合方。
- 不通过时在备注栏记录现象、影响和整改期限，整改完成后由原负责人复检并在同一行补充复检结论，不另起新表。
一行完整示例：检查项“重启恢复”，通过标准“重启应用节点后 10 分钟内全部组件恢复运行，健康检查接口返回正常”，证据“重启前后状态截图与时间记录”，负责人“实施方（主责）、运维负责人（配合）”，阻断标记“是”，备注“首次重启后一个组件未自动拉起，已修复并复检通过”。
验收项和遗留问题需要跨角色跟踪时，可以把每项检查建成 ONES 工作项，把截图、日志和确认单作为附件或文档关联，复检结论回写到同一工作项，形成从自检到关闭的记录链。
阻断项与上线完成条件
阻断项的判定聚焦四类影响：无法登录或身份对接失败，数据导入不完整或关键字段错误，安全基线不达标（如初始密码未处置、审计日志不可用），以及备份无法恢复。出现任一类问题，上线不予放行。
其余问题可以记录为带条件上线项，但必须写明影响范围、责任人和关闭期限，期限一般落在观察期内。带条件上线项数量过多时，应重新评估是否具备上线条件，避免把风险集中推到上线后处理。
| 判定结果 | 适用情形 | 处理方式 |
|---|---|---|
| 阻断 | 影响登录、数据完整性、安全基线或恢复能力 | 整改并复检通过后方可放行 |
| 带条件上线 | 不影响上述四类，且有明确影响范围和关闭计划 | 记录责任人、期限，观察期内关闭 |
| 通过 | 通过标准满足，证据齐全 | 归档证据，进入下一阶段 |
上线完成的条件是：阻断项清零，带条件上线项全部登记且有责任人和期限，联合验收各方在放行记录上签字，检查表与证据一并归档。观察期结束后做一次复核，确认带条件上线项已关闭、运行期间未出现新的阻断级问题，验收才算最终完成。
常见问题
验收清单里的检查项可以按项目情况增删吗？
可以增删，但增删要有依据并记录。基础设施、部署启动、账号安全、数据集成、备份恢复这几类检查项对应上线的基本条件，删减前应确认该项目确实不涉及相关对象，例如未采用高可用集群部署时，节点故障转移验证项可以不列入。增加检查项通常来自项目实施方案的特别约定，例如特定的容灾指标或对接系统清单，增补后同样要写明通过标准、证据和负责人。无论增删，最终清单应作为验收记录的一部分归档，便于观察期复核时对照。
实施方自检已经通过的项，联合验收时还要重新核验吗？
不必逐项重做，但要抽查并核对证据。联合验收的重点是确认自检结论可信：对阻断类检查项，验收方应现场查看证据或要求演示，例如登录验证、审计日志查询、恢复演练记录；对非阻断项，可按比例抽查，确认证据能定位到具体时间和对象。自检与验收使用同一份表，验收方在原有记录上补充确认结论，发现证据不足或结论不成立时退回整改并复检，避免出现两套口径。
观察期内出现新的阻断级问题，验收结论怎么处理？
应暂停验收结论，按阻断项流程处理。观察期复核的目的就是发现上线后暴露的问题，一旦出现影响登录、数据完整性、安全基线或恢复能力的问题，先记录现象、影响范围和发生时间，明确责任人与整改期限，整改完成后复检。复检通过后更新验收记录，并在复核结论中说明该问题的处理过程。若同类问题反复出现，应重新评估该阶段的通过标准是否写得不够具体，补充可观察的判断条件后再确认验收完成。
没有专职运维团队的小型项目，角色和时点怎么简化？
角色可以兼任，时点不宜合并。小型项目中实施方人员可能同时承担平台管理员职责，业务方代表也可能由项目负责人兼任，这种情况下在表中如实写明兼任关系即可，但每项检查仍要落到具体岗位或具体人。三个时点建议保留：部署完成自检用于留下证据，上线前联合验收用于确认阻断项清零，观察期复核用于关闭带条件上线项。若项目周期紧张，可缩短观察期长度，但复核动作本身应执行并留下记录。
验收记录和遗留问题用什么方式跟踪比较合适？
关键是让每项检查有唯一记录、复检结论能回写到同一处。可以用表格加共享文档的方式，按阶段分表，证据作为附件归档；验收项较多、涉及多方跟进的场景，可以把每项检查建成工作项，把截图、日志和确认单关联到对应工作项，复检结论回写后关闭。ONES 的工作项与文档能力可以承载这类检查记录和遗留问题闭环，具体使用方式按项目实际情况确定。无论采用哪种方式，放行前应能一次性导出完整清单和证据，供归档和后续复核使用。
