这场大流行加速了经济向数字原生服务和产品的过渡。在各个行业和类别中，面对日益严重的人才短缺和竞争，各组织都希望扩大他们的开发业绩。在全球建立的DevOps社区中，包括共享的实践和专用DevOps工具和技术的凶猛市场，大规模的调查提供了一个有用的外部视角来衡量他们团队的表现并评估改进的方案。
2021年，三份经过深入研究的报告已经出版，涵盖了DevOps和软件交付领域。每份报告都针对相同的公司统计数据，并在很大程度上应用了可比的分析方法。因此，将这些报告进行并列比较，寻找重叠的结果，作为既定标准和明确趋势的指标，是一项有见地的工作。这篇文章回顾了关于DevOps状态的三份最新报告：Puppet DevOps状态、Google Cloud Accelerate DevOps状态和Humanitec DevOps状态标杆分析（以下分别为Puppet、Google和Humanitec）。
这三份报告都使用了通过Nicole Forsgren、Jez Humble和Gene Kim的《加速》一书普及的软件开发性能指标。由于其概念上的优势，这些指标演变成了团队绩效的既定指标，被称为DORA指标：交付准备时间、部署频率、平均恢复时间和变更失败率。
有两个核心方面使它们有效。首先，用户倾向于针对指标进行优化，而不是客户体验。这是所有衡量标准的一个共同问题。然而，四个指标的组合可以平衡片面的操纵。例如，如果一个团队不合理地推动了部署频率，就会对变更失败率产生负面影响。第二，聪明的衡量标准考虑的是工作的影响，而不是工作的存在。例如，恢复的平均时间，可能需要大量的平淡无奇的、常常不被注意的工作来为实际事件做准备。有效的衡量标准是以最终用户客户为中心来衡量结果。快速的恢复时间意味着更好的客户体验。
客户需求不断变化，组织必须以快速可靠地交付和运行软件的能力来适应。在以结果为导向的系统级指标上衡量软件交付性能，可以为DevOps的状态提供可靠的洞察力。
跨越软件交付性能的关键发现
软件交付性能指标是字母数字性质的。所有的报告都将调查结果分为三组，分别代表高、中、低绩效者。Humanitec的报告使用了一个全面的评分系统，对四个群组的受访者进行基线分析。这种方法使作者能够放大每个组群中的绩效趋势。(例如。有多达50%的被认为是低绩效的组织能够实现平均不到一天的良好恢复时间）。
系统层面的指标是相当复杂的，以平均化单一工具或做法的影响。虽然在高绩效和平均绩效之间的界限总是有争议的，但分层是相当明显的。谷歌计算了一个概率来说明低绩效和高绩效团队之间的相对绩效差异，这突出了令人印象深刻的结果，但可能让读者感到困惑。("与低绩效团队相比，高绩效团队从提交到部署的时间要快6.570倍。")
然而，在所有调查中，总体情况是明确的。绩优组织为竞争力设定了一个明确的标准。在所有四个指标中，表现最好的组织在接受调查的公司中占了很大比例。现在不仅仅是一些名人品牌的表现超过了其他人。顶尖表现已经成为各行业和各地区软件开发团队的事实标准。
图片。来自Puppet的软件交付性能指标和成果层级
部署频率 衡量软件组织将代码部署到生产中或发布给终端用户的频率。它是一个代理，捆绑了相互关联和理想的效果。例如，较小的批次往往会更频繁地出货，这也降低了风险。每天部署是高绩效团队的特征。高绩效团队中的一个分组甚至按需部署。低绩效团队则远远落后于此，他们的部署频率在几周或一年中只有几次。
变更的准备时间是指代码从提交到测试再到成功交付到生产的各个阶段所需的时间。几乎有一半的软件交付机构将标准定得很高，不到1天，有时甚至只有几分钟的准备时间，这使得他们有能力非常迅速地改善客户体验。即使是中等规模的企业也远远落后于此，25%的受访者花了一天到一周的时间来交付代码。根据Humanitec的数据，另外20%的人需要一个星期到一整个月的准备时间。
恢复（或者说复原）服务的平均时间衡量的是在发生影响用户的事件或缺陷后，恢复服务所需的时间。虽然大多数软件组织可以在1天之内恢复服务。表现最好的企业，代表了近50%的受访团队，在不到1小时内就能恢复他们的服务。随着公司的价值流转向数字服务，服务中断的每一秒钟都是有价值的，而且要花钱。这对那些继续在几天或几周的恢复时间中挣扎的人来说是一个明确的警钟。恢复服务的时间少于1天是事实上的标准。
变更失败率是指发布到生产中的有缺陷的变更的数量，这些变更导致最终用户的服务下降，需要进行补救。Puppet使用一个非常雄心勃勃的门槛，即5%来识别表现最佳的团队。Humanitec则更有包容性，将低于15%的变更失败率视为最佳表现。然而，这一趋势是明确的。超过3/4的组织可以将错误代码的比例限制在15%或以下。在16%或更多的部署中出现故障的团队需要紧急改进，因为大多数的开发组织已经远远领先。请注意，高的变更失败率会产生痛苦的连锁反应。发布到生产后的每一次干预都是无效的行动，会使其他任务陷入瓶颈，不能为客户推进价值。
如何改进
所有的报告都一致表明，软件开发的最高绩效不是一个理论上的雄心，而是一个实践上的现实。高绩效的团队存在于各个行业和地区，并为各自领域的竞争对手设定了标准。那些指标显示绩效中等或较低的开发组织需要迅速地进行实质性的调整，以追赶绩效领先者。
DevOps是一套动态的工具和实践。不同的组织制定了不同的安排来实施DevOps和改造软件交付。因此，不存在任何 "银弹"，也没有任何单一的技术可以让软件开发团队将自己提升为绩效最高的群体。
相反，经审查的研究建议采用广泛的视角和方法来全面解决DevOps的绩效问题。所有建议的共同点是真诚地强调在团队中实现更好的沟通、知识转移和以客户为中心，以此作为提高绩效的基础。本评论强调了Container Solutions的工程专家根据其改造深度/作用认为最相关的一些建议。
平衡认知负荷
认知负荷指的是每个团队成员（和整个团队一样）只能承受有限范围的任务复杂性，以获得最佳绩效。任何超过团队最佳认知负荷的东西都会变成一种分心。它使团队无法专注于他们的关键职责，也无法有效地利用他们的能力。这个概念的优势在于其在个人层面和团队层面的直观的双重适应性。工程经理可能会问自己，"我的团队成员的能力是否得到了最有效的利用？"
表现一般的团队通常会发现自己在毫无意义的任务中打转，他们需要执行这些任务来完成他们的预期工作。伟大的团队以最佳的认知负荷工作。内部开发者平台有助于实现这一点，因为它们抽象了操作任务并实现了开发者的自我服务。有效的内部开发者平台允许团队在限制抽象和过度认知负荷之间取得适当的平衡。那些努力在理想的认知负荷下工作的软件开发团队已经准备好获得最佳的绩效。
对术语的思考
强烈建议将实践和术语区分开来。虽然许多组织确实实施了（或计划实施）DevOps团队，但成功并不伴随着这个名称。DevOps的概念通过实施招致变化和适应。在复杂的环境中，关键是责任的明确沟通。一个组织可能会选择使用更令人兴奋的 "新 "团队名称或听起来很熟悉的词汇。在任何情况下，重要的是对团队内部和团队之间的任务和责任有一个明确和共同的理解。含糊不清和缺乏透明度会造成组织上的摩擦，阻碍绩效。
改进文件
很容易理解为什么这是一个让开发者和工程师爱恨交加的话题。优秀的文档是优秀软件交付的一个相当无形的结果。因此，这项服务经常被忽视。然而，谷歌提出了令人信服的证据，即改进的文档与改进的性能相关。它也增加了实施新实践的成功概率，如网站可靠性工程（SRE）、可靠性目标或安全实践。
三个问题有助于自我评估当前的文档质量。
- 它是否有助于完成他们的目标？
- 它是否准确和充分？
- 在需要的时候，它是否可以被找到/获取？
我们建议那些希望提高文档质量的团队，将文档作为一种持续的实践融入到他们的软件交付过程中，并以保持文档内容的相关性和可靠性为荣。
发展产品心态
软件开发人员必须专注于客户的需求，以建立对终端用户来说既有用又愉悦的产品。同时，软件开发人员本身就是开发平台的客户。因此，用产品思维来构建云原生的开发者平台是至关重要的。
产品思维指的是一套用于识别、理解和优先处理已知客户群所面临的问题的流程，然后系统地构建和验证有望大幅改善客户状况的解决方案。平台团队必须能接受开发者的需求。产品思维是一种对技术的服务方式，它不关心闪亮的新技术，而是专注于提高其客户（即开发团队）的能力，使其更有效地工作，更快地交付更好的软件的解决方案。
引入SRE实践
网站可靠性工程是一个由谷歌提出的著名概念，并很快被业界采用，以扩大其焦点。拥有成熟产品的组织面临着双重挑战。一方面，客户要求不断改进产品，提供更有吸引力的体验和功能。另一方面，不断变化的应用程序需要在一个前所未有的规模上可靠地运行。
这两个方面都汇聚在客户对产品的整体体验中。SRE设计原则直接促进了软件交付性能指标。以用户为中心的突发学习和心理安全的文化，在无责的事后检验等实践中得到体现，与顶级软件开发团队的成长型文化无缝对接。一个没有精心维护的应用设计迟早会适得其反，恶化软件交付性能和客户体验。反过来说，这意味着SRE为软件开发团队铺平了通往顶级性能的道路。
结论-投资于人和平台
三份报告的软件交付性能分析结果趋于一致，这并不令人惊讶。毕竟，分析的数据来自于代表全球软件开发社区的同一组组织和个人。软件开发人员使用相同的技术组合，接触相同的思想领袖，并通过社交媒体保持良好联系。他们中的许多人已经与不同形式和规模的内部开发人员平台合作。全球DevOps社区通过会议演讲、博客文章、教程和其他类型的知识传递，不断进行交流。
通过知识交流来分享经验和向同事学习，表明了一种可以让人茁壮成长的文化。生成性工作文化的其他重要方面包括在心理安全的条件下公开合作的能力，以及允许开发人员尽其所能地工作。强大的组织对人员和平台进行投资，使他们能够建立起一种顶级的文化。
