加速：2022年DevOps现状报告

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