【DevOps效能】使用DORA指标成为精英团队

几十年来，各组织一直在尝试衡量软件开发生产力。注意力往往集中在易于量化的指标上，如工时、提交的代码行、功能点或每次冲刺添加的功能。遗憾的是，这些都不足以预测团队生产力。这是一个如此复杂的问题，以至于有些人宣称它不可能解决。

尽管这些尝试都失败了，DORA还是着手制定发展生产力的衡量标准。

什么是DORA？

DORA（DevOps研究与评估）是一个由Nicole Forsgren、Jez Humble和Gene Kim于2015年成立的研究团队。该小组的目标是找到改进软件开发的方法。在七年的时间里，他们调查了数百个不同行业组织的数千名软件专业人员。

该团队的发现首次发表在《加速：精益软件和DevOps的科学》（2018）上。该书介绍了与高绩效组织相关的四个基准：DORA指标。

在上述书籍出版的同一年，谷歌收购了该集团，并成立了DORA研究项目，负责发布年度DevOps状态报告。

DORA指标是什么？

DORA的研究获得了突破性的见解，即在足够长的时间内，速度和质量之间没有权衡。换句话说，从长远来看，降低质量并不能带来更快的开发周期。

速度和稳定性都至关重要。以牺牲质量为代价来增加功能会导致不合格的代码、不稳定的发布和技术债务，最终扼杀进展。

DORA确定了软件开发的两个关键方面：

• 吞吐量：衡量新代码达到生产所需的时间。
• 稳定性：衡量部署失败的频率和修复的平均时间。

DORA用两个指标衡量稳定性：

• 恢复服务的时间（MTTR）：组织（平均）从生产故障中恢复所需的时间。
• 变更失败率（CFR）：导致生产失败的发布或部署的百分比。

在吞吐量方面，DORA又增加了两个指标：

• 部署频率（DF）：组织向用户成功发布产品或将其部署到生产中的频率。
• 变更交付周期（LT）：承诺达到生产或发布所需的时间。

​

DORA衡量软件开发的两个方面：稳定性和吞吐量。

​

DORA指标采用以下4个级别进行测量：精英、高级、中级和低级。

Metric	Low	Medium	High	Elite
部署频率	fewer than 1 per 6 months	1 per month to 1 per 6 months	1 per week to 1 per month	On demand (multiple deploys per day)
变更的交付周期	more than 6 months	1 month to 6 months	1 day to 1 week	Less than 1 hour
恢复服务的时间	more than 6 months	1 day to 1 week	Less than a day	Less than 1 hour
更改失败率	16 to 30%	16 to 30%	16 to 30%	0 to 15%

DORA水平

⚠️ 在《2022年DevOps状态报告》中，精英和高级被合并为一个层次。

根据《2021年DevOps状况报告》（PDF），不同级别的表现是惊人的。

💡 2021年，DORA团队引入了第五个指标：可靠性，通过评级组织如何达到或超过其可靠性目标来衡量运营绩效。

通过DORA指标达到精英水平

让我在本节的开头提出一些警告：

• DORA指标仅在跟踪团队在DevOps旅程中的进展时有效。它们不能用于比较团队或个人。
• 不应混淆目标和指标。由于所有指标都可以博弈，将指标等同于目标会导致不正当的激励。例如，如果管理层决定无论成本如何都要优化部署频率，那么部署他们能想到的任何微小更改都将符合团队的最大利益，无论它是否会为用户增加价值。
• 组织文化对团队绩效有着巨大的影响。我们稍后会在帖子中再次讨论这个问题。

好了，既然已经解决了，让我们继续吧。

在过去的几年里，精英球队的数量一直在增长。2018年，只有7%的团队或组织被视为精英。2021年，这一数字增长到26%。所以我们知道增长是可以实现的。

DevOps maturation of the software industry measured in DORA metrics. Source: State of DevOps Report 2021.

问题是如何使用DORA指标来提升团队或组织的比赛水平。度量中的错误值是一种症状。它表明存在组织、文化或技能问题需要解决。一旦对这些进行了管理，基本指标自然会得到改进。

提高吞吐量

生产周期较慢的组织部署频率较低，更改的交付周期较长。通常，我们可以通过优化连续集成和连续交付（CI/CD）、识别组织问题、加快测试套件以及减少部署摩擦来提高吞吐量。

问问自己，“是什么阻止我现在发布？”答案将揭示组织中的瓶颈。例如，您可能在代码评审上浪费了太多时间，等待QA批准更改，或者在其他团队完成其功能之前等待发布。

您可以通过多种方式提高吞吐量：

• 减小发布的大小。经常进行小型、安全的更换。如果某个功能还没有准备好进入黄金时段，请将其隐藏在功能标志后面或通过暗启动进行发布。
• 确保整个部署过程是自动化的，只需按下一个按钮即可完成。这意味着在部署过程中没有检查表，也没有人工干预。
• 采用基于主干的开发。它将减少合并冲突的机会，并鼓励合作。
• 通过管理缓慢的测试和删除零散的测试来优化持续集成的速度。
• 跟踪您在软件交付过程中的每个步骤上花费的时间。检查循环时间，找出可以节省时间的地方。

提高项目的稳定性

没有稳定性的速度最终会导致累积的技术债务，并花费更多的时间来修复错误，而不是发布功能。当稳定性指标看起来不好时，用户会有糟糕的体验，开发人员会把大部分时间花在灭火上，而不是编码上。

以下是一些可以用来提高稳定性的想法：

• 在CI管道中执行代码质量检查。拒绝发送不符合标准的代码。
• 加强代码同行评审过程，或尝试配对编程。
• 当灾难发生时，把重点放在恢复上，而不是所有其他任务上。
• 确保您的系统中有足够的监控和可观察性，以快速确定故障的原因。
• 每次发生严重停机时，都要召开“经验教训”会议。
• 在部署管道中使用烟雾测试，以避免在故障环境中部署。
• 实现部署的自动回滚。尝试金丝雀或蓝绿色部署。

生成性文化

也许不足为奇的是，《2021年DevOps现状》报告发现，精英团队与组织内的生成文化之间存在高度相关性。“生成文化”一词是由Ron Westrum创造的，用来描述一种包容、高度合作的文化，它提供了在不担心后果的情况下冒险所需的心理安全。

组织的文化超越了一个团队。它必须得到管理层的支持，由工程团队共享，并在整个公司进行维护。一种生成性的文化可以减少孤立，鼓励工程团队以外的合作。

不理智的 （以动力为导向）	官僚的 （以规则为导向）	生成 （以效能为导向）
Low cooperation	Modest cooperation	High cooperation
Messengers “shot”	Messengers neglected	Messengers trained
Responsibilities shirked	Narrow responsibilities	Risks are shared
Bridging discouraged	Bridging tolerated	Bridging encouraged
Failure leads to scapegoating	Failure leads to justice	Failure leads to inquiry
Novelty crushed	Novelty leads to problems	Novelty implemented

资料来源：组织文化类型学，Ron Westrum博士，2004年。

结论

认为改进DORA指标会自动产生更好的团队是错误的。恰恰相反：一种包容、生成的文化自然会产生更高的基准。换言之，在低合作、规避风险的环境中，没有机会维持一支精英团队。将指标设定为目标不仅目光短浅，而且往往是一个组织误入病态或官僚文化的指标。

你想知道你的DORA分数是多少吗？进行DevOps快速检查并找出答案！