3、变更失败率定义：变更失败率的计算公式、业界基准、与MTTR/MTBF的关系

变更失败率（Change Failure Rate, CFR）是平台工程中衡量变更质量的核心指标，也是 DORA（DevOps Research and Assessment）四关键指标之一。它直接反映了一次变更上线后导致服务降级、故障或回滚的概率，是评估变更风险与交付稳定性的关键依据。

3.1 变更失败率的计算公式

变更失败率的定义非常明确：在特定时间窗口内，导致服务故障或需要修复的变更次数占总变更次数的比例。其标准计算公式如下：

变更失败率（CFR） = （导致服务故障的变更次数 / 总变更次数） × 100%

在实际平台工程中，计算时需注意以下关键点：

• 时间窗口：通常以周或月为统计周期，建议与团队迭代节奏对齐。
• 故障判定标准：仅统计由变更直接引发的生产事故、严重告警或回滚操作，排除环境波动、外部依赖等非变更因素。
• 变更范围：包括代码部署、配置变更、基础设施变更、数据库迁移等所有生产环境变更。

3.2 业界基准与分级标准

根据 DORA 2023 年度报告，变更失败率在不同效能等级的团队中呈现显著差异。以下为业界公认的基准分级：

平台工程团队应将 CFR ≤ 5% 作为长期目标，同时结合部署频率（Deployment Frequency）综合评估，避免因追求低失败率而过度抑制变更频率。

3.3 变更失败率与 MTTR / MTBF 的关系

变更失败率并非孤立指标，它与 MTTR（平均修复时间）和 MTBF（平均故障间隔时间）共同构成了服务可靠性的三角评估体系。三者之间的关系如下：

• CFR 与 MTTR 的正相关：高变更失败率通常意味着团队频繁处理故障，若 MTTR 也较高，则表明故障恢复能力不足，形成“变更多→故障多→恢复慢”的恶性循环。
• CFR 与 MTBF 的负相关：变更失败率越低，服务稳定性越高，故障间隔时间（MTBF）自然延长。反之，高 CFR 会频繁打断正常运行周期，缩短 MTBF。
• 综合评估模型：仅关注 MTTR 或 MTBF 可能掩盖变更质量的问题。例如，MTBF 很长但 CFR 很高，说明变更虽少但每次变更风险极大；MTTR 很短但 CFR 也很高，说明团队虽能快速修复，但变更质量仍需提升。

3.4 平台工程中的联合监控策略

在平台工程自助服务体系中，建议将 CFR、MTTR、MTBF 纳入统一的 SLO 仪表盘，并设置以下联合告警规则：

• CFR 超标 + MTTR 上升：触发“变更质量与恢复能力双重恶化”告警，建议暂停高风险变更，启动变更流程审查。
• CFR 正常但 MTBF 下降：可能由非变更因素（如外部依赖、基础设施老化）导致，需排查环境稳定性。
• MTTR 极低但 CFR 持续偏高：团队可能陷入“快速修复但反复出错”的救火模式，应优先改进变更前测试与验证环节。