DevOps和云是业务成功的催化剂

本文要点

• DevOps已经“跨越了鸿沟”：优秀的实践者占了所有组织的20%，几乎是原来的三倍，这表明任何人都可以做到卓越的DevOps。
• 虽然良好实现的云计算策略可以帮助交付更好的结果（有助于提高速度、稳定性和可用性），但其他因素如领导力、文化、流程和技术实践等也有助于提高绩效。
• 为了充分利用云，我们需要对NIST定义的五个基本特性进行投资：按需自助服务、广泛的网络访问、资源共享、快速伸缩和服务可度量。
• 贯穿软件开发和交付过程的自动化带来了很多好处。
• 表现最好的实践者正在利用构建社区的结构性解决方案来扩展他们的DevOps实践：社区实践和基础解决方案让组织可以逐步成长为DevOps组织，并且可以以组织或产品为中心。

由Nicole Forsgren博士和Dustin Smith博士主导的最新的DevOpss加速状态报告于2019年8月发布。该报告展示了最新的研究成果，展示了对软件开发和组织绩效有贡献的能力和实践。InfoQ就2019年报告的主要发现、最成功的DevOps和云策略以及驱动业务成功的技术采访了Nicole Forsgren博士。

InfoQ：祝贺Forsgren博士发布了最新的DevOps加速状态报告！这是一个巨大的创举，今年的报告绝对令人吃惊。感谢您接受InfoQ的采访。您想和我们的读者分享的要点是什么？

**Dr. Forsgren：**今年我们有许多重要的发现：

• 这个行业在不断进步，每个人都有可能做到最好。我们发现，表现最好的实践者，也就是表现最好的那群人，几乎是原来的三倍。这确实令人兴奋，它证实了许多其他分析师的报告。
• 我们今年还做了一件过去几年都没做过的事，那就是除了绩效之外，还深入研究了生产力。
• 正如我们在前几年所做的，我们调查了有利于绩效提升的文化、过程和技术实践。我们能够重新验证一些发现；例如，云是一个关键的区别。
• 我们看到了一系列确凿的发现，关于变更审批应该如何进行。特别重要的变更审批对绩效有负面影响，而明确的变更审批过程对绩效有正面影响。
• 今年我们还加了一个不错的部分，关于大规模转型。

InfoQ：您提到的一个重要发现是DevOps已经“跨越了鸿沟”。这一里程碑事件是否会给其他公司敲响警钟，更快地跟上这一趋势？对于那些在理解DevOps、云计算和自动化的重要性方面有困难的大公司来说，这可能是一个机会，可以开始探索这些领域。

Dr. Forsgren: 现在不管什么类型的技术，它正好符合你的要求是再好不过了：这是一个安全的举措。这不再是一场赌博，你没有处在前沿。我们现在了解了很多关于技术转型成功的因素。我已经做了六年的DevOps报告了，所以它不是一个疯狂的新奇事物。对于许多组织来说，他们都可以放心地说，“我们绝对要在云上投资”。一些高度监管的组织现在都在云中，我们现在可以安全地将数据放到公有云中。 不仅如此，在很多方面，我们知道它是安全且有保障的——我们知道它更安全，更有保障。对我们而言，这是一个很好的发展方向，我们了解自动化、投资、CI/CD方面的能力和实践，CI应该是什么样的，CD应该是什么样的，我们的流程应该是什么样的，这样才更可能成功。所以现在，从管理人员的角度来看：如果我正在做重大投资决策，我知道我有很大的可能性取得成功。 举个例子：我跟几家银行交流过，他们说“你知道我们几年前被伤过，我不想冲在前面，我想做一个快速的跟随者，我想成为第二波的第一人”。我们已经深入DevOps转型，这是一个安全而明智的举动，甚至那些讨厌风险而非常谨慎的公司也在采用这些方法，并努力追赶——利用我们从其他行业获得的十年经验。

