变更失败率是什么
变更失败率是生产事故中与变更相关、需要修复行动（热修复、回滚、补丁）的比例，DORA 四项指标之一，用来观察发布质量而不是发布数量。统计关键是失败判定标准：通常以是否需要紧急修复发布为准，并依赖事故记录与部署记录的关联。批次越小、预发验证越完整、发布越渐进，该指标通常越低。
基本信息
| 分子 | 导致服务劣化并需修复行动的部署 |
|---|---|
| 分母 | 同期全部生产部署 |
| 判定 | 由事故记录与部署记录关联得出 |
| 改善 | 更小的批次、更完整的预发验证、渐进式发布 |
| 口径 | 先定好失败判定与统计窗口再开始收集 |
| 配套指标 | 与发布频次一起看，单独看容易误读 |
统计思路（伪代码）
统计思路（伪代码）
failed = deployments where incident_severity >= S2
and linked_change is not null
rate = len(failed) / len(all_deployments) * 100%
# 先定义失败的判定标准
# 再定义事故与部署的关联方式
# 最后固定统计窗口与分母口径口径要点
| 要素 | 做法 | 需要避免 |
|---|---|---|
| 分子判定 | 以是否需要紧急修复为准 | 把无关波动算作失败 |
| 分母范围 | 全部生产部署 | 混入日常维护任务 |
| 关联方式 | 事故记录回链部署号 | 靠人工回忆补记 |
| 统计窗口 | 固定按周或按迭代 | 随结论调整窗口 |
典型使用场景
- 发布质量回顾：按周或按迭代观察变更失败率的趋势
- 改进验证：缩小批次、补齐预发验证后，观察指标是否下降
- 事故归因：把每次需修复的事故关联到具体部署，积累样本
- 横向对比：先统一口径，再比较不同团队或服务的水平
- 与发布频次联动：只提升频次不管质量会推高变更失败率
- 复盘改进：失败率偏高的服务优先补预发验证与回滚演练
把环境与容量类事故混入分子：指标失真；应限定与具体变更关联的事件。
指标是观察工具而不是考核棒：用于考核容易诱发瞒报，反而失去参考价值。