DevOps效能度量

前言

之前做了几个公司的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效能度量有任何疑问欢迎找我讨论。我也会在后续的咨询工作中不断去总结和改善这个效能度量指标。