InfoQ：很高兴听到这个消息！我们知道，如果我们在技术、流程和文化方面进行正确的投资，并利用好云，那么就可能实现大规模的DevOps。为什么我们仍然没有在自动化方面投入足够的资金，我们可以做些什么来帮助组织理解他们需要进行的投资，他们如何才能在这方面做得更好？

Dr. Forsgren：开发和交付技术需要投资并执行，目的是为客户交付价值。我有时会说：如果我们想要更好的表现，我们需要投资，也需要执行。如果我是健身房会员，我也需要去健身房，我还需要锻炼。 我经常看到以下两种脱节的情况：

• 首先，从某些高管或领导层的角度来看，我们有时认为，我们可以开一张支票，然后走开，但仍能让它生效。实际上，我们还必须改变我们开发软件的方式，当我们在云中开发和交付软件时，它实际上会极大地改变我们交付价值的方式。
• 第二个脱节是我们如何谈论采用和实现云计算。有时高管们会说：“我们进行了投资，但还没有看到回报。”所以，我问：“你说的云是什么意思？”我们可能会与15家不同的公司讨论云，关于云对他们意味着什么，我们会收到15个不同的答案。因此，我们使用NIST的定义来定义云计算。云是不可互换的，主要的云提供商有明显的不同。但是，即使云提供商之间存在这些差异，你也必须进行架构设计并实现自动化，从而以正确的方式使用和访问云：
  • 按需自助服务：当有人需要提供计算资源时，它需要随需应变并支持完全自助的服务。你必须能够立即快速地配置并访问它，否则你将失去在云上的好处。
  • 广泛的网络访问：你需要能够跨不同的设备、手机、笔记本电脑、平板电脑访问你的网络。
  • 资源共享：然后我们需要能够按使用付费。
  • 快速伸缩：我开玩笑说这是“就像变魔术一样突然变化”——上上下下。
  • 服务可度量：你只需要为你使用的东西付费；大多数公有云处 理都可以这样处理。
• 有一些部分是需要组织付出真正的努力才能解决的——通常是自助服务部分和广泛的网络访问。如果我们不改变访问和使用基础设施的方式，我们就无法得到迁移到云的全部好处。回到我那个类比：我可以付费成为健身房会员，但如果我不去健身房并进行锻炼，我就得不到成为会员的好处。

InfoQ：在2017年接受InfoQ采访时提到，您一直在扩展其他组织领域的研究，比如领导力。在DOES 2017大会上，您介绍了当年的研究，并讨论了变革型领导与仆人型领导的区别。您能给我们介绍一下吗？

Dr. Forsgren：组织有绩效目标，他们试图推动业务结果。所以，我们想要研究一种与结果更一致的领导模式。在我为那年的研究做准备时，我发现很多学术文献和研究表明，变革型领导模式比服务型领导模式更适合驱动绩效。（变革型领导推动业务成果）这一假设之前没有在技术变革这样的背景下被研究过，所以我们对其进行了测试，我们能够找到证据证明变革型领导在技术变革中的深远影响。我们没有继续研究下去，因为每年都有很多东西要研究！ 我们注意到，变革型领导并不要求员工有直接下属，这一点很重要，因为DevOps具有草根文化背景。任何人都可以成为冠军和团队的一员，并帮助激励和领导他们的团队或组织。我们在Accelerate一书中着重介绍了这一点。

InfoQ：关于基层工作的文化，我真的很喜欢您针对组织大规模DevOps转型时的策略所做的分析。您能谈谈这个吗?

Dr. Forsgren：谢谢！那一部分很棒，其灵感来自于我们中的一位顾问Sam Guckenheimer。这个分析是由Dustin主导的，我喜欢他发现的模式。他从对整体模式的广泛观察开始，我们注意到一些常见的模式，比如Big Bang很少被使用（并且在优秀的实践者中使用频率最低）。然后，Dustin和我聊天时说想要了解那些高水平的精英级实践者在使用什么样的扩展策略——也就是说，如果有人想问最好的人在做什么，我们能把模式告诉他们吗？高水平的精英级实践者中间存在四个清晰的模式，这与我在与我合作的企业中所看到的相呼应：

