我们该如何看待 DevOps 的未来？

本文要点：

• 从项目到产品的转变仍在继续，并着眼于长期的可维护性和适应性。

• 向小型、半自治团队的转变仍在继续，集成和聚合来自不同工具的信息的平台市场亦是如此。

• 数据科学和分析在开发生命周期中的重要性与日俱增。

• 像价值流映射这样关注整个开发生命周期的概念变得越来越重要，提供支持的预构建工具也变得越来越普遍。

• 越来越多的专业供应商和 SI 合作伙伴提供工具或服务帮助满足 DevOps 需求。

DevOps 运动对 IT 生态系统的冲击与影响与日俱增。毫无疑问，DevOps 运动正在走向成熟，它的影响和呼声可以与云计算、敏捷等其他运动相媲美。DevOps 运动有一个有趣的特点，它产生于 IT 部门的一个愿望，即优化和协调不同团队的活动；但是，它成熟了，它现在还考虑了最终用户的需求，并提供了在规模较大时组织如何运作才能保证既灵活又高效的整体观点。

业务负责人可能会抱怨 IT 工作者不理解他们所处的潜在商业环境；从历史上看，IT 部门一直被视为企业的成本中心，而不是价值中心。这样做的最终结果是，IT 很难证明那些会增加成本的基础设施和流程改进是合理的，除非它们与新的业务活动密切相关。但 IT 正日益成为企业运营的核心。与之前的数字化基础设施相比，如果做得好，软件的灵活性可以让组织更快地适应变化，从而使高效的 IT 团队成为最大的价值推动者。

从项目到产品

近几十年来，数字转型已经成为一个特别流行的词，但企业必须认识到，数字化转型不是一次性的活动。Mik Kersten在《从项目到产品》一书中特别指出，将 IT 改进视为一次性项目是一种谬论。深入研究技术革命的历史，目睹当今最先进的生产流程，Kersten 认识到，转变为以产品为中心的思维模式，对企业而言是一种更为有益的 IT 规划方式。

将内部 IT 方案作为产品来处理意味着什么？一方面是认识到 IT 系统需要担负起长期的维护责任，而不是简单地创建一个东西并移交给一个不相关的团队。另一个方面是重新思考我们资助项目的方式。年度预算周期针对相对稳定的系统进行优化，可以提前一年进行更改。各个团队都在争取一部分预算，并确保用完分得的款项，以免下一年得到的预算更少。提前申请资金往往是为了推动成本高昂的大型项目，而后续运营的预算往往没有考虑在内。这就导致那些复杂 IT 系统的运维团队不是构建这些系统的团队，那些系统太复杂了，运维团队常常不能满足最终用户的需求。敏捷性需要扩展到业务的每个方面，从团队的结构到如何资助各项工作，再到组织如何以及何时决定进行改进。

产品思维模式的一个例子是让负责 CPQ（配置-定价-报价）系统的团队负责随着时间的推移构建和维护该系统——“谁构建，谁负责”。这种思维模式的力量在于保证所构建系统的稳定性和灵活性。当一个团队需要长期负责构建和维护产品，并获得关于产品实际使用情况的反馈时，这将极大地增加该产品为组织带来持久价值的机会。关于系统生产使用情况的反馈是持续改进的基本输入。正是由于这个原因，在 DevOps 社区中，软件开发的装配线主题已经被软件开发的循环或无限循环主题所取代。该循环表明，来自最终用户的持续反馈与原始规范同样重要。

从本质上来说，产品公司和产品团队比那些做完一个就开始下一个的团队更稳定。项目团队在建筑和土木工程领域非常有效，这些领域的基础设施一旦建成就很少需要改变。但是，软件的灵活度完全不同。我们可以在终端用户不知情的情况下更换平台或重构；它的设计或功能可以在发布给用户之前的最后一分钟进行更改；不同的版本可以提供给不同的用户来寻求反馈。这种灵活性性就是创建软件产品的知识必须尽可能保留在团队中的原因。有一个“不确定性圆锥”，在开始构建某个东西的时候，是我们对这个东西了解得最少的时候。随着开发的进行和系统的使用，我们必然会了解到一些即使是最聪明、最深思熟虑的团队也无法预测的东西。

