研发平台私有化部署上线验收不通过，原因通常集中在环境与基础设施、部署与配置、数据迁移与初始化、集成与网络连通、性能与容量、安全合规、验收口径与证据七类。本文按“症状归集—原因假设与排除证据—分批整改—同口径复验”的顺序展开，帮助实施与验收双方把“不通过”拆成可定位、可整改、可复核的问题。
要点总览（TL;DR）
- 验收不通过先拆成可定位的症状清单，再按环境与基础设施、部署与配置、数据迁移与初始化、集成与网络、性能与容量、安全合规、验收口径七类归因。
- 每个原因假设都要有验证方法和可留存证据，先排除环境与部署类问题，再排查数据、集成、性能与安全。
- 整改按阻断上线、影响体验、可延后三类排序，先修环境与配置，再处理数据与集成，最后调整性能与安全，每项整改保留备份与回滚点。
- 复验沿用原验收用例和通过标准，补充回归用例，逐项核对整改证据，遗留项写明风险接受人。
- 把本次问题沉淀为部署检查清单，并明确版本升级、扩容、网络与认证变更时的复测触发条件。
验收不通过时先界定症状与范围
拿到“验收不通过”的结论后，第一步是把结论还原成具体症状。验收报告上写“功能不可用”“性能不达标”只是结论，无法直接指导排查。需要逐条记录症状的表现形式、发生时间、所在环境、复现步骤和影响范围，形成一份按类别归集的症状清单。
典型表现可以归为五组：功能不可用，如登录失败、页面报错、关键流程中断；数据不一致，如迁移后条目缺失、字段错位、统计数与源系统对不上；性能不达标，如并发登录超时、列表加载缓慢；安全项缺失，如越权访问、审计日志为空、存在弱口令；文档与交付物不全，如部署手册、配置清单、迁移记录缺失。每组症状再对应到环境、部署、数据、集成、性能、安全、验收口径七类原因方向，为后续排查建立索引。
范围界定同样重要。本文处理的是平台部署落地相关问题，包括服务器资源、依赖版本、服务启动、网络连通、数据迁移、接口对接、容量与安全配置。业务流程配置是否合理、权限模型是否符合某部门管理习惯、字段设计是否贴合业务，属于业务配置治理问题，应另行组织评审，不混入部署验收的整改清单，否则会把技术问题和管理问题搅在一起，拖长整改周期。
症状记录建议包含以下字段，便于后续与原因假设一一对应：
- 症状编号与简述，例如“SSO 登录跳转后返回 502”；
- 发生环境，明确是测试环境、预生产环境还是验收环境；
- 发生时间与持续时长，是否可稳定复现；
- 复现步骤，从哪个入口进入、执行了什么操作；
- 影响范围，涉及哪些用户角色、哪些模块、是否阻断主流程；
- 初步归类，先归入七类中的一类，允许后续调整。
常见原因假设与排除证据
症状清单建立后，按类别提出原因假设，并为每个假设设计验证方法。关键原则是：假设只是排查方向，结论必须由证据支撑。下表给出七类原因的常见假设、验证方法和可留存证据，可作为排查时的对照表使用。
| 原因类别 | 常见假设 | 验证方法 | 可留存证据 |
|---|---|---|---|
| 环境与基础设施 | CPU、内存、磁盘不足；操作系统或依赖版本不符；时钟不同步；DNS 解析异常 | 查看资源监控曲线；核对版本清单；执行连通性与解析测试 | 监控截图、版本核对表、连通性测试记录 |
| 部署与配置 | 参数配置错误；服务未全部启动；证书过期或端口冲突 | 检查启动日志；比对配置文件与基线；端口探测 | 启动日志片段、配置比对结果、端口探测输出 |
| 数据迁移与初始化 | 数据缺失；字符编码不一致；初始化脚本未执行完 | 源库与目标库行数比对；抽样字段核对；校验和比对 | 数据比对报告、校验和记录、脚本执行日志 |
| 集成与网络 | 单点登录、代码仓库、消息通知等对接失败；防火墙策略拦截 | 调用接口并查看返回码；抓包分析请求链路 | 接口调用记录、抓包文件、防火墙策略核对单 |
| 性能与容量 | 并发下响应超时；连接池耗尽；慢查询拖累整体 | 按验收口径压测；查看慢查询日志与连接池监控 | 压测报告、慢查询日志、连接池监控数据 |
| 安全与合规 | 权限越权；审计日志缺失；存在弱口令 | 按权限矩阵逐角色核对；查看审计记录；执行口令扫描 | 权限核对表、审计日志样例、扫描报告 |
| 验收口径 | 用例与需求不一致；验收环境与生产环境存在差异 | 比对验收标准文档与需求文档；核对环境差异清单 | 标准比对记录、环境差异说明 |
排查时建议从阻断主流程的症状入手，先排除环境与部署类原因，因为这两类问题影响面大、验证成本低。例如登录失败，先确认服务进程是否全部启动、证书是否有效、端口是否可达，再排查账号数据与集成配置。数据类问题需要源系统与目标系统同时在场，比对行数、关键字段和校验和，避免只看抽样页面就下结论。集成类问题以接口调用记录为准，抓包能区分是平台侧未发出请求、网络层拦截，还是对端返回异常。
性能与安全类问题的证据要求更高。性能结论应来自与验收口径一致的压测数据，而不是单次页面访问感受；安全结论应来自权限矩阵核对和扫描报告，而不是抽查几个账号。验收口径类问题容易被忽略：同一功能在验收环境通过、在生产规格环境不通过，往往源于环境差异未在验收标准中写明。把这类差异单独记录，有助于复验时统一口径。
按风险分批整改的处置步骤
原因确认后，把问题转成整改任务，按风险排序而不是按发现顺序排序。建议分为三类：阻断上线类，如服务无法启动、核心流程不可用、数据大面积缺失；影响体验类，如部分页面加载慢、通知延迟、非核心集成不稳定；可延后类，如文档补充、个别报表格式调整。阻断类必须在上线前关闭，影响体验类给出整改时限和临时规避方案，可延后类纳入上线后迭代计划并明确责任人。
整改顺序上，先修环境与配置，再处理数据与集成，最后按验证结果调整性能与安全。原因是环境与配置问题会干扰其他类别的验证结果：资源不足时压测数据不可信，服务未全部启动时接口调用必然失败。数据与集成整改依赖稳定的运行环境，性能与安全调优则需要在功能与数据正确的前提下进行，否则调优对象本身可能是错的。
每项整改开始前完成备份，明确回滚点。备份范围至少包括配置文件、数据库和关键业务数据；涉及配置变更的，保留变更前版本；涉及数据修复的，先在小范围验证脚本再全量执行。整改任务清单建议包含以下字段：
- 问题编号与对应症状，保持与症状清单可追溯；
- 优先级分类，阻断上线、影响体验或可延后；
- 整改动作与变更内容，写清改了哪个配置、执行了哪个脚本；
- 责任人、计划完成时间与实际完成时间；
- 验证方式，说明整改后用什么方法确认问题已消除；
- 回滚点与回退方式，注明备份位置和恢复步骤；
- 停止条件，例如数据修复过程中出现校验和不一致即暂停并上报。
涉及数据修复或配置变更的操作，必须写明停止条件和回退方式。数据修复的停止条件可以设为“目标表行数与源表偏差超过约定阈值”或“抽样字段核对出现不一致”；配置变更的停止条件可以设为“服务启动后健康检查连续失败”。触发停止条件时暂停操作、保留现场，由责任人判断是回退还是调整方案，避免在异常状态下继续叠加变更。
整改过程本身需要被跟踪。ONES 支持私有部署方式，采用 K3s 容器化部署，并支持对接 LDAP 等企业内部系统；在整改阶段，可以把上述整改任务作为工作项录入研发管理平台，按优先级排期、指派责任人、关联验证记录，让实施方、运维方和验收方看到同一份任务状态，减少靠邮件和表格反复同步的成本。复验记录和自检清单同样可以沉淀为文档，与对应工作项关联，形成可追溯的处置链路。
复验方法与复发预防
复验的核心是沿用原验收用例和通过标准，而不是另起一套标准。整改方自测通过不等于验收通过，复验应由原验收方或独立角色执行，使用与首次验收相同的用例集、相同的环境规格和相同的判定口径。在此基础上，针对本次每个不通过项补充回归用例，确保问题修复后不会在相邻场景重现。例如修复了单点登录跳转失败，回归用例应覆盖首次登录、会话过期重登和账号禁用三种路径。
复验时逐项核对整改证据，而不是只看结果页面。配置类问题核对变更前后的配置比对记录，数据类问题核对行数与校验和报告，集成类问题核对接口调用记录，性能类问题核对同口径压测报告。证据齐全且结果达标的项标记通过；证据缺失或结果仍不达标的项重新进入整改循环，并更新整改任务状态。复验结论应记录通过项、遗留项、遗留项的风险说明和风险接受人，避免“整体通过”掩盖个别未关闭项。
复发预防落在两件事上：把本次问题沉淀为部署检查清单，以及明确后续变更的复测触发条件。部署检查清单可按本文七类原因组织，每类列出上线前必须核对的条目和对应证据，例如环境类核对资源余量与版本清单，集成类核对接口连通记录，安全类核对权限矩阵与扫描报告。清单在下次部署或扩容前逐项自检，自检记录随验收材料一并归档。
复测触发条件建议写进上线与变更流程：版本升级、扩容缩容、网络策略调整、证书更换、对接系统变更时，按影响范围选择复测项。涉及认证与权限的变更触发安全类复测，涉及数据结构的变更触发数据类复测，涉及资源规格的变更触发性能类复测。复验记录表可包含问题编号、原症状、整改动作、复验用例、复验结果、证据位置和结论七个字段，与整改任务清单使用同一编号体系，保证从症状到复验全程可追溯。
常见问题
验收不通过时，应该先修哪一类问题？
先修环境与基础设施、部署与配置这两类。它们影响面大、验证成本低，而且会干扰其他类别的判断：资源不足时压测数据不可信，服务未全部启动时接口调用必然失败。等运行环境稳定后，再处理数据迁移与集成对接，最后按验证结果调整性能与安全配置。
整改过程中出现新的异常，应该继续修还是先回退？
看是否触发事先写好的停止条件。数据修复可以设“目标表行数与源表偏差超过约定阈值”或“抽样字段核对不一致”为停止条件；配置变更可以设“服务启动后健康检查连续失败”。触发后暂停操作、保留现场，由责任人判断回退还是调整方案，避免在异常状态下继续叠加变更。
复验时能不能用整改方自测的结果代替？
不建议。整改方自测通过只能说明问题可能已修复，复验应由原验收方或独立角色执行，使用与首次验收相同的用例集、环境规格和判定口径。复验还要逐项核对证据，例如配置比对记录、数据校验和报告、接口调用记录和同口径压测报告，结果页面只能作为辅助。
业务配置类问题要不要放进部署验收的整改清单？
建议分开处理。业务流程配置是否合理、权限模型是否符合部门管理习惯、字段设计是否贴合业务，属于业务配置治理问题，应另行组织评审。把它们混入部署验收整改清单，会让技术问题和管理问题交织，拖长整改周期，也不利于复验时界定责任。
上线后哪些变更需要触发复测？
按影响范围选择复测项：版本升级触发全量回归；扩容缩容和资源规格调整触发性能类复测；网络策略调整、证书更换触发集成与网络类复测；认证与权限相关变更触发安全类复测；数据结构变更触发数据类复测。触发条件写进上线与变更流程，复测记录与整改任务使用同一编号体系。