• 社区建设者：46%——侧重于实践社区、草根研究和概念验证（POC）；
• 大学：只有9%——侧重于教育和培训，有卓越中心、培训中心、实践社区；
• 新用户（Emergent）：23%——侧重于草根研究和实践社区；
• 试验者：22%——针对Big Bang和DOJO之外的策略活动较多。

总的来说，我们看到，他们使用的大多数策略都是利用构建社区的结构化解决方案。通过这种方式，他们已经建立了对任何类型的变化都有很强弹性的组织，比如部门重组、产品战略变更等等。当市场条件需要时，公司可以继续调整。(我将在报告中详细介绍每种策略的定义和模式。)

需要指出的是，这些工作仍然需要资源，无论是买午餐或棕色食品袋的钱，还是用时间资源，如20%的时间。

InfoQ：关于成熟度模型的一个问题。我真的很喜欢您对成熟度模型的描述。我完全同意您的看法，我认为它们源于瀑布模型的角度和方法，我们非常习惯这些成熟度模型和路线图，它们可以告诉我们如何以及何时我们会变得更加成熟，这无疑会限制DevOps团队尽快创新的能力。

为什么我们仍然要DevOps成熟度模型，花无数时间定义标准？在大多数情况下，我们最终都没有遵循它们。就像瀑布项目计划一样，它们永远不会得到更新，阻碍了团队探索和加速。

Dr. Forsgren：在某些组织中，有几个原因可以解释那为什么会存在。它们很容易推销，因为那让人舒服，让人安心。然后，领导者们想知道未来两年、三年、五年将会发生什么。如果你给我一个成熟度模型，从中你可以知道你现在的位置，接下来的位置，以及再接下来的位置…这是非常强大的，因为它给我一种安全感，它给我一种安心的感觉，它让我可以长期计划。这会让人觉得那人（给你模型的人）很专业。事实上，它们都是虚构的。它们都是编造的，就像CMMI是编造的一样。我们会有不同程度的投入，一些组织做了很多计划和尝试，但它们都是编造的。 相反，我们应该做的是基于约束的模型，即：

• 这就是我现在的处境。
• 我知道下面这些事情会让我变得更好。

当我们找出25到30件能让我们变得更好的事情时，这个清单可能会让人有点不知所措。缩小范围，优先考虑最大的限制。你可以通过几种不同的方式来识别你的约束条件：

• 你可以使用基于流程的约束模型和价值流映射。在这个方法中，你绘制出价值流，及时描述我们浪费时间的地方，然后确定最大的约束。
• 另一种选择是使用基于能力的约束模型。在这种方法中，列出了对重要结果（通常是速度和稳定性）有贡献的能力。DORA的研究做了这项工作，你可以在免费的DevOps现状报告中找到这些内容，或者在Accelerate一书中找到。然后，你可以借助工具通过算法来确定你的约束（DORA的评估就可以做到这一点），或者你可以询问你的团队，交付软件时最头痛或负担最大的功能是什么。
• 有些团队同时使用这两种方法。

这里的挑战在于，你基本上得告诉一位高管，你只知道明年的路线图。这让人不舒服。不仅如此，这是在说我们只知道一年内会怎样，这意味着我们不是专家。但问题是：我们是专家。因为现在，我们是知道如何诊断真正的问题并继续前进的人。这很强。 我与许多管理人员一起工作，我没有向他们推销成熟度模型，而是教他们如何根据团队的需要定制自己的基于约束的模型，并跟踪进度。

我想说的是，当你谈论单一工具时，成熟度模型很好。你可以测量对工具或其基本安装的了解程度，或者我们可以讨论人们从采用一项技术到成为专家的进展情况。但是，如果你谈论的是像技术转型这样的事情，它太复杂了，有太多的事情在起作用，你要紧密结合组织的约束。

InfoQ：回到2019年DevOps状态报告的结果，该研究证实，吞吐量和稳定性都是可能的，不需要折中。您认为，只要我们实现自动化，不需要折中，就两者都可能实现吗？