团队拓扑

围绕团队认知负荷所做的研究，以及以最有利于沟通和信任的方式构建团队的重要性，也与“从项目到产品”这一主题相关。独立工作的小型团队比大型团队或具有许多依赖关系的团队更有效，这种说法是有数学和实证基础的。亚马逊的双披萨团队规模并不是为了简化他们的餐饮需求。这是一个明智的结构，可以最大限度地发挥团队合作的力量，同时最小化持续协调所需的开销。康威定律指出，你的架构将反映你的团队结构。考虑到最佳的团队规模应限制在 5 到 10 人，如果你希望能够在一段时间内保持速度，那么模块化架构是必不可少的。其思想是给予团队特定系统的相对自主权。这就涉及到像持续集成这样的主题，它致力于减少并行化所带来的影响。这些类型的 DevOps 最佳实践始于该领域的研究和实验，然后逐渐发展成为 DevOps 社区的知识，并通过像DevOps研究和评估这样的团队的研究得到证实，逐渐成为专用工具和根深蒂固的工作方式的基础。

我们今天看到的大部分工具的发展包括集成和价值流管理平台，如 Copado、Tasktop、Plutora、Xebialabs、GitLab 和 Cloudbees，它们正努力将来自多个不同系统的信息整合到一个工具中。作为处理企业系统的各种实际情况的一种实用方法，我希望这种集成和聚合趋势能够继续下去。事实上，能够选择自己的工具使团队获益良多。在Matthew Skelton和Manuel Pais合著的《团队拓扑》一书中，他们将标准化称为“整体思维”的一种类型，这种思维方式会妨碍效率最大化。如果你正在努力避免整体思维，但是仍然需要系统和流程的集成视图，那么数据集成是你唯一的选择。

工具演变

LaunchDarkly表明，促进特定 DevOps 实践（在这里是将部署与发布分离开来）的产品是有市场的。这种做法是 A/B 测试和金丝雀部署等活动不可或缺的一部分，而这些活动已被视为降低风险和支持试验的有力方式。我期望支持 DevOps 实践的工具会继续出现，否则我们就需要自己编码了。

虽然这并不是一个新趋势，但可以肯定的是，像 Amazon Web Services（AWS）、Azure 和谷歌云平台（GCP）这样的服务将会继续推出新的服务，相互竞争，并从遗留基础设施那里获得市场份额。在提供的产品种类和控制的市场份额方面，Azure 和 GCP 仍在追赶，但预计它们会紧跟 AWS 的步伐。Kubernetes 即服务等产品有助于降低管理底层基础设施的复杂性。预计其他类型的复杂系统将继续打包进这种立即可用的应用程序里。

数据科学

来自Puppet和谷歌的 DevOps 现状报告为使用数据科学来评估开发实践的有效性设立了标准。希望可以看到更多的工具开始将分析和数据科学集成到它们的产品中。也希望看到更多的团队请求并利用这些功能来促进实验，并验证这些实验的结果。

多年来，营销等业务职能部门一直在使用 A/B 测试并对其有效性进行量化。有大量面向营销的工具已经被高度调优，以提供点击率、采用率、网站停留时间、投资回报等指标。其中，存在时间最长的是谷歌分析，但有大量的工具可供营销人员选择。颇具讽刺意味的是，在诸如 A/B 测试和确保用户采用应用程序等实践方面，IT 团队却成了迟到者。经常是由业务团队跟踪 IT 部门创建的应用程序的采用情况。但是，内部 IT 部门是最有可能做出改进以满足用户需求的部门。

