17 个可以衡量成功的 DevOps 指标

今天是「DevOps云学堂」与你共同进步的第 51天

---

软件开发的生产力一直很难衡量。与其他行业不同，编程行为不容易并行化。开发过程的独特之处在于它需要多种技术和沟通技能的组合，这需要一组专门的 DevOps 指标来跟踪团队的体征。

软件开发的脉搏

并非所有指标都是一样的。根据上下文，有些比其他更有用。我们选择衡量的事物可以帮助我们发现问题或掩盖不相关数据和非生产性目标背后的问题。
在决定跟踪哪些 DevOps 指标时，我们应该考虑以下几点：

1. 当人们感到被观察时，他们的行为不会一样。这称为霍桑效应，它会产生过度的压力。最好尽可能保持指标的非个人性和匿名性。

2. 第一点还意味着指标只能用于跟踪团队随时间的进展，而不是用于比较团队或个人。

3. 过分强调达到任意数字会产生对系统进行博弈的动机。戴夫·法利 (Dave Farley) 和杰兹·汉布尔 (Jez Humble) 就这个话题说道：

“衡量代码行数，开发人员会编写很多短行代码。测量已修复的缺陷数量，测试人员将记录可以通过与开发人员快速讨论来修复的错误。” —持续交付：通过构建、测试和部署自动化实现可靠的软件发布

因此，在选择要用于跟踪团队进度的指标之前，每个人都应该知道他们的唯一目的是跟踪进度并发现问题。它们并不是为了赞扬或惩罚个人。

四个 DORA 指标

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

DORA 指标是我们衡量软件开发的主要工具。它们由四个基准组成：

• 部署频率 ( Deployment frequency** **DF)：组织成功向用户发布产品或将其部署到生产环境的频率。

• 变更前置时间 (Lead time to changes** **LT)：提交达到生产或发布所需的时间。

• 平均恢复服务时间 (MTTR)：组织从生产故障中恢复需要多长时间。

• 变更失败率 (CFR)：导致生产失败的发布或部署的百分比。

开发团队可以分为四个级别之一：低、中、高和精英。

指标	Low 低	Medium 中	High高	Elite 精英
DF 部署频率	每6月至少1次	每月 1 次至每 6 个月 1 次	每周一次至每月一次	按需 一天多次
LT 变更前置时间	超过6个月	1-6个月	一天至一周	小于1小时
MTTR  平均恢复服务时间	超过6个月	1天至1周	小于1天	小于1小时
CFR 变更失败率	16~30%	16~30%	16~30%	0~15%

年复一年，DORA 研究团队证明，高 DORA 分数是高绩效的可预测指标。因此，它们应该包含在任何涉及软件开发的测量策略中。

周期

与 DORA 一样，周期时间也是生产力的另一个主要指标。它被定义为我们决定添加功能与将其部署或发布给公众或客户之间的平均时间。

快速的周期时间意味着团队能够以持续的速度持续交付功能。

质量

质量对于不同的人来说意味着不同的东西。虽然一些团队强调遵守样式规则，但其他团队可能更关心安全风险或保持愉快的用户体验。重要的是团队就质量要求达成一致。
我们可以使用多种参数来估计代码的质量。不符合预定质量标准的内容会导致 CI 管道失败。一些有价值的指标是：

• 漏洞数量。

• 违反代码风格指南。

• 代码覆盖率。

• 陈旧分支的数量。

• 圈复杂度。

• 打破了架构限制。例如，确保一个模块中的代码不会引用另一模块中的类。

客户的反馈意见

客户反馈可以有多种形式，例如开ticket、社交媒体上的提及以及从净推荐值 (NPS) 调查中收集的信息。具体情况因业务和产品而异，但我们必须以某种具体形式代表客户的声音，因为最终是他们付账的。

用户对产品满意吗？

员工满意度

我们必须关注的不仅仅是我们的用户和客户。开发人员、测试人员、质量和业务分析师、产品经理和经理也至关重要，因为我们需要他们所有人来打造出色的产品。最好的想法来自乐观、自信和充分休息的头脑。
员工满意度受到多种因素的影响，我们应该以某种方式来衡量：

• 文档的全面性和更新程度如何？

• 加入新开发人员有多容易？

• 员工是否觉得自己的声音被听到了？

• 工作/生活平衡如何？有人烧坏了吗？

• 工作场所是否是一个可以冒险和尝试的安全环境？

• 员工是否拥有合适的工具来完成他们的工作？

• 他们觉得自己可以安全地提出建设性批评吗？

平均 CI 持续时间

