几十年来，各组织一直在尝试衡量软件开发生产力。注意力往往集中在易于量化的指标上，如工时、提交的代码行、功能点或每次冲刺添加的功能。遗憾的是，这些都不足以预测团队生产力。这是一个如此复杂的问题，以至于有些人宣称它不可能解决。
尽管这些尝试都失败了，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快速检查并找出答案！
