4、变更失败率的计算模型：基于部署次数的计算、基于时间窗口的计算、加权计算模型、多环境下的聚合计算
变更失败率（Change Failure Rate, CFR）是 DORA 四大核心指标中唯一衡量质量稳定性的指标。其核心定义是：在特定统计周期内，导致服务降级、回滚、修复或补丁的变更次数占总变更次数的比例。然而，在实际工程环境中，由于部署频率、环境拓扑、故障检测窗口的差异，CFR 的计算口径需要适配多种场景。本节将深入剖析四种主流计算模型，帮助你在不同组织成熟度下选择最合适的口径。
4.1 基于部署次数的计算（基础模型）
这是最直观、最符合 DORA 原始定义的计算方式，适用于部署频率稳定、变更粒度均匀的团队。
公式： CFR = (导致失败的部署次数 / 总部署次数) × 100%
关键判定标准：
- 失败定义：部署后 24 小时内触发了回滚、热修复、功能降级或 P0/P1 级告警。
- 计数单位：以“次部署”为原子单位，而非“次变更”。
- 适用场景：单环境、单服务、部署频率 ≤ 1 次/天。
| 维度 | 说明 | 示例 |
|---|---|---|
| 总部署次数 | 统计周期内所有生产环境的部署动作 | 30 次 |
| 失败部署次数 | 触发回滚或紧急修复的部署 | 3 次 |
| CFR 结果 | 3 / 30 = 10% | DORA 中等级别 |
实践建议：对于首次引入 DORA 度量的团队，建议从“基于部署次数”模型开始。它最容易从 CI/CD 流水线中直接采集，且与 DORA 原始基准（2021-2023）对齐。
4.2 基于时间窗口的计算（滑动窗口模型）
当部署频率极高（如每日多次部署）或故障检测存在延迟时，基于部署次数的模型会产生“分母膨胀”或“归属错位”问题。此时应采用时间窗口模型，将变更与故障在时间维度上对齐。
公式： CFR = (在时间窗口 T 内被标记为失败的变更数 / 在时间窗口 T 内完成的变更总数) × 100%
时间窗口 T 的设定规则：
- 固定窗口：按自然日/周/月统计，适合低频部署团队。
- 滑动窗口：以当前时刻为终点，向前回溯 N 小时（通常为 24h 或 48h），适合高频部署团队。
- 事件窗口：以每次部署为起点，向后观察 M 小时（通常为 1h-4h），适合微服务架构。
| 窗口类型 | 窗口长度 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|---|
| 固定窗口 | 1 天 / 1 周 | 低频部署（≤1次/天） | 易于理解，与报表周期对齐 | 无法反映实时状态 |
| 滑动窗口 | 24h / 48h | 高频部署（≥5次/天） | 实时性强，平滑异常峰值 | 计算复杂度较高 |
| 事件窗口 | 1h / 4h | 微服务、金丝雀发布 | 精确归因，减少误报 | 需要精确的部署时间戳 |
常见陷阱：使用滑动窗口时，如果窗口长度小于平均故障检测时间（MTTD），会导致大量“假阴性”——即故障发生在窗口外，但被错误地归因到窗口内的变更。建议窗口长度 ≥ 2 × MTTD。
4.3 加权计算模型（风险加权 CFR）
并非所有失败都具有相同的业务影响。一次导致全站宕机 30 分钟的失败，与一次导致 1% 用户延迟增加 200ms 的失败，在 DORA 度量中应被区别对待。加权计算模型通过引入“失败严重度权重”，使 CFR 更能反映真实的业务稳定性。
公式： 加权 CFR = (Σ(失败变更次数 × 严重度权重) / 总变更次数) × 100%
严重度权重定义（参考 SRE 故障等级）：
| 严重度等级 | 定义 | 权重 | 示例 |
|---|---|---|---|
| P0（严重） | 核心服务完全不可用，影响所有用户 | 1.0 | 数据库宕机、支付链路中断 |
| P1（高） | 核心功能受损，影响大量用户 | 0.7 | 搜索不可用、登录失败率 > 5% |
| P2（中） | 非核心功能异常，影响部分用户 | 0.4 | 推荐不准确、页面样式错乱 |
| P3（低） | 轻微体验问题，无功能损失 | 0.1 | 文案错误、图片加载慢 |
实践建议：加权模型特别适合平台工程团队和基础设施团队。这类团队的变更往往影响面广，一次失败的 P0 事件可能抵得上数十次 P3 事件。使用加权 CFR 可以避免“小失败淹没大事故”的度量失真。
计算示例对比：
| 变更编号 | 是否失败 | 严重度 | 权重 | 加权失败值 |
|---|---|---|---|---|
| #1001 | 是 | P0 | 1.0 | 1.0 |
| #1002 | 是 | P2 | 0.4 | 0.4 |
| #1003 | 否 | - | 0 | 0 |
| #1004 | 是 | P3 | 0.1 | 0.1 |
| #1005 | 否 | - | 0 | 0 |
| 合计 | 3 次失败 | - | - | 1.5 |
对比结果：
• 基础 CFR = 3 / 5 = 60%（DORA 低级别）
• 加权 CFR = 1.5 / 5 = 30%（DORA 中级别）
• 加权模型更准确地反映了“虽然失败次数多，但多为低影响事件”的真实情况。
• 基础 CFR = 3 / 5 = 60%（DORA 低级别）
• 加权 CFR = 1.5 / 5 = 30%（DORA 中级别）
• 加权模型更准确地反映了“虽然失败次数多，但多为低影响事件”的真实情况。
4.4 多环境下的聚合计算
现代软件交付通常涉及开发（Dev）、测试（Test）、预发布（Staging）、生产（Prod）等多个环境。不同环境的变更失败率具有不同的业务含义，需要采用分层聚合策略。
聚合策略对比：
| 聚合策略 | 计算方式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| 简单平均 | CFR_total = (CFR_dev + CFR_test + CFR_staging + CFR_prod) / 4 | 环境权重相同，流量均匀 | 计算简单 | 忽略环境重要性差异 |
| 加权平均 | CFR_total = Σ(CFR_env × weight_env) | 生产环境权重远高于非生产 | 反映真实业务影响 | 权重需要业务方确认 |
| 串联模型 | CFR_total = 1 - Π(1 - CFR_env) | 变更必须依次通过所有环境 | 反映整体交付链质量 | 假设环境间独立，实际有相关性 |
| 仅生产模型 | CFR_total = CFR_prod | 非生产环境不稳定或数据不可信 | 聚焦最终交付质量 | 丢失非生产环境的早期预警 |
关键原则：无论采用哪种聚合策略，生产环境的 CFR 必须单独报告，不能与非生产环境混合。DORA 基准中的 Elite/High/Medium/Low 分级仅针对生产环境。非生产环境的 CFR 应作为“质量门禁”的输入，而非最终度量。
4.5 模型选择决策矩阵
为帮助团队快速选择最合适的计算模型，以下提供决策矩阵：
| 团队特征 | 推荐模型 | 理由 |
|---|---|---|
| 部署频率 < 1 次/天，单服务 | 基于部署次数 | 简单直接，与 DORA 原始定义对齐 |
| 部署频率 ≥ 5 次/天，微服务 | 基于时间窗口（滑动窗口） | 避免分母膨胀，精确归因 |
| 变更影响差异大（P0 vs P3） | 加权计算模型 | 反映真实业务影响，避免度量失真 |
| 多环境交付链，需要端到端质量 | 多环境聚合（加权平均或串联） | 兼顾各环境质量，提供全局视图 |
| 刚启动 DORA 度量，数据基础薄弱 | 基于部署次数 + 仅生产模型 | 最小可行度量，快速建立基线 |
演进路径：建议团队按照“基础模型 → 时间窗口模型 → 加权模型 → 多环境聚合”的路径逐步演进。每个阶段至少稳定运行 2-4 个迭代周期，积累足够数据后再升级模型，避免一次性引入过多复杂度导致度量体系不可信。