加速：2021 年 DevOps 现状

Google Cloud 的 DevOps 研究与评估 (DORA) 团队今年的《加快改变 DevOps 现状的速度报告》代表了来自全球 32,000 多名专业人士的七年研究和数据。

我们的研究考察了推动软件交付、运营和组织绩效的能力和实践。通过利用严格的统计技术，我们寻求了解促成卓越技术交付和强大业务成果的实践。为此，我们提出了关于有效且高效的技术开发和交付方式的数据驱动分析。

我们的研究持续表明，卓越的软件交付和运营绩效推动了组织在技术转型中的绩效。为了让团队以行业为基准，我们使用聚类分析来形成有意义的绩效类别（例如低、中、高或精英绩效）。在您的团队了解他们当前相对于行业的表现后，您可以使用我们的预测分析结果来定位实践和能力，以改善关键成果，并最终提高您的相对地位。今年，我们强调实现可靠性目标、在整个软件供应链中集成安全性、创建高质量的内部文档以及充分利用云的重要性。我们还探讨了积极的团队文化是否可以减轻因新型冠状病毒感染 (COVID-19) 大流行而导致的远程工作影响。

为了做出有意义的改进，团队必须采用持续改进的理念。使用基准来衡量您的当前状态，根据研究调查的能力确定限制条件，并尝试改进以消除这些限制条件。 实验可能成功，也可能失败，但无论哪种情况，团队都可以根据经验教训采取有意义的行动。

表现最好的团队正在成长并继续提升能力。

在我们的研究中，表现出色的团队现在占所有团队的 26%，他们缩短了生产变更的提前期。行业继续加速发展，团队从中看到了有意义的好处。

SRE 和 DevOps 是相辅相成的理念。

利用我们的站点可靠性工程 (SRE) 朋友概述的现代运营实践的团队报告了更高的运营绩效。优先考虑交付和卓越运营的团队报告了最高的组织绩效。

越来越多的团队正在利用云，并从中看到了巨大的好处。

持续将工作负载迁移到云端的团队以及利用云服务的全部五种功能的团队会发现软件交付和运营 (SDO) 绩效以及组织绩效都有所提高。多云采用率也在提高，因此团队可以利用每个提供商所提供的服务的独特功能。

安全的软件供应链是必不可少的，并且能够提升性能。

鉴于近年来恶意攻击显著增加，组织必须从被动实践转向采取主动和诊断措施。在整个软件供应链中集成安全实践的团队可以快速、可靠、安全地交付软件。

良好的文档是成功实现 DevOps 能力的基础。

我们第一次测量了有助于提高这种质量的内部文档和实践的质量。拥有高质量文档的团队能够更好地实现技术实践并在整体上表现得更好。

积极的团队文化有助于在困难情况下减轻过度劳累。

团队文化对团队交付软件以及实现或超越其组织目标的能力产生重大影响。在新型冠状病毒感染 (COVID-19) 疫情期间，具有积极^1,2 文化的包容性团队经历了较少的过度劳累。

____________________________

1. 从 Westrum 的类型学组织文化来看，积极的团队文化是指高度合作、打破孤岛、让失败引发探究、分担决策风险的团队。

2. Westrum, R. (2004)。“组织文化的类型学。”BMJ 质量与安全，13（增刊 2），ii22-ii27。

我们研究了团队如何开发、交付和操作软件系统，然后将回复者分为四个绩效组：精英绩效者、高绩效者、中等绩效者和低绩效者。通过将您的团队的绩效与每组的绩效进行比较，您可以了解您在本报告中描述的调查结果的环境中所处的位置。

软件交付表现和运营绩效

为了满足不断变化的行业需求，组织必须快速可靠地交付和运营软件。您的团队更改软件的速度越快，您就能越快地为客户带来价值、运行实验以及获得有价值的反馈。 基于七年的数据收集和研究，我们设置并验证了四个用于衡量软件交付表现的指标。自 2018 年以来，我们添加了第五个指标来反映运营能力。

在所有五个指标上均表现出色的团队能够实现卓越的组织绩效。 我们将这五个指标称为软件交付表现和运营 (SDO) 绩效。请注意，这些指标侧重于系统级结果，这有助于避免软件指标的常见缺陷，例如使功能相互竞争以及以整体结果为代价进行局部优化。

关于软件交付表现的四个指标可以从吞吐量和稳定性这两个方面来考虑。我们使用代码更改前的准备时间（即从代码提交到在生产环境中发布的时间）和部署频率来衡量吞吐量，使用突发事件后恢复服务所需的时长和更改失败率来衡量稳定性。

同样，对四个软件交付指标的聚类分析揭示了四种不同的表现情况 - 精英、高、中和低 - 它们之间的吞吐量和稳定性度量存在统计学上的显著差异。与往年一样，我们表现最好的团队在所有四项指标上的表现都明显较好，而表现不佳的团队在所有领域的表现都明显较差。

第五个指标代表运营绩效，可用来衡量现代运营实践。运营绩效的主要指标是可靠性，这是一个团队对他们所运营的软件兑现承诺和断言的程度。从历史上看，我们衡量的是可用性而不是可靠性，但由于可用性是可靠性工程的一个特定焦点，因此我们已经将衡量标准扩展到可靠性，以便更广泛地代表可用性、延迟时间、性能和可伸缩性。具体而言，我们请受访者评估了他们达到或超越其可靠性目标的能力。 我们发现，交付表现程度不同的团队在优先提高运营绩效时会看到更好的结果。

