3. 变更失败率基础：定义、计算公式与 DORA 标准
变更失败率（Change Failure Rate, CFR）是软件交付效能四大关键指标之一，直接衡量变更上线的稳定性风险。本节从基础概念出发，建立可观测性设计所需的度量共识。
3.1 变更失败率的定义
变更失败率是指：在生产环境中，因软件变更（功能发布、配置修改、补丁部署等）导致服务降级、故障或回滚的变更次数，占总变更次数的比例。
核心判定条件（需同时满足）：
- 变更已上线：变更已进入生产环境，非预发或灰度阶段。
- 产生负面效果：导致服务不可用、响应延迟显著增加、数据错误、功能异常或需要紧急回滚。
- 因果关系明确：通过可观测性数据（指标、链路、日志）可定位到具体变更。
可观测性视角：CFR 的统计依赖变更与故障的关联能力。没有完善的变更事件标签和故障根因定位，CFR 计算将退化为人工估算。
3.2 计算公式与统计口径
标准计算公式：
变更失败率 (CFR) = (导致服务降级或故障的变更次数 / 总变更次数) × 100%统计口径需明确以下三个维度：
| 维度 | 说明 | 常见误区 |
|---|---|---|
| 时间窗口 | 通常按周或月统计，也可按发布批次统计 | 窗口过短（如按天）导致样本不足，波动大 |
| 失败判定窗口 | 变更上线后多长时间内出现的故障算作该变更导致（常见：1小时、24小时、直到下次变更前） | 窗口过短遗漏延迟故障，过长引入噪声 |
| 变更粒度 | 单次部署、单个 PR 合并、单个配置推送 | 粒度不统一导致跨团队对比失真 |
推荐实践：以“单次生产部署”为变更粒度，失败判定窗口设为部署后 2 小时，统计周期为最近 4 周滚动计算。
3.3 DORA 指标与业界标准
Google 的 DORA（DevOps Research and Assessment）团队通过多年研究，将变更失败率划分为四个等级，作为行业基准：
| 等级 | 变更失败率 | 典型特征 |
|---|---|---|
| 精英 (Elite) | 0% – 5% | 高度自动化测试与灰度发布，变更可快速回滚 |
| 高 (High) | 5% – 10% | 完善的 CI/CD 流水线，变更可观测性强 |
| 中 (Medium) | 10% – 15% | 部分自动化，人工审核为主，回滚流程较慢 |
| 低 (Low) | > 15% | 手动部署多，测试覆盖不足，变更风险高 |
DORA 同时强调：变更失败率应与部署频率（Deployment Frequency）协同观察。高部署频率 + 低失败率才是理想状态；低部署频率 + 低失败率可能意味着变更过于保守，阻碍业务响应速度。
3.4 变更失败率与可观测性设计的关联
CFR 不是孤立的统计数字，它直接驱动可观测性系统的 Metric Design 选型：
- 失败判定需要可观测性数据支撑：错误率（Error Rate）、延迟（Latency）、可用性（Availability）等 SLI 是判定变更是否失败的客观依据。
- 变更事件需要被标记：每次部署、配置变更、功能开关切换都应在可观测性系统中留下标签（如
deploy_id、change_type），便于关联分析。 - CFR 趋势是告警策略的输入：当 CFR 超过团队设定的 SLO 阈值时，应触发变更流程审查或自动阻断。
3.5 常见计算陷阱与避坑指南
| 陷阱 | 错误做法 | 正确做法 |
|---|---|---|
| 分母混淆 | 用代码提交次数代替部署次数 | 分母统一为“生产环境部署次数” |
| 重复计数 | 一次失败变更被多次回滚，计为多次失败 | 一次变更无论回滚几次，只计 1 次失败 |
| 忽略配置变更 | 只统计代码变更，忽略配置推送、数据库变更 | 所有可能影响服务行为的变更都应纳入 |
| 时间窗口错位 | 用月度故障总数除以月度部署总数 | 按变更批次一对一关联，避免跨时间归因 |
注意：CFR 是滞后指标，反映的是过去一段时间的变更质量。不要单独用 CFR 做实时阻断决策，应结合部署前置时间（Lead Time）和变更量级综合评估。