软件开发是一种实验练习——我们进行一些小的改变，然后看看它们的效果如何。来自CI 管道的反馈最终决定更改是否保留在代码库中。
当 CI/CD 过程缓慢时，以小增量工作会变得痛苦，因为开发人员必须等待查看结果，或者继续前进并尝试记住在结果出现时返回到管道。无论哪种情况，都非常困难保持创意的流动。

CI 管道的平均持续时间应以分钟为单位进行测量。我们的目标应该是少于 10 分钟，以保持开发人员的参与度和代码的流畅性。如果您的管道花费太长的时间，请查看Semaphore 的测试优化指南。

CI 每天运行

这是每天 CI 管道执行的数量。我们希望保持这个数字较高——每个活跃开发人员至少运行 4 或 5 次——因为这意味着开发人员信任并依赖 CI/CD 流程。
当每天运行的 CI 减少时，可能是由于 CI/CD 系统缓慢或难以使用造成的。

CI 平均恢复时间 (MTTR)

当构建不起作用时，我们无法测试、发布或部署。在这种情况下，每个人都应该停止正在做的事情，专注于恢复构建。平均恢复时间衡量团队修复损坏的 CI 构建平均需要多长时间。在衡量这个指标时，我们通常只关心主分支。
较长的恢复时间表明我们需要努力使 CI/CD 流程更加稳健。我们还必须确保优先修复 CI 构建的习惯在团队文化中根深蒂固。

CI测试失败率

测量 CI 管道因测试失败而失败的频率。测试是一个安全网，因此失败并没有什么问题。尽管如此，开发人员应该在提交代码之前在他们的机器上运行测试。如果失败率太高，则可能表明开发人员发现很难在本地运行测试。

CI 成功率

CI 成功率是 CI 成功运行的次数除以运行总数。成功率低表明 CI/CD 过程很脆弱，需要更多维护，或者开发人员过于频繁地合并未经测试的代码。

不稳定性

不稳定表明 CI 管道的脆弱程度。不稳定的构建会无缘无故地随机失败或成功。不稳定是由不稳定的测试或不可靠的 CI/CD 平台引起的。不稳定的测试会对 CI 运行时间、成功率和恢复时间产生负面影响。

“测试摘要”选项卡显示不稳定且缓慢的测试。

覆盖范围

代码覆盖率是测试套件覆盖的代码的百分比。这有点有争议，因为众所周知，这是一个经常被滥用的指标。例如，要求 100% 的覆盖率并不能提高质量——相反，它会导致对琐碎代码进行不必要的测试。
与其他任何事情一样，适度使用覆盖范围是有用的。例如，一个覆盖率为 5% 的项目无疑没有经过测试，以至于测试结果并没有向我们展示太多内容。

缺陷逃逸率

测量 CI/CD 过程未检测到的错误数量。高值意味着测试不充分。在这种情况下，我们应该检查覆盖率值，然后重新评估测试套件的结构。我们的测试套件中可能需要更多类型的测试。

正常运行时间

正常运行时间是应用程序可用的时间百分比。该值越高，特定时期内的中断次数越少。例如，99.9% 的正常运行时间相当于每年 8 小时 45 分钟的停机时间。此运营 DevOps 指标应始终成为我们衡量的一部分，因为每次站点或应用程序停机时我们都面临着失去客户的风险。
正常运行时间值低表明基础设施、代码和/或部署过程中存在问题。

服务水平指标

签署服务级别协议 (SLA) 的企业必须注意正常运行时间，以避免罚款或其他处罚。服务级别指标 (SLI) 将实际应用程序性能或正常运行时间与预定标准进行对比。
即使 SLA 未生效，公司也可以建立内部服务级别目标 (SLO)，以完成相同的功能。

SLI 展示了现实与 SLA 或 SLO 的对比。

平均检测时间

这是问题在被发现并分配给适当团队之前在生产中持续存在的平均时间。我们可以用从问题开始到提出问题或票证的时间来衡量。平均检测时间与监控的全面程度和通知的有效性直接相关。

故障间隔时间。

平均故障间隔时间

衡量系统或子系统平均发生故障的频率。它是一个适合测量应用程序子组件稳定性的指标。它可以帮助我们确定哪些部分需要重构。

DevOps Metrics 只是测量症状

指标是项目的生命体征。糟糕的指标只是一种症状，而不是疾病。他们指出了问题的存在，但没有明确说明根本原因。虽然通过“管理”指标下的变量来解决问题可能很诱人，但这样做类似于自我治疗——它只能成功地隐藏症状。像任何优秀的医生一样，优秀的工程师会进行调查，提出解决方案，并通过检查指标是否有所改善来确认其有效性。
感谢您的阅读，祝您测量愉快！