与之前的报告一样，我们将精英绩效者与低绩效者进行了比较，以说明特定能力的影响。不过，今年我们会尽量考虑运营绩效的影响。在所有交付表现类别（从低级到精英级）中，我们看到了优先满足或超过其可靠性目标的团队在多个结果中的主要好处。

每年，我们都会持续看到行业发展，并以更快的速度和更好的稳定性交付软件。第一次，我们的高绩效者和精英绩效者占到回复者的三分之二。此外，与之前的评估相比，今年的精英绩效者再次提高了能力，缩短了变更的提前期（例如，从 2019 年的不到一天缩短到 2021 年的不到一小时）。此外，这是第一次，只有精英绩效者才最大限度地降低了变更失败率（与前几年中高绩效者能够做到这一点相比）。

吞吐量

部署频率

与往年一致，精英团队报告称，他们定期按需部署，每天执行多次部署。相比之下，低绩效者报告每六个月部署次数少于一次（每年少于两次），与 2019 年相比，绩效再次降低。标准化的年度部署数量从最高绩效者每年 1,460 次部署（计算方式为每天 4 次部署 x 365 天）到低绩效者每年 1.5 次部署（两次部署和一次部署的平均值）。该分析近似表明，精英绩效者部署代码的频率是低绩效者的 973 倍。

更改前的准备时间

相较于 2019 年，精英绩效者报告的变更提前期不到一小时，其中变更提前期的衡量标准为从代码提交到代码成功部署到生产环境的时间。与 2019 年相比，绩效有所提升，当时我们的最高绩效者报告的变更提前期不到一天。与我们的精英绩效者相比，低绩效者需要超过六个月的提前期。精英绩效者的提前期为 1 小时（保守估计为“不到 1 小时”的高端），低绩效者的提前期为 6,570 小时（每年 8,760 小时和 6 个月 4,380 小时的平均值），精英团队的变更提前期是低绩效者的 6,570 倍。

稳定性

恢复服务所需的时长

精英团队报告的恢复服务时间不到 1 小时，而低绩效者报告的恢复服务时间则超过 6 个月。对于此计算，我们选择了保守的时间范围：高绩效者为一小时，低绩效者为一年（8,760 小时）和六个月（4,380 小时）的平均值。根据这些数字，精英团队的恢复服务速度是低绩效者的 6,570 倍。与 2019 年相比，精英绩效者恢复服务时间的绩效保持不变，而低绩效者的绩效则提高了。

更改失败率

精英绩效者报告的变更失败率在 0%-15% 之间，而低绩效者报告的变更失败率在 16%-30% 之间。这两个范围之间的平均值显示，精英绩效者的变更失败率为 7.5%，低绩效者为 23%。精英绩效者的变革失败率是低绩效者的三分之一。今年，与 2019 年相比，精英绩效者的变更失败率保持不变，低绩效者的变更失败率有所改善，但介于两者之间的团队则进一步恶化。

将精英团队与低绩效者进行比较，我们发现精英绩效者：

• 代码部署频率是低绩效者的 973 倍
• 从提交到部署，提前期是低绩效者的 6570 倍
• 变更失败率是低绩效者的 1/3（变更失败的可能性是低绩效者的 1/3）
• 从突发事件中恢复的速度是低绩效者的 6570 倍

如何改善 SDO 和组织绩效？我们的研究结果提供了基于证据的指导，以帮助您专注于提高绩效。

今年的报告探讨了云、SRE 做法、安全、技术做法和文化的影响。在本部分中，我们将介绍其中每个功能，并说明它们对各种结果的影响。如果您熟悉 DORA 的 DevOps 现状研究模型，我们创建了一个在线资源来托管今年的模型和之前的所有模型。³

^{____________________________}

3. https://devops-research.com/models.htm

____________________________

与《加快改变 2019 年 DevOps 现状的速度》一致，越来越多的组织正在选择多云和混合云解决方案。在我们的调查问卷中，回复者被问到其主要服务或应用的托管位置，而公有云的使用量有所上升。56% 的回复者表示使用公有云（包括多个公有云），与 2019 年相比增加了 5%。今年，我们还专门询问了多云使用情况，21% 的回复者报告正在部署到多个公有云。21% 的回复者表示不使用云，而是使用数据中心或本地解决方案。最后，34% 的回复者报告使用混合云，29% 的回复者报告使用私有云。

利用混合云和多云加快取得业务成果的速度

今年，我们发现混合云和多云的使用量在增加，这对企业所关心的结果产生了重大影响。使用混合云或多云的回复者超过其组织绩效目标的可能性是未使用混合云或多云的回复者的 1.6 倍。我们还看到了对 SDO 的强烈影响，混合云和多云用户在部署频率、变更提前期、恢复时间、变更失败率和可靠性方面表现出色的可能性要高出 1.4 倍。

为什么选择多云？

与 2018 年的评估类似，我们要求回复者报告他们利用多个公有云提供商的理由。今年，我们并未要求选择所有适用选项，而是请回复者报告使用多个提供商的主要原因。超过四分之一 (26%) 的回复者这样做是为了充分利用每个云服务提供商的独特优势。 这表明回复者选择其他提供商时，会了解当前提供商与备选提供商之间的差别。迁移到多云的第二个最常见原因是可用性 (22%)。不出所料，采用多个云服务提供商的回复者达到或超出其可靠性目标的可能性是 1.5 倍。

使用多个提供商的主要原因

基准变更

