3、变更失败率（CFR）精讲
3.1 CFR 定义与核心地位
变更失败率（Change Failure Rate, CFR） 是 DORA 四大核心指标之一，衡量的是部署到生产环境的变更中，导致服务降级或需要立即修复的比例。CFR 直接反映变更质量与交付稳定性，是 DevOps 成熟度评估中“稳定性”维度的关键度量。
核心认知： CFR 不是“Bug 率”或“缺陷密度”，而是变更对生产环境造成负面影响的频率。一个变更即使代码质量很高，如果因配置错误导致回滚，同样计入 CFR。
3.2 计算公式与统计口径
| 项目 | 说明 |
|---|---|
| 公式 | CFR = (失败变更数 / 总变更数) × 100% |
| 统计周期 | 通常按周或月统计，建议与部署频率（DF）周期对齐 |
| 总变更数 | 统计周期内所有到达生产环境的变更（含金丝雀、灰度、全量） |
| 失败变更数 | 满足“失败判定标准”之一的变更计数 |
| DORA 基准 | 精英：0%~15% | 高：16%~30% | 中：31%~45% | 低：>45% |
统计陷阱： 一次变更如果触发多次回滚，只计为 1 次失败变更；同一变更在多个环境（如预发→生产）失败，只计生产环境失败。
3.3 失败变更的判定标准
判定一次变更是否“失败”，需要建立明确的自动化或半自动化判定规则。以下是业界通用的四种判定场景：
- 回滚（Rollback）：变更上线后，因功能异常、性能退化或数据不一致，主动将版本恢复到上一个稳定版本。
- 热修复（Hotfix）：变更上线后，发现紧急问题，立即发布一个修复版本（通常跳过正常 CI/CD 流程）。
- 降级（Degradation）：变更导致部分功能不可用或性能指标（如 P99 延迟、错误率）超过阈值，触发熔断或降级开关。
- 紧急配置变更：通过运维平台或数据库直接修改生产配置，且该变更未走标准变更审批流程。
3.4 判定标准详细对比
| 判定类型 | 触发条件 | 典型场景 | 自动化检测难度 |
|---|---|---|---|
| 回滚 | 版本回退操作（自动/手动） | 新版本导致 500 错误率飙升 | 低（可监听部署系统事件） |
| 热修复 | 非计划内紧急发布 | 线上安全漏洞需立即修补 | 中（需标记变更类型） |
| 降级 | 熔断器打开 / 功能开关关闭 | 数据库慢查询导致接口超时 | 高（需关联监控指标） |
| 紧急配置 | 绕过标准 CI/CD 的配置修改 | 运维人员直接修改 Nginx 上游 | 中（需审计配置中心） |
3.5 失败变更的计数规则
- 一次变更，多次失败：同一变更上线后，先后触发回滚和热修复，只计 1 次失败变更。
- 批量变更：一次发布包含多个功能模块，只要其中任一模块触发失败判定，整个变更计为失败。
- 灰度/金丝雀：如果变更在灰度阶段即触发回滚，且未到达全量环境，不计入 CFR（因为未到达生产全量）。
- 基础设施变更：数据库迁移、网络策略变更等非应用代码变更，同样适用 CFR 判定。
实践建议： 在 CI/CD 流水线中集成“失败类型标签”，通过部署工具（如 Spinnaker、ArgoCD）自动标记回滚/热修复事件，减少人工统计误差。
3.6 CFR 与 DORA 成熟度模型
3.7 常见误区与避坑指南
| 误区 | 正确理解 |
|---|---|
| CFR 只统计代码 Bug | 配置变更、基础设施变更、数据迁移失败都计入 |
| 回滚就是失败 | 回滚是结果，不是原因；应关注回滚背后的根因 |
| 热修复不计入 CFR | 热修复是典型的失败变更，必须计入 |
| CFR 越低越好 | CFR 为 0% 可能意味着变更过于保守或不敢上线 |
| 只看 CFR 不看 DF | CFR 需与部署频率（DF）联合分析，低频高成功率无意义 |
联合分析示例： 团队 A 部署频率 100 次/周，CFR 10%（10 次失败）；团队 B 部署频率 5 次/周，CFR 0%（0 次失败）。团队 A 虽然失败次数多，但快速试错、快速修复，整体交付效率远高于团队 B。