3. 变更失败率定义：什么是变更失败率、计算公式、统计口径与常见误区
变更失败率（Change Failure Rate, CFR）是 DORA 四大核心指标中唯一衡量质量的指标，它直接反映软件交付过程中变更引入故障的比例。与部署频率、前置时间、恢复时间等效率指标不同，CFR 关注的是“变更是否安全”。
3.1 什么是变更失败率
变更失败率定义为：导致生产环境服务降级或需要立即修复的部署所占的比例。DORA 团队将其视为“部署质量的反向指标”——CFR 越低，说明变更质量越高，交付流水线越可靠。
核心理解： 变更失败率不是“代码 Bug 率”，也不是“线上事故数”，而是“部署行为导致负面后果的概率”。一次部署即使只引发 5% 的用户请求超时，只要触发了回滚或热修复，就应计入失败变更。
3.2 计算公式
标准计算公式如下：
变更失败率（CFR） = （导致失败的部署次数 / 总部署次数） × 100%其中：
- 分子（失败部署次数）：部署后导致服务降级、回滚、热修复、紧急补丁的部署次数。
- 分母（总部署次数）：同一统计周期内所有生产环境部署的总次数，包括正常部署、回滚部署、金丝雀部署等。
示例计算：
| 统计周期 | 总部署次数 | 失败部署次数 | 变更失败率 |
|---|---|---|---|
| 2025-01 周 | 50 | 2 | 4% |
| 2025-02 周 | 45 | 5 | 11.1% |
| 2025-03 周 | 60 | 1 | 1.7% |
3.3 统计口径与判定标准
不同团队对“失败”的判定存在差异，DORA 建议采用以下统一口径：
| 判定维度 | 计入失败变更 | 不计入失败变更 |
|---|---|---|
| 回滚 | 任何手动或自动回滚 | — |
| 热修复 | 部署后 1 小时内发布紧急修复 | 计划内的常规补丁 |
| 服务降级 | 错误率上升超过基线 20% | 低于阈值的轻微波动 |
| 功能不可用 | 核心功能完全不可用 | 非核心功能降级 |
| 金丝雀失败 | 金丝雀阶段自动中止并回滚 | 金丝雀正常通过 |
统计周期建议： 按周或按月统计 CFR，避免按天统计导致分母过小、波动剧烈。对于低频部署团队（如每月 1-2 次），建议按季度滚动计算。
3.4 常见误区与避坑指南
以下是在实际建模中容易出现的误区：
- 误区一：只统计“严重事故”
将 CFR 等同于 P0/P1 级事故率。实际上，任何导致回滚或热修复的部署都应计入，包括轻微降级。 - 误区二：分母只统计“成功部署”
部分团队只统计正常上线次数，忽略了回滚部署本身也是部署行为。分母必须包含所有生产部署。 - 误区三：忽略金丝雀/灰度部署
金丝雀部署如果在中途失败并回滚，应计入失败变更。只有完全通过并全量发布的才算成功。 - 误区四：跨团队口径不一致
微服务架构下，不同服务团队对“失败”的判定标准不同，导致 CFR 无法横向对比。建议统一判定规则。 - 误区五：将 CFR 与 SLA 混淆
CFR 是部署质量指标，SLA 是服务可用性指标。一次部署可能未违反 SLA，但触发了回滚，仍应计入 CFR。
关键提醒： 变更失败率与部署频率存在联动关系。高频部署团队如果 CFR 过高，说明流水线质量存在系统性问题；低频部署团队即使 CFR 很低，也可能因为变更集过大而隐藏风险。后续章节将详细讲解两者的联动建模方法。
3.5 变更失败率判定流程
下图展示了从部署到判定失败变更的完整流程：
3.6 与 DORA 其他指标的联动关系
变更失败率不是孤立指标，它与部署频率、变更前置时间、恢复时间存在内在联动：
| 指标组合 | 典型画像 | 联动含义 |
|---|---|---|
| 高部署频率 + 低 CFR | 精英团队 | 流水线成熟，变更质量高 |
| 高部署频率 + 高 CFR | 混乱团队 | 变更频繁但质量失控，需优先治理 |
| 低部署频率 + 低 CFR | 保守团队 | 变更集过大，风险虽低但交付缓慢 |
| 低部署频率 + 高 CFR | 高风险团队 | 每次变更都伴随故障，需重构流程 |