实现云基础设施的方式很重要

从过去来看，我们发现并非所有受访者都以相同的方式采用云技术。这导致云采用在推动业务成果方面的有效性有差异。我们通过关注云计算的基本特征（由美国国家标准与技术研究院 [NIST] 定义）并将其作为我们的指南来解决这一限制。我们使用 NIST 云计算定义，研究了基本做法对 SDO 效能的影响，而不仅仅是调查云采用对 SDO 的影响。

我们发现，真正重要的是团队如何实现云服务，而不仅仅是他们在使用云技术。这是我们第三次得出这一结论。精英团队符合所有基本 NIST 云特征的可能性高达 3.5 倍。在声称使用云基础设施的受访者中，仅 32% 同意或强烈同意他们满足 NIST 定义的云计算的所有五个基本特征，比 2019 年增加了 3%。总体而言，NIST 云计算特征的采用率增加了 14%–19%，其中快速弹性的增幅最大。

按需自助服务

使用方可以根据需要自动预配计算资源，而无需提供商方面的任何人工交互。

73% 的回复者使用了按需自助服务，比 2019 年增加了 16%。

广泛的网络访问

功能广泛可用，可以通过多个客户端访问，例如手机、平板电脑、笔记本电脑和工作站。

74% 的回复者曾使用广泛的网络访问，比 2019 年增加了 14%。

资源池

提供商资源在多租户模型中汇集，物理和虚拟资源根据需要动态分配和重新分配。客户通常无法直接控制所提供的资源的确切位置，但可以在更高的抽象级别（例如国家/地区、州/省/自治区/直辖市或数据中心）指定位置。

73% 的回复者使用了资源池，比 2019 年增加了 15%。

快速弹性

功能可以灵活地预配和发布，以快速按需扩容或缩容。可供预配的消费者能力似乎是无限的，并且可以随时以任意数量配置。

77% 的回复者使用了快速弹性，比 2019 年增加了 18%。

衡量的服务

云系统通过利用与服务类型（例如存储、处理、带宽和活跃用户账号）相适应的抽象级别的计量功能来自动控制和优化资源使用。您可以监控、控制和报告资源使用情况，以确保信息透明。

78% 的回复者使用了衡量的服务，比 2019 年增加了 16%。

