Four Key Metrics - 软件交付效能如何影响组织绩效

https://cloudplatformonline.com/2018-state-of-devops.html  和 https://puppet.com/resources/whitepaper/state-of-devops-report 发布了2018年发布了侧重于高绩效组织的数据驱动型统计分析的Devops报告，报告持续了多年，软件交付效能对于组织绩效的影响已经被研究和证明了多年，本文主要介绍一下在交付过程中最重要的四个指标，以及交付效率如何影响组织绩效的研究结果。

01 

持续交付的闭环

从整体组织交付效能提升的角度看业界的发展，CI，CD似乎是一条毕竟之路，管理了从需求，代码提交，构建部署，测试，验证反馈，甚至线上监控运维，回滚等整个发布环节。

从CD的角度，业界已经有了一个比较成熟的成熟度模型，在不同规模，业务形态的公司会有一定的区别，但是本质上是想通的，目标是一致的。从成熟度的角度，界定状态，找到问题，不断改进，形成反馈闭环才是”持续“的精髓所在，不断改进，有效的关键指标度量则是必要的环节。从下图简化的CD闭环来看，有效的度量能帮助我们看到，我们的改进和目标是否在improving和delivering我们的目标，并且从长远的角度可以一定预测表现和成本评估的帮助。

02

four key metrics

在通常的工程实践中，交付效率和交付质量是需要权衡和取舍的，但是从State of Devops大样本来看，最高效能的企业在交付效率和质量同样表现优秀，从CD的成熟度模型和”持续“的角度来讲，程度度到达一定程度，质量和效率会相互赋能、促进彼此。

虽然从精细化运营的角度，我们可以提供更多维度的度量，但是从执行成本和交付效能与组织绩效的关联程度，我们主要从两个维度，四个Metrics来说明。

交付频率（Deployment frequency） ：code发布的频率。

持续交付，”持续“也可以理解为高频率，高吞吐，高频率以为单次发布承担更小的风险，用户能够更快看到反馈的需求，同样可以更早的新功能验证和更多的反馈。

从企业的的调研结果看，高效的团队在发布频率上高于低效的团队，从数据统计上看最高（1460次）vs. 最低（32次）。

Cycle & Lead time

从两张图看Cycle和Lead time。

前两个指标一个衡量的是频率，一个是周期， 同样，有效度量的基石需要有达成共识的计算方式。

从数据统计上看，最快（60min）vs. 最慢（26940min）。

失败率（Failure rate）

影响发布的问题，比如break build， 配置错误等，pipeline的稳定性，代码的质量会直接影响发布频率和后面要提到的MTTR。

从数据统计上看，最好（0-15%）， 最差（46-60%）。

MTTR（平均恢复时间）

持续交付过程提到了fast feedback loop的重要性，低MTTR反映了更快的反馈。

从数据统计上看，最快（1h） vs. 平均（169h）vs. 最慢（5040h）。

总体上看，不同组织在4个重要指标上的表现差异。

最后，定义和度量只是开始，持续的践行和改进才是走向高效能团队的必经之路。

参考：

https://puppet.com/resources/whitepaper/state-of-devops-report

https://www.gocd.org/assets/images/campaign/ebook-cd-analytics/ebook-cd-analytics.pdf

https://cloudplatformonline.com/2018-state-of-devops.html

THE END

- 晚安 -

图片长按2秒，识别图中二维码，关注订阅号