研发平台上线验收标准要能直接回答“这次部署能不能上线”。制定时先锁定验收对象为私有化部署落地结果，再按环境准备、部署与配置、数据与权限、集成与性能、安全与运维交接五个阶段列出检查项，每项写清通过标准、证据形式、负责人和检查时点，并把影响上线决策的项标为阻断项。这样形成的清单可以在上线前评审会上逐项判定，也能在上线后观察期复核。
要点总览（TL;DR）
- 验收对象锁定为私有化部署落地结果，业务配置治理不纳入清单，避免标准被拉长成上线后治理文档。
- 检查项按环境准备、部署与配置、数据与权限、集成与性能、安全与运维交接五个阶段排列，每项写清通过标准、证据、负责人、时点和是否阻断。
- 通过标准要包含可观察结果或可复现操作，例如重启后健康检查返回正常；性能、权限、备份等条目需给出阈值或抽样方法。
- 证据由实施方提交、运维与安全复核、业务方确认，提供证据与确认证据的角色分开，证据缺失按不通过处理。
- 阻断项未关闭即不给出上线结论；非阻断项限期整改并纳入观察期，验收记录归档后视为完成。
谁在什么时点使用这份验收清单
这份清单的验收对象是研发平台私有化部署的落地结果，包括环境是否就绪、服务是否可用、数据与权限是否正确、集成是否连通、运维是否完成交接。业务配置与治理规则（例如项目模板怎么设计、字段怎么规范）属于上线后的运营工作，不纳入本文的验收范围，避免清单被拉长成一份无法在上线前完成的治理文档。
清单由五类角色共同使用，各自承担不同的判定责任：
| 角色 | 部署完成自检 | 上线前评审 | 上线后观察期复核 |
|---|---|---|---|
| 实施方 | 逐项执行检查并提交证据 | 现场说明未通过项与整改计划 | 配合处理观察期发现的问题 |
| 平台运维 | 复核环境、部署与运维类证据 | 确认运维交接完成、监控告警生效 | 跟踪告警与容量表现 |
| 安全与合规 | 检查认证、密钥、高危安全问题 | 确认安全类阻断项已闭环 | 复核观察期安全事件 |
| 业务方代表 | 参与集成连通性与关键流程验证 | 确认业务可用性满足上线要求 | 反馈实际使用中的阻断问题 |
| 项目负责人 | 组织自检、汇总结果 | 主持评审并签署上线结论 | 决定是否触发回退 |
三个使用时点的判定口径应保持一致：自检阶段由实施方给出初判，评审阶段由复核角色确认或推翻，观察期复核只针对上线时遗留的非阻断项和运行表现。清单的填写方式是逐项标记“通过 / 不通过 / 不适用”，不适用项必须写明理由并经项目负责人确认，不能留空。
分阶段检查项：从环境准备到运维交接
下表给出可直接勾选的分阶段检查表。检查项按部署落地顺序排列，同一阶段内的项目可以并行执行，但阶段之间的阻断项应在前一阶段关闭后再进入下一阶段。
| 阶段 | 检查项 | 通过标准 | 证据 | 负责人 | 时点 | 阻断 |
|---|---|---|---|---|---|---|
| 环境准备 | 服务器资源与规格符合部署方案 | CPU、内存、磁盘、节点数量与方案一致，资源余量满足约定比例 | 资源清单、云平台截图 | 实施方提供，运维复核 | 自检 | 是 |
| 环境准备 | 网络连通与端口开放 | 各节点之间、节点与客户端之间按方案要求的端口可连通，防火墙规则已生效 | 连通性测试命令输出 | 实施方 | 自检 | 是 |
| 环境准备 | 操作系统与依赖组件版本符合要求 | 操作系统、容器运行时、数据库等版本在支持清单内，版本号可查 | 版本查询命令输出 | 实施方 | 自检 | 是 |
| 环境准备 | 域名解析与证书配置 | 访问域名解析正确，证书在有效期内且与域名匹配，浏览器访问无证书告警 | 访问截图、证书信息截图 | 实施方 | 自检 | 是 |
| 环境准备 | 备份与回滚环境就绪 | 备份存储可用、回滚所需镜像或快照已准备，回滚步骤经演练可执行 | 备份任务记录、回滚演练记录 | 运维 | 自检 | 是 |
| 部署与配置 | 安装步骤可复现 | 按部署文档从零执行可完成安装，步骤与实际操作一致，无未记录的临时操作 | 部署记录、修订后的部署文档 | 实施方 | 自检 | 是 |
| 部署与配置 | 配置文件与密钥管理 | 配置文件纳入版本管理，密钥不写入明文配置，密钥存放位置与访问权限已登记 | 配置清单、密钥登记表 | 实施方提供，安全确认 | 评审 | 是 |
| 部署与配置 | 版本与补丁记录 | 部署的产品版本、组件版本、已打补丁均有记录，与交付清单一致 | 版本清单 | 实施方 | 评审 | 否 |
| 数据与权限 | 初始数据导入 | 组织、用户、基础数据按约定范围导入，抽样核对数量与内容一致 | 导入日志、抽样核对记录 | 实施方提供，业务方确认 | 自检 | 是 |
| 数据与权限 | 账号与角色配置 | 管理员账号可用，角色权限按方案配置，抽样账号的实际权限与设计一致 | 权限配置截图、抽样验证记录 | 实施方提供，业务方确认 | 评审 | 是 |
| 数据与权限 | 认证方式对接 | 企业统一认证（如 LDAP）对接后，测试账号可正常登录，禁用账号无法登录 | 登录测试记录 | 实施方提供，安全确认 | 评审 | 是 |
| 集成与性能 | 代码仓库与 CI/CD 连通 | 平台可读取代码仓库信息，流水线状态可回传，失败场景有明确提示 | 集成测试记录、截图 | 实施方提供，业务方确认 | 评审 | 是 |
| 集成与性能 | 消息通知可达 | 测试消息可送达约定渠道，通知内容包含必要字段 | 通知截图 | 实施方 | 自检 | 否 |
| 集成与性能 | 并发与响应基线 | 按项目约定的并发数压测，响应时间与错误率在约定阈值内 | 压测报告 | 实施方提供，运维复核 | 评审 | 是 |
| 安全与运维 | 日志与监控接入 | 平台日志进入统一日志系统，关键指标可在监控面板查看 | 监控面板截图、日志查询结果 | 运维 | 评审 | 是 |
| 安全与运维 | 告警规则生效 | 服务不可用、磁盘不足等关键告警已配置，并通过模拟触发验证可送达 | 告警触发记录 | 运维 | 评审 | 是 |
| 安全与运维 | 备份恢复演练 | 从备份恢复至测试环境后，核心数据与服务可用，恢复耗时记录在案 | 恢复演练报告 | 运维 | 评审 | 是 |
| 安全与运维 | 运维文档交接 | 部署架构、日常巡检、故障处理、升级流程文档齐全并完成讲解 | 文档清单、交接签字单 | 实施方提供，运维确认 | 评审 | 否 |
表中“阻断”列标注为“是”的项目，未关闭即不能给出上线结论；“否”的项目可以限期整改，但必须登记责任人与完成期限。性能基线、并发数等阈值需要在项目启动时与业务方约定，不能等到评审会上临时确定。
每项检查的通过标准怎么写才可判断
通过标准的写法底线是：换一个人拿着标准去检查，能得出相同结论。满足这一点的标准通常包含可观察的结果或可复现的操作，例如“重启服务后健康检查接口返回正常，且 5 分钟内无异常日志”，而不是“服务运行稳定”。
以下对照可以帮助判断一条标准是否合格：
| 不合格写法 | 问题 | 可判断的写法 |
|---|---|---|
| 系统性能优秀 | 无阈值、无测试方法 | 在 200 并发用户下持续压测 30 分钟，平均响应时间不超过约定值，错误率低于约定比例 |
| 权限配置合理 | “合理”无法判定 | 抽取 10 个不同角色账号，逐一核对可见菜单与操作权限，与权限设计表一致 |
| 备份正常 | 未说明验证方式 | 从最近一次备份恢复至测试环境，核心数据条数与源环境一致，恢复过程有记录 |
| 文档齐全 | 未列文档范围 | 部署架构、巡检、故障处理、升级四类文档齐备，运维人员按文档完成一次巡检 |
标准中还要处理两类特殊情况。一是必须满足与可接受偏差的区分：核心服务可用、认证可用属于必须满足；界面个别文案不一致、非关键报表样式差异可以列为可接受偏差，但需记录偏差内容、处理计划和责任人。二是不适用项的判定：某项检查在当前部署方案中确实不存在对应对象时，由实施方提出理由，项目负责人审批后标记为不适用，并在评审记录中保留说明。
证据形式与负责人如何分配
验收结论要经得起事后追溯，每项检查都应留下可复核的证据。证据优先选择能直接反映检查结果的原始材料，避免只留一句“已确认”。
- 截图：用于界面状态、配置结果、监控面板等可视化结果，截图需包含时间与访问地址。
- 命令输出：用于版本查询、连通性测试、资源规格核对，保留完整输出而非截取片段。
- 日志片段：用于服务启动、集成调用、告警触发等过程性结果，标注时间范围与查询条件。
- 测试报告：用于性能压测、备份恢复演练，包含测试方法、数据与结论。
- 配置清单与签字确认单：用于配置项登记、文档交接、业务方确认。
证据统一存放在项目约定的共享位置，按“阶段-检查项编号-日期”命名，评审时按清单顺序逐项调取。负责人分配遵循一条原则：提供证据的人与确认证据的人分开。实施方负责提交执行证据，平台运维复核环境与运维类证据，安全与合规确认认证、密钥与高危问题，业务方代表确认集成与业务可用性，项目负责人对整体结论签字。
证据缺失时不能默认通过。处理方式是：能当场补测的当场补测并留存证据；无法当场补测的，该项按不通过处理，登记补测计划与期限，若属于阻断项则直接推迟上线结论。
阻断项与上线完成条件
阻断项的判断标准是：该项不通过时，平台上线会直接影响可用性、数据安全或核心业务流转。典型阻断项包括：核心服务不可用或频繁重启；认证与权限异常导致用户无法登录或越权访问；备份无法恢复；代码仓库、CI/CD 等关键集成中断；高危安全问题未闭环。这些项目在评审会上只要有一项未关闭，就不给出上线结论。
非阻断项的处理方式是限期整改并纳入观察期跟踪。每项非阻断项要写明责任人、完成期限和验证方式，观察期复核时逐项确认关闭。上线完成条件可以归纳为三条：阻断项全部关闭并有证据支撑；非阻断项均有明确责任人与期限；验收记录、证据与评审结论完成归档。
上线后观察期建议设定固定时长，复核内容包括服务可用性、告警触发情况、性能表现和遗留项整改进度。同时预先约定回退触发条件，例如核心服务连续不可用超过约定时长、出现数据损坏或高危安全事件，触发后由项目负责人决定是否执行回滚，回滚步骤以环境准备阶段演练过的方案为准。
当验收检查项、证据和阻断项需要在多个角色之间流转确认时，可以把清单落到协作工具中跟踪。ONES 支持私有部署方式，其私有化部署采用 K3s 容器化部署，并支持对接 LDAP 等企业内部系统；验收阶段可将每个检查项建为工作项，关联证据附件与负责人，阻断项未关闭时保持未完成状态，评审结论与遗留项处理计划记录在文档中，便于上线后观察期继续复核。
常见问题
验收清单里的性能阈值和并发数，应该在什么阶段确定？
性能阈值不宜等到上线前评审会才临时商定。建议在项目启动或部署方案确认阶段，由业务方、实施方和运维共同约定并发用户数、平均响应时间、错误率上限等口径，并写入验收标准。评审时按约定条件压测，报告中的测试方法、数据量和结论要与约定口径对应，否则结果无法用于判定通过与否。
某项检查在当前部署方案中没有对应对象，能否直接跳过？
可以标记为不适用，但要留下判定过程。由实施方说明该项为何不适用，项目负责人审批后在评审记录中保留说明，清单上标记“不适用”并附理由。直接留空或口头跳过会让验收记录出现缺口，观察期复核时也难以判断是遗漏还是确实不存在。
上线后观察期发现的问题，是否要重新走一遍验收？
通常不需要重走全部验收，观察期复核聚焦两类内容：上线时遗留的非阻断项是否按期关闭，以及服务可用性、告警、性能等运行表现是否稳定。若观察期内出现核心服务不可用、数据损坏或高危安全事件，按预先约定的回退触发条件处理，由项目负责人决定是否回滚，回滚方案以环境准备阶段演练过的版本为准。
验收检查项和证据分散在多个角色手里，怎么保证评审时能逐项调取？
关键是统一存放位置和命名规则。证据按“阶段-检查项编号-日期”命名，集中存放在项目约定的共享位置，评审时按清单顺序逐项调取。若希望检查项状态、证据附件和负责人流转在同一处跟踪，可以把每项检查建为工作项，关联证据并保持阻断项未完成状态。ONES 支持私有部署方式，私有化部署采用 K3s 容器化部署，并支持对接 LDAP 等企业内部系统，可作为验收跟踪的承载工具之一。
部署文档和实际操作不一致时，以哪个为准？
以实际可复现的操作结果为准，同时把文档修订到与操作一致。验收中“安装步骤可复现”这一项要求按部署文档从零执行能完成安装，若过程中出现未记录的临时操作，应补充进文档后再判定通过。文档与操作长期不一致，会影响后续升级、故障处理和运维交接。