Dr. Forsgren：在过去的六年中，我们的分析证实，速度和稳定性是相辅相成的。在这项研究中，我收集了两个速度指标和两个稳定性指标。我们每年都观察到，速度与稳定性是同向变动的。 但我要指出，速度和稳定性在高端实践者那里是同向变动的，不需要折中，它们在低端实践者那里也是同向变动的，不过，他们是在速度上陷入挣扎，在稳定性上也陷入挣扎。 现在回答问题的下一部分，是否必须自动化？不！你的意思是，这很重要，如果你想做得更好，是的，自动化是必要的，但如果你想保持糟糕的速度和稳定性，因为没有折中，自动化就是不需要的。如果我们不投资于自动化，我们就会处处受阻。你的观察很有趣也很聪明。因此，我们确实需要提高自动化程度，而且我确实认为，在软件开发和交付过程中提高自动化程度将帮助我们提高绩效和业务成果。这并不是唯一的原因，有几个因素影响了绩效，还有流程，比如小批量工作，这有助于我们获得更小段的代码，这是一种改进的文化，这是云计算的使用。 自动化有一些优势，比如有良好的自动化测试套件、部署自动化。

自动化的另一个好处是它为你提供了可重复性、可审核性，并最终在安全方面产生了巨大的影响。所以，就质量而言，你获得了下游效应。也让你流程中的反馈循环更快速，所以你的代码会变得更好，因为如果它在我的脑海里还记忆犹新，我得到更快的反馈，我立即可以改进我的代码，而不是三个月后得到反馈，我必须弄清楚我当时在想什么。自动化有很多非常好的好处。

InfoQ：接下来是一个相关问题：为什么组织在自动化投资方面存在困难？我采访了Scrum的创始人Jeff Sutherland，他也给出了同样的反馈。他和大公司合作过，他对自动化也有同样的看法。我们需要雇佣有自动化技能的人吗?

Dr. Forsgren：我们不需要雇佣有自动化技能的人，我认为我们需要雇佣有发展思维的人，他们聪明，想要学习自动化。那些聪明的人，那些能够很好地识别和理解这个过程的人，会找到编码的方法。我不担心人，我担心的是那些不理解将不同东西自动化所带来的价值的组织，相反，他们会坚持当前的方式，不管是变更审批过程还是其他的什么，因为这是一直以来的方式。 我们永远不会失去自动化的机会，特别是当我们的人非常聪明且有创造力的时候。我们发现了自动化的机会，然后就有新的东西冒出来了，总有一些东西等你去发现。

InfoQ：自动化是否有助于提高开发人员的参与度，因为他们需要使用最新的技术？

Dr. Forsgren：我认为提升并具备进行自动化的能力提高了许多人的士气。 有些人有时会担心这可能会威胁到他们的工作，但我认为这通常是一个机会，管理层可以借机澄清他们不会失去工作。

如果有什么不同的话，这意味着他们将做更多令人兴奋的工作，因为有令人兴奋的挑战需要解决。如果你的工作中有一部分是你可以自动化的，那就意味着它是重复的，有一些新的、有创造性的东西还没有被发现我们，那需要你的专业知识来发现。

我曾与一些大型组织合作，他们采用这种方法来帮助改变这种表述方式和思维方式。

InfoQ：我该如何在我自己的组织中利用这份报告来帮助我们填补空白或制定路线图呢？

Dr. Forsgren：我们设计并组织了2019年报告，这样任何人都可以打印一两页，以此作为指导或指南。我在网上看到几家公司打印了一两个（或者几个）页面，然后把它们挂在办公室的墙上，比如云页面。人们也会拿出一两页，把它们做成幻灯片。这就是为什么这个报告是完全开放的，没有任何限制。 比如，如果你想预测SDO性能，就可以这样做。我确实看到了人们在推特上发布的照片。他们打印出来，然后圈出他们当前对于未来六个月的关注焦点。

InfoQ：2019年的报告提供了很多有价值的数据。领导者和执行人员面临的挑战之一是如何将研究和数据应用到我们的路线图和日常工作中。您是否正在考虑开发开源蓝图或指南来帮助组织着手将您的研究应用到他们的团体和组织中？

Dr. Forsgren：在资源方面，DevOps加速状态报告是我们对行业社区的重要综述。我们也在准备同行评议的学术论文，但这些论文不太适合大众消费。我们也有一个执行摘要，正在准备发布。 我们目前正在研究一些蓝图，以帮助组织扩展他们的转型，并根据我们的研究采用云。

InfoQ：您之前提到过您喜欢研究，而且喜欢研究很多东西。您是怎么进入研究领域的？

Dr. Forsgren：我实际上是技术背景。我一开始是一名程序员，做了几年的开发。我也做过几年的系统管理员，做过一点咨询工作。我意识到我的一些问题在类别上看起来非常相似，研究的目的是分类回答问题，这样你就可以用一种概括的方式来回答它们。与此相关的是，我经常会去找我的经理或我正在做的项目的经理，提出解决方案。很多时候，他们会反驳说：“哦，那在这里行不通，因为我们和其他组织不一样。”我意识到，如果我有很好的研究和数据，可能有助于消除我遇到的阻力。这就是我开始考虑做研究的原因。

InfoQ：您能分享一下您的研究方法吗？您是如何阐述假设的？您是否利用过敏捷技术，比如冲刺、演示、快速反馈循环等？

Dr. Forsgren：在Accelerate一书的第二部分中有很多这方面的内容。一旦我开始研究设计，你实际上无法做冲刺。在早期的研究中，我埋头于文献，勾勒出假设，然后弄清楚什么适合于今年的研究报告，什么将超出范围。 在这一年中，我广泛地收集各种想法。为了做到这一点，我把我们过去6年研究的内容以及我想要重新验证的内容记在心里，那就是模型的核心部分，因为它是模型的一部分。

在这一年中，我从多个来源广泛搜索，确定研究设计中应包含什么内容：

• 我观察这个行业的趋势。我和分析师交流，看看他们的雷达上出现了什么。但我必须在这两者之间取得平衡。有一些趋势正在形成冲击，但如果它还不够普遍，我就必须在考虑研究设计时对其进行权衡。举个例子，混沌测试和混沌工程是当前的大趋势，但是它们的应用还不够广泛，所以我还没有把它们包括在DevOps报告类型的研究设计中。
• 我每年都会和一些顾问一起工作。今年这份报告的顾问有来自谷歌的Kelsey Hightower、Adrian Cockroft、Sam Guckenheimer和Gene Kim。
• 我也参加过几次会议，与几家公司、高管和企业级开发人员交流过，也与中小型企业和初创公司交流过，因为我想了解他们在规模扩张方面面临的挑战。我也想看看什么对他们真正有用。
• 我还会关注相关领域的最新研究（包括在期刊和会议上发表的研究），以确保我了解正在发生的事情。

很多，但我很喜欢，这也很重要，可以确保我们赢得这个行业。

InfoQ：我知道您将参加今年的DevOps企业峰会。您能让我们的读者先睹为快吗？

Dr. Forsgren：Dustin Smith博士是今年这份报告的第二作者，我将介绍2019年的报告中我们最喜欢的一些发现。然后，我将与Christina Maslach博士（加州大学伯克利分校）和Andre Martin博士（谷歌）一起在Workplace Engagement Panel上发言。

受访者简介

Nicole Forsgren博士是DevOps研究与评估中心的联合创始人、首席执行官和首席科学家。她最著名的工作是测量技术过程，她是迄今为止最大的DevOps研究的首席研究员。她曾是一名教授、系统管理员和性能工程师。她的研究成果已经在几家同行评审的期刊上发表。Forsgren在亚利桑那大学获得了管理信息系统博士学位，是克莱姆森大学和佛罗里达国际大学的附属研究机构。

原文链接：

DevOps and Cloud as Catalysts for Business Success