2. 验收标准体系设计

验收标准体系不是把“功能正常、性能良好、安全可靠”这类形容词堆在一起，而是把每一类验收目标翻译成可测量、可复现、可判定的指标。设计时先确定验收对象（GitLab 实例、CI/CD 流水线、制品库、权限模型、备份链路等），再为每类验收选择“指标—阈值—测量方法—判定依据”四要素。缺少测量方法，阈值就只是口号；缺少判定依据，争议就无法收敛。

一、五类验收的指标设计逻辑

功能验收关注“业务动作是否按预期完成”。指标应落在具体操作路径上，例如：项目创建后默认分支保护是否生效、MR 合并后是否触发流水线、流水线失败是否阻断合并、制品上传后能否被下游项目拉取。判定方式通常是“执行 N 个用例，通过率 100%”，并保留用例编号与执行记录。

性能验收关注“在给定负载下是否满足响应与吞吐要求”。常用指标包括：页面首字节时间（TTFB）、API P95 响应时间、Git 克隆/推送吞吐、流水线排队时长、并发 Runner 作业数。阈值必须绑定负载条件，例如“在 200 并发用户、500 个活跃 Runner 作业下，API P95 ≤ 800ms”。

安全验收关注“权限、凭据、漏洞与审计是否可控”。指标可设计为：高危漏洞数 = 0、越权访问用例通过率 100%、密钥扫描命中数 = 0、审计日志覆盖关键操作比例 ≥ 95%、双因素认证覆盖率 ≥ 90%。安全指标要区分“阻断项”和“观察项”，阻断项不达标即验收不通过。

兼容性验收关注“不同客户端、浏览器、操作系统与集成工具能否一致工作”。指标包括：支持的浏览器版本矩阵内功能可用率 100%、Git 客户端版本兼容列表、LDAP/OIDC 对接成功率、Webhook 与外部系统联调通过率。兼容性验收必须明确“支持范围”，范围外的失败不计入缺陷。

可维护性验收关注“交付后能否被稳定运维与演进”。指标包括：备份恢复演练 RTO ≤ 30 分钟、RPO ≤ 5 分钟、监控覆盖率 ≥ 90%、日志保留 ≥ 180 天、升级回滚演练成功、配置即代码覆盖率 ≥ 80%。可维护性指标往往在交付前通过演练验证，而不是靠文档承诺。

二、把指标写成可执行的验收清单

指标设计完成后，必须落到清单才能执行。清单的每一行至少包含：验收类别、验收项、指标定义、阈值、测量方法、样本量、判定结果、证据链接。下面给出一份可直接参考的示例清单（参数为教学示例，实际项目需按业务规模调整）。

三、阈值设定与证据留存

阈值不能拍脑袋。性能阈值应来自容量规划或历史基线：例如当前生产环境 API P95 为 500ms，新版本验收可设 800ms 作为回归红线；若业务要求更严，则需同步扩容。安全阈值通常取“零容忍”策略，但要把“高危”定义写清楚，例如 CVSS ≥ 7.0 且可利用。兼容性阈值要明确支持矩阵，矩阵外的失败不判缺陷。可维护性阈值应通过演练取得，而不是引用厂商文档。

证据留存决定验收是否可追溯。建议每项指标至少保留：执行时间、执行人、环境版本、原始数据文件、截图或日志链接。对于性能类，保留压测脚本与结果 CSV；对于安全类，保留扫描报告与修复记录；对于可维护类，保留演练记录与恢复耗时截图。没有证据的“通过”在交付评审中视为未验收。

四、从清单到验收结论

执行完成后，按类别汇总：功能阻断项全部通过、性能阻断项达标、安全阻断项为零、兼容阻断项通过、可维护阻断项通过，则整体判定为“通过”；任一阻断项不通过，则判定为“不通过”，并输出整改项与复验范围。观察项不阻断交付，但必须进入整改计划并约定复验时间。这样，验收标准体系才真正从“指标设计”走到“可量化、可判定、可追溯”的交付闭环。