研发平台部署选型的验收标准，要围绕“部署模式是否按选型结论落地、关键约束是否被满足”来定，评价对象是部署方式本身，平台全部功能不在本次验收范围内。做法是把选型阶段确认的部署模式、控制权、数据位置、集成边界和成本上限转成可核验的验收项，再为每项写清数据口径、证据来源、计算方式与通过标准，最后用试点或试运行数据复算并解释偏差。下文给出分模式指标、口径表、判定规则和一个填表示例，ONES可作为登记验收项与证据的载体。
要点总览（TL;DR）
- 验收对象是部署模式是否按选型结论落地，平台全部功能不在本次验收范围内。
- 公有云与私有化要分别设指标：前者看可用性、数据驻留、账号权限与订阅成本，后者看环境交付、网络边界、升级路径、运维责任与持续成本。
- 每项定量指标写清分子、分母、时间窗、单位和缺失值处理；定性指标写清证据形式与判定人。
- 整体结论采用阻断项一票否决加其余项分级，取数前定稿判定规则，不通过项整改后只复验整改项。
- 验收通过只说明约定试运行期内关键约束成立，样本期短、环境差异和指标权衡都会影响结论外推。
验收要回答什么：把选型结论变成可判定的条件
部署选型验收的目标只有一个：确认当初选定的部署模式已经按结论落地，并且选型时认定的关键约束在真实环境中成立。它回答的是“我们选的那条路走通了吗”，平台功能是否丰富、供应商综合实力如何，属于另一类评估，不应混入同一张验收表。
把选型结论转成验收条件，可以先列一份决策项清单，逐条对应到可观察的事实：
- 部署模式：实际交付的是公有云、私有化还是高可用集群，与选型结论是否一致。
- 控制权：环境由谁运维、升级由谁发起、故障由谁响应，责任边界是否落到书面。
- 数据位置：数据存放在哪里、能否直接访问、隔离方式是否与选型时的承诺一致。
- 集成边界：需要对接的内部系统（如账号目录、单点登录）是否按约定打通。
- 成本：一次性投入与持续费用是否落在选型时设定的上限内。
验收结论需要预设处置方向。阻断项不通过时，通常选择回退到备选部署模式或要求供应商限期整改后复验；非阻断项不通过，可以带条件通过并列入整改计划。处置方向应在验收启动前写进验收方案，避免结论出来后再讨论怎么办。
验收指标与范围：分模式设定检查项
公有云与私有化两种模式的验收重点差异明显，用同一套指标套两种模式，会得到看似完整却无法判定的结果。下表按模式列出应验收的维度，具体指标名和通过标准在验收方案中细化。
| 维度 | 公有云（SaaS）重点 | 私有化部署重点 |
|---|---|---|
| 可用性 | 服务可用时段、故障响应与恢复承诺 | 集群故障转移、单点故障消除情况 |
| 数据 | 数据驻留区域、导出与删除机制 | 数据隔离方式、直接访问权限 |
| 账号与权限 | 账号开通、角色配置、审计日志 | 与企业目录（如 LDAP）对接、权限同步 |
| 集成方式 | 开放接口、单点登录、Webhook 等 | 内网系统对接、网络策略放通 |
| 版本与升级 | 新功能获取节奏、变更通知 | 升级路径、升级窗口、回滚方案 |
| 运维责任 | 供应商运维范围与支持渠道 | 双方职责矩阵、监控与告警归属 |
| 成本 | 订阅费用、按人计费口径 | 一次性交付成本与年度持续成本 |
范围上要划清一条线：环境交付、网络与安全边界、升级路径、运维责任、成本结构属于部署验收；需求管理、测试管理、报表能力等功能项归平台功能评估，不在本表打分。以 ONES 为例，其官网说明支持私有部署和公有云部署，私有化部署采用 K3s 容器化方式并支持对接 LDAP 等企业内部系统，另有高可用集群部署与信创版全栈适配；这些描述可以作为设定验收项的参照，具体可用性数值、SLA 条款与适配版本清单仍需在合同中确认后写入通过标准。
数据口径与证据：每项指标怎么取数、谁来证明
口径不清是验收争议的主要来源。同一项“集成打通”，一方按接口联调成功计，另一方按生产环境稳定运行一周计，结论可能完全相反。因此每项指标都要在验收前写清取数规则，并指定证据形式和责任人。
定量指标的口径至少包含五个要素：
- 分子：计入达成的数量或时长，明确哪些情形算达成。
- 分母：统计总体，明确排除项，例如计划外停机是否计入。
- 时间窗：统计起止时间，试运行期与观察期分开计算。
- 单位：百分比、小时、次数、元，避免混用。
- 缺失值处理：数据未采集或分母为零时如何记录。
定性指标要有证据清单和判定人。常见证据形式包括配置截图、交付清单、测试记录、责任矩阵和会议确认纪要。证据应在约定时点采集，例如上线当日、试运行第 7 天、验收评审前一日，并统一存放在验收工作区，保留采集人和采集时间。
| 指标 | 口径要点 | 证据形式 | 责任人 | 采集时点 |
|---|---|---|---|---|
| 服务可用率 | 可用时长÷统计时长，按分钟计 | 监控导出记录 | 运维负责人 | 试运行结束时 |
| 账号目录对接 | 应同步账号中成功同步的比例 | 同步日志、抽样核对表 | 系统管理员 | 对接完成后 3 日内 |
| 数据隔离确认 | 隔离方式与选型承诺逐条比对 | 架构说明、配置截图 | 安全负责人 | 交付验收时 |
| 升级路径确认 | 升级方式、窗口、回滚步骤齐全 | 升级方案文档、演练记录 | 双方运维代表 | 验收评审前 |
| 成本核对 | 实际费用与预算上限比对，含年度持续费用 | 合同、账单 | 采购负责人 | 首期账单出具后 |
分母为零或数据缺失时，预先约定处理规则：记为“不适用”并从合成中剔除，或触发补充取数后延期判定，不能默认按通过处理。例如试运行期内没有发生计划外停机，停机相关指标的分母为零，应记为不适用并说明原因，而不是直接给满分。
计算与判定步骤：从取数到通过结论
判定规则要在取数之前定稿，保证任何人拿到同一批数据能算出同一结论。单项指标的通过标准写成“公式＋阈值＋时间窗”的形式，例如：服务可用率＝（统计时长－不可用时长）÷统计时长×100%，试运行 30 天内不低于验收方案约定值，按分钟统计，计划内维护窗口不计入不可用时长。阈值来自选型阶段的约束或合同条款，没有依据时不设通用达标线。
整体结论建议采用阻断项一票否决与其余项分级并存的合成方式：
- 先判阻断项：数据隔离、核心集成打通、成本超限等选型时认定的硬约束，任一项不通过即整体不通过，不再计算加权分。
- 再判一般项：按“通过／带条件通过／不通过”三级评定，带条件通过须写明整改内容和期限。
- 复算与复核：由未参与取数的人员按口径表独立复算定量项，差异超过约定幅度时回到原始证据核对。
- 整改与复验：不通过项形成整改清单，明确责任人和完成时间，到期后只对整改项复验，复验记录与原验收表关联保存。
这套流程产生的验收项、证据和整改任务，可以在 ONES 中登记为工作项与文档，让每项结论都能追溯到取数记录和判定人，复验时不必重新翻找材料。
一个示例：私有部署试运行的验收表怎么填
以下为演示情景，数值仅用于说明填写方法，不代表任何产品的真实承诺或达标线。场景：某团队选择私有化部署，试运行期 30 天，验收方案约定服务可用率不低于 99.5%，账号目录对接成功率 100%，并确认数据隔离方式与选型承诺一致。
定量项一：服务可用率。统计窗口为试运行 30 天，共 43200 分钟；期间发生两次不可用，分别为 45 分钟和 30 分钟，计划内维护 60 分钟按口径不计入。计算：（43200－75）÷43200×100%≈99.83%，高于 99.5%，判定通过。若维护窗口也计入不可用，结果约为 99.69%，仍通过，但口径必须在表中注明，否则两次计算结果无法比较。
定量项二：账号目录对接成功率。应同步账号 1200 个，实际成功 1194 个，6 个因属性缺失未同步。计算：1194÷1200×100%＝99.5%，未达 100%，判定不通过，列入整改：补齐属性后重新同步并复验。这里分母是应同步账号数，不是已尝试同步数，口径不同结论会不同。
定性项：数据隔离确认。证据为架构说明文档、存储配置截图和安全负责人签署的比对表，逐条对照选型阶段的隔离承诺。判定人依据证据清单确认一致，判定通过；若某项承诺无法提供证据，记为待补证，不按通过处理。
边界情况：试运行期内未发生计划外停机，则“平均故障恢复时长”分母为零，记为不适用，从合成中剔除并注明原因；若监控数据缺失三天，触发补充取数，该指标延期判定，其余指标照常合成。
解读与限制：结论能说明什么、不能说明什么
验收通过说明的是：在约定的试运行期内，部署模式按选型结论落地，关键约束在当时的证据下成立。它不覆盖平台功能是否满足全部业务需求，也不构成对长期服务质量的保证。把一次验收结论当作全年稳定性的承诺，是常见的误读。
解读时需要注意几类偏差。样本期短，30 天的可用率无法反映年度故障分布，极端故障可能尚未出现；环境差异，试运行环境与生产全量环境的负载、网络条件不同，指标不能直接外推；指标之间存在权衡，例如更严格的隔离配置可能增加集成工作量，单项得分高低要结合约束条件看；不同模式、不同规模的团队之间，指标数值不具备直接可比性。
建议在验收结论中写明适用范围和观察期，并在上线后按季度复看关键指标，出现部署模式变更、重大升级或架构调整时重新组织专项验收。这样验收表既是一次判定的记录，也成为后续观察的基线。
常见问题
试运行期太短，验收结论还能用吗？
可以用，但要在结论中写明适用范围。30 天试运行能确认部署模式已落地、关键约束在当期证据下成立，无法反映年度故障分布。建议把验收结论作为上线基线，上线后按季度复看可用性、集成稳定性等关键指标；出现部署模式变更、重大升级或架构调整时，重新组织专项验收。
选型时没有约定具体阈值，验收时怎么定通过标准？
阈值应来自选型阶段的约束或合同条款，例如合同中的可用性承诺、数据隔离要求、预算上限。若选型时未约定，可在验收启动前由业务、运维、采购和供应商共同确认，并写入验收方案，同时注明依据来源。没有依据时不宜套用行业通用数值，否则结论缺乏可追溯的判定基础。
阻断项和一般项怎么区分？
阻断项对应选型时认定的硬约束，例如数据隔离方式、核心系统集成打通、成本不超预算上限，任一项不通过即整体不通过。一般项影响使用体验或后续运维，可按通过、带条件通过、不通过三级评定。区分清单应在验收启动前确定并告知各方，避免结论出来后再调整哪些项属于阻断项。
验收不通过后，复验要重新走一遍全部指标吗？
通常只复验整改项。整改清单应写明责任人和完成时间，到期后对不通过项重新取数判定，复验记录与原验收表关联保存。若整改涉及架构调整或部署模式变更，影响范围超出原整改项时，再扩大复验范围。复验仍不通过，按验收方案预设的处置方向执行，例如回退到备选部署模式。
ONES 在验收过程中能承担什么角色？
ONES 支持私有部署和公有云部署两种方式，私有化部署采用 K3s 容器化方式并支持对接 LDAP 等企业内部系统，另有高可用集群部署。验收时可以把验收项、证据材料、整改任务登记为工作项和文档，让每项结论追溯到取数记录和判定人。具体可用性数值、SLA 条款与适配版本清单仍需在合同中确认后写入通过标准。
