头图

DevOps效能度量

Woody

前言

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

阅读 695

Woody的专栏
Woody的专栏会记录一些技术文章,技术洞见,和好玩的技术东西。

ThoughtWorks|高级咨询师

804 声望
45 粉丝
0 条评论
你知道吗?

ThoughtWorks|高级咨询师

804 声望
45 粉丝
宣传栏