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