暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

“谷歌 2022加速: DevOps 状态报告”中文版发布

软件质量报道 2022-10-31
1747
【10月初Google Cloud和DORA(DevOps Research and Assessment)发布了Accelerate State of DevOps report,今天在QECon的组织下,其中文版正式发布。下面是报告中的摘要,完整的报告下载见文章末尾。】

在过去的 8 年里,我们撰写了 加速: DevOps 状态报告(Accelerate State of DevOps report),其间听取了大约 33,000 名专业人士的意见。我们的研究重点在于审 视那些预测 DevOps 核心产出的能力和实 践,包括下列几个方面:
  • 软件交付效能(Software delivery performance)——软件交付效能的四个 关键指标:部署频率、变更前置时间、变 更失败率和服务恢复时间;
  • 运维效能——第五个关键指标是可靠性;
  • 组织绩效——组织实现绩效和盈利目标的情况。
此外我们还关注了导致其他结果 (如职业倦怠)的成因,以及员工 愿意推荐他们团队的可能性。
保护软件供应链
在 2021 年,我们发现保护软件供应链对取得许多重要成果而言至关重要。
今年,我们对软件供应链的安全问题进行了更深入的研究,使其成为调查和报告的中心主题。我们利用软件安全制品的供应链级别(Supply Chain Levels for Secure Artifacts,简称 SLSA) 框架来探索支持软件供应链安全开发的技术实践。我们还使用了国家标准与技术协会(NIST)的安全软件开发框架(Secure Software Development Framework,简称 NIST SSDF) 来探索与软件供应链安全相关的态度、过程和非技术实践。
我们发现,预测一个组织的应用程序开发安全实践水平的最大因素是文化,而不是技术:对于采用新兴安全实践的可能性,注重效能的“高信任和低指责”文化,是注重权力或规则的 “低信任和高指责”文化的 1.6+倍。我们还发现早期的证据表明,部署前安全扫描可以有 效地发现易受攻击的依赖项,从而减少生产代码中的漏洞。
此外,采用良好的应用程序开发安全实践可以带来额外的好处。我们发现,专注于建立这些安全实践的团队减少了开发人员的职业倦怠;安全实践水平低的团队比安全实践水平高的团队职业倦怠的几率高 1.4 倍。专注于建立安全实践的团队明显更有可能将他们的团队推荐给其他人。此外,SLSA 框架相关的安全实践积极地预测了组织绩效和软件交付效能,但这种 效果需要强大的持续集成能力才能完全显现。
 1. 组织绩效的驱动因素
除了上面提到的安全实践,影响组织绩效的关键因素往往属于以下几类:
1) 组织和团队文化
正如 Westrum 定义的那样,“高信任和低指责”的文化往往具有更高的组织绩效。类似地, 如果一个组织的团队感觉得到了资金的赞助和领导的支持,那么它的组织绩效往往会更高。团队稳定性和对团队的积极看法(推荐团队的可能性)也往往会导致更高水平的组织绩效。最后,提供灵活工作安排的公司往往会有高水平的组织绩效。
2) 可靠性
我们与可靠性工程相关的实践(例如,明确的可靠性目标、聚焦的可靠性度量等)和报 告满足其可靠性期望的程度,都是高水平组织绩效的强大预测器。
3) 云
我们发现云的使用可以预测组织的效能。软件最初建立在云上并且云化的公司往往具有更高 的组织绩效。使用私有云、公共云、混合云或多云都比单独使用内部服务器具有更高的组织 绩效。那些使用多种公共云的组织对比不使用的,有 1.4 倍的可能性获得高于平均水平的组 织绩效。
云的使用似乎也通过我们数据集中的其他因素,影响着组织绩效。一个例子是供应链安全, 我们发现使用公共云的组织也更有可能实现 SLSA 实践——可能是因为云提供商鼓励并为 许多 SLSA 实践提供构建块,例如自动化构建和部署。更广泛接受的观点是,使用云平台开 拓了团队,使他们继承了许多最终导向更高组织绩效的能力和实践。
 2. 环境的重要性
长期以来,DORA 考虑到效果取决于更广泛的团队环境(Context,上下文)。我们相信理 解一个团队的特征(流程、优势、约束和目标)以及工作发生的环境是很重要的。例如,在 一个环境中具有优势的技术能力在另一个环境中可能是有害的。今年,我们专注于以相互作 用的形式明确地建模这些假设条件;其中许多假设都得到了今年数据的支持:
  • 只有当运维效能也很高时,较高的软件交付效能才有利于组织绩效。如果我们的服 务不能满足用户的可靠性期望,那么快速交付的价值就没有发挥出来。的。
  • 实现软件供应链安全控制,就像 SLSA 框架所推荐的那样,当持续集成牢固建立时, 对软件交付效能有积极的影响。如果没有合适的持续集成功能,软件交付效能和安 全控制可能会发生冲突。
  • 站点可靠性工程(SRE)实践对团队达到可靠性目标能力的影响是非线性的。在团队达到一定的 SRE 成熟度之前,实践 SRE 不会对可靠性产生积极的影响。在一个团队达到这个级别的 SRE 成熟度之前,我们发现 SRE 和达到可靠性目标之间没有相关性。然而,随着团队采用 SRE 的增长,它达到了一个拐点,SRE 的使用开始强 烈地预测可靠性。持续增长的可靠性会影响组织的效能。
  • 技术能力建立在彼此之上持续的交付和版本控制可以互相增强能力,以促进高水 平软件交付的效能。将持续交付、松耦合的架构、版本控制和持续集成结合起来, 可以培养出比各部分总和更出色的软件交付效能。
软件交付所依赖的条件,以及了解团队更广泛背景的需要,使我们得出了与 2021 年的见解 类似的结论: 为了进行有意义的提升,团队必须采用持续改进的哲学。使用基准测试来度量当前的状态,根据研究和实验所调查的能力来确定约束,并尝试改进以减轻这些约束。实验将包含胜利和失败,但在这两种情况下,团队都可以根据吸取的教训采取有意义的行动。
事实上,我们今年发现了一个与这一总体哲学高度一致的结果: 认识到持续改进必要性的团队,往往比那些没认识到这一点的团队,有更高的组织绩效
简而言之,团队需要不断地适应,并实验软件开发实践。我们知道这一点是因为,总体而言, 这样做的团队具有更高的组织绩效。但并非总是如此(适用于一个组织的东西不一定适用于另一个组织),但大多数情况下都是如此。当我们在进行自己的 DevOps 实践实验时,请为 偶尔的失败做好准备,因为我们正在研究什么适合我们的团队。
今年,我们也在数据中发现了一些令人惊讶的事情,但请你继续阅读,以找出那些是什么。
【下载完整的中文报告】,点击:https://www.modb.pro/doc/79707

最后修改时间:2022-10-31 10:26:27
文章转载自软件质量报道,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论