持续交付报告解读：敏稳双运，精英级效能组织DevOps五大黄金指标

持续交付基金会（CDF）在近期发布了持续交付报告，初读报告的时候，还是有些许震惊，持续交付已经持续多年，但是依旧有很多企业或者组织很难做到。

报告原文在https://cd.foundation/state-cd-report/。报告大体分为以下个部分：

报告前言

•持续交付概述（what is continuous delivery)•持续交付的重要性（why does continuous delivery matter）•持续交付的度量（how to measure success in software delivery)

报告主体

•部署频率（Deployment frequency）•变更前置时间（Lead Time For Chances）•服务恢复时间（Time To Restore Service)•不同行业的的软件交付效能•不同编程语言的的软件交付效能

报告前言

什么是持续交付

持续交付在不同行业和领域都扮演着重要的角色。它可以加速软件新功能的交付，当然需要确保服务的可靠和安全。

持续交付是一种软件开发的实践方式，它能够让团队以安全、快速和稳定的方式来向用户交付软件变更。持续交付对于团队是如何交付价值来讲是非常重要的。对于现代化企业来讲，随时交付可靠的软件变更是非常重要的。

持续交付和 DevOps 是息息相关的，因为 DevOps 是一个旨在改善持续交付的组织和文化运动，旨在改善持续交付，并在软件利益相关者（stakeholder）之间建立共同的所有权。

持续交付为 Netflix 的创新提供动力，我们很高兴能成为持续交付基金会的创始成员。与其他领先的从业者合作促进持续交付是一个令人兴奋的机会，我们可以联合起来，把快速、可靠和安全交付的好处带给更大的社区。 

– Andy Glover, 产品交付总监, Netflix

为何持续交付如此重要？

所有的企业和组织都不得不适应在不断变化的环境中进行运作。在传统方式下，业务的开始往往来源于针对一件产品或者服务的一些想法，这些想法被认为是需要的。然后他们花费时间来打造产品，之后将其推送给潜在用户。当他们不能从客户那里获得广泛的接受时，通常是因为他们从未收到潜在客户的早期反馈，以确定产品和服务是否是他们想要的。

现在精益方法能够帮助组织以更加精简的方式来进行创新。和客户反复进行想法沟通，通过构建一系列的验证实验来测试一个想法在最小可行规模下的实用性。对于那些高度契合市场的想法，可以进行大量投资。精益方法的关键是要减少软件安全、可靠交付的时间。持续交付是关于优化软件交付循环，使企业能够负担得起尽可能多的迭代，以最大限度地提高发现一个能在不断变化的市场中取得成功的功能或服务的机会。

除了创新和适应不断变化的市场的关键之外，研究表明，持续交付对组织、其流程和团队的好处已得到证实。

对于组织

•加速新功能的交付•提升对外部变化的响应•构建深度的用户关系

对于流程

•快速反馈和洞察力•减少部署痛点•提高质量

对于团队

•创造一个高可信的文化•提升员工的工作满意度•减少倦怠

如何度量软件的成功交付？

为何实现持续交付，组织必须采取一系列的实践并且持续进行改进。这些实践包括持续集成、自动化测试、持续部署、安全自动化等。为了了解这些努力是否是有效的，重要的一点是对一些重点指标进行跟踪。Nicole Forsgren 等人在《加速》一书的研究中确定了四个关键指标用来衡量软件交付效能，同时也是对组织效能的预测。对于同行评审的研究发现，在这些指标上表现良好的团队，在产品或服务质量、客户满意度和实现任务目标方面超过目标的可能性是原来的两倍。

速度（Speed）

•部署频率（Deployment frequency）：团队成功上线的频率，比如每天、每周、每月甚至每年•变更前置时间（Lead Time for Changes）：从代码提交到上线的时间中位数

稳定性（Stability）

•变更失败率（Change Fail Rate）：部署失败次数在部署次数中的占比•服务恢复时间（Time to Restore Services）：针对一次故障，造成故障的部署与故障恢复之间的时间中位数

四大关键指标是任何组织走向成功的指明灯。它们是与业务成功紧密结合的且 IT 相关的指标。衡量标准有一种简单性，有助于形成一种共同的语言和团队的共同关注点。这些衡量标准 也适用于任何团队，无论该团队的速度或背景如何。

– Nicholas Penston, 富达投资公司副总裁兼企业云计算工程部负责人

报告正文

2021 软件交付效能

对上述四个关键指标，我们希望能有一个更好的共同观点，即对于每个行业的开发者来说，软件交付性能的现实情况是什么。我们最近委托了 SlashData，一家每年对 4 万多开发者进行调研的公司，来开发一个供我们社区使用的仪表盘。该仪表盘基于SlashData的“开发者国家” 调研。该调研涉及来自 155 个国家的 19,000 多名受访者，是在 2020 年 12 月至 2021 年 2 月期间进行的。

