17个DevOps指标

      软件开发的生产力一直是很难衡量的。与其他行业不同，编程行为并不容易并行化。开发过程是独特的，因为它需要技术和沟通技能的多样化组合，这就要求有一套专门的指标来跟踪团队的生命力。

软件开发的脉搏
      并非所有的衡量标准都是平等的。根据不同的环境，有些比其他的更有用。我们选择测量的东西可以帮助我们发现问题，也可以把问题掩盖在不相关的数据和非生产性的目标后面。

在决定要跟踪哪些指标时，我们应该考虑几点:

1. 当人们感到被观察时，他们的行为是不一样的。这被称为霍桑效应，它可能会造成不适当的压力。最好是在可能的情况下保持指标的非个人化和匿名性。
2. 第一点也意味着，指标应该只用于跟踪一个团队在一段时间内的进展，而不是用来比较团队或个人。
3. 过分强调达到一个任意的数字，会刺激人们去玩弄这个系统。Dave Farley和Jez Humble对这个问题有这样的看法:

"衡量代码行数，开发人员会写很多短的代码行。衡量缺陷修复的数量，测试人员会记录那些可以通过与开发人员快速讨论来修复的缺陷"。

----- <<持续交付--通过构建、测试和部署自动化实现可靠的软件发布>>

因此，在选择你想用来跟踪团队进展的指标之前，每个人都应该知道，它们的唯一目的是跟踪进展和发现问题。它们的目的不是为了表扬或责备个人。

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

部署频率（DF）：一个组织成功向用户发布产品或将其部署到生产的频率。
变更准备时间（LT）：一个承诺到达生产或发布所需的时间。
恢复服务的平均时间（MTTR）：一个组织从生产故障中恢复的时间。
变更失败率（CFR）：在生产中导致失败的发布或部署的百分比。

开发团队可以被排在四个级别中的一个。低，中，高，和精英。

年复一年，DORA研究小组已经证明，DORA高分是一个可预测的高绩效指标。因此，它们应该被纳入任何涉及软件开发的测量策略中。

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

周期时间跨越了整个功能开发的过程，从开始到现实。当一个功能的第一行代码被提交时，更改的准备时间就开始计时。

快速的周期意味着一个团队可以持续不断地交付功能。

质量
质量对不同的人意味着不同的东西。有些团队强调遵守风格规则，而其他团队可能更关心安全风险或保持愉快的用户体验。重要的是，团队对质量的含义达成了一致。

我们可以使用各种参数的组合来估计代码的质量。那些不符合预定质量标准的代码应该导致CI管道的失败。一些有价值的指标是。

漏洞的数量。
违反风格指南的情况。
代码覆盖率。
陈旧分支的数量。
循环复杂性。
破解架构约束。例如，确保一个模块的代码不引用另一个模块的类。

客户反馈
客户的反馈有多种形式，例如打开的票据、使用模式、在社交媒体上的提及，以及从净促进分数（NPS）调查中收集到的信息。具体情况因业务和产品而异，但我们必须以某种具体形式代表客户的声音，因为在一天结束时，他们支付账单。

员工满意度
我们的用户和客户并不是我们必须关注的唯一对象。开发人员、测试人员、质量和业务分析人员、产品经理和管理人员也是至关重要的，因为我们需要他们都来制作一个伟大的产品。最好的想法来自于乐观、自信和休息好的头脑。

员工的满意度受到各种因素的影响，我们应该以某种方式衡量这些因素。

文件的全面性和更新程度如何？
新的开发人员入职有多容易？
员工是否觉得他们的声音被听到了？
工作/生活的平衡情况如何？是否有人感到疲惫？
工作场所是否是一个安全的环境，可以冒险和实验？
员工是否有合适的工具来完成他们的工作？
他们是否觉得自己可以安全地提出建设性的批评意见？

平均CI时间
软件开发是一项实验性的工作--我们做一些小的改动，看看它们的效果如何。来自CI管道的反馈最终决定了一个变化是否会留在代码库中。

当CI/CD过程缓慢时，小规模的工作变得很痛苦，因为开发人员必须等待看到结果，或者继续前进，并努力记住在结果出来时返回管道。在这两种情况下，都很难保持创造性的流程。

CI管道的平均持续时间应该用分钟来衡量。我们应该以至少十分钟为目标，以保持开发人员的参与和代码的流动。

每天CI运行次数
这是每天CI管道执行的数量。我们希望保持这个数字较高--每个活跃的开发者至少有四到五次运行--因为这意味着开发者信任并依赖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分钟的停机时间。这个运营指标应该始终是我们测量的一部分，因为每次网站或应用程序出现故障时，我们都有可能失去客户。一个低的正常运行时间值指出了基础设施、代码和/或部署过程中的问题。

服务水平指标
       签署服务水平协议（SLA）的企业必须注意正常运行时间，以避免罚款或其他处罚。服务水平指标（SLI）将实际应用性能或正常运行时间与预先确定的标准进行对比。即使在SLA没有生效的情况下，公司也可以建立一个内部服务水平目标（SLO）来完成同样的功能。

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

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

衡量标准只是衡量症状
       指标是你项目的重要标志。一个糟糕的指标是一个症状，而不是一个疾病。它们指出了问题的存在，但并没有说明任何关于根本原因的明确信息。虽然通过 "管理 "指标下的变量来解决问题是很诱人的，但这样做就像自我治疗一样--它只能成功地隐藏症状。就像任何一个好医生一样，一个好的工程师会调查、提出解决方案，并通过检查指标是否有改善来确认其有效性。

---

今天先到这儿，希望对云原生，技术领导力， 企业管理，系统架构设计与评估，团队管理, 项目管理, 产品管管，团队建设 有参考作用 , 您可能感兴趣的文章:
领导人怎样带领好团队
构建创业公司突击小团队
国际化环境下系统架构演化
微服务架构设计
视频直播平台的系统架构演化
微服务与Docker介绍
Docker与CI持续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变

如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：

作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。