加速：2022年DevOps现状报告

目录内容提要03如何比较？08如何提升？简介19云端21SRE和DevOps26技术DevOps能力29文化37供应链安全为何至关重要42意料之外的现象55受众特征和企业特征59最后总结67致谢68作者69调研方法73补充阅读材料760102030405060708091011 01内容提要 Claire Peters Derek DeBellis 过去8年来，我们每年都会发布《加速：DevOps现状》报告，在此过程中听取了33,000位专业人士的意见和建议。我们的研究重点是，了解各项功能和实践如何影响我们认为对DevOps极为重要的成效。 •软件交付表现-软件交付表现的四个关键指标：部署频率、更改前的准备时间、更改失败率和恢复服务所需的时长。 •运营绩效-第五个关键指标，可靠性。 •组织绩效-贵组织在实现绩效和盈利目标方面的表现。 此外，我们还重点关注导致产生其他结果的因素，例如倦怠率和员工推荐所在团队的可能性。 保护软件供应链安全 采用良好的应用开发安全性实践可带来其他好处。我们发现，在专注于采用这些安全性实践的团队中，开发者较少出现倦怠；与安全性实践采用程度较高的团队相比，采用程度较低的团队中出现高度倦怠的几率达到1.4倍1。如果团队专注于采用安全性实践，其成员向他人推荐团队的可能性会显著提高。不仅如此，SLSA相关安全性实践有助于提升组织绩效和软件交付表现，但组织需要具备强大的持续集成能力，才能使这种积极影响充分发挥出来。 2021年，我们发现保护软件供应链安全对于实现许多重要成效都至关重要。 今年，我们对软件供应链安全性进行了更深入的研究，将其作为问卷调查和报告的主要主题。我们利用安全工件的供应链级别(SLSA)框架来探索支持软件供应链安全性开发的技术实践。此外，我们还利用美国国家标准与技术研究院的安全软件开发框架(NIST SSDF)来探索与保护软件供应链相关的看法、流程和非技术实践。 我们发现，文化对组织的应用开发安全性实践影响最大，而不是技术：信任度较高且不常问责的成效导向型文化更有可能拥有超出平均水平的新兴安全性实践采用率，可能性是信任度较低且经常问责的权力或规则导向型文化的1.6倍。我们还发现有早期证据表明，部署前安全扫描可有效找出存在安全漏洞的依赖项，进而减少生产环境中的代码安全漏洞。 我们将此统计数据中的“高”的概念定义为得分（例如安全性）标准差大于或等于1，“低”的概念定义为得分标准差小于或等于-1。 组织绩效的驱动因素 除了上述安全性实践以外，影响组织绩效的关键变量往往可分为以下几类： 云端 我们发现，云端使用情况与组织绩效密切相关。一开始便构建云端专用软件的公司往往能实现更高的组织绩效。与仅使用本地服务器相比，使用私有云、公有云、混合云或者混合使用多种云可实现更高的组织绩效。使用多个公有云的公司更有可能获得超出平均水平的组织绩效，可能性是未使用的公司的1.4倍。 组织和团队文化 信任度较高且不常问责的文化（根据Westrum的定义）往往会推动实现更高的组织绩效。同样地，如果组织能够让团队感受到资金方面和领导阶层的支持，往往会实现更高的组织绩效。此外，团队稳定性以及成员对团队的正面看法（推荐团队的可能性）也有助于实现更高的组织绩效。最后，在工作安排方面灵活多变的公司也更有可能实现较高的组织绩效。 此外，根据我们的数据集，云端使用情况似乎还会通过其他因素影响组织绩效。以供应链安全性为例，我们发现使用公有云的组织采用SLSA实践的可能性也更高，原因可能是云服务提供商鼓励采用和提供许多SLSA实践的基础组件，例如自动构建和部署2、3。从广义上讲，使用云端平台可让团队沿用许多功能和实践，而这最终会转化为更高的组织绩效。” 可靠性 与可靠性工程相关联的实践（例如，明确的可靠性目标、重要的可靠性指标等）以及员工认为的其可靠性期望满足程度，对能否实现较高的组织绩效有着极大的影响。 背景至关重要 成效依赖于更广泛的团队背景。长久以来，DORA都考虑到了这一点。我们认为，了解团队的特征（业务流程、强项、限制和目标）以及工作执行环境非常重要。例如，在某个背景下是优势的技术能力在其他背景下却可能是劣势。今年，我们的重点是以互动的形式对这些假设条件进行显式建模；今年的数据支持了其中许多假设： •只有在运营绩效同样出色的情况下，出色的软件交付表现才对组织绩效有所助益。如果服务无法满足用户对可靠性的期望，即使拥有快速交付能力也可能无关紧要。 •各项技术能力是相辅相成的。持续交付和版本控制可强化彼此的能力，进而带动软件交付表现提升。结合使用持续交付、松散耦合架构、版本控制和持续集成后，软件交付表现会比分别使用时的总和更出色。 •持续集成非常成熟时，实现软件供应链安全性控制机制（例如SLSA框架建议的控制机制）会对软件交付表现产生积极影响。如果不具备持续集成能力，软件交付表现与安全性控制机制之间可能会存在冲突。 •站点可靠性工程(SRE)实践对团队实现可靠性目标的能力的影响是非线性的。只有当团队的SRE成熟度达到特定级别时，SRE实践才会对可靠性产生积极的影响。在团队的SRE成熟度 达到该级别之前，我们并未发现SRE与实现可靠性目标之间的关系。然而，当团队的SRE采用率提高到拐点时，使用SRE便会开始对可靠性产生明显的积极影响。可靠性提高后，就会连带影响组织绩效。 我们了解这一点，是因为从总体来看，这样做的团队具有更出色的组织绩效。这并非放之四海而皆准（适合一个组织的不一定适合另一个组织），但在大多数情况下都适用。在探索和强化适合团队的DevOps实践时，难免会遇到失败的情况，建议您对此做好准备。 鉴于交付所依赖的条件以及了解更广泛的团队背景的必要性，我们得出了与2021年的这项洞察类似的结论： “为了做出有意义的改进，团队必须采用持续改进的理念。使用基准来衡量您的当前状态，根据研究调查的能力确定限制条件，并尝试改进以消除这些限制条件。实验可能成功，也可能失败，但无论哪种情况，团队都可以根据经验教训采取有意义的行动。” 此外，我们今年还在数据中发现了一些意料之外的现象。请继续阅读，了解具体有哪些现象。 事实上，我们今年发现了一个与此总体原则高度契合的现象：与未意识到需要持续改进的团队相比，意识到这一点的团队往往具有更出色的组织绩效。 简而言之，团队需要不断做出调整，尝试各种软件开发实践。 与未意识到需要持续改进的团队相比，意识到这一点的团队往往具有更出色的组织绩效。 02如何比较？ Derek DeBellis 第二种聚类方法包含第五个指标，即可靠性，我们利用该指标来了解运营绩效。为什么要向组分析添加新的指标？因为该指标持续展现出了它的重要性。事实上，我们有证据表明，如果没有出色的运营绩效，交付表现可能有损于组织绩效。与传统的聚类方法不同，这是一种描述性做法，会尝试呈现团队在交付和运营方面的常见表现。因此，不一定能够看出哪个组的表现更好。 您是否想知道，相较于业内其他团队，您的团队表现如何？本部分介绍了最新的DevOps表现基准评估方式。我们研究团队如何开发、交付和操作软件系统，然后将受访者分为多个组，这些组涵盖最常见的DevOps表现组合。 今年，我们添加了两种不同的聚类方法。第一种方法是基于以往惯例。这种聚类方法侧重于根据反映软件交付表现的四个指标来创建组，这些指标分别为：准备时间、部署频率、恢复服务所需的时长以及更改失败率。我们会下文中概要介绍这些指标。这种方法的目标是帮助您量化团队的当前表现，以便您将自己团队的表现与其他团队进行比较。 首先，我们来简单看一下用于了解软件交付表现和运营绩效的五个衡量指标。 软件交付表现和运营绩效 为了满足不断变化的行业的需求，组织必须快速可靠地交付和运营软件。您的团队更改软件的速度越快，您就能越快地为客户带来价值、运行实验以及获得有价值的反馈。基于八年的数据收集和研究，我们设置并验证了四个用于衡量软件交付表现的指标。2018年，我们添加了第五个指标， 以涵盖运营能力。在所有五个指标上均表现出色的团队能够实现卓越的组织绩效。我们将这五个指标称为软件交付表现和运营(SDO)绩效。请注意，这些指标侧重于系统级成效，有助于避免跟踪软件指标的常见问题，而这些问题可能会导致功能相互对立，以及以牺牲总体成效为代价进行局部优化。 关于软件交付表现和运营绩效的五个指标 关于软件交付表现的四个指标可以从吞吐量和稳定性这两个方面来考虑。我们使用代码更改前的准备时间（即从代码提交到在生产环境中发布的时间）和部署频率来衡量吞吐量，使用突发事件后恢复服务所需的时长和更改失败率来衡量稳定性。 第五个指标代表运营绩效，用来衡量现代运营实践。运营绩效根据可靠性来评定，即您服务的可用性和性能等方面在多大程度上达到了用户的预期。在过去，我们衡量的是可用性而不是可靠性，但由于可用性是可靠性工程的一个具体关注点，因此我们于2021年将可靠性纳入衡量范围，以便更广泛地反映可用性、延迟时间、性能和可伸缩性。具体而言，我们请受访者评估了他们达到或超越其可靠性目标的能力。我们发现，交付表现程度不同的团队若能一并优先考虑运营绩效，将会获得更出色的成效（例如倦怠率较低）。 无一例外地表明，无论采用何种聚类技术，三个组都能以最佳方式捕获数据。下表介绍了每个组的交付表现特征。 历史聚类方法：聚类交付表现 今年，在评估我们自2018年起使用的包含四个组的解决方案时，我们注意到，在数据中，一个组的绩效明显较高，一个组的绩效明显较低。但是，传统上我们用来划分中等绩效和高绩效的两个组差异化程度不足，无法确保适当的拆分。此外，我们用来选择合适的聚类解决方案的各种指标 与去年明显不同的是，今年我们没有将任何组划为卓越绩效组。今年的高绩效组是去年的高绩效组和卓越绩效组的组合。我们决定去掉卓越绩效组，因为今年绩效最高的组并不完全符合去年的卓越绩效组的特征。 这表明，此样本并不能代表员工认为自己取得进步的团队或组织。我们目前缺乏数据来支持的一个可能的假设是，软件开发在实践、工具和信息共享方面的创新减少了。原因或许是持续的疫情限制了团队和组织共享知识和实践的能力，减少了他们聚在一起互相学习的机会，这反过来拖慢了创新速度。我们希望更深入地探究此发现结果背后的原因。 尽管如此，与去年相比，今年低、中和高绩效组的交付表现都略有提高。今年各个组的交付表现看起来介于去年的两个组之间。2022年高绩效组的交付表现介于2021年的高绩效组与卓越绩效组之间。2022年低绩效组的交付表现介于2021年的低绩效组与中等绩效组之间。低绩效组的交付表现提升表明，尽管交付表现的上限降低，但下限却有所提高。 上表中的百分比细分数据显示，高绩效者所占百分比处于4年来的低点，而低绩效者所占百分比则急剧提高，从2021年的7%提高到今年的19%。今年，超过三分之二的受访者划入中等绩效组。高绩效者和卓越绩效者所占百分比明显下降，这可能表明，今年的许多受访者所在的组织或团队尚未建立或正在建立许多现代化团队都有的DevOps文化。 我们可能过于关注2021年与2022年之间的不同，而不是强调相似之处。2021年与2022年的组之间有许多共同特征，包括高绩效者与低绩效者之间的差距很大。例如，高绩效者拥有的部署数量预计1是低绩效者的417倍。 DevOps表现的重要一环，如果不将其纳入考虑，将无法全面了解DevOps表现。 聚类交付表现和运营绩效 我们决定对上述五个指标所代表的三个类别进行聚类分析：吞吐量（涵盖代码更改前的准备时间和部署频率）、稳定性（涵盖恢复服务所需的时长和更改失败率）和运营绩效（可靠性）。这么做的原因是，运营绩效在我们的模型中扮演着重要的角色。对于运营绩效不佳的组织，吞吐量和稳定性对组织绩效的影响较小。我们认为，运营绩效 是评估 通过探索数据，我们制定了包含四个组的解决方案。以下是四个组的细分及其名称： 每个组都有独特的特征，且在受访者中占据相当大的比例