研发平台私有化部署的上线验收报告，建议按“结论页+检查项清单+证据索引+确认签字”四部分组织：先写清验收范围、环境与版本、参与角色和总体结论，再用检查项表逐条记录部署完整性、功能可用性、性能与容量、安全与权限、备份恢复、监控告警、集成连通和文档交付，每条检查项对应证据编号、证据位置、验证方式和结果，最后由建设方、运维方、业务方分别确认签字，遗留问题单列并约定关闭时间。下面给出一套可直接复制填写的空白表格，并说明字段口径、必填范围、填写示例与模板维护方法。
要点总览（TL;DR）
- 上线验收报告按“结论页+检查项清单+证据索引+确认签字”四部分组织，检查项与证据通过证据编号关联，签字表对应总体结论中的遗留问题清单。
- 部署完整性、功能可用性、安全与权限、备份恢复、监控告警、文档交付为必填类别；性能与容量、高可用切换、容量规划按项目要求列为选填，不适用时保留行并写明理由。
- 检查项结果统一取“通过/不通过/不适用/待确认”，证据位置写到具体系统、目录、文件名或文档页码，避免只写“见截图”。
- 总体结论可写“带条件通过”，条件与遗留问题单列，记录影响范围、临时措施、责任人和计划关闭时间，由建设方、运维方、业务方分别签字确认。
- 模板按部署形态、对接系统清单和上线模块范围裁剪，验收后把新增检查项与暴露的问题回写模板，并记录版本变更。
可复制空白验收报告模板
以下表格可直接粘贴到文档工具中填写。报告主体由封面信息、总体结论、检查项清单、证据索引和签字确认五张表组成，检查项表与证据索引表通过“证据编号”关联，签字表与总体结论中的遗留问题清单对应。
表1 报告基本信息
| 字段 | 填写内容 |
|---|---|
| 项目名称 | |
| 验收环境（生产/预生产/灾备） | |
| 部署形态（单机/集群/高可用） | |
| 平台版本号 | |
| 验收日期 | |
| 验收范围（模块、用户范围、集成系统） | |
| 建设方 / 运维方 / 业务方代表 | |
| 报告编号与版本 |
表2 总体结论与遗留问题汇总
| 项目 | 填写内容 | ||||
|---|---|---|---|---|---|
| 检查项总数 / 通过 / 不通过 / 不适用 / 待确认 | |||||
| 总体结论（通过 / 带条件通过 / 不通过） | |||||
| 遗留问题数量 | |||||
| 遗留问题编号 | 问题描述 | 影响范围 | 临时措施 | 责任人 | 计划关闭时间 |
| YQ-01 | |||||
| YQ-02 |
表3 上线验收检查项清单
| 检查项编号 | 类别 | 检查内容 | 预期结果 | 验证方式 | 结果 | 证据编号 | 责任人 |
|---|---|---|---|---|---|---|---|
| JB-01 | 部署完整性 | ||||||
| GN-01 | 功能可用性 | ||||||
| QX-01 | 安全与权限 | ||||||
| BF-01 | 备份恢复 | ||||||
| JK-01 | 监控告警 | ||||||
| JC-01 | 集成连通 | ||||||
| WD-01 | 文档交付 | ||||||
| XN-01 | 性能与容量（选填） |
表4 证据索引
| 证据编号 | 对应检查项 | 证据类型 | 证据位置 | 采集人 | 采集时间 |
|---|---|---|---|---|---|
| ZJ-01 | JB-01 | ||||
| ZJ-02 | GN-01 | ||||
| ZJ-03 | QX-01 | ||||
| ZJ-04 | BF-01 |
表5 确认签字
| 角色 | 姓名 | 单位/部门 | 确认意见 | 签字 | 日期 |
|---|---|---|---|---|---|
| 建设方负责人 | |||||
| 运维方负责人 | |||||
| 业务方负责人 | |||||
| 安全/合规（如需） |
检查项字段说明与填写口径
同一份报告往往由建设方、运维方和业务方共同填写，字段口径不统一会导致结果无法复核。下表逐字段给出含义、取值和示例，填写时以本表为准。
| 字段 | 含义 | 取值与填写要求 | 示例 |
|---|---|---|---|
| 检查项编号 | 检查项的唯一标识 | “类别缩写-两位序号”，类别缩写固定，序号连续不跳号 | QX-03 |
| 类别 | 检查项所属验收维度 | 从部署完整性、功能可用性、安全与权限、备份恢复、监控告警、集成连通、文档交付、性能与容量中选取 | 安全与权限 |
| 检查内容 | 本次要验证的具体对象和动作 | 写清对象、动作和判定对象，避免“系统正常”这类无法验证的表述 | 验证普通成员账号无法访问管理员配置页面 |
| 预期结果 | 判定通过的标准 | 写成可观察的状态或数值，涉及指标时注明单位和口径 | 访问被拒绝并记录审计日志 |
| 验证方式 | 取得结论的手段 | 查看配置、执行操作、比对日志、抽样测试四类中选取，可组合 | 执行操作+比对日志 |
| 结果 | 本次验证结论 | 通过 / 不通过 / 不适用 / 待确认，四选一 | 通过 |
| 证据编号 | 指向证据索引的关联键 | 与证据索引表编号一一对应，一条检查项可对应多条证据 | ZJ-03、ZJ-04 |
| 责任人 | 执行验证并提交证据的人 | 写姓名和所属方，便于复核时追溯 | 张工（运维方） |
验证方式的选择依据检查对象的性质：配置类检查项适合“查看配置”并截图留存；业务流程类适合“执行操作”并记录操作路径；权限与安全类适合“执行操作+比对日志”，既看拦截结果也看日志是否留痕；性能与容量类适合“抽样测试”，需注明样本量、测试时段和统计口径。
结果取值需要统一判定口径。“通过”指实际结果与预期结果一致且有证据支撑；“不通过”指结果与预期不符，须同步登记遗留问题；“不适用”指该检查项在当前部署形态或业务范围内不存在，必须写明理由；“待确认”指本次未能完成验证，须写明责任人和计划完成时间，不能留空。
证据编号与证据位置遵循“一证据一编号、位置可直达”的规则。证据位置写到具体系统、目录、文件名或文档页码，例如“运维文档库/验收证据/2025-06-12/权限配置截图-01.png”，避免只写“见截图”或“已提供”。证据类型可标注为截图、配置文件、日志片段、测试记录、会议纪要或签字扫描件。
必填项与选填项的划分
报告基本信息和签字确认在任何项目中都必须完整填写，检查项则按部署形态和业务范围裁剪。裁剪的原则是：影响上线可用性和数据安全的检查项必填，与特定部署形态或性能目标绑定的检查项按项目要求列为选填。
| 类别 | 必填/选填 | 适用条件 | 不适用时的记录方式 |
|---|---|---|---|
| 报告基本信息、总体结论、签字确认 | 必填 | 所有项目 | 不适用裁剪 |
| 部署完整性 | 必填 | 所有项目 | — |
| 功能可用性 | 必填 | 所有项目，范围按本次上线模块确定 | — |
| 安全与权限 | 必填 | 所有项目 | — |
| 备份恢复 | 必填 | 所有项目，至少验证一次恢复流程 | — |
| 监控告警 | 必填 | 所有项目，至少覆盖服务存活与关键资源 | — |
| 集成连通 | 必填 | 存在对接系统（如统一身份认证、消息通知）时 | 无对接系统时整类标注不适用并说明 |
| 文档交付 | 必填 | 所有项目 | — |
| 性能与容量 | 选填 | 有明确性能指标或用户规模要求时 | 结果填“不适用”，注明“本期未约定性能指标” |
| 高可用切换 | 选填 | 采用集群或高可用部署形态时 | 单机部署时填“不适用”，注明部署形态 |
| 容量规划 | 选填 | 需要评估存储与并发增长时 | 填“不适用”，注明由运维另行评估 |
选填项标注“不适用”时，仍需保留该行记录和理由，不能直接删除行。保留记录的作用是让评审人看到该类检查已被考虑过，而非遗漏。若项目后期追加性能指标或改为高可用部署，可在模板中把对应选填项转为必填，并在版本记录中注明变更原因。
填写示例：一份完整的验收记录
以下示例为演示情景：某研发团队完成研发平台私有化部署，本期上线需求管理、迭代管理和文档协作三个模块，对接企业统一身份认证，采用单机部署。示例中的检查项与证据写法可直接套用到表3和表4。
| 检查项编号 | 类别 | 检查内容 | 预期结果 | 验证方式 | 结果 | 证据编号 | 责任人 |
|---|---|---|---|---|---|---|---|
| JB-02 | 部署完整性 | 核对生产环境各服务实例运行状态与版本号 | 全部服务运行正常，版本号与交付清单一致 | 查看配置 | 通过 | ZJ-05 | 李工（运维方） |
| GN-03 | 功能可用性 | 新建一个迭代并关联三条需求，走完状态流转 | 需求与迭代关联成功，状态按配置流转 | 执行操作 | 通过 | ZJ-06 | 王工（业务方） |
| QX-02 | 安全与权限 | 普通成员账号尝试访问管理员配置页面 | 访问被拒绝，审计日志记录该次访问 | 执行操作+比对日志 | 通过 | ZJ-07 | 张工（运维方） |
| BF-01 | 备份恢复 | 从最近一次备份恢复到测试环境并抽查数据 | 恢复完成，抽查的需求与文档数据完整 | 执行操作+抽样测试 | 待确认 | ZJ-08 | 李工（运维方） |
对应的证据索引记录写法如下：ZJ-05 为截图，位置“运维文档库/验收证据/2025-06-12/服务状态截图-01.png”；ZJ-06 为操作记录，位置“验收记录表/功能验证/GN-03-迭代流转记录”；ZJ-07 为日志片段，位置“日志归档/2025-06-12/audit-access.log 第 120–135 行”；ZJ-08 为测试记录，位置“验收记录表/备份恢复/BF-01-恢复抽查记录”，因恢复演练安排在验收会后，结果暂记“待确认”，责任人为李工，计划完成时间为验收会后三个工作日内。
总体结论示例：检查项共 32 项，通过 29 项，待确认 1 项，不适用 2 项（性能与容量、高可用切换，理由分别为本期未约定性能指标、采用单机部署）。总体结论为“带条件通过”，条件为 BF-01 恢复抽查在约定时间内完成并补充证据。遗留问题登记一条：YQ-01，备份恢复抽查未在验收当日完成，影响范围为灾备能力确认，临时措施为保留最近一次全量备份并每日增量备份，责任人为李工，计划关闭时间为验收会后第三个工作日。三方代表在表5签字确认该结论及条件。
当检查项和证据数量较多时，报告文档本身适合作为归档载体，检查项的执行状态和遗留问题则需要持续跟踪。ONES Wiki 支持记录页面版本并随时查看与回滚，可作为验收报告与证据文档的版本留存位置；遗留问题可以登记为工作项，按责任人和计划关闭时间跟进，关闭后再回写报告结论。是否采用这类方式，取决于团队已有的文档与事项管理习惯。
模板的调整与维护方法
模板的价值在于跨项目复用，前提是每次验收后把新增检查项和暴露的问题回写到模板中。建议指定一名模板维护人，负责版本记录和裁剪规则的解释。
按部署规模与业务范围增删检查类别的原则：单机部署可省略高可用切换类，集群或高可用部署则将其转为必填并补充切换验证；对接系统越多，集成连通类的检查项越细，每个对接系统至少一条；上线模块范围变化时，功能可用性类按模块增删检查项，编号保持连续。新增检查项追加在对应类别末尾，不复用已删除的编号。
检查项编号体系随模板版本管理。模板版本号与报告编号分开记录，模板每次调整递增次版本号，检查类别或编号规则变化时递增主版本号。版本记录表建议包含以下字段：
| 模板版本 | 调整日期 | 调整内容 | 调整原因 | 维护人 |
|---|---|---|---|---|
| V1.0 | 初始版本 | |||
| V1.1 |
验收后遗留问题的跟踪与模板回写同步进行：遗留问题关闭时，判断其是否暴露了模板缺失的检查项，若是则在下次验收前补入模板并记录版本；若问题源于检查方法不当，则修订对应检查项的验证方式说明。下次验收复用模板时，重点核对四项更新检查点：部署形态是否变化、对接系统清单是否变化、性能与容量指标是否新约定、上一轮遗留问题是否已全部关闭。核对完成后更新报告基本信息表中的版本号与验收范围，再开始填写检查项。
常见问题
验收当天无法完成的检查项，报告里应该怎么记？
结果填“待确认”，并在同一行或备注中写明未完成原因、责任人和计划完成时间，不能留空。总体结论可写“带条件通过”，把该检查项对应的条件写进遗留问题清单，例如恢复演练安排在验收会后完成，则登记问题编号、影响范围、临时措施和关闭时间。条件完成并补充证据后，再更新报告结论和证据索引，保留原记录以便追溯。
证据数量很多时，报告正文和证据文件如何分工？
报告正文保留检查项表、证据索引和结论，证据文件本身按编号归档到统一位置，索引中写清证据类型、位置、采集人和采集时间。这样评审人先看索引定位，再按位置调取原始截图、日志或测试记录。证据文件较多时，建议按验收日期和检查类别分目录存放，目录结构与证据编号规则保持一致，便于后续复查和跨项目复用。
单机部署的项目，高可用切换和性能容量类检查项还要写吗？
保留行记录，结果填“不适用”，并写明理由，例如“采用单机部署”“本期未约定性能指标”。保留记录让评审人看到该类检查已被考虑过，而非遗漏。若项目后期改为集群部署或追加性能指标，可在模板中把对应选填项转为必填，并在版本记录中注明变更原因。
验收报告和遗留问题如何持续跟踪，避免签完字就搁置？
签字确认只代表验收结论成立，遗留问题仍需按责任人和计划关闭时间跟进。可以把遗留问题登记为工作项，关闭时回写报告结论，并判断是否暴露了模板缺失的检查项。报告文档本身需要版本留存，ONES Wiki 支持记录页面版本并随时查看与回滚，可作为验收报告与证据文档的存放位置；是否采用取决于团队已有的文档与事项管理习惯。
多个项目复用同一份模板，检查项编号怎么管理？
检查项编号采用“类别缩写-两位序号”，类别缩写固定，序号在类别内连续。模板调整时新增检查项追加在对应类别末尾，不复用已删除的编号，避免历史报告中的编号指向发生变化。模板版本号与报告编号分开记录，模板每次调整递增次版本号，检查类别或编号规则变化时递增主版本号，并在版本记录表中写明调整内容、原因和维护人。
