暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / DevOps效能度量

DevOps效能度量

Woody的专栏 2021-04-14
744

前言

之前做了几个公司的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效能度量有任何疑问欢迎找我讨论。我也会在后续的咨询工作中不断去总结和改善这个效能度量指标。
数据库
文章转载自Woody的专栏，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论