3. 变更失败率计算模型：分子与分母的精确界定

变更失败率（Change Failure Rate, CFR）是 DORA 四大核心指标中最能反映变更质量与稳定性的关键度量。其定义看似简单——失败变更次数 / 总变更次数——但在实际工程落地中，分子与分母的界定、时间窗口的选择以及滚动计算方式，直接决定了指标的可信度与可操作性。本节将逐一拆解这些核心设计要素。

3.1 分子：失败变更次数的精确界定

“失败变更”并非仅指变更本身执行失败，而是指变更上线后导致服务出现预期外负面行为。常见的界定标准包括：

3.2 分母：总变更次数的统计口径

分母的统计口径直接影响 CFR 的数值范围与可比性。常见口径包括：

• 生产环境部署次数：最常用口径，包含所有正式上线部署（含金丝雀、灰度、全量）。
• 代码合并次数：仅统计合并到主分支的 PR/MR 数量，适合与 CI/CD 流水线深度绑定。
• 功能发布次数：按功能特性维度聚合，一个功能可能包含多次部署，适合产品级度量。
• 配置变更次数：单独统计配置中心、动态开关、特性标记的变更，适合基础设施团队。

3.3 时间窗口选择：周/月/季度

时间窗口的选择决定了 CFR 的敏感度与稳定性。不同窗口适用于不同场景：

• 周窗口：敏感度高，适合快速反馈循环，但易受单次失败事件扰动，波动较大。
• 月窗口：平衡敏感度与稳定性，适合团队级月度复盘，是 DORA 官方推荐窗口。
• 季度窗口：稳定性最高，适合组织级战略度量，但反馈延迟较大，不适合快速迭代。

3.4 滚动窗口计算

固定时间窗口（如“本月 1 日到 30 日”）存在边界效应与数据滞后问题。滚动窗口（Rolling Window）通过持续滑动时间范围，提供更平滑、更实时的 CFR 趋势。

滚动窗口的核心参数：

• 窗口长度：如 7 天、28 天、90 天。
• 滑动步长：通常为 1 天（每日更新）或 1 周（每周更新）。
• 计算方式：每次滑动时，移除最旧的数据点，加入最新的数据点，重新计算 CFR。

# 伪代码：滚动窗口 CFR 计算
def rolling_cfr(deployments, window_days=28):
    """
    deployments: 按时间排序的部署记录列表，每条记录包含 timestamp 和 is_failure
    window_days: 滚动窗口天数
    """
    from collections import deque
    window = deque()
    cfr_series = []
    
    for dep in sorted(deployments, key=lambda x: x['timestamp']):
        # 添加当前部署
        window.append(dep)
        # 移除超出窗口的旧数据
        while window and (dep['timestamp'] - window[0]['timestamp']).days > window_days:
            window.popleft()
        # 计算当前窗口 CFR
        total = len(window)
        failures = sum(1 for d in window if d['is_failure'])
        cfr = failures / total if total > 0 else 0
        cfr_series.append((dep['timestamp'], cfr))
    
    return cfr_series

3.5 变更失败率计算模型总览

下图展示了完整的 CFR 计算模型，涵盖分子/分母界定、时间窗口选择与滚动计算流程：

3.6 服务画像工程中的 CFR 设计要点

在服务画像工程中，CFR 并非孤立指标，而是与变更频率、部署前置时间、平均恢复时间（MTTR）共同构成 DORA 四维度量。设计 CFR 时需注意：

• 服务粒度对齐：每个服务独立计算 CFR，避免跨服务聚合导致信号稀释。
• 变更类型标签：为变更打上“代码变更”“配置变更”“基础设施变更”等标签，支持按类型下钻分析。
• 失败根因关联：将失败变更与故障根因、回滚原因关联，形成改进闭环。
• 自动化采集：通过 CI/CD 流水线、部署平台、告警系统自动采集分子与分母数据，减少人工标注。