2. 变更失败率（CFR）定义与口径
变更失败率（Change Failure Rate, CFR）是 DORA 四大核心指标中唯一衡量质量稳定性的指标。它回答一个关键问题：“我们部署的变更中，有多少比例导致了服务降级或需要立即修复？”。本章将深入拆解 CFR 的官方定义、计算公式、统计口径与常见误区。
2.1 官方定义
根据 DORA 2023 年加速状态报告（Accelerate State of DevOps Report），CFR 的官方定义为：
变更失败率 = 导致服务受损（如服务降级、故障、回滚、热修复）的部署次数 ÷ 总部署次数 × 100%
核心要点：
- 失败 不仅指完全宕机，还包括性能退化、功能异常、数据不一致等任何需要人工干预的负面事件。
- 变更 指任何对生产环境的代码、配置、基础设施的修改，包括常规发布、紧急修复、配置推送。
- 统计周期 通常以周或月为单位，DORA 建议至少观察 4 周以上以获得稳定基线。
2.2 计算公式与口径
CFR 的标准计算公式如下：
CFR = (失败部署次数 / 总部署次数) × 100%
示例：
- 本月总部署次数：50 次
- 其中导致回滚或热修复的部署：3 次
- CFR = (3 / 50) × 100% = 6%统计口径关键参数
| 参数 | 推荐口径 | 说明 |
|---|---|---|
| 时间窗口 | 滚动 4 周 / 月度 | 避免单周波动；建议使用滚动窗口平滑数据 |
| 失败判定标准 | 回滚、热修复、服务降级、P1/P2 事故 | 需团队事先定义“失败”的明确边界 |
| 分母（总部署） | 所有生产环境部署 | 包括常规发布、紧急修复、配置变更 |
| 分子（失败部署） | 触发上述失败标准的部署 | 同一部署触发多个失败事件只计 1 次 |
| 排除项 | 预发布/测试环境、非生产变更 | 仅统计生产环境 |
2.3 失败判定标准详解
实践中，团队需要将“失败”操作化。以下是 DORA 推荐的判定层级：
- 回滚（Rollback）：部署后立即或短期内执行回滚操作，无论是否触发事故。
- 热修复（Hotfix）：因本次部署导致问题，需紧急发布修复版本。
- 服务降级（Degradation）：响应时间增加 >50%、错误率上升 >1%、吞吐量下降 >30%（需团队设定阈值）。
- 事故（Incident）：触发 P1（严重）或 P2（高）事故响应流程。
- 用户反馈：来自监控、告警、客服或用户报告的明显功能异常。
建议：团队应建立一份“失败判定清单”，并在每个部署后自动或人工标记是否命中清单中的任意一条。清单需每季度评审更新。
2.4 CFR 统计流程 SVG
下图展示了从部署到失败判定的完整统计流程：
2.5 常见误区与避坑指南
| 误区 | 错误做法 | 正确做法 |
|---|---|---|
| 只统计宕机 | 仅当服务完全不可用时才记为失败 | 包含性能降级、错误率上升、回滚等所有人工干预场景 |
| 忽略热修复 | 热修复被视为“正常部署”不计入失败 | 热修复是典型的失败响应，必须计入分子 |
| 时间窗口过短 | 只统计 1 天或 1 周的 CFR | 使用滚动 4 周窗口，避免小样本偏差 |
| 分母口径不一致 | 只统计“主要发布”，忽略配置变更 | 所有生产变更（代码+配置+基础设施）均计入分母 |
| 重复计数 | 一次部署同时触发回滚和事故，计 2 次失败 | 一次部署只计 1 次失败，避免夸大 |
| 手动统计偏差 | 依赖人工回忆或手动标记 | 通过 CI/CD 流水线自动标记回滚/热修复，结合监控告警自动判定 |
关键提醒：CFR 的目标不是“零失败”，而是可观测、可改进。精英团队的 CFR 通常 <5%，但即使达到 15% 也属于中等水平。重要的是建立一致的统计口径，让趋势说话。
2.6 质量门禁与 CFR 联动
在质量门禁实战中，CFR 通常作为后置门禁的输入指标：
- 门禁阈值：例如 CFR > 10% 时，自动暂停该团队的部署流水线，触发复盘。
- 门禁动作：生成失败分析报告、通知 On-Call 负责人、锁定后续发布直到 CFR 回落。
- 门禁周期：建议以滚动 4 周 CFR 为门禁判断依据，避免单次波动导致误触发。