2022 加速 DevOps状态报告

翻译出品 2022加速 DevOps状态报告 译者：朱少民，茹炳晟，吴骏龙，顾黄亮，王永雷，李威审校：张乐 Ta目ble录ofcontents 01摘要02 02如何比较？07 06个人和企业统计概况 58 03如何改进？18 简介18 云20 SRE和DevOps25 DevOps技术能力28 文化36 07总结66 08致谢67 09作者简介68 10本报告方法论75 04供应链安全重要性 41 11扩展阅读78 05意外发现54 01摘要 在过去的8年里，我们撰写了加速：DevOps状态报告（AccelerateStateofDevOpsreport），其间听取了大约33,000名专业人士的意见。我们的研究重点在于审视那些预测DevOps核心产出的能力和实践，包括下列几个方面： 软件交付效能（Softwaredeliveryperformance）——软件交付效能的四个关键指标：部署频率、变更前置时间、变更失败率和服务恢复时间； 运维效能——第五个关键指标是可靠性； 组织绩效——组织实现绩效和盈利目标的情况。 此外我们还关注了导致其他结果 （如职业倦怠）的成因，以及员工愿意推荐他们团队的可能性。 保护软件供应链 在2021年，我们发现保护软件供应链对取得许多重要成果而言至关重要。 今年，我们对软件供应链的安全问题进行了更深入的研究，使其成为调查和报告的中心主题。我们利用软件安全制品的供应链级别（SupplyChainLevelsforSecureArtifacts，简称SLSA）框架来探索支持软件供应链安全开发的技术实践。我们还使用了国家标准与技术协会的安全软件开发框架(SecureSoftwareDevelopmentFramework，简称NISTSSDF)来探索与软件供应链安全相关的态度、过程和非技术实践。 我们发现，预测一个组织的应用程序开发安全实践水平的最大因素是文化，而不是技术：对于采用新兴安全实践的可能性，注重效能的“高信任和低指责”文化，是注重权力或规则的“低信任和高指责”文化的1.6+倍。我们还发现早期的证据表明，部署前安全扫描可以有效地发现易受攻击的依赖项，从而减少生产代码中的漏洞。 此外，采用良好的应用程序开发安全实践可以带来额外的好处。我们发现，专注于建立这些安全实践的团队减少了开发人员的职业倦怠；安全实践水平低的团队比安全实践水平高的团队职业倦怠的几率高1.4倍。专注于建立安全实践的团队明显更有可能将他们的团队推荐给其他人。此外，SLSA框架相关的安全实践积极地预测了组织绩效和软件交付效能，但这种效果需要强大的持续集成能力才能完全显现。 01摘要 4 1.组织绩效的驱动因素 除了上面提到的安全实践，影响组织绩效的关键因素 往往属于以下几类： 1）组织和团队文化 正如Westrum定义的那样，“高信任和低指责”的文化往往具有更高的组织绩效。类似地，如果一个组织的团队感觉得到了资金的赞助和领导的支持，那么它的组织绩效往往会更高。团队稳定性和对团队的积极看法(推荐团队的可能性)也往往会导致更高水平的组织绩效。最 后，提供灵活工作安排的公司往往会有高水平的组织绩效。 2）可靠性 我们与可靠性工程相关的实践（例如，明确的可靠性目标，聚焦的可靠性度量，等等)和报告满足其可靠性期望的程度，都是高水平组织绩效的强大预测器。 3）云 我们发现云的使用可以预测组织的效能。软件最初建立在云上并且云化的公司往往具有更高的组织绩效。使用私有云、公共云、混合云或多云都比单独使用内部服务器具有更高的组织绩效。那些使用多种公共云的组织对比不使用的，有1.4倍的可能性获得高于平均水平的组织绩效。 云的使用似乎也通过我们数据集中的其他因素，影响着组织绩效。一个例子是供应链安全，我们发现使用公共云的组织也更有可能实现SLSA实践——可能是因为云提供商鼓励并为许多SLSA实践提供构建块，例如自动化构建和部署。更广泛接受的观点是，使用云平台开拓了团队，使他们继承了许多最终导向更高组织绩效的能力和实践。 2.环境的重要性 长期以来，DORA考虑到效果取决于更广泛的团队环境（Context，上下文）。我们相信理解一个团队的特征（流程、优势、约束和目标）以及工作发生的环境是很重要的。例如，在一个环境中具有优势的技术能力在另一个环境中可能是有害的。今年，我们专注于以相互作用的形式明确地建模这些假设条件；其中许多假设都得到了今年数据的支持： 只有当运维效能也很高时，较高的软件交付效能才有利于组织绩效。如果我们的服务不能满足用户的可靠性期望，那么快速交付的价值就没有发挥出来。的。 实现软件供应链安全控制，就像SLSA框架所推荐的那样，当持续集成牢固建立时，对软件交付效能有积极的影响。如果没有合适的持续集成功能，软件交付效能和安全控制可能会发生冲突。 站点可靠性工程(SRE)实践对团队达到可靠性目标能力的影响是非线性的。在团队达到一定的SRE成熟度之前，实践SRE不会对可靠性产生积极的影响。在一个团队达到这个级别的SRE成熟度之前，我们发现SRE和达到可靠性目标之间没有相关性。然而，随着团队采用SRE的增长，它达到了一个拐点，SRE的使用开始强烈地预测可靠性。持续增长的可靠性会影响组织的效能。 技术能力建立在彼此之上。持续的交付和版本控制可以互相增强能力，以促进高水平软件交付的效能。将持续交付、松耦合的架构、版本控制和持续集成结合起来，可以培养出比各部分总和更出色的软件交付效能。 软件交付所依赖的条件，以及了解团队更广泛背景的需要，使我们得出了与2021年的见解类似的结论： “为了进行有意义的提升，团队必须采用持续改进的哲学。使用基准测试来度量当前的状 态，根据研究和实验所调查的能力来确定约束，并尝试改进以减轻这些约束。实验将包含胜利和失败，但在这两种情况下，团队都可以根据吸取的教训采取有意义的行动。” 事实上，我们今年发现了一个与这一总体哲学高度一致的结果：认识到持续改进必要性的团队，往往比那些没认识到这一点的团队，有更高的组织绩效。 简而言之，团队需要不断地适应，并实验软件开发实践。我们知道这一点是因为，总体而言，这样做的团队具有更高的组织绩效。但并非总是如此（适用于一个组织的东西不一定适用于另一个组织)，但大多数情况下都是如此。当我们在进行自己的DevOps实践实验时，请为偶尔的失败做好准备，因为我们正在研究什么适合我们的团队。 认识到持续改进必要性的团队，往往比那些没有认识到这一点的团队，有更高的组织绩效。 今年，我们也在数据中发现了一些令人惊讶的事情，但请你继续阅读，以找出那些是什么。 02如何比较？ 你是否好奇自己的团队与业内其他团队相比如何?本节内容包括了DevOps效能的最新基准评估。我们研究了团队如何开发、交付和运维软件系统，然后将受访者划分为捕捉DevOps效能最常见组合的聚类。 今年我们包含了两种不同的聚类方法。第一种是基于历史先例。这种聚类方法关注基于四个指标创建聚类，这些指标体现了软件交付效能：前置时间、部署频率、服务恢复时间和变更失败率。我们在下面逐一总结。这种方法的目标是帮助我们量化团队当前的效能，以便我们可以将自己的效能与其他团队进行比较。 第二种聚类方法包括第五个度量——可靠性，我们用它来理解运维效能。为什么要在聚类分析中添加一个新的度量？因为我们一直都看到这个指标的重要性。事实上，我们有证据表明，如果没有与强大的运维效能相匹配，交付效能可能对组织绩效有害。与传统的聚类方法不同，这是一种描述性的运用，它试图描绘团队跨交付和运维效能执行的常见方式。因此，并不总是很明显得表现出哪个聚类会更好。 2022加速DevOps状态报告 首先，让我们简要概述一下用于理解软件交付和运维效能的五种度量方法。 软件交付和运维效能 为了满足不断变化的行业需求，组织必须快速、可靠地交付和运维软件。我们的团队对我们的软件进行变更的速度越快，我们就能越快地向客户交付价值、进行实验，并接收有价值的反馈。经过8年的数据收集和研究，我们已经开发并验证了四个度量软件交付效能的指标。 自2018年以来，我们为捕获运维能力引入了第五个指标。在所有五项指标中都表现出色的团队表现出出色的组织绩效。我们将这五种度量称为软件交付和运维(SDO)效能。请注意，这些度量关注系统级结果，这有助于避免跟踪软件度量的常见缺陷，这些缺陷可能导致功能相互对立，并以整体结果为代价进行局部优化。 2022加速DevOps状态报告 02如何比较？9 1）软件交付和运维效能的五个指标 可以从吞吐量和稳定性的角度考虑软件交付效能的四个指标。我们使用代码变更前置时间(即从代码提交到生产中发布的时间)和部署频率来度量吞吐量。我们通过在事件发生后恢复服务的时间和变更失败率来衡量稳定性。 第五个指标代表运维效能，是对现代运维实践的衡量。我们将运维效能建立在可靠性的基础上，即我们的服务在多大程度上满足用户的期望，如可用性和性能。过去，我们衡量的是可用性而不是可靠性，但因为可用性是可靠性工程的一个特定焦点，我们在2021年扩大了对可靠性的衡量，这样可用性、延迟、性能和可伸缩性将得到更广泛的代表。具体来说，我们要求受访者对他们达到或超过可靠性目标的能力进行评级。我们发现，当他们也优先考虑运维效能时，具有不同程度交付效能的团队得到了更好的结果(例如，更少的职业倦怠)。 02如何比较？10 2）历史聚类方法：对交付效能进行聚类 今年，在评估我们自2018年以来使用的四个聚类方案（four-clustersolution）时，我们注意到数据显示一个明显的低效能聚类和一个明显的高效能聚类。然而，我们传统上用来区分中等效能和高效能的两个聚类没有足够的区别，因此不能进行拆分。此外，我们用于选择正确聚类解决方案的各种指标都表明，无论应用何种聚类技术，三个聚类都能最好地捕获数据。表2-1描述了每个聚类的交付效能特征。 表2-1 软件交付效能度量 低 中 高 部署频率对于我们使用的主要应用程序或服务，我们的组织将代码部署到生产环境或将其发布给最终用户的频率是多少? —个月一次到六个月一次之间 每周一次到每月一次之间 按需部署(每天多次部署) 变更前置时间对于我们从事的主要应用程序或服务，变更的前置时间是多少(即，从提交的代码到在生产中成功运行的代码需要多长时间)? —个月到六个月之间 —个星期到一个月之间 —天到一个星期之间 服务恢复时间对于我们使用的主要应用程序或服务，当发生影响用户的服务事件或缺陷(例如，计划外停机或服务损害)时，通常需要多长时间才能恢复服务? —个星期到一个月之间 —天到一个星期之间 不到一天 变更失败率对于我们使用的主要应用程序或服务，对生产或发布给用户的更改中有多少百分比会导致服务降级(例如，导致服务降级或服务中断)并随后需要补救(例如，需要热修复、回滚、转发修复、补丁)? 46%-60% 16%-30% 0%-15% 02如何比较？ 11 与去年的显着区别在于，今年没有精英效能聚类。今年的高效能聚类是去年高效能聚类和精 英效能聚类的混合。我们决定忽略精英效能聚类，因为表现最好的聚类并不能充分显示去年精英效能聚类的特征。 这表明，这个样本并不代表员工感觉自己取得了长足进步的团队或组织。一个可能的假设 （我们目前缺乏数据支持)是，软件开发在实践、工具和信息共享方面的创新减少了。这可能是由于目前的大流行病阻碍了团队和组织之间共享知识和实践的能力。聚集和相互学习的机会可能会减少，这反过来可能会减缓创新。我们希望能做更深入的研究，以探索是什么支撑了这一发现。 尽管如此，如果我们将今年的低、中、高效能聚类与去年的聚类进行比较，我们将看到交付效能的略微提高。今年的聚类似乎介于去年的两个聚类之间。2022的高效能聚类介于2021 的高效能和精英效能之间。2022年的低效能聚类似乎介于2021年的低效能和中等效能之间。低效能聚类的上移