当 DevOps 社区在公开会议和对话中产生时，Google 内部正在开展一个类似的运动：站点可靠性工程 (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% 的回复者报告在某种程度上使用了这些实践（尽管团队之间采用的深度差异很大）。数据表明，使用这些方法可以预测更高的可靠性和更好的整体 SDO 性能：SRE 有助于 DevOps 取得成功。

此外，我们发现运营责任共担模型（反映在开发者和运营商共同授权为可靠性做出贡献的程度）也可以预测更好的可靠性结果。

除了提高客观的绩效衡量标准以外，SRE 还可以改善技术从业者的工作体验。通常，执行大量运营任务的个人容易感到倦怠，而 SRE 可以产生积极的影响。我们发现，团队采用的 SRE 做法越多，其成员感到倦怠的可能性越小。SRE 也有助于优化资源：通过采用 SRE 做法实现其可靠性目标的团队表示，与不采用 SRE 做法的团队相比，他们花费更多时间来编写代码。

我们的研究表明，任何 SDO 效能水平的团队（从低效能到精英团队）都可以从 SRE 实践的增加中受益。团队的效能越好，他们采用现代运营模式的可能性就越大：精英团队报告使用 SRE 实践的可能性是低效能团队的 2.1 倍。但即使是运营水平最高的团队也有增长空间：只有 10% 的精英受访者表示他们的团队已经完全实施了我们调查的每一项 SRE 实践。随着各行业 SDO 效能的不断增强，每个团队的运营方法都是 DevOps 持续改进的关键驱动因素。

____________________________

4. Betsy Beyer 等编辑，站点可靠性工程（O'Reilly Media，2016 年）。

____________________________

文档

今年，我们考察了内部文档的质量，即团队所开发的服务和应用的文档，例如手册、自述文件，甚至代码注释。我们按文档在以下方面的表现来衡量文档质量：

• 帮助读者实现目标
• 准确、最新且全面
• 可找到、组织良好且清晰⁵

记录和访问有关内部系统的信息是团队技术工作的关键部分。我们发现，约 25% 的受访者拥有高质量的文档，这种文档工作的影响是显而易见的：文档质量较高的团队有更好的软件交付和运营 (SDO) 效能的可能性是其他团队的 2.4 倍。文档质量好的团队能够比文档质量差的团队更快、更可靠地交付软件。文档不必是完美无缺的。我们的研究表明，文档质量的任何改进都会对效能产生积极和直接的影响。

今天的技术环境中有越来越复杂的系统，以及这些系统不同方面的专家和专业角色。从安全到测试，文档是在这些专业化团队之间以及与更广泛的团队共享专业知识和指导的关键方式。

我们发现，文档质量可以预测团队在实施技术实践方面的成功。这些实践继而又可以预测系统技术能力的改进，如可观测性、连续测试和部署自动化。我们发现，拥有优质文档的团队：

• 实施安全做法的可能性高达 3.8 倍
• 达到或超出其可靠性目标的可能性高达 2.4 倍
• 实施站点可靠性工程 (SRE) 做法的可能性高达 3.5 倍
• 充分利用云的可能性提高了 2.5 倍

如何提高文档质量

技术工作涉及查找和使用信息，但质量文档依赖于编写和维护内容的人员。2019 年，我们的研究发现，访问内部和外部信息源可提高工作效率。今年的研究进一步考察了所访问文档的质量，以及对文档质量有影响的实践。

我们的研究表明，以下做法对文档质量有显著的积极影响：

记录产品和服务的关键用例。您记录的关于系统的内容非常重要，而用例可让读者将信息和系统运用于工作。

创建有关更新和修改现有文档的明确指导原则。大部分文档工作都是维护现有内容。当团队成员知道如何进行更新或删除不准确或过时的信息时，即使系统随时间变化，团队也可以保持文档质量。

定义所有者。拥有高质量文档的团队更有可能拥有明确定义的文档所有权。所有权允许明确负责编写新内容以及更新或验证对现有内容的更改。拥有高质量文档的团队更有可能声明文档是针对他们所从事的应用的所有主要功能编写的，明确的所有权有助于创建这种广泛的覆盖范围。

将文档作为软件开发过程的一部分。创建文档并在系统更改时进行更新的团队拥有更高质量的文档。与测试一样，文档创建和维护也是高性能软件开发过程不可或缺的一部分。

在绩效考核和晋升中认可文档工作。认可与文档的整体质量具有相关性。编写和维护文档是软件工程工作的核心部分，认可其核心作用有助于提高文档质量。

我们发现，可为高质量文档提供支持的其他资源包括：

• 关于如何编写和维护文档的培训
• 对代码示例或不完整文档的自动化测试
• 各种指南，例如文档风格指南和面向全球读者的写作指南

文档是成功实现 DevOps 功能的基础。更高质量的文档会提升各个 DevOps 功能（例如安全性、可靠性和充分利用云）的投资成效。通过实施支持高质量文档的做法，您可以获得更强的技术能力和更高的 SDO 效能。

____________________________

5. 现有技术文档研究提供的质量指标，例如：

- Aghajani, E. 等 (2019)。软件文档问题揭晓。2019 年 IEEE/ACM 第 41 届软件工程国际会议论文集，1199-1210。https://doi.org/10.1109/ICSE.2019.00122

— Plösch, R.、Dautovic, A. & Saft, M. (2014)。软件文档质量的价值。质量软件国际会议论文集，333-342。https://doi.org/10.1109/QSIC.2014.22

- Zhi, J. 等 (2015)。软件开发文档的成本效益和质量：系统映射。系统与软件杂志，99(C)，175-198。https://doi.org/10.1016/j.jss.2014.09.042

____________________________

安全性

[左移] 并贯穿始终

随着技术团队不断加速和发展，安全威胁的数量和复杂程度也在不断增加。根据 Tenable 的 2020 年威胁形势回顾报告，2020 年，超过 220 亿条机密个人信息或业务数据记录被泄露。⁶安全不能是事后考虑或交付前的最后一步，必须集成在整个软件开发过程中。

为了安全地交付软件，安全实践必须比恶意行为者使用的技术发展得更快。在 2020 年 SolarWinds 和 Codecov 软件供应链攻击期间，黑客入侵了 SolarWinds 的构建系统和 Codecov 的 bash 上传程序脚本⁷，以秘密地将自己嵌入到这些公司数千名客户的基础设施中。鉴于这些攻击的广泛影响，行业必须从预防转向诊断方法，在这种方法中，软件团队应该假设他们的系统已经受到威胁，并在他们的供应链中建立安全性。

与之前的报告一致，我们发现精英绩效者擅长实施安全实践。今年，达到或超过其可靠性目标的精英绩效者将安全集成到他们的软件开发过程中的可能性提高了一倍。这表明，在保持可靠性标准的同时加快交付速度的团队已经找到了一种集成安全检查和实践的方法，而不会影响他们快速或可靠地交付软件的能力。

除了表现出高交付和运营绩效外，在整个开发过程中集成安全实践的团队实现或超过其组织目标的可能性要高出 1.6 倍。

____________________________

6. https://www.tenable.com/cyber-exposure/2020-threat-landscape-retrospective

7. https://www.cybersecuritydive.com/news/codecov-breach-solarwinds-software-supply-chain/598950/

____________________________

如何正确处理

强调安全的重要性并建议团队对其进行优先排序很容易，但这样做需要对传统的信息安全方法进行一些更改。您可以集成安全性，通过利用以下实践来提高软件交付和运营绩效，并提高组织绩效：

测试安全性。测试安全性要求是自动化测试流程的一部分，包括应使用预批准代码的领域。

将安全审核纳入每个阶段中。将信息安全 (InfoSec) 集成到整个软件交付生命周期的日常工作中。这包括让信息安全团队在应用的设计和架构阶段提供输入，参加软件演示，并在演示期间提供反馈。

安全审核。对所有主要功能进行安全审核。构建预批准的代码。让 InfoSec 团队构建预批准的且易于使用的库、软件包、工具链和流程，以供开发者和 IT 运营人员在工作中使用。尽早并经常邀请 InfoSec 团队成员。在规划和应用开发的所有后续阶段邀请 InfoSec 团队成员，以便他们能够及早发现与安全相关的弱点，从而为团队提供充足的时间来修复它们。

构建预批准的代码。让 InfoSec 团队构建预批准的且易于使用的库、软件包、工具链和流程，以供开发者和 IT 运营人员在工作中使用。

尽早并经常邀请 InfoSec 团队成员。在规划和应用开发的所有后续阶段邀请 InfoSec 团队成员，以便他们能够及早发现与安全相关的弱点，从而为团队提供充足的时间来修复它们。

正如我们之前提到的，高质量的文档推动了各种功能的成功，安全性也不例外。我们发现，拥有高质量文档的团队在整个开发过程中集成安全性的可能性高达 3.8 倍。并非组织中的每个人都具有加密专业知识。通过记录在案的安全实践，可以最好地在组织中分享相关人员的专业知识。

我们的研究表明，通过采用持续交付进行 DevOps 转型的组织更有可能拥有高质量、低风险和具有成本效益的流程。

具体而言，我们衡量了以下技术实践：

• 松散耦合架构
• 主干开发
• 持续测试
• 持续集成
• 使用开源技术
• 监控和可观测性实践
• 数据库变更管理
• 部署自动化

我们发现，虽然所有这些实践都改进了持续交付，但松散耦合架构和持续测试的影响最大。例如，今年我们发现，达到可靠性目标的精英绩效者采用松散耦合架构的可能性是低绩效者的三倍。

松散耦合的架构

我们的研究持续表明，您可以通过减少服务和团队之间的精细依赖关系来提高 IT 效能。事实上，这是成功持续交付最有力的预测因素之一。使用松散耦合的架构，团队可以彼此独立地扩缩、失败、测试和部署。团队可以自主掌控节奏，以较小的批量工作，积累较少的技术债务，并更快地从失败中恢复。

持续测试和持续集成

与我们前几年的发现类似，我们表明持续测试是成功持续交付的有力预测因素。达到可靠性目标的精英绩效者利用持续测试的可能性高达 3.7 倍。通过在整个交付过程中结合早期和频繁的测试，测试人员与开发者一起工作，团队可以更快地迭代和更改他们的产品、服务或应用。您可以使用此反馈循环为您的客户提供价值，同时还可以轻松整合自动化测试和持续集成等实践。

持续集成还可以改进持续交付。 达到可靠性目标的精英团队利用持续集成的可能性高达 5.8 倍。在持续集成中，每次提交都会触发软件的构建，并运行一系列自动化测试，这些测试会在几分钟内提供反馈。通过持续集成，您可以减少成功集成所需的手动且通常是复杂的协调工作。

持续集成（由 Kent Beck 和它发起的极限编程社区定义）还包括基于主干的开发实践，接下来将讨论。⁷

主干开发

我们的研究一直表明，高绩效组织更有可能实施基于主干的开发，其中开发者从事小批量工作，并经常将他们的工作合并到一个共享主干中。事实上，达到可靠性目标的精英绩效者使用主干开发的可能性高达 2.3 倍。低绩效者更有可能使用长期存在的分支并延迟合并。

团队应该每天至少合并一次他们的工作 - 如果可能的话，每天合并多次。基于主干的开发与持续集成密切相关，因此您应该同时实施这两种技术实践，因为当您将它们一起使用时它们会产生更大的影响。

部署自动化

在理想的工作环境中，计算机执行重复性任务，而人类则专注于解决问题。实施部署自动化可帮助您的团队更接近这一目标。

当您以自动化方式将软件从测试转移到生产时，您可以通过实现更快、更高效的部署来缩短交付周期。您还可以降低部署错误的可能性，这在手动部署中更为常见。当您的团队使用部署自动化时，他们会立即收到反馈，这可以帮助您以更快的速度改进您的服务或产品。虽然您不必同时实施持续测试、持续集成和自动化部署，但当您将这三种实践结合使用时，您可能会看到更大的改进。

数据库更改管理

通过版本控制跟踪更改是编写和维护代码以及管理数据库的关键部分。我们的研究发现，与低绩效者相比，达到可靠性目标的精英绩效者进行数据库变更管理的可能性高达 3.4 倍。此外，成功的数据库变更管理的关键是所有相关团队之间的协作、沟通和透明度。虽然您可以从特定的实施方法中进行选择，但我们建议您在需要对数据库进行更改时，在更新数据库之前，团队应该聚在一起审查更改。

____________________________

8. Beck, K. (2000)。极限编程解释：拥抱变化。Addison-Wesley Professional

____________________________

监控和可观测性

与前几年一样，我们发现监控和可观测性实践支持持续交付。成功实现其可靠性目标的精英绩效者拥有将可观测性纳入整体系统运行状况的解决方案的可能性高达 4.1 倍。可观测性实践让您的团队更好地了解您的系统，从而减少识别和解决问题所需的时间。我们的研究还表明，具有良好可观测性实践的团队会花费更多时间进行编码。对此发现的一种可能解释是，实施可观测性实践有助于将开发者的时间从寻找问题的原因转移到问题排查并最终回到编码上。

开源技术

许多开发者已经利用开源技术，他们对这些工具的熟悉是组织的一项优势。闭源技术的一个主要缺点是，它们限制了向组织内外传递知识的能力。例如，你不能雇佣已经熟悉本组织工具的人员，开发者也无法将他们积累的知识转移到其他组织。相比之下，大多数开源技术都有一个社区，开发者可以使用它来获得支持。开源技术更容易获得、费用相对较低，并且可以自定义。达到可靠性目标的精英团队利用开源技术的可能性高达 2.4 倍。我们建议您在实现 DevOps 转型时改用更多开源软件。

如需详细了解 DevOps 技术能力，请访问 https://cloud.google.com/devops/capabilities 查看 DORA 功能

COVID-19

今年，我们调查了 COVID-19 疫情期间影响团队表现的因素。具体来说，COVID-19 疫情是否对软件交付和运营 (SDO) 效能产生了负面影响？团队是否因此感到过度劳累？最后，哪些因素可以减轻倦怠？

首先，我们想要了解疫情对交付和运营效能的影响。许多组织都已优先进行现代化改造，以应对市场的巨大变化（例如，从线下购物到线上购物）。在“我们如何比较？”章节，我们探讨了软件行业的效能如何大幅提升，并继续加快发展。在我们的样本中，高效能团队现在已成为大多数，而精英团队则继续提高标准，他们的部署频率更高、提前期更短、恢复时间更短、变更失败率更低。同样，GitHub 研究人员的一项研究表明，2020 年，开发者的活动（即推送、拉取请求、审核的拉取请求以及每个用户评论的问题⁹）有所增加。可以说，疫情带来的是负面影响而不是正面影响，但整个行业仍在加速发展。值得注意的是，在这一艰难时期，SDO 效能并未出现下降趋势。

这场疫情改变了我们的工作方式，也改变了很多公司的工作地点。因此，我们研究了疫情导致的远程办公的影响。我们发现，89% 的受访者因疫情而在家办公。仅 20% 的受访者表示在疫情之前曾在家办公。转移到远程工作环境对我们开发软件、开展业务和协同工作的方式产生了重大影响。对很多人而言，在家办公减弱了在走道即兴聊天或当面协作的能力。

____________________________

9. https://octoverse.github.com/

____________________________

什么因素减少了倦怠？

尽管如此，我们仍然发现了一个对团队是否因远程办公而感到倦怠有很大影响的因素：文化。由具有包容性和归属感的成员组成并具有生成式团队文化的团队在疫情期间感到倦怠的概率是其他团队的一半。这一发现突出了团队和文化的重要性。表现出色的团队准备充分，能够安然度过给团队和个人都带来压力的困难时期。

文化

广义地说，文化是每个组织不可避免的人际暗流。它是影响员工对组织和其他员工的想法、感受和行为的任何东西。每个组织都有自己独特的文化，我们的研究结果一致表明，文化是组织和 IT 效能的主要驱动因素之一。具体而言，我们的分析表明，生成式文化（使用 Westrum 组织文化类型学以及人们在组织中的归属感和包容性来衡量）预示着更高的软件交付和运营 (SDO) 效能。例如，我们发现，达到可靠性目标的精英团队拥有生成式团队文化的可能性是低效能团队的 2.9 倍。同样，生成式文化预示着更高的组织绩效和更低的员工倦怠率。简而言之，文化真的很重要。 幸运的是，文化是流动的，多面的，并且总是在不断变化，使得人们可以改变它。

DevOps 的成功执行要求组织拥有协作和跨职能工作的团队。2018 年，我们发现，高效能团队在单一的跨职能团队中开发和交付软件的可能性是其他团队的 2 倍。这加强了协作与合作对任何组织的成功都至关重要的观点。一个关键问题是：哪些因素有助于创造一个鼓励和支持跨职能协作的环境？

多年来，我们一直在努力使文化的构建变得有形，并让 DevOps 社区更好地理解文化对组织和IT绩效的影响。我们通过使用 Westrum 的组织文化类型学对文化进行运营上的定义来开始这一过程。他确定了三种组织类型：以权力为导向、以规则为导向和以绩效为导向。我们在自己的研究中使用了这一框架，并发现，针对信息流、信任、创新和风险分担进行优化的绩效导向型组织文化预示着高 SDO 效能。

随着我们对文化和 DevOps 的理解不断完善，我们已努力扩展文化的初始定义，使其包括心理安全等其他心理社会因素。高绩效的组织更有可能拥有这样一种文化，即鼓励员工有计划地、适度地承担风险，而不必担心负面后果。

归属与包容

鉴于文化对绩效的持续强大影响，今年我们扩展了模型，以探索员工的归属感和包容感是否有助于文化对绩效的有益影响。

心理研究表明，人们天生就有与其他人建立并保持牢固且稳定的关系的动机。¹⁰我们有动力去与他人建立联系，并在我们居住的各个群体中感到被接纳。归属感会带来一系列有益的生理和心理结果。例如，研究表明，归属感对动机有积极影响，并有助于提升学术成就。¹¹

这种联系感的一个组成部分是，人们应该对全身心投入工作感到自在，并且他们独特的经历和背景受到重视和赞赏。¹²专注于在组织内创造包容性的归属感文化有助于创造一个繁荣、多样化和积极进取的员工队伍。

我们的研究结果表明，与组织文化不那么积极的组织相比，注重归属感和包容性的绩效导向型组织更有可能具有较低的员工倦怠水平。

鉴于有证据表明心理社会因素如何影响 SDO 绩效和员工的倦怠程度，我们建议，如果您正在寻求成功的 DevOps 转型，您可以投资解决与文化相关的问题，作为转型工作的一部分。

____________________________

10. Baumeister 和 Leary，1995。归属的需要：将人际依恋作为人类基本动机的渴望。心理公报，117(3)，497-529。https://doi.org/10.1037/0033-2909.117.3.497

11. Walton 等，2012。单纯的归属感：社交关系的力量。人格与社会心理学杂志，102(3):513-32。https://doi.org/10.1037/a0025731

12. Mor Barak 和 Daya，2014；管理多元化：朝着全球包容的工作场所前进。Sage. Shore、Cleveland 和 Sanchez，2018；具有包容性的工作场所：评价和模型，人力资源评价。https://doi.org/10.1016/j.hrmr.2017.07.003

凭借七年的研究和来自行业专业人士的 32,000 多份调查回复，2021 年《加快改变 DevOps 现状速度》展示了使团队和组织取得最大成功的软件开发和 DevOps 实践。

今年，来自全球各行各业的 1200 名专业人士分享了他们的经验，帮助我们更好地了解推动更高绩效的因素。总而言之，受众特征和企业特征衡量的取样比例仍保持着高度的一致性。

与往年类似，我们收集了每一位调查问卷回复者的受众特征信息。类别包括性别、残障人士和代表性不足的群体。

人口特征和企业特征 

今年，公司规模、行业和区域等企业特征类别的取样比例和之前的报告一致。其中超过 60% 的受访者是工程师或经理，且三分之一来自科技行业。此外，还有来自金融服务、零售和工业/制造公司的业界代表。

____________________________

13. https://www.washingtongroup-disability.com/question-sets/wg-short-set-on-functioning-wg-ss/

____________________________

性别

与以往的问卷调查一样，今年的样本包括 83% 的男性、12% 的女性和 1% 的非二元性别。受访者表示，女性在其团队中约占 25%，相比 2019 年大幅增长 (16%)，再次与 2018 年保持一致 (25%)。

残障

我们根据 Washington Group Short Set 指南从 6 个维度标识残障。¹³这是我们询问残障情况的第三年。残障人士所占比例为 9%，与我们 2019 年的报告一致。

代表性不足的群体

受访者可能会因种族、性别或其他特征而被认定为属于代表性不足的群体。这是我们第四年询问代表性不足的群体相关信息。被认定为属于代表性不足群体的受访者所占比例从 2019 年的 13.7% 小幅增加到 2021 年的 17%。

工作年限

今年的回复者拥有丰富的经验，41% 的回复者至少拥有 16 年的经验。超过 85% 的回复者拥有至少 6 年的工作经验。

部门

回复者大多为开发团队或工程团队 (23%)、DevOps 团队或 SRE 团队 (21%)、主管 (18%) 以及 IT 运营或基础架构团队 (9%) 的成员）。我们看到顾问的代表性有所下降（2019 年为 4% 至 2%），而高管层的人数有所增加（2019 年为 4% 至 9%）。

行业

与以前的《加快改变 DevOps 现状的速度》报告一样，我们发现大多数回复者都是在技术行业工作，接着是金融服务、零售和其他行业。

员工

与以前的《加快改变 DevOps 现状的速度》报告一样，回复者来自不同的组织规模。22% 的受访者来自员工人数超过 10,000 的公司，7% 的受访者来自员工人数介于 5,000 - 9,999 之间的公司，另有 15% 的回复者所属的组织拥有 2,000-4,999 名员工。此外，有 500-1,999 名员工占 13%、100-499 名员工占 15%，20-99 名员工占 15%，这样的回复者具有代表性。

团队规模

超过半数 (62%) 的回复者 (62%) 负责处理成员不超过 10 人的团队（6-10 名为 28%、2-5 人为 27% 以及单人团队为 6%）。另外 19% 的团队成员是 11-20 名的团队成员。

Regions

今年的调查显示，北美洲用户的回复减少（2019 年为 50%，2021 年为 39%）。欧洲（2019 年为 29%，2021 年为 32%）、亚洲（2019 年为 9%，2021 年为 13%）、大洋洲（2019 年为 4%，2021 年为 6%）、南美洲（2019 年为 2%，2021 年为 4%）占比则有所增长。

操作系统

操作系统的分布情况与以前的 DevOps 现状报告一致。我们还要感谢那些曾强调我们的操作系统可以更新的受访者。

今年，我们调查了受访者的主要工作或应用的部署目标。令我们感到惊讶的是，很大一部分受访者使用的是容器 (64%)，48% 使用的是虚拟机。这可能反映了该行业向更现代的部署目标技术的转变。我们查看了不同公司规模之间的差异，未发现部署目标之间存在显著差异。

遵循其原则和功能的团队可以快速可靠地交付软件，同时直接为业务带来价值。今年，我们调查了 SRE 实践、安全软件供应链和质量文档的影响，并重新审视了利用云技术的探索。每个领域都能提高人员和团队的效率。我们关注的重点是构建适合利用这些功能的员工的解决方案，而不是让员工来适应解决方案。

我们衷心感谢为今年的调查做出贡献的所有人，希望我们的研究能够帮助您和您的组织构建更好的团队和更好的软件，同时还能保持工作与生活的平衡。

今年的报告是在众多热情的贡献者的参与下完成。我们的同事为帮助完成这一庞大计划付出了巨大的心血，调查问卷的问题设计、分析、撰写、编辑和报告设计只是其所做工作一部分。全体作者由衷感谢所有人对今年报告的贡献和指导。致谢对象名单按字母顺序列出。

Dustin Smith

Dustin Smith 是 Google 的人因心理学家和员工用户体验研究经理，他从事 DORA 项目已有三年时间。在过去的七年中，他研究了人们在各种情境中如何受到周围系统和环境的影响：软件工程、免费游戏、医疗保健和军事。他在 Google 的研究确定了软件开发者在开发过程中可以感到更快乐、工作更高效的领域。他从事 DORA 项目已有两年时间。Dustin 获得了威奇托州立大学的人因心理学博士学位。

Daniella Villalba

Daniella Villalba 是专门负责 DORA 项目的用户体验研究员。她专注于研究使开发者保有幸福感并提高效率的因素。在加入 Google 之前，Daniella 研究过冥想训练的益处、影响大学生经历的心理社会因素、目击者记忆和虚假供认。她拥有佛罗里达国际大学的实验心理学博士学位。

Michelle Irvine

Michelle Irvine 是 Google 的技术文档工程师，负责在开发者工具与使用这些工具的用户之间搭建桥梁。在加入 Google 之前，她在教育出版社工作，并为物理模拟软件撰写技术文档。Michelle 拥有滑铁卢大学的物理学学士学位，以及修辞和传播设计硕士学位。

Dave Stanke

Dave Stanke 是 Google 的开发者关系工程师，负责为客户提供采用 DevOps 和 SRE 的实践建议。在他的职业生涯中，他担任过各种职务，包括初创公司首席技术官、产品经理、客服人员、软件开发者、系统管理员和图形设计师。他拥有哥伦比亚大学技术管理硕士学位。

Nathen Harvey

Nathen Harvey 是 Google 的开发者关系工程师，致力于帮助团队充分发挥自身潜力，同时根据业务成效来调整技术。Nathen 曾有幸与一些优秀的团队和开源社区合作，帮助他们应用 DevOps 和 SRE 的原则和实践。Nathen 曾参与编辑 O’Reilly 2020 年出版的《97 Things Every Cloud Engineer Should Know》（所有云端工程师都应知道的 97 件事），贡献一己之力。

研究设计

本研究采用了基于理论的跨行业设计。这种基于理论的设计被称为推断性预测，是当今商业和技术研究中最常见的类型之一。当无法进行纯实验设计且首选现场实验时，可使用推断设计。

目标人群和采样

此调查问卷的目标人群是技术和转型领域的从业者和领导者，尤其是熟悉 DevOps 的人士。我们通过电子邮件列表、在线促销信息、在线小组、社交媒体宣传了该调查，并邀请了参与者在其人际网络中分享该调查（即滚雪球抽样）。

创建潜在结构

我们尽可能根据之前经过验证的构念来准备我们的假设和构念。我们基于理论、定义和专家意见建立全新的构念。然后，我们执行额外的步骤来阐明意图，以确保通过调查问卷收集的数据可靠且有效的可能性较高。¹⁴

统计分析方法

聚类分析。我们使用聚类分析，根据部署频率、提前期、恢复服务的时间和更改失败率来确定软件交付效能概况。我们使用了潜在类分析¹⁵，因为我们没有任何行业或理论原因来确定预定数量的聚类，我们使用贝叶斯信息标准 (16) 来确定最佳聚类数量。

测量模型。 在进行分析之前，我们通过探索性因子分析和使用 varimax 旋转的主成分分析确定了结构。¹⁷我们使用平均方差提取值 (AVE)、相关性、Cronbach 的 Alpha 值¹⁸ 和复合信度确认了收敛和发散效度和信度的统计测试。

结构方程建模。我们使用偏最小二乘 (PLS) 分析测试了结构方程模型 (SEM)，这是一种基于相关性的 SEM。¹⁹

^{________________________}

14. Churchill Jr, G. A. “A paradigm for developing better measures of marketing constructs”（改进营销构念衡量的范式），《Journal of Marketing Research》（营销研究杂志）16:1，(1979)，64–73。

15. Hagenaars, J. A., 和 McCutcheon, A. L. 编辑，(2002)。应用潜在类分析。剑桥大学出版社。

16. Vrieze, S. I. (2012)。模型选择与心理学理论：Akaike 信息准则（AIC）和贝叶斯信息准则（BIC）之间差异的讨论。心理学方法，17(2)，228。

17. Straub, D., Boudreau, M. C. 和 Gefen, D.(2004)。IS 实证研究的验证指南。《Communications of the Association for Informa-tion systems》（信息系统协会通讯），13(1)，24。

18. Nunnally, J.C. 心理测量理论。纽约：McGraw-Hill，1978

19. Hair Jr, J. F., Hult, G. T. M.、Ringle, C. M. 和 Sarstedt, M. （2021 年）。《偏最小二乘结构方程建模 (PLS-SEM) 入门》。圣人出版物

如需详细了解 DevOps 功能，请访问 https://cloud.google.com/devops/capabilities

在以下位置查找有关站点可靠性工程 (SRE) 的资源

https://sre.google

执行 DevOps 快速检查：

https://www.devops-research.com/quickcheck.html

浏览 DevOps 研究项目：

https://www.devops-research.com/research.html

了解 Google Cloud 应用现代化改造计划：

https://cloud.google.com/solutions/camp

阅读《DevOps 转型的投资回报率：如何量化现代化改造计划的影响》白皮书：

https://cloud.google.com/resources/roi-of-devops-transformation-whitepaper

查看以前的 DevOps 现状报告：

DevOps 2014 现状：https://services.google.com/fh/files/misc/state-of-devops-2014.pdf

DevOps 2015 现状：https://services.google.com/fh/files/misc/state-of-devops-2015.pdf

DevOps 2016 现状：https://services.google.com/fh/files/misc/state-of-devops-2016.pdf

DevOps 2017 现状：https://services.google.com/fh/files/misc/state-of-devops-2017.pdf

加快改变 2018 年 DevOps 现状的速度：https://services.google.com/fh/files/misc/state-of-devops-2018.pdf

加快改变 2019 年 DevOps 现状的速度：

https://services.google.com/fh/files/misc/state-of-devops-2019.pdf