希望可以看到内部开发团队更多地使用监控工具，甚至是嵌入式反馈和用户满意度调查工具。这些实践有助于缩小最终用户和开发团队之间的距离，就像营销团队多年来一直努力缩小公司和客户之间的距离一样。这种反馈非常有效，因为之前每次你想要征求用户的反馈时，都会涉及业务分析人员，导致效率低下。选择性反馈措施也存在样本偏差的问题。

精益和敏捷

DevOps 的目标是“实现敏捷”，确保团队拥有真正敏捷的技术能力，而不仅仅是缩短他们的计划和工作节奏。重要的是，DevOps 也有精益的血统。这意味着需要关注端到端生命周期、流程优化，并考虑如何在消除浪费方面进行改进，而不是仅仅增加能力。有大量的组织和团队仍然只是迈出了这个过程的第一步。对于他们来说，尽管术语和概念在一开始可能让人觉得透不过气来，但他们可以从许多经过良好发展的选项中受益，以满足他们的开发生命周期的需要。我预计，许多软件工具将会在易用性方面进行优化，并继续在可用性和 UI 外观方面进行竞争。

尽管大多数早期的 DevOps 方案都是严格基于脚本和配置文件的，但是，最新产品可以帮助可视化流程和依赖关系，并且可以被组织更广泛的部分轻松理解。特别是当公司试图抓住 CIO、CTO 和其他组织决策者的注意力并争取资金分配时，减少工具实际的 UI 与可视化及营销工作之间的差异变得越来越重要。最漂亮的图形化工具才能把自己卖出去（卖给业务和技术用户）。价值流映射和交付管道是可视化交付流程特别流行而有效的方法，同时还提供了对度量指标和监控的日常访问。

系统集成商

最后，具备这项技能的人员显然无法满足 DevOps 实践的市场和需求。因此，系统集成商将继续帮助团队提升这方面的技术和流程，在某些情况下，甚至帮助管理组织的开发生命周期。DevOps 现状报告的研究表明，职能外包预示着低效，因此，组织在将特定的活动委派给外部承包商时要特别小心，例如测试或部署。除非特别小心，否则职能外包就违背了 DevOps 的精神，DevOps 的核心是统一所有相关利益干系人（从开发人员到运维人员）的目标，共享可见性和技术。

在内部缺乏人才的情况下，咨询合作伙伴是获得帮助的一种极其有效的方式。但这必然会引入组织边界的问题，除非咨询师深入组织内部，与全职员工长期共事。依靠 DevOps 顾问来帮助你采用技术、改进流程、设计指标等等。但是，外包流程中处于关键生产路径上的特定部分（例如测试）要非常谨慎。

将特定应用程序的整个开发过程交给咨询公司可能会更好。但是，要考虑它的长期生命周期，以及你希望公司今后如何维护应用程序。按照从项目到产品的精神，让一个团队构建应用程序，让另一个单独的团队维护应用程序是有风险的。将你在团队中构建的知识视为组织架构的关键组成部分。在上线之后从你的架构中删除大量内容是鲁莽的，同样，在上线之后从你的团队中删除大量知识也是不明智的。

小结

总之，DevOps 运动会继续在 IT 界和业务领域中发展壮大并获得影响力。随着我们的组织数字化程度越来越高，IT 系统的敏捷性对我们公司的生命和健康变得至关重要。DevOps 是一场融合了心理学、社会学、技术管理、自动化、安全以及精益和敏捷等实践的运动，其目的是优化组织在数字世界中蓬勃发展的能力。为这项运动提供支持的咨询、工具、基础设施和培训生态系统也还在发展之中。实际上，DevOps 市场是数字化成果的市场，因此，2020 年及以后预计会持续增长。

作者简介：

Andrew Davis 是 Salesforce DevOps 专家，他热衷于帮助团队交付创新成果、建立信任并提高绩效。目前，他担任 Copado 的产品营销高级总监，帮助人们理解 DevOps 对于扩展 Salesforce 实现的重要性。

原文链接：

What’s Next in DevOps?