研发平台部署选型的验收标准，应围绕本次部署形态本身可核验的结果来定：先锁定验收对象和边界，再把环境交付、数据边界、集成连通、性能容量、运维回退、成本口径拆成可观测指标，逐项写明公式或证据、时间窗、单位与通过标准。本文给出这套方法、执行步骤和一个可复算的算例，并说明验收结论能证明什么、不能证明什么。
要点总览（TL;DR）
- 部署选型验收的对象是部署形态及其运行条件，平台全功能评估和私有化实施细节不纳入本轮判定。
- 验收指标按六组划分：环境交付与可重复性、数据与权限边界、集成连通性、性能与容量、运维与回退、成本口径，每组对应一类部署风险。
- 定量指标要写清分子分母、时间窗、单位和数据来源，定性指标要给出可留存的判定证据，分母为零记为不适用，不按0或100%处理。
- 执行顺序是先判必过项、再算评分项，不通过项需整改后按相同口径复验，仅提供说明不视为关闭。
- 验收通过只说明部署形态在约定条件下满足要求，不证明业务效果，部署形态、版本或负载变化时应触发复验。
部署选型验收要验到什么程度
部署选型验收的对象是部署方式及其运行条件，包括环境能否按约定交付、数据落在哪里、与既有系统能否连通、在约定负载下是否稳定、出故障能否回退、成本口径是否清楚。平台功能是否齐全、业务流程是否顺畅，属于功能选型评估，不放在这一轮验收里判定。把两件事分开，验收结论才有明确指向：通过，说明这种部署形态在既定条件下可用；不通过，说明部署条件存在缺口，需要整改或更换形态。
验收结论由两类结果组成。必过项是一票否决的条件，例如数据存储位置符合约定、核心集成连通、回退方案经过演练；任何一项不通过，整体结论即为不通过，不进入评分环节。评分项用于在多个候选形态之间比较优劣，例如环境交付耗时、平均恢复时间、单位用户年成本；评分项不设统一及格线，由验收方案在启动前写明权重和计算方式。两类项在验收启动前确定，执行过程中不临时调整，避免结论随结果变化。
边界划分建议写进验收方案首页：本文方法覆盖部署形态的验收，不覆盖平台全功能与供应商综合评估，也不覆盖私有化实施中的环境搭建与日常运维细节。实施环境工作（如机房、网络、操作系统准备）作为验收的前置条件记录，其完成情况影响验收能否开始，本身不作为部署形态的评分依据。这样划分后，验收记录可以独立复算，后续复盘时能分清问题出在部署条件还是平台功能。
验收指标与范围：六组指标怎么划
六组指标分别对应部署环节的一类风险，分组的目的不是求全，而是让每组都能落到可观测的证据上。分组确定后，再逐组判断本次验收是否纳入：与本次部署形态直接相关的纳入，属于后续阶段或平台功能范畴的明确排除，并在方案中写明排除理由。
| 指标组 | 回答的部署问题 | 本次适用范围 |
|---|---|---|
| 环境交付与可重复性 | 环境能否按约定时间交付，重复搭建结果是否一致 | 纳入；含首次交付与一次重建验证 |
| 数据与权限边界 | 数据存储位置、访问控制、隔离方式是否符合约定 | 纳入；权限模型细节留给功能评估 |
| 集成连通性 | 与账号目录、内部系统、消息通道能否稳定连通 | 纳入；仅验连通与认证，不验业务规则 |
| 性能与容量 | 约定负载下响应与吞吐是否满足，容量余量多少 | 纳入；以试点规模为口径，不外推生产峰值 |
| 运维与回退 | 备份、监控、故障转移、回退演练是否可执行 | 纳入；日常运维流程细节留给运维阶段 |
| 成本口径 | 许可、资源、人力成本能否按统一口径归集 | 纳入；具体报价以采购环节为准 |
范围界定要防止两种偏差。一种是把平台功能测试塞进部署验收，导致指标膨胀、结论失焦；另一种是把部署风险全部推给上线后观察，验收阶段只做形式检查。可行的做法是：凡属部署形态引入的风险，本轮必须有一项可核验指标；凡属业务使用效果的问题，明确写入后续评估计划。对于高可用、信创适配这类有明确形态差异的部署方式，验收指标应相应增加，例如故障转移演练、适配环境下的启动与运行检查。ONES 支持私有部署和公有云部署，私有化部署采用 K3s 容器化部署并支持对接 LDAP 等企业内部系统，高可用集群部署可实现故障转移、数据容灾与零停机服务升级；这些形态差异会直接影响上述指标组的取数方式，验收方案应按实际选择的形态裁剪指标，而不是套用同一张表。
数据口径与证据：每个指标怎么取数
口径的作用是让另一个人拿着同样的记录能算出同样的结果。每个定量指标至少写清四件事：计算公式（含分子分母）、统计时间窗、单位、数据来源。定性指标写清判定证据和通过标准，证据应是可留存的文件、截图、日志或演练记录，避免用“基本可用”“体验良好”这类无法复核的描述。
| 指标 | 公式或证据 | 时间窗 | 单位 | 数据来源 |
|---|---|---|---|---|
| 环境交付准时率 | 按约定时间交付的环境数 ÷ 计划交付环境数 | 本次交付周期 | % | 交付计划与交付确认记录 |
| 环境重建一致率 | 重建后配置项与基线一致的数量 ÷ 基线配置项总数 | 重建完成后 1 个工作日内核对 | % | 配置基线清单、重建核对记录 |
| 数据边界符合项占比 | 符合约定存储位置与访问控制的检查项数 ÷ 检查项总数 | 验收执行当日 | % | 存储位置核查记录、权限配置截图 |
| 集成连通成功率 | 连通成功次数 ÷ 连通尝试次数 | 连续 3 个工作日 | % | 集成日志、连通测试记录 |
| 约定负载下平均响应时间 | 各采样请求响应时间之和 ÷ 采样请求数 | 稳定运行 30 分钟后的采样窗口 | 毫秒 | 压测或试点运行日志 |
| 容量余量 | （实测承载上限 − 约定负载）÷ 约定负载 | 压测当日 | % | 压测记录 |
| 平均恢复时间 | 各次故障演练恢复耗时之和 ÷ 演练次数 | 每次演练单独计时 | 分钟 | 演练记录、监控告警时间戳 |
| 回退演练完成情况 | 证据：回退方案、演练步骤记录、回退后系统状态确认 | 验收期内至少 1 次 | 定性 | 演练报告 |
| 单位用户年成本 | （许可费 + 资源费 + 运维人力折算）÷ 用户数 ÷ 年数 | 按合同周期折算 | 元/人/年 | 报价单、资源账单、人力工时记录 |
缺失值和不可比情形要在方案里预先定规则，而不是执行时临时决定。分母为零时，该指标记为“不适用”，不计算比率，也不按 0 或 100% 处理；例如本次没有发生故障，平均恢复时间就没有样本，应记录“未触发演练”并说明原因。数据缺失时，先判断缺失是否影响必过项：影响必过项的，按不通过处理并要求补证；只影响评分项的，记为“缺数”，在总分计算中按方案约定的方式处理，不得用估算值替代原始记录。不同部署形态之间，只有在指标定义、负载条件、时间窗一致时才可比较；公有云与私有化的资源成本构成不同，直接比单位成本容易得出误导性结论，应分列展示并注明口径差异。
验收怎么执行：从试点到结论的步骤
执行阶段的目标是用一轮试点跑出完整证据链，而不是把所有指标测一遍就结束。建议按以下顺序推进，每一步都留下可复核的记录。
- 准备验收环境与样本。确认前置条件（网络、账号目录、资源配额）已就绪，确定试点用户范围、数据规模和集成清单，把验收方案中的指标表冻结为执行版本。
- 执行环境交付与重建验证。记录计划交付时间与实际交付时间，完成一次重建并按基线逐项核对，形成交付与重建记录。
- 核查数据与权限边界。按检查项逐条核对存储位置、访问控制与隔离方式，留存配置截图或核查记录。
- 执行集成连通测试。按集成清单逐项测试，连续记录若干工作日的连通结果，保留日志。
- 开展性能与容量测试。在约定负载下采样响应时间，逐步加压至承载上限，记录容量余量。
- 执行运维与回退演练。至少完成一次备份恢复或故障转移演练，记录耗时与系统状态；回退方案须实际走一遍。
- 归集成本数据。按统一口径收集许可、资源与人力数据，形成单位成本计算表。
- 判定与复验。先判必过项，全部通过后再计算评分项；不通过项列出整改要求、责任人和复验时间，复验通过后方可关闭。
判定顺序不能颠倒。必过项未全部通过时，评分结果不对外发布，避免用高分掩盖硬性缺口。复验的关闭条件是：整改措施已执行，且对应指标在相同口径下重新取数达到通过标准；仅提供说明或承诺的，不视为关闭。验收过程中的工作项、证据附件与评审结论需要集中留存，ONES 可用于承载这类记录与评审流转，具体字段和流程按团队既有做法设置。
一个可复算的验收例子
以下为演示情景，数据为假设值，用于说明计算与判定过程，不代表任何真实项目结果。假设某团队对一套私有化部署的研发平台开展验收，约定负载为 500 名活跃用户，计划交付 4 套环境（开发、测试、预发、生产），基线配置项 40 项，集成清单 6 项，验收期内安排 2 次故障演练。
指标一：环境交付准时率。4 套环境中 3 套按约定时间交付，1 套延迟 2 天，计算为 3 ÷ 4 = 75%。若方案约定必过标准为 100%，该项不通过，需记录延迟原因并安排复验。
指标二：集成连通成功率。6 项集成在连续 3 个工作日内共尝试 180 次，成功 171 次，计算为 171 ÷ 180 = 95%。若方案约定通过标准为不低于 99%，该项不通过；此时应查看失败集中在哪几项集成，区分是配置问题还是网络条件问题，再决定整改方式。
指标三：平均恢复时间。2 次演练恢复耗时分别为 18 分钟和 24 分钟，计算为（18 + 24）÷ 2 = 21 分钟。若方案约定不超过 30 分钟，该项通过。
定性指标：回退演练。证据为回退方案文档、演练步骤记录、回退后核心功能可用性确认截图，三项齐全且回退后系统状态与基线一致，判定通过。
异常数据处理示例：本次验收期内未发生非计划故障，故障次数为 0，故障率的分母为零，该指标记为“不适用”，不计算为 0%。另有一次集成测试因账号目录维护中断 2 小时，该时段数据标记为“不可比”，从成功率计算中剔除并在记录中注明剔除区间，而不是按失败计入。若将不同部署形态的单位成本直接对比，需先确认双方是否包含同口径的资源与人力项，口径不一致时只做分列展示，不给出孰优孰劣的结论。
结果怎么解读：限制与常见误用
验收通过说明部署形态在本次约定的环境、负载和检查项下满足条件，它不证明业务流程更顺畅、研发效率更高，也不构成对业务效果的因果保证。把验收结论写成“平台可用性得到验证”是合理的，写成“上线后效率提升可期”则超出了证据范围。
单指标不能代表整体结论。集成连通率 95% 在评分项里可能只是扣分，在必过项里则直接导致不通过；平均恢复时间达标，也不能抵消数据边界检查中的缺项。解读时应先看必过项结论，再看评分项分布，最后看缺数与不适用项的比例，三者合起来才构成完整判断。
不同部署形态之间的结果不可直接横比。公有云与私有化在资源成本构成、交付方式、运维责任上差异明显，同一指标在不同形态下的分母含义可能不同；只有在指标定义、负载条件、时间窗完全一致时，比较才有意义，否则应分列呈现并注明差异。
结论具有时效性。出现以下情形应触发复验：部署形态或基础设施发生变更，平台版本升级，约定负载或用户规模显著变化，集成清单增减，以及距上次验收超过方案约定的有效期。复验可只针对受影响指标，但必过项须重新确认。把这份限制清单与验收方案一并归档，后续引用结论时才能说清它成立的条件。
常见问题
验收方案启动后，还能临时增加或调整指标吗？
不建议在执行过程中调整指标和通过标准。验收方案应在启动前冻结为执行版本，必过项、评分项、权重和计算方式一并确定。执行中如果发现某项指标确实无法取数，按方案预先约定的缺失值规则处理：影响必过项的按不通过处理并要求补证，只影响评分项的记为缺数。确需新增指标时，应作为下一轮复验的内容，并在记录中说明新增原因，避免同一轮结论前后口径不一致。
试点规模的数据能直接用来推断生产环境的性能吗？
不能直接外推。试点验收的性能与容量指标以试点规模和约定负载为口径，反映的是该条件下的响应时间与容量余量。生产环境的用户规模、并发特征、数据量和集成数量可能明显不同，验收结论只对约定条件成立。如果需要在生产规模下判断，应在方案中另设压测场景和通过标准，或在上线后按实际负载安排复验，并在引用试点结论时注明适用规模。
必过项里有一项因外部条件未满足而无法验证，整体结论怎么判？
按不通过处理，并记录未验证的原因和补证计划。必过项的作用是一票否决，未取得证据等同于条件未确认，不能用评分项的高分来抵消。常见的外部条件包括网络策略未开通、账号目录维护窗口冲突、资源配额未到位，这些属于验收前置条件，应在准备阶段确认。若确认是前置条件缺失，可暂停验收、待条件具备后重新执行该项，而不是在缺证状态下出具通过结论。
多个候选部署形态都通过验收时，怎么用验收结果做选择？
在必过项全部通过的前提下，比较评分项的分布，而不是只看总分。先确认各候选形态的指标定义、负载条件和时间窗是否一致，口径不一致的指标分列展示，不直接比大小。成本类指标尤其要注意构成差异，公有云与私有化的资源费和人力折算项不同，直接比单位成本容易误导。可以按权重计算综合得分作为参考，同时保留单项结果，便于说明某一形态在交付速度、恢复能力或成本上的具体差异。
验收记录和证据需要保留多久，后续复验要重新做全部指标吗？
保留期限可按团队的项目归档要求确定，至少应覆盖到下一次复验完成，确保结论可追溯。复验不必重做全部指标：部署形态或基础设施变更、平台版本升级、约定负载或用户规模显著变化、集成清单增减时，针对受影响指标重新取数即可，但必过项须重新确认。距上次验收超过方案约定有效期时，也应安排复验，并在记录中写明触发原因和复验范围。
