DORA 指标与 CI/CD 健康度

欢迎学习 DORA 指标！在现代软件开发中，仅仅部署代码还不够。我们需要了解开发和运营流程运行得有多好。

DORA 指标提供了一个强大的框架，用于衡量和改进 CI/CD 的健康状况以及整体 DevOps 性能。

DORA 代表 DevOps 研究与评估小组，该小组确定了四项能够预测软件交付性能和组织成果的关键指标。

• 部署频率 (DF)
• 变更前置时间 (LTFC)
• 平均恢复时间 (MTTR)
• 变更失败率 (CFR)

让我们逐一了解这些指标！

部署频率衡量您的组织成功将代码发布到生产环境的频率。它告诉您向用户交付价值的速度。

较高的部署频率通常意味着部署的变更更小、风险更低，从而带来更快的反馈循环和持续改进。

要跟踪部署频率，只需统计特定时间段内成功部署到生产环境的次数（例如每天、每周或每月）。

• 示例：如果您的团队一周部署 15 次，则 DF 为 15/周。
• 目标：提高这个数字。高水平团队每天会部署多次。

变更前置时间是指代码变更从提交到在生产环境中成功运行所需的时间。它衡量整个开发流水线的速度。

该指标体现了开发流程的效率，包括编码、测试、审查和部署。

LTFC 从开发人员提交代码时开始，到该代码对用户正式生效时结束。它通常以小时或天为单位衡量。

• 示例：某项功能于周一上午提交，并在周二晚上于生产环境中上线，其 LTFC 约为 36 小时。
• 目标：缩短这一时间。更短的前置时间意味着更快的交付和更迅速的迭代。

平均恢复时间 (MTTR)衡量生产环境发生事故或故障后恢复服务所需的时间。它反映团队响应问题并从中恢复的能力。

较低的 MTTR 表明运营韧性较强，事故响应流程也更有效。

MTTR 从检测到事故的那一刻开始计算，直到服务完全恢复。它通常以分钟或小时为单位衡量。

• 示例：如果某应用中断需要 2 小时来识别、诊断和修复，则该事故的 MTTR 为 2 小时。
• 目标：缩短这一时间。更快的恢复可以减少对用户的影响和业务中断。

变更失败率是指导致服务降级、需要回滚或以其他方式必须立即修复的生产环境变更所占的百分比。

该指标对于了解部署流程的稳定性和可靠性至关重要。较高的 CFR 表明测试或部署实践中可能存在问题。

CFR 的计算方式是：将失败部署次数除以某一时间段内的部署总次数，再乘以 100。

• 示例：如果 100 次部署中有 5 次导致生产事故，则 CFR 为 5%。
• 目标：尽可能保持该数字较低。高水平团队的 CFR 通常低于 15%。

您已经学习了四项 DORA 指标。现在，让我们测试一下您对每项指标所衡量内容的理解。

恭喜您！您已经学习了四项 DORA 指标：

• 部署频率：发布的频率。
• 变更前置时间：代码上线的速度。
• 平均恢复时间：修复问题的速度。
• 变更失败率：部署导致问题的频率。

通过跟踪这些指标，您可以深入了解 CI/CD 的健康状况，并推动 DevOps 实践持续改进。