| 2021-09-26
第 1 章 调查总述
谷歌云的DevOps研究与评估（ DORA ）团队今年发布的 DevOps 加速状态报告代表了来自全球 32000 多名专业人士的七年研究和数据。
我们的研究考察了推动软件交付、技术运营和组织绩效的能力和实践。通过利用严格的统计技术，我们试图了解能够带来卓越技术交付和强大业务成果的实践。为此，我们提供了数据驱动的见解，以了解开发和交付技术的最有效和最高效的方法。
我们的研究继续表明，卓越的软件交付和技术运营绩效推动了技术变革中的组织绩效。为了使团队能够根据行业对自己进行基准测试，我们使用聚类分析来形成有意义的绩效类别（如低、中、高或精英绩效）。
当你的团队了解到当前相对于行业的绩效后，你可以使用我们的预测分析结果来针对实践和能力，以改进关键成果，并最终改善您的相对位置。
一、今年的重点
今年，我们强调了满足可靠性目标、整合整个软件供应链的安全性、创建高质量的内部文档，以及充分利用云的潜力的重要性。
我们还探讨了积极的团队文化是否可以减轻因新冠病毒大流行而产生的远程工作的影响。
为了做出有意义的改进，团队必须采用持续改进的理念。使用基线来衡量您的当前状态，根据本调查中提到的能力，识别出你团队的约束，并尝试改进，以缓解这些约束。这种尝试可能是既有成功的做法，也有失败的做法。但是，无论哪一种情况，团队都要根据经验教训采取有意义的行动。
二、关键发现
1、表现最好的公司正在成长，并继续提高标准
在我们的研究中，精英绩效团队现在占全部团队的26%，而且生产变更的交付周期也缩短了。行业持续加速，团队看到，这么做会得到有益的好处。
2、SRE 和 DevOps 是互补的哲学 （ complementary philosophies ）
那些使用我们的（SRE）所概述的现代操作实践的团队说他们自己表现了更高的技术运营绩效。同时优先考虑交付和卓越技术运营的团队报告了最高的组织绩效。
3、更多的团队利用了云技术，并从中看到了很大的收益
团队继续推动将工作搬上云，那些利用云的所有五种能力的团队看到软件交付与运营（ SDO ）绩效，以及组织绩效的提升。采用多云方案的团队也在增加，因此。团队可以利用每个提供商的独特功能。
4、安全软件供应链既至关重要，又能驱动绩效
鉴于近年来恶意攻击的显著增加，组织必须从被动实践转向主动和诊断措施。在整个软件供应链中，集成安全实践的团队可以快速、可靠、安全地交付软件。
5、好的文档是成功实现 DevOps 能力的基础
我们第一次衡量了内部文档和实践的质量，这些都有助于提高质量。拥有高质量文档的团队能够更好地实施技术实践，并在整体上表现更好。
6、在充满挑战的环境中，积极的团队文化可以缓解工作倦怠
团队文化对“团队交付软件并达到或超过其组织目标”的能力有很大影响。在新冠病毒大流行期间，具有生机性文化的包容性团队较少感到倦怠。
生机性团队文化是指，高度合作性、打破组织筒仓结构、失败会触发反思且分担决策风险的团队。
第 2 章 我们如何做比较
您是否好奇您的团队与业内其他团队相比如何？本节包括 DevOps 绩效的最新基准评估。
我们研究团队如何开发、交付和运营他们的软件系统，然后将受访者分为四个绩效集群：精英、高绩效、中绩效和低绩效。通过将你团队绩效与每个集群的绩效进行对比，可以从本报告中描述的调查结果中了解你自己的情况。
一、软件交付与技术运营绩效
为了满足不断变化的行业的需求，组织必须快速可靠地交付和操作软件。对软件进行变更的速度越快，就可以越快地向客户交付价值、运行实验和接收有价值的反馈。
通过七年的数据收集和研究，我们已经开发并验证了四个度量软件交付性能的指标。
自2018年以来，我们纳入了第五个指标以获取运营能力。
在所有五项指标上都表现出色的团队表现出卓越的组织绩效。
我们称这五种度量指标为软件交付和技术运营（ SDO ）绩效。
请注意，这些指标侧重于整个系统级的结果，这有助于避免软件指标的常见问题，例如功能之间的相互比较，或者以总成本为代价进行局部优化。
1、交付绩效的四个指标
我们可以认为，软件交付性能的四个度量体现了吞吐量和稳定性。代码变更前置时间（即从代码提交到生产环境中发布的时间）和部署频率来衡量吞吐量。我们使用事件发生后恢复服务的时间和变更失败率来衡量稳定性。
对四个软件交付指标的聚类分析揭示了四种不同的绩效特征的团队，它们分别是精英、高、中、低，而它们之间在吞吐量和稳定性度量方面存在统计上的显著差异。
与前几年一样，我们的精英绩效团队在所有四项指标上都表现出色，而低绩效团队在所有领域都表现糟糕。
2、第五个指标：从可用性到可靠性 from availability to reliability
第五个指标代表技术运营绩效，是现代技术运营实践的衡量标准。运营绩效的主要衡量标准是可靠性，即团队能够在多大程度上对其所运营的软件系统达成承诺和主张。
过去，我们衡量的是可用性，而不是可靠性。但是，由于可用性是可靠性工程的一个特定重点，因此，我们将衡量范围扩展到可靠性，以便更广泛地表示可用性、延迟、性能和可伸缩性。
具体而言，我们要求受访者对其达到或超过可靠性目标的能力进行评分。我们发现，既使具有不同交付绩效的团队，当他们提高运营绩效的优先级时，都会看到更好的结果。
与以前的报告一样，我们将精英员工与低绩效员工进行了比较，以说明特定能力的影响。然而，今年我们试图考虑技术运营绩效的影响。在所有交付绩效类别（从低到精英）中，对于优先满足或超过其可靠性目标的团队，我们看到了多个结果的重大好处。
3、行业在持续加速
每年，我们都会看到行业不断发展，并加快以更快的速度和更好的稳定性交付软件的能力。
我们的高水平和精英团队首次占到了受访者的三分之二。此外，与之前的评估相比，今年的精英团队再次将标准提升了，比如，代码变更前置时间缩短了（例如，从 2019 年的不到一天提高到 2021 年的不到一小时）。此外，与前几年相比，只有精英团队的变更失败率被降至新的最低点，而前几年的高绩效团队也能做到这一点。
4、吞吐量
A）部署频率
与往年一样，精英团队报告称，它定期按需部署，每天执行多次部署。
相比之下，表现不佳的公司报告称，每六个月部署不到一次（每年不到两次），与 2019 年相比，这又是一次性能下降。
标准化 ( normalized ) 后的年度部署数量范围从每年 1460 次部署（按每天 4 次部署 x 365 天计算）到每年 1.5 次部署（平均两次部署和一次部署）。此分析近似于，精英团队的部署频率要高出低绩效团队约 973 倍。
B）变更前置时间
变更前置时间是从代码提交到成功部署到生产环境上的时间。精英团队报告，它的变更前置时间不到 1 个小时。与 2019年 相比，这是一个绩效提升。2019年，精英绩效团队的变更前置时间少于一天。与精英团队相比，低绩效团队的需求交付周期超过六个月。
所以， 对于变更前置时间，根据平均每年 8760 小时，即半年为 4380 小时来计算的话，由于精英团队少于 1 小时，而低绩效团队按 6570 小时算，我们可以得出，精英团队的变更前置时间比低绩效团队快 6570 倍。
5、稳定性
A）服务恢复时间
精英团队称，其服务恢复时间不到一个小时，而低绩效团队要超过六个月。
在这一计算中，我们选择了一个保守的时间范围：精英绩效者为一小时，低绩效者为一年（8760小时）和六个月（4380小时）的平均时间。
根据这些数字，精英团队服务恢复速度是低绩效者的 6570 倍。
与2019年相比，精英团队的恢复服务时间保持不变，而低绩效团队的服务恢复时间有所增加。
B）变更失败率
精英团队称，其变更失败率在 0 % ～ 15 % 之间，而低绩效团队的变更失败率为 16 % ～ 30 %。这两个范围之间的平均值显示，精英团队的变更失败率为 7.5 %，而低绩效团队的变更失败率为 23 %。精英团队的变更失败率比低绩效团队要低三倍。今年，与 2019 年相比，精英团队的变更失败率保持不变，低绩效团队的变更失败率有所提高，但中间群体的变更失败率有所下降。
第 3 章 应该如何改进
如何改进 SDO 和组织绩效呢？我们的本次研究提供了基于证据的指导，帮助你关注推动绩效性的能力。
今年的报告考察了云、SRE实践、安全、技术实践和文化的影响。
在本节中，我们将介绍这些能力中的每一项，并关注它们对各种结果的影响。
对于那些熟悉 DORA 的 DevOps 研究模型的人来说，我们已经创建了一个在线资源，用于托管今年的模型和所有以前的模型。
一、云
与 DevOps 2019 的加速状态一致，越来越多的组织正在选择多云和混合云解决方案。在我们的调查中，受访者被问到他们的主要服务或应用程序在哪里，公共云的使用率正在上升。 56% 的受访者 表示使用公共云（包括多个公共云），比 2019 年增加 5% 。今年，我们还专门询问了多云的使用情况，21% 的受访者表示部署到多个公共云。21% 的受访者表示不使用云，而是使用数据中心或内部部署解决方案。最后，34% 的受访者报告使用混合云，29% 报告使用私有云。
1、采纳
- 利用混合云和多云加速业务成果
今年，我们看到混合云和多云的使用在增长，对企业关心的结果产生了重大影响。使用混合云或多云的受访者超过组织绩效目标的可能性是未使用混合云或多云的受访者的 1.6 倍。我们还看到了 SDO 的强大影响，混合云和多云的用户在部署频率、变更前置时间、恢复时间、变更失败率和可靠性方面表现优异的可能性高出 1.4 倍。
- 为什么使用多云？
与我们 2018 年的评估类似，我们要求受访者报告他们利用多个公共云提供商的理由。今年，我们要求受访者报告他们使用多家供应商的主要原因，而不是选择所有适用的供应商。
超过四分之一（ 26% ）的受访者这样做是为了利用每个云提供商的独特优势。这表明，当受访者选择其他供应商时，他们会在当前供应商和备选供应商之间寻找差异。
迁移到多云的第二个最常见原因是可用性（ 22% ）。毫不奇怪，采用多家云提供商的受访者达到或超过其可靠性目标的可能性是前者的 1.5 倍。
2、基准线的变化
A）使用云基础设施的方式很重要。
在过去，我们发现并非所有受访者都以相同的方式使用云。这导致了云应用在推动业务成果方面的有效性差异。我们通过关注云计算的基本特征（由国家标准与技术研究所（ NIST ）定义）来解决这一局限性，并以此为指导。使用 NIST 对云计算的定义，我们调查了基本实践对 SDO 绩效的影响，而不是只是调查云应用对 SDO 的影响。
我们发现真正重要的是团队如何实现他们的云服务，而不仅仅是他们在使用云技术。精英团队符合 NIST 云计算所有基本特征的可能性是优秀员工的 3.5 倍。那些表示正在使用云基础设施的受访者中，只有 32% 同意或强烈同意他们符合 NIST 定义的云计算的所有五个基本特征，比 2019 年增加了 3% 。总体而言，NIST 云计算特性的使用率增加了 14～19% ，其中快速弹性增长幅度最大。
B）按需自助服务
消费者可以根据需要自动提供计算资源，而无需与提供商进行任何人工交互。
73% 的受访者表示使用。比 2019 年上升了 16%。
C）更多的网络接入形式
功能广泛可用，可通过多个客户端（如移动电话、平板电脑、笔记本电脑和工作站）访问。
74% 的受访者表示使用。比 2019 年上升了 14%。
D）资源池
功能广泛可用，可通过移动电话、平板电脑、笔记本电脑和工作站等多个客户端访问。提供商资源汇集在多租户模型中，物理和虚拟资源可按需动态分配和重新分配。客户通常无法直接控制所提供资源的确切位置，但可以在更高的抽象级别（如国家、州或数据中心）指定位置。
73% 的受访者表示使用。比 2019 年上升了 15%。
E）快速弹性
可以弹性地调配和释放功能，以根据需求快速向外或向内扩展。可用于资源调配的消费者功能似乎是无限的，并且可以在任何时间以任何数量进行分配。
77% 的受访者表示使用。比 2019 年上升了 18%。
F）计量服务
云系统通过在与服务类型（如存储、处理、带宽和活动用户帐户）相适应的抽象级别上利用计量功能，自动控制和优化资源使用。可以监视、控制和报告资源使用情况以提高透明度。
78% 的受访者表示使用。比 2019 年上升了 16%。
二、SRE 和 DevOps
当D evOps 社区在公开会议和对话中崭露头角时，谷歌内部正在形成一场志同道合的运动：网站可靠性工程（ SRE ）。SRE 和类似的方法，如 Facebook 生产环境工程部门，包含许多激励 DevOps 的相同目标和技术。2016 年，当第一本书《网站可靠性工程》出版时，SRE 正式进入公众视野，并开始广泛讨论。自那时以来，该运动不断发展，如今，全球 SRE 从业人员社区就技术运营实践进行合作。
混乱也许不可避免会出现。SRE 和 DevOps 之间有什么区别？我需要选择一个还是另一个？哪一个更好？事实上，这里没有冲突； SRE 和 DevOps 是高度互补的，我们的研究证明了它们的一致性。SRE 是一门优先考虑跨职能沟通和心理安全的学习学科，这些价值观是精英 DevOps 团队典型的以绩效为导向的生机文化的核心。SRE 从其核心原则出发，提供了实用技术，包括服务级别指标/服务级别目标（ SLI /SLO ）度量框架。正如精益产品框架规定了如何实现我们的研究所支持的快速客户反馈周期一样，SRE 框架提供了实践和工具的定义，这些实践和工具可以提高团队持续履行对用户承诺的能力。
2021 年，我们扩大了对技术运营的调查，从服务可用性分析扩展到更一般的可靠性类别。今年的调查引入了几个受 SRE 实践启发的项目，以评估团队：
- 根据面向用户的行为定义可靠性
- 利用 SLI/SLO 度量框架，根据错误预算确定工作优先级
- 使用自动化减少手动工作和中断性警报
- 为事件响应定义协议和准备演练
- 在整个软件交付生命周期中纳入可靠性原则（“可靠性左移”）
在分析结果时，我们发现有证据表明，在这些现代运营实践中表现出色的团队报告更好的SDO绩效的可能性是优秀团队的 1.4 倍，报告更好的业务成果的可能性是优秀团队的 1.8 倍。在我们的研究中，大多数团队都采用了 SRE 实践：52% 的受访者报告在一定程度上使用了这些实践，尽管不同团队采用 SRE 实践的深度差异很大。数据表明，使用这些方法可以预测更高的可靠性和更高的整体 SDO 性能：SRE推动了DevOps的成功。
此外，我们还发现，一个共享的运营责任模型（反映在开发人员和运营人员联合授权为可靠性做出贡献的程度上）也可以预测更好的可靠性结果。
除了改进客观的绩效衡量标准外，SRE 还提高了技术从业者的工作经验。通常，承担繁重操作任务的个人容易精疲力竭，但 SRE 有积极的影响。我们发现，一个团队越多地采用 SRE 实践，其成员越不可能经历倦怠。SRE 还可能有助于优化资源：通过应用 SRE 实践达到可靠性目标的团队报告说，他们比不实践 SRE 的团队花更多的时间编写代码。
我们的研究表明，无论 SDO 表现如何，从低绩效到精英，团队都可能从 SRE 实践的增加中获益。团队的绩效越好，他们采用现代技术运营模式的可能性就越大：精英团队报告使用 SRE 实践的可能性高于低绩效团队约 2.1 倍。但即使是最高级别的团队也有增长空间：只有 10% 的精英受访者表示，他们的团队已经完全实施了我们调查的每一项 SRE 实践。随着各行业 SDO 绩效的不断提高，每个团队的运营方法都是 DevOps 持续改进的关键驱动因素。
三、文档
今年，我们考察了内部文档的质量，即团队工作的服务和应用程序的文档，如手册、READMEs，甚至代码注释。
我们通过以下程度来衡量文件质量：
- 帮助读者实现他们的目标
- 准确、最新且全面
- 可查找、组织良好且清晰
记录和访问有关内部系统的信息是团队技术工作的关键部分。
我们发现，大约 25% 的受访者拥有高质量的文档，这种文档工作的影响是显而易见的：
文档质量较高的团队有更好的软件交付和技术运营（SDO）绩效的可能性是其他团队的 2.4 倍。文档质量好的团队比文档质量差的团队更快、更可靠地交付软件。文档不必是完美的。我们的研究表明，文档质量的任何改进都会对性能产生积极和直接的影响。
今天的技术环境中有越来越复杂的系统，以及这些系统不同方面的专家和专业角色。从安全到测试，文档是在这些专业化团队之间，以及与更广泛的团队共享专业知识和指导的关键方式。
我们发现，文档质量可以预测团队在实施技术实践方面的成功。这些实践反过来预测系统技术能力的改进，如可观察性、连续测试和部署自动化。我们发现具有质量文档的团队包括：
- 实施安全措施的可能性提高 3.8 倍
- 达到或超过其可靠性目标的可能性提高 2.4 倍
- 实施网站可靠性工程（ SRE ）实践的可能性提高 3.5 倍
- 充分利用云的可能性提高 2.5 倍
技术文档的质量指标参见：
如何改进文档的质量
技术工作包括查找和使用信息，但质量文档依赖于编写和维护内容的人员。
2019年，我们的研究发现，访问内部和外部信息源有助于提高生产率。
今年的研究进一步考察了所访问文档的质量，以及对文档质量有影响的实践。
我们的研究表明，以下做法对文档质量有显著的积极影响：
- 记录产品和服务的关键用例。关于系统的文档很重要，用例允许读者将信息和系统投入工作。
- 为更新和编辑现有文档创建明确的指导原则。大部分文档工作都是维护现有内容。当团队成员知道如何进行更新或删除不准确或过时的信息时，即使系统随时间变化，团队也可以保持文档质量。
- 定义所有者。拥有高质量文档的团队更有可能明确定义文档的所有权。所有权允许明确负责编写新内容和更新或验证对现有内容的更改。具有高质量文档的团队更有可能声明文档是针对他们所处理的应用程序的所有主要功能编写的，明确的所有权有助于创建这种广泛的覆盖范围。
- 将文档作为软件开发过程的一部分。创建文档并在系统更改时进行更新的团队拥有更高质量的文档。与测试一样，文档创建和维护也是高性能软件开发过程的一个组成部分。
- 在绩效考核和晋升中，识别文档工作。识别与总体文档质量相关。编写和维护文档是软件工程工作的核心部分，这样处理文档可以提高其质量。
我们发现支持高质量文档的其他资源包括：
- 关于如何编写和维护文档的培训
- 对代码样本或不完整文档的自动化测试
- 指南，如文档风格指南和面向全球读者的写作指南
文档是成功实现 DevOps 功能的基础。更高质量的文档增强了对单个 DevOps 功能（如安全性、可靠性和充分利用云）的投资成果。实施支持质量文档的实践通过更强大的技术能力和更高的 SDO 绩效获得回报。
四、安全
1、左移，并贯穿始终
随着技术团队的不断加速和发展，安全威胁的数量和复杂性也在不断提高。根据 Tenable 的 2020 年威胁情景回顾报告，在 2020 年，超过 220 亿份机密个人信息或商业数据记录被披露。安全性不能是事后考虑或交付前的最后一步，它必须集成到整个软件开发过程中。
为了安全地交付软件，安全实践必须比恶意参与者使用的技术发展得更快。在 2020 年 SolarWinds 和 Codecov 软件供应链攻击期间，黑客破坏了 SolarWinds 的构建系统和 Codecov 的 bash uploader 脚本，将自己秘密嵌入到这些公司数千名客户的基础设施中。考虑到这些攻击的广泛影响，行业必须从预防性方法转向诊断性方法，软件团队应该假设他们的系统已经受损，并在供应链中构建安全性。
与之前的报告一致，我们发现精英团队擅长实施安全实践。今年，达到或超过可靠性目标的精英团队在软件开发过程中集成安全性的可能性是别人的两倍。这表明，那些在保持可靠性标准的同时加快交付速度的团队已经找到了一种集成安全检查和实践的方法，而不会影响他们快速或可靠交付软件的能力。
除了表现出较高的交付和操作性能外，在整个开发过程中集成安全实践的团队达到或超过其组织目标的可能性要高出 1.6 倍。支持安全性的开发团队看到了显著的业务价值驱动。
2、如何做对
强调安全性的重要性并建议团队优先考虑安全性是很容易的，但这样做需要对传统的信息安全方法进行一些更改。通过利用以下实践，您可以集成安全性、改进软件交付和运营性能，并提高组织绩效：
- 安全测试。作为自动化测试过程的一部分测试安全性要求，包括应使用预先批准的代码的区域。
- 将安全审查整合到每个阶段中。将信息安全（ InfoSec ）集成到整个软件交付生命周期的日常工作中。这包括让 InfoSec 团队在应用程序的设计和架构阶段提供输入，参加软件演示，并在演示期间提供反馈。
- 安全审查。对所有主要功能进行安全审查。
- 构建预先批准的代码。让 InfoSec 团队构建预先批准、易于使用的库、包、工具链和流程，供开发人员和IT操作员在工作中使用。
- 尽早并经常邀请 InfoSec 。在规划和应用程序开发的所有后续阶段包括 InfoSec ，以便他们能够尽早发现与安全相关的弱点，从而使团队有足够的时间修复这些弱点。
如前所述，高质量的文档推动了各种功能的成功，安全性也不例外。我们发现，拥有高质量文档的团队在整个开发过程中集成安全性的可能性是其他团队的 3.8 倍。并非组织中的每个人都有密码学方面的专业知识。通过记录在案的安全实践，最好在组织中共享这些人的专业知识。
五、技术 DevOps 能力
我们的研究表明，通过采用连续交付进行DevOps转型的组织更有可能拥有高质量、低风险和成本效益的流程。
具体而言，我们衡量了以下技术实践：
- 松耦合体系结构
- 基于主干的开发
- 持续测试
- 持续集成
- 使用开源技术
- 监控和可观察性实践
- 数据库变更的管理
- 部署自动化
1、松耦合体系结构
我们发现，虽然所有这些实践都改善了连续交付，但松耦合体系结构和持续测试的影响最大。
例如，今年我们发现，达到可靠性目标的精英团队采用松耦合体系结构的可能性是低性能同行的 3 倍。
我们的研究持续续表明，您可以通过减少服务和团队之间的细粒度依赖关系来提高 IT 性能。事实上，这是持续交付成功最有力的预测因素之一。使用松散耦合的体系结构，团队可以彼此独立地进行扩容、失败、测试和部署。团队可以按照自己的节奏前进，以较小的批量工作，积累较少的技术债务，并更快地从失败中恢复。
2、持续测试与持续集成
与前几年的研究结果类似，我们发现持续测试是持续交付成功的有力预测因素。达到可靠性目标的精英团队利用持续测试的可能性是高绩效团队的3.7倍。通过在整个交付过程中结合早期和频繁的测试，测试人员在整个交付过程中与开发人员一起工作，团队可以更快地迭代和更改其产品、服务或应用程序。您可以使用此反馈循环为客户提供价值，同时还可以轻松地结合自动化测试和持续集成等实践。
持续集成还改进了持续交付。精英团队达到可靠性目标的可能性多了 5.8 倍。在持续集成中，每次提交都会触发软件的构建，并运行一系列自动测试，在几分钟内提供反馈。通过持续集成，您可以减少成功集成所需的手动和通常复杂的协调。
由Kent Beck和极限编程社区（它的发源地）定义的持续集成还包括基于主干的开发实践，下面将讨论。
3、主干开发
我们的研究一直表明，高绩效组织更有可能实施基于主干的开发，即：开发人员以小批量工作，并经常将其工作合并到共享主干中。
事实上，达到可靠性目标的精英团队使用基于主干的开发的可能性是 2.3 倍。低绩效者更有可能使用长生产周期的分支，并延迟合并。
团队应至少每天合并一次工作，如果可能的话，每天应合并多次。基于主干的开发与持续集成密切相关，因此您应该同时实现这两种技术实践，因为当您将它们结合使用时，它们会产生更大的影响。
4、部署自动化
在理想的工作环境中，计算机执行重复性任务，而人类则专注于解决问题。实现部署自动化有助于团队更接近这一目标。
当以自动化的方式将软件从测试环境转移到生产环境时，你可以通过实现更快、更高效的部署来缩短交付周期。你还可以降低部署错误的可能性，而部署错误在手动部署中更为常见。
当团队使用部署自动化时，他们会立即收到反馈，这可以帮助你以更快的速度改进服务或产品。虽然你不必同时实施持续测试、持续集成和自动化部署，但当你同时使用这三种实践时，可能会看到更大的改进。
5、数据库变更管理
通过版本控制跟踪变更是编写和维护代码以及管理数据库的关键部分。
我们的研究发现，与表现不佳的同行相比，达到可靠性目标的精英团队执行数据库变更管理的可能性高 3.4 倍。此外，成功的数据库变更管理的关键是所有相关团队之间的协作、沟通和透明度。虽然你楞以选择具体的实现方法，但我们建议，无论何时当你需要对数据库进行更改，团队都应该在你更新数据库之前聚集在一起检查变更。
6、监控和可观测性
与前几年一样，我们发现监控和可观察性实践支持持续交付。
成功实现其可靠性目标的精英团队拥有将可观测性纳入整体系统健康的解决方案的可能性是 4.1 倍。可观察性实践可以让团队更好地了解系统，从而减少识别和排除问题所需的时间。
我们的研究还表明，具有良好可观察性实践的团队花在编码上的时间更多。这一发现的一个可能解释是，实现可观察性实践有助于将开发人员的时间从寻找问题的原因转移到故障排除，并最终返回到编码。
7、开源技术
许多开发人员已经利用了开源技术，他们对这些工具的熟悉是组织的优势。封闭源代码技术的一个主要弱点是，它们限制了组织内外传递知识的能力。例如，你不能雇佣已经熟悉本组织工具的人员，开发人员也不能将他们积累的知识转移到其他组织。相比之下，大多数开源技术都有一个社区，开发者可以使用它来获得支持。开源技术更容易获得，成本相对较低，并且可以定制。达到可靠性目标的精英团队利用开源技术的可能性是 2.4 倍。
我们建议您在实现DevOps转换时使用更多的开源软件。
六、文化
广义地说，文化是每个组织不可避免的人际潜流。它是影响员工对组织和彼此的想法、感受和行为的任何东西。所有组织都有自己独特的文化。
我们的研究结果一致表明，文化是组织和IT绩效的首要驱动因素之一。具体而言，我们的分析表明，生机性文化——使用 Westrum 组织文化类型学以及人们在组织中的归属感和包容性来衡量——预测更高的软件交付和运营（SDO）绩效。
例如，我们发现，达到可靠性目标的精英团队比低绩效团队更容易形成创造性的团队文化。同样，生成性文化可以预测更高的组织绩效和更低的员工倦怠率。
简言之，文化真的很重要。幸运的是，文化是流动的，多方面的，并且总是在不断变化，使它成为你可以改变的东西。
DevOps 的成功执行需要组织拥有协作和跨职能工作的团队。2018 年，我们发现，高绩效团队在单个跨职能团队中开发和交付软件的可能性是其他团队的 2 倍。这强化了协作与合作对任何组织的成功都至关重要的观点。一个关键问题是：哪些因素有助于创造一个鼓励和庆祝跨职能协作的环境？
多年来，我们一直在努力使文化的构建成为有形的，并让 DevOps 社区更好地理解文化对组织和IT绩效的影响。我们通过使用 Westrum 组织文化类型学对文化进行操作性定义开始了这段旅程。他确定了三种类型的组织：权力导向型、规则导向型和绩效导向型。
我们在自己的研究中使用了这一框架，并发现，优化信息流、信任、创新和风险分担的以绩效为导向的组织文化可以预测高SDO绩效。
随着我们对文化和 DevOps 的理解的发展，我们已经努力扩展我们对文化的初始定义，以包括其他心理社会因素，如心理安全。高绩效的组织更有可能拥有一种文化，鼓励员工在不担心负面后果的情况下，有计划地、适度地承担风险。
1、归属与包容
鉴于文化对绩效的影响一直很强，今年我们扩展了模型，探讨员工的归属感和包容性是否有助于文化对绩效的有益影响。
心理学研究表明，人们天生就有与他人建立并保持牢固稳定关系的动机。我们有与他人建立联系的动机，并在我们所居住的各个群体中感到被接受。归属感会带来一系列良好的生理和心理结果。例如，研究表明归属感会积极影响动机，并导致学业成绩的提高。
这种联系感的一个组成部分是这样一种观念，即人们应该感到全身心投入工作的舒适，他们独特的经历和背景受到重视和赞扬。专注于在组织内创造包容性的归属文化有助于创建一支繁荣、多样化和积极的员工队伍。 我们的研究结果表明，与组织文化不太积极的组织相比，注重归属感和包容性的绩效导向组织更有可能具有较低的员工倦怠水平。
鉴于有证据表明心理社会因素如何影响 SDO 绩效和员工的倦怠水平，我们建议，如果您正在寻求成功的 DevOps 转型，您可以投资解决文化相关问题，作为转型工作的一部分。
第 4 章 谁参加了调查
经过七年的研究和超过 32000 份来自行业专业人士的调查回复 Accelerate State of DevOps 2021 展示了使团队和组织最成功的软件开发和 DevOps 实践。
今年，来自全球不同行业的 1200 名在职专业人士分享了他们的经验，以帮助我们更好地理解推动更高绩效的因素。总之，人口统计和立体测量的代表性保持了显著的一致性。
第 5 章 最后的想法
经过七年的研究，我们继续看到 DevOps 给组织带来的好处。
与去年同期相比，各组织继续加速和改进。采用其原则和功能的团队可以快速可靠地交付软件，同时直接为业务带来价值。
今年，我们调查了 SRE 实践、安全软件供应链、质量文档的影响，并重新探讨了利用云的探索。每个领域都使人员和团队更加有效。我们关注的重点是构建适合员工的解决方案，利用这些能力，而不是让员工适应解决方案。
我们感谢所有为今年的调查做出贡献的人，希望我们的研究能够帮助您和您的组织建立更好的团队和更好的软件，同时保持工作与生活的平衡。
第 6 章 致谢
今年的报告是由一大群热情的贡献者促成的。调查问题设计、分析、写作、编辑和报告设计只是我们的同事帮助实现这一巨大努力的几种方式。作者要感谢所有这些人对今年报告的投入和指导。所有确认都按字母顺序列出。
第 7 章 作者
Dustin Smith
Dustin Smith 是谷歌的人因心理学家和员工用户体验研究经理，他在 DORA 项目上工作了三年。在过去的七年中，他研究了人们在各种环境中如何受到周围系统和环境的影响：软件工程、自由游戏、医疗保健和军事。他在谷歌的研究确定了软件开发人员在开发过程中可以感到更快乐、更高效的领域。他为多拉项目工作了两年。达斯汀在威奇托州立大学获得人类因素心理学博士学位。
Daniella Villalba
Daniella Villalba 是一名致力于 DORA 项目的用户体验研究员。她专注于理解使开发人员快乐和高效的因素。在谷歌之前，丹尼拉研究了冥想训练的益处、影响大学生经历的心理社会因素、目击者记忆和虚假供词。她在佛罗里达国际大学获得了实验心理学博士学位。
Michelle Irvine
Michelle Irvine 是谷歌的一名技术写作者，她致力于填补开发人员工具和使用工具的人之间的鸿沟。在谷歌之前，她在教育出版社工作，并担任物理模拟软件的技术作家。米歇尔拥有物理学学士学位，也是滑铁卢大学修辞学和传播学硕士学位。
Dave Stanke
Dave Stanke 是 Google 的开发者关系工程师，他为客户提供采用 DevOps 和 SRE 的实践建议。在他的职业生涯中，他担任过所有职务，包括初创公司首席技术官、产品经理、客户支持、软件开发人员、系统管理员和图形设计师。他拥有哥伦比亚大学技术管理硕士学位。
Nathen Harvey
Nathen Harvey 是谷歌的开发者关系工程师，他的职业生涯是帮助团队实现他们的潜力，同时使技术与业务成果保持一致。Nathen有幸与一些最好的团队和开源社区合作，帮助他们应用DevOps和SRE的原则和实践。Nathen 共同编辑并贡献了“每个云工程师都应该知道的 97 件事”，O’Reilly 2020。
第 8 章 方法论
一、调查问卷的设计
本研究采用 cross-sectional, theorybased 设计。这种基于理论的设计被称为推理预测，是当今商业和技术研究中最常见的类型之一。当无法进行纯实验设计且首选现场实验时，可使用推理设计。
二、目标人群与样本
本次调查的目标人群是从事或密切关注技术和变革的从业者和领导者，尤其是那些熟悉DevOps的人。我们通过电子邮件列表、在线促销、在线小组、社交媒体宣传该调查，并要求人们与其网络分享该调查（即滚雪球抽样）。
三、创建隐藏结构（ Creating latent constructs ）
在可能的情况下，我们使用先前验证过的结构来阐述我们的假设和结构。我们开发了基于理论、定义和专家输入的新结构。然后，我们采取了其他步骤来澄清目的，以确保从调查中收集的数据具有高度的可靠性和有效性。
四、统计分析方法
1、聚类分析。我们使用聚类分析来根据部署频率、交付周期、恢复服务的时间和更改失败率确定软件交付性能概要。我们使用潜在类别分析，因为我们没有任何行业或理论原因来确定预定数量的集群，我们使用贝叶斯信息准则16来确定最佳集群数量。
2、测量模型。在进行分析之前，我们使用探索性因子分析和使用 varimax 旋转的主成分分析确定了结构。我们使用平均方差提取（AVE）、相关性、Cronbachα、和复合信度确认了收敛和发散效度和信度的统计测试。
3、结构方程建模。我们使用偏最小二乘（PLS）分析测试了结构方程模型（SEM），这是一种基于相关性的SEM。
第 9 章 进一步阅读
Find more information on DevOps capabilities at https://cloud.google.com/devops/capabilities
Find resources on site reliability engineering (SRE) at https://sre.google
Take the DevOps Quick Check: https://www.devops-research.com/quickcheck.html
Explore the DevOps research program: https://www.devops-research.com/research.html
Find out about the Google Cloud Application Modernization Program: https://cloud.google.com/camp
Read the “The ROI of DevOps Transformation: How to quantify the impact of your modernization initiatives” whitepaper: https://cloud.google.com/resources/roi-of-devops-transformation-whitepaper
See prior State of DevOps reports: