研发平台上线验收不通过，先不要签字放行。把不通过项按阻断项和一般项分级，逐条记录现象、复现步骤、期望与实际的差距，形成整改清单并明确责任人与期限；整改后按同一验收口径复验，阻断项全部关闭、一般项有书面处置结论，再签复验结论并约定上线后的观察期。本文聚焦平台部署落地相关的验收问题，业务配置与治理问题另行处理。
要点总览（TL;DR）
- 验收不通过先冻结放行，把不通过项按阻断项与一般项分级，逐条记录现象、复现步骤、发生环境、影响范围和发现时间。
- 每条不通过项先建立原因假设并收集日志、截图、复现记录、环境比对等证据，区分已证实原因与待验证假设，再决定走整改、缺陷还是裁决路径。
- 阻断项停止上线、整改后必须复验；一般项可带条件上线，写明遗留项、责任人与关闭时间；争议项依据验收标准原文由双方负责人书面裁决。
- 复验沿用与原验收相同的用例、环境和判定口径，阻断项全部关闭、一般项有书面结论后再签复验通过，并约定上线后的观察期。
- 复盘不通过原因，把量化指标、对接清单等补进验收检查项，减少同类问题在下次验收中复发。
验收不通过时先确认哪些症状与范围
验收不通过很少是“全部不行”或“全部可以”这么简单。第一步是把结论拆开：哪些条目直接阻止上线，哪些条目可以带着条件放行。这个判断决定了后续整改的优先级和资源投入，也决定了上线时间是否需要调整。
先把不通过的具体表现逐条写下来。常见的表现包括：功能未达预期，例如某个流程节点无法按设计流转；性能不达标，例如并发登录或批量导入的响应时间超出验收标准；部署环境异常，例如服务启动失败、依赖组件版本不匹配；文档或交付物缺失，例如部署手册、运维手册、接口说明未交付；验收争议，即双方对某条结果是否算通过存在不同理解。
记录症状时，每条至少包含五项信息：现象描述、复现步骤、发生环境、影响范围、发现时间。现象描述写“看到什么”，不写“可能是什么原因”；复现步骤写到他人可以照着操作重现；发生环境注明是测试环境、预生产环境还是特定节点；影响范围说明影响哪些角色或哪些业务动作；发现时间用于后续判断问题是否在整改过程中新增。
接下来做分级。阻断项指不整改就无法上线的问题，通常包括核心功能不可用、数据安全或权限控制存在明显缺陷、部署环境无法稳定运行、关键交付物缺失导致运维无法接手。一般项指不影响基本运行、可以在上线后限期关闭的问题，例如个别非核心页面的显示异常、部分文档内容待补充、边缘场景的兼容性问题。分级建议由双方共同确认，避免实施方单方面把问题降级。
| 分级 | 典型表现 | 处置方向 |
|---|---|---|
| 阻断项 | 核心功能不可用、权限或数据隔离缺陷、环境无法稳定运行、关键交付物缺失 | 停止上线流程，整改后必须复验 |
| 一般项 | 非核心页面异常、文档待补充、边缘场景兼容问题 | 可约定带条件上线，写明遗留项、责任人和关闭时间 |
范围也要划清。本文处理的是平台部署落地相关的验收问题，包括环境、部署、集成对接、交付物和验收口径。业务侧的流程配置是否合理、权限体系如何治理、数据标准如何统一，属于另一类问题，应另行组织评审，不混入本次部署验收的整改清单，否则清单会越滚越大，责任边界也会模糊。
完成这一步的交付物是一份按阻断/一般分级的不通过项症状清单。清单确认后即冻结放行，任何“先上线再说”的口头提议都应回到清单上逐条讨论。
逐条判断原因并收集排除证据
症状清单只是起点。每条不通过项都需要从“看到的现象”推进到“可验证的原因假设”，再判断这个假设是否成立。原因判断的价值在于：环境问题修环境，配置问题改配置，产品缺陷走缺陷流程，标准理解偏差则回到验收标准本身。四类问题的处置路径完全不同，判断错了会浪费整改时间。
为每条不通过项列出原因假设，并说明验证该假设需要什么证据。常见的原因分类包括：
- 部署环境与依赖不匹配：操作系统版本、中间件版本、网络策略、存储容量等与部署要求不一致。
- 参数配置错误：连接池、超时时间、域名与证书、单点登录对接参数等配置项填写有误。
- 版本或补丁缺失：部署包版本与验收约定版本不一致，或缺少约定的修复补丁。
- 验收标准本身表述不清：标准写的是“响应及时”，但没有给出具体指标和测量方法。
- 测试方法或数据问题：测试数据构造不符合真实场景，或测试步骤与标准规定的操作不一致。
证据形式要与假设对应。日志用于判断服务端是否报错以及报错类型；截图用于固定界面现象；复现记录用于证明问题可稳定重现；环境比对用于确认测试环境与约定环境的差异；标准原文条款用于判断争议项到底按哪条口径验收。证据收集时注意保留时间戳和环境标识，避免后续复验时无法对照。
| 不通过项 | 原因假设 | 验证证据 | 状态 |
|---|---|---|---|
| 示例：单点登录跳转失败 | 对接参数配置错误 / 企业目录服务网络不通 | 对接日志、网络连通性测试记录、配置项截图 | 待验证 |
| 示例：批量导入超时 | 数据量超出约定范围 / 服务端资源不足 | 导入数据量统计、服务端资源监控记录、验收标准中的性能条款 | 待验证 |
表格中的示例为演示情景，用于说明填写方式。实际使用时每条不通过项单独一行，状态栏区分“已证实原因”和“待验证假设”。已证实原因指有直接证据支撑、可以据此安排整改的判断；待验证假设指目前只有线索、还需要补充证据的判断。不要把猜测写成结论，也不要在证据不足时直接归因于产品缺陷。
对争议项，处理方式略有不同。先回到验收标准原文，核对双方对同一条款的理解是否一致；再对照测试证据，看实际结果与标准描述之间的差距在哪里。如果标准本身表述模糊，争议的实质是标准问题，应在裁决记录中明确本次按何种口径判定，并在后续验收标准中补充量化指标。
按不通过类型安排处置步骤
原因明确后，处置按类型分开走。不同类型的问题有不同的停止点、责任人和验证方式，混在一起处理容易遗漏。
阻断项。停止上线流程，不做带病上线。为每条阻断项指定整改责任人和完成期限，整改内容写入整改清单。整改完成后必须复验，复验不通过则继续整改，直到关闭。阻断项的关闭需要证据支撑，例如修复后的复现记录显示问题不再出现。
一般项。可以约定带条件上线。条件是：遗留项逐条列明，写明责任人、关闭时间和验证方式；上线范围不涉及遗留项影响的功能；双方对带条件上线形成书面确认。带条件上线不等于问题消失，关闭时间到期后仍需复验。
环境或配置类问题。修正环境或配置后，重新执行对应的验收用例，而不是只做一次手工验证。重新执行的范围至少覆盖受影响的用例，必要时扩大到关联用例，确认修改没有引入新的问题。
产品缺陷类问题。提交缺陷单，记录现象、复现步骤、影响范围和期望结果，跟踪修复版本。修复版本部署后执行回归验证，回归范围包括原缺陷用例和相邻功能用例。
争议项。由双方负责人依据验收标准原文和测试证据书面裁决，形成会议纪要或裁决记录，写明裁决结论、依据条款和后续动作。口头承诺不替代书面结论，裁决记录作为验收档案的一部分留存。
涉及数据或环境变更的整改操作，执行前先备份，并约定回退方式。回退方式要写清楚触发条件、操作步骤和责任人，避免整改过程中出现新问题时无法快速恢复。
| 不通过类型 | 处置动作 | 责任人 | 停止点 |
|---|---|---|---|
| 阻断项 | 停止上线，整改后复验 | 整改责任人 + 验收方 | 复验通过前不放行 |
| 一般项 | 带条件上线，限期关闭 | 遗留项责任人 | 关闭时间到期未关闭则升级处理 |
| 环境/配置类 | 修正后重跑对应用例 | 实施工程师 | 用例重跑通过 |
| 产品缺陷类 | 提交缺陷单，修复后回归 | 产品/研发接口人 | 回归验证通过 |
| 争议项 | 依据标准书面裁决 | 双方负责人 | 裁决记录签署 |
处置过程中，不通过项的状态需要持续可见：谁在处理、处理到哪一步、预计何时关闭。在ONES中，这类整改项可以作为工作项统一登记，关联责任人、期限和证据附件，复验记录与裁决纪要可以放在对应文档中，便于验收双方按同一份清单核对进度。ONES支持私有部署和公有云部署，私有化部署采用 K3s 容器化部署，支持对接企业内部系统（如 LDAP），这些部署方式与验收阶段的环境核对、集成对接检查直接相关。
复验通过与复发预防怎么验证
整改完成不等于验收通过，复验才是判定环节。复验的核心要求是口径一致：使用与原验收相同的用例、相同的环境和相同的判定标准。口径漂移是复验阶段最常见的问题，例如原验收在预生产环境执行，复验却在测试环境执行；原标准要求并发一百用户响应在三秒内，复验时改成五十用户。口径一变，结论就失去可比性。
复验执行时，逐条对照整改清单：阻断项是否全部关闭，关闭证据是否齐全；一般项的遗留项是否有书面处置结论，责任人和关闭时间是否明确；争议项是否已有裁决记录并执行到位。复验结论要写明关闭项清单、遗留项清单及各自处置结论，由双方确认后签署。
通过判定标准可以归纳为三条：阻断项全部关闭并有证据；一般项全部有书面处置结论；复验使用的用例、环境和判定口径与原验收一致。三条同时满足，才签署复验通过。任何一条不满足，复验结论应写明未通过项和下一步安排，不签“原则通过”这类模糊结论。
上线后设置观察期。观察期长度根据平台影响范围约定，观察指标包括核心功能可用性、关键接口响应情况、异常日志数量、用户反馈的问题数量。同时约定异常上报路径：谁接收、多久响应、什么情况下触发回退。观察期内出现与原不通过项同类的问题，按缺陷流程处理并记录。
最后做一次复盘。把本次不通过的原因归类，看哪些属于验收标准表述不清、哪些属于环境准备不足、哪些属于集成对接遗漏，据此补充验收检查项和标准条款。例如性能类标准补充具体指标和测量方法，集成类标准补充对接清单和验证步骤。复盘产出的检查项进入下一次验收的模板，同类问题就不容易重复出现。
对于采用高可用集群部署的场景，复验时还应确认故障转移、数据容灾等架构相关项是否按约定验证过。ONES的高可用集群部署基于高可用架构运行，可实现故障转移、数据容灾、零停机服务升级，这类能力是否纳入本次验收范围，应在验收标准中事先写明，复验时按同一口径核对。
常见问题
验收不通过但业务上线时间已经定了，能不能先上线再补整改？
能否带条件上线，取决于不通过项的分级。阻断项涉及核心功能不可用、权限或数据隔离缺陷、环境无法稳定运行、关键交付物缺失，这类问题应先停止上线流程，整改并复验后再放行。一般项可以约定带条件上线，前提是遗留项逐条列明，写明责任人、关闭时间和验证方式，上线范围不涉及遗留项影响的功能，并由双方书面确认。把阻断项当作一般项处理，等于把风险带到生产环境，后续排查成本更高。
双方对某条验收结果是否算通过争执不下，怎么裁决？
先回到验收标准原文，核对双方对同一条款的理解是否一致，再对照测试证据看实际结果与标准描述的差距。如果标准本身表述模糊，例如只写“响应及时”而没有量化指标，争议的实质是标准问题。此时由双方负责人依据标准原文和证据书面裁决，形成会议纪要或裁决记录，写明裁决结论、依据条款和后续动作，并作为验收档案留存。口头承诺不替代书面结论，本次按何种口径判定也应写清楚，后续在验收标准中补充量化指标。
整改后复验，需要把原验收用例全部重跑一遍吗？
复验的核心是口径一致，使用与原验收相同的用例、环境和判定标准。实际操作中，至少覆盖受影响的用例，并视修改范围扩大到关联用例，确认修改没有引入新问题。环境或配置类问题修正后，应重新执行对应的验收用例，而不是只做一次手工验证。如果复验环境或判定标准与原验收不同，例如换了环境或调整了并发指标，结论就失去可比性，应在复验结论中说明差异及影响。
带条件上线的遗留项到期没关闭，应该怎么处理？
带条件上线时已经约定关闭时间和责任人，到期未关闭应触发升级处理，由双方负责人确认新的关闭计划，并评估遗留项是否已影响实际使用。如果影响范围扩大或出现同类新问题，应按缺陷流程处理并记录。遗留项的关闭同样需要证据，例如复现记录显示问题不再出现，关闭后在清单上更新状态，避免清单长期挂着未关闭项而失去跟踪意义。
验收不通过项和复验记录用什么方式跟踪比较稳妥？
关键是让不通过项的状态持续可见：谁在处理、处理到哪一步、预计何时关闭。常见做法是把整改项作为工作项统一登记，关联责任人、期限和证据附件，复验记录与裁决纪要放在对应文档中，验收双方按同一份清单核对进度。在ONES中，这类整改项可以作为工作项登记，复验记录与裁决纪要可放在对应文档中。ONES支持私有部署和公有云部署，私有化部署采用 K3s 容器化部署，支持对接企业内部系统（如 LDAP），这些部署方式与验收阶段的环境核对、集成对接检查直接相关。
上线后观察期一般看哪些指标，出现同类问题怎么办？
观察期长度根据平台影响范围约定，观察指标包括核心功能可用性、关键接口响应情况、异常日志数量、用户反馈的问题数量。同时约定异常上报路径：谁接收、多久响应、什么情况下触发回退。观察期内出现与原不通过项同类的问题，按缺陷流程处理并记录，作为复盘材料的一部分。对于采用高可用集群部署的场景，复验时还应确认故障转移、数据容灾等架构相关项是否按约定验证过，这类能力是否纳入验收范围应在验收标准中事先写明。
