本文选自 《DORA DevOps 报告 2021》第 3 章 到 第 4 章。
想了解精英团队与低绩效团队之间的差距，以及调查关键发现，可查看《 2021 DevOps 报告(上篇）》。
本文为下半部分：
当 DevOps 社区在公开会议和对话中崭露头角时，谷歌内部正在形成一场志同道合的运动：网站可靠性工程（ 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 倍
技术文档的质量指标参见：
Software Documentation Issues Unveiled
The Value of Software Documentation Quality.
Cost benefits and quality of software development documentation:A systematic mapping. Journal of Systems and Software
如何改进文档的质量
技术工作包括查找和使用信息，但质量文档依赖于编写和维护内容的人员。
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 的理解的发展，我们已经努力扩展我们对文化的初始定义，以包括其他心理社会因素，如心理安全。高绩效的组织更有可能拥有一种文化，鼓励员工在不担心负面后果的情况下，有计划地、适度地承担风险。
归属与包容
鉴于文化对绩效的影响一直很强，今年我们扩展了模型，探讨员工的归属感和包容性是否有助于文化对绩效的有益影响。
心理学研究表明，人们天生就有与他人建立并保持牢固稳定关系的动机。
我们有与他人建立联系的动机，并在我们所居住的各个群体中感到被接受。
归属感会带来一系列良好的生理和心理结果。例如，研究表明归属感会积极影响动机，并导致学业成绩的提高。
这种联系感的一个组成部分是这样一种观念，即人们应该感到全身心投入工作的舒适，他们独特的经历和背景受到重视和赞扬。
专注于在组织内创造包容性的归属文化有助于创建一支繁荣、多样化和积极的员工队伍。我们的研究结果表明，与组织文化不太积极的组织相比，注重归属感和包容性的绩效导向组织更有可能具有较低的员工倦怠水平。
鉴于有证据表明心理社会因素如何影响 SDO 绩效和员工的倦怠水平，我们建议，如果您正在寻求成功的 DevOps 转型，您可以投资解决文化相关问题，作为转型工作的一部分。