仪表盘提供了关于变更前置时间、部署频率以及服务恢复时间的可视化。目前还没有变更失败率的数据。可以通过对编程语言和行业做筛选来查看响应的报告。这些数据可以作为一个基线，我们可以观察到软件交付性能是如何随着时间变化的，特别需要注意的是，持续交付基金会一直在寻求提高世界上以速度、安全和稳定的方式交付软件的能力。

如下是关键指标的仪表盘

部署频率

在部署频率这一项上，只有十分之一的开发者属于精英层，也即他们每天可以有多个部署。

样本数为 n=8,354。

•部署频率少于六个月每次的占比为 11.4%•部署频率为每月一次到每六个月一次的占比为 26.4%•部署频率为每周一次到每个月一次的占比为 31.3%•部署频率为每天一次到每周一次的占比为 16.5%•部署频率为每小时一次到每天一次的占比为 3.51%•部署频率为每天按需部署的占比为 10.8%

变更前置时间

接近三分之二的开发者表示从代码提交到成功上线大概需要花费一周时间。

样本数为 n=8,572

•9.02% 的人表示变更前置时间超过 6 个月•27.3% 的人表示变更前置时间在 1 到 6 个月之间•28.3% 的人表示变更前置时间在 1 周到 1 个月之间•19.6% 的人表示变更前置时间为 1 天到 1 周•10% 的人表示变更前置时间为 1 小时到 1 天•5.74% 的人表示变更前置时间小于 1 小时

服务恢复时间

一半的开发者报告说，他们在不到一天的时间内就能从计划外的故障中恢复服务。

样本数为 n=7,941

•6.29% 的人表示服务恢复时间超过 6 个月•13.4% 的人表示服务恢复时间为 1 到 6 个月之间•14% 的人表示服务恢复时间超过 1 周到 1 个月之间•16.9% 的人表示服务恢复时间在 1 天到 1 周之间•34.4% 的人表示服务恢复时间在 1 个小时到 1 天之间•15% 的人表示服务恢复时间小于 1 个小时

不同行业的软件交付效能

仪表盘可以让我们看到不同行业的软件交付效能，以让我们能够试图回答这些问题：“不同行业在软件交付方面的表现如何？”。我们可以得到一个“Speed“指标（变更前置时间和部署频率）为横坐标，以”Stability“（服务恢复时间）为纵坐标的全局图。右上角的行业能快速和稳定的进行软件交付。以这种方式来观察数据，我们可以发现，零售业的排名是最好的。而像电信业这样的行业相对于其他行业来说则是落后的。

不同编程语言的软件交付效能

仪表盘可以让我们看到不同编程语言的软件交付效能。当谈及到 DevOps 和持续交付时，文化是非常重要的，当涉及到DevOps和持续交付时，文化是非常重要的，当谈到开发者社区时，开发者文化通常围绕着编程语言生态系统。以“Speed”指标（变更前置时间和部署频率）为横坐标，以“Stability”（服务恢复时间）为纵坐标，我们可以得到一个编程语言在软件交付方面的排名图片。这为我们提供了一个基线，我们可以在此基础上逐年比较社区及其生态系统是如何发展的，并在软件交付效能方面变得更好（或不更好）。

排名前 10 的编程语言

此外，基于软件交付效能的相关数据，我们提供了一个排名前 10 的编程语言列表：

1.Shell Scripting Languages2.Go/Golang3.Javascript4.PHP5.Scala6.Dart7.C#8.Ruby9.Python10.Java

总结

持续交付是在一个持续变化的世界里保持竞争力的关键。持续交付基金会的使命是提高世界上软件安全可靠交付的能力。要做到这一点，重要的是要有一个共同的观点，即对2021年行业在关键指标上的状况有一个共同的看法，特别是变更前置时间、部署频率和服务恢复时间时间。我们提供了进一步的分析，深入了解行业和编程语言划分的相对表现。Nicole Forsgren 在《加速》一书中提到：软件交付是一项持续改进的工作。我们的研究表明，年复一年，最优秀的企业不断改进，而那些未能改进的企业则越来越落后。

这份报告提供了一个基线，我们可以在此基础上跟踪产业和开发者社区的发展以及支持这些行业和社区不断发展的努力。

报告思考

这个世界唯一不变的就是改变，如何在不断变化的环境中找到创新发展的前进方向，保持竞争力，一直是所有个人、组织、企业所寻找的答案。在软件交付领域，DevOps（持续交付是其一部分）被认为是一个新的突破点。虽然 DevOps 的出现已经十余年，最近几年的发展可以用如火如荼来形容，但是从上面的报告可以看出：

1.有的部署频率在半年一次，50% 的做不到每周一次2.代码变更到部署上线时间过长，50% 的都在一周以下3.服务恢复时间依旧有超过一周以上的

这里面应该有很多可以继续挖掘的内容，导致上述内容的原因究竟是什么，意识不到位？组织架构难改变？自动化无法实现？安全拖后腿？

拥抱 DevOps 是一回事，真正实践又是一回事，如何能帮助更多企业或者组织更好的落地实践 DevOps 是一条充满挑战的道路。