前言

之前做了几个公司的 DevOps 转型，发现不少公司都比拟热衷于如何去度量 DevOps 效力。（一部分起因是领导们想要以此来考核 KPI。）

度量的形式有很多种，这里我就基于这些年 DevOps 征询的教训，总结了一些可度量的指标供大家参考。

大家能够依据不同的指标组合应用，并联合本人的团队的理论状况，量力而为。有些指标须要本人依据状况开发脚本来统计。

其实目前市面上的大部分 DevOps 工具或平台，都或多或少的有了各种数据报表，来帮忙团队进行 DevOps 效力度量。

DevOps 效力度量指标

效力等级

效力次要分为 4 个等级：

1. 精英效力
2. 高效能
3. 中等效力
4. 低效能

精英效力则是以谷歌、微软、亚马逊等公司的 DevOps 先驱团队为代表的团队水准。

高效能是目前大部分 DevOps 实际做得好的团队水准。

中等效力则代表了大部分正在 DevOps 摸索路上的团队水准。

低效能则是大部分还没开始应用 DevOps 的团队水准。

度量指标

度量指标有两种：

• 后果指标
• 过程指标

过程指标远多于后果指标，过程指标是帮忙咱们改良麻利开发过程的。后果指标多用于做总结汇报。

阶段分类

DevOps 是一个十分长的价值流，那么在这个过程中，咱们大抵能够把它分为三个阶段来进行效力度量。

1. 麻利开发治理
2. 继续交付
3. 技术运维

第一个阶段次要对应了需要和治理局部。

第二个阶段次要针对整个研发过程。

第三个阶段次要针对上线后的运维局部。

所有的指标又能够分为交付效率和品质两类。

因而把所有指标汇总一下，就如下图一样。

DevOps 效力度量指标详解

• 用户故事交付周期

  - 用户故事从创立到上线所须要的工夫。- 计算形式：一个用户故事从创立到上线所需的工夫。

• 用户故事吞吐量

  - 一个迭代内能实现的用户故事总数。- 计算形式：迭代内实现用户故事数。

• 用户故事完成率

  - 一个迭代内，布局的用户故事数与实现的用户故事数的比率。- 计算形式：理论实现用户故事数 / 布局用户故事数。

• 团队速率

  - 一个团队每个迭代能实现故事点的数量。- 计算形式：每个迭代实现故事点数。

• 故事点完成率

  - 一个迭代内，布局的故事点数与实现的故事点数的比率。- 计算形式：理论实现的故事点 / 布局的故事点。

• 需要停留时长

  - 一个需要从创立到剖析实现后，并进入开发所花的工夫。- 计算形式：需要移动到“开发中”列的工夫点 - 需要呈现在“待处理”列的工夫点。- 备注：需要剖析实现后在期待开发中也算期待老本。这里其实度量的就是 Processing time。

• 研发停留时长

  - 一个需要开发实现所须要的工夫。- 计算形式：需要移动到“测试中”列的工夫点 - 需要呈现在“开发中”列的工夫点。- 备注：需要开发实现后在期待测试中也算期待老本。这里其实度量的就是 Processing time。

• 测试停留时长

  - 一个需要测试实现所须要的工夫。- 计算形式：需要移动到“待上线”列的工夫点 - 需要呈现在“测试中”列的工夫点。- 备注：这里其实度量的就是 Processing time。

• 部署频率

  - 代码部署到服务器的频率，不论是测试环境还是生产环境。- 计算形式：距离多久部署一次 

• 公布频率

  - 代码公布到生产环境的频率。- 计算形式：距离多久公布一次。- 备注：公布频率是小于部署频率的。

• 公布时长

  - 一次公布上线的过程所需的工夫。- 计算形式：一次公布所需工夫。

• 公布失败率

  - 公布上线有可能失败，此指标用于统计失败率。- 计算形式：公布失败次数 / 公布总次数 

• 变更前置工夫

  - 从代码提交到代码正式运行在生产环境所须要的工夫。- 计算形式：代码上线工夫 - 代码提交工夫。

• 构建频率

  - 构建产生的频率
  - 计算形式：一个迭代内构建的次数 

• 构建失败率

  - CI 在构建的时候会因为各种起因失败
  - 计算形式：迭代内构建失败次数 / 迭代内构建总次数 

• CI 修复时长

  - CI 红了之后须要花工夫去修复，此指标统计修复 CI 所需的工夫。- 计算形式：CI 从新变绿的工夫 - CI 变红的工夫 

• 代码坏滋味数

  - 很多代码扫描工具都能统计代码坏滋味，比方 Sonar。- 计算形式：单次构建扫描的坏滋味数，取屡次的平均数。

• 代码反复率

  - 反复代码在代码库中的占比。Sonar 等工具能统计后果。- 计算形式：反复代码数量 / 总代码数。

• 代码扫描 bug 数

  - Sonar 等工具能扫描出代码中存在的 bug 数。- 计算形式：迭代内代码扫描 bug 呈现的次数。

• 代码扫描破绽数

  - Sonar 等工具能扫描出代码中存在的破绽数。- 计算形式：迭代内代码扫描破绽呈现的次数。

• 代码提交频率

  - 统计每日代码提交的次数。- 计算形式：每日代码 commit 或 push 次数。

• 代码合并次数

  - 统计周期时间内代码合并的次数。- 计算形式：迭代内代码 merge request 次数。

• 代码评审通过率

  - 每次代码评审都有可能因为代码品质起因不通过。- 计算形式：迭代内代码评审通过次数 / 迭代内代码评审总次数 

• 自动化测试率

  - 测试工作有多少是自动化实现的，而不依赖于人工测试。- 计算形式：（主动执行测试用例数 - 人工执行测试用例数）/ 总测试用例数
  - 备注：测试分为很多类型：单元测试、集成测试、验收测试、性能测试、平安测试等，能够别离度量。

• 自动化测试失败率

  - CI 跑的测试是会因为各种起因失败的，这个指标用于统计失败的频率。- 计算形式：CI 测试失败次数 /CI 测试执行总次数 

• 测试覆盖率

  - 测试所笼罩的代码的比率
  - 计算形式：大部分测试工具都能主动统计测试覆盖率，比方 Jacoco

• 缺点修复时长

  - 一个缺点修复所需的工夫。- 计算形式：一个缺点修复所需的工夫。

• 缺点密度

  - 统计一个迭代内缺点呈现的密度。- 计算形式：迭代内缺点个数 / 迭代内用户故事数 

• 服务复原工夫

  - 一次服务故障复原所需的均匀工夫。- 计算形式：服务复原工夫 - 服务故障产生工夫 

• 生产问题个数

  - 统计周期时间内生产问题的个数，屡次统计后以计算平均数。- 计算形式：用户故事上线后 2 个迭代内生产问题的个数。

• 生产问题密度

  - 统计周期时间内生产问题产生的密度。- 计算形式：用户故事上线后 2 个迭代内产生的问题个数 / 2 个迭代的用户故事数
  

每个指标对于具体的等级的数值请参考下表。

总结

DevOps 是麻利开发的一种演进，通过联合人、流程与工具，继续改良研发效力。

因而度量只是一种可视化伎俩，真正能进步效力的还是要从文化、组织、技术等方面去建设 DevOps。一直打消节约，进步生产效率。

对于此 DevOps 效力度量有任何疑难欢送找我探讨。我也会在后续的征询工作中一直去总结和改善这个效力度量指标。