2025 年 InfoQ 趋势报告：云计算和 DevOps 篇

作者 | Steef-Jan Wiggers, Shweta Vohra 等

译者 | 张卫滨

策划 | 丁晓昀

InfoQ 趋势报告为 InfoQ 读者提供了一个简洁且有见解性的概览，我们认为架构师和技术领导者应该优先考虑这些主题。除了这份报告和更新后的 DevOps 和云 InfoQ 趋势图之外，还有一个 配套的播客，其中包括几位编辑和 InfoQ 的朋友们讨论这些趋势。

年度趋势报告的一个重要部分是趋势图，它显示了哪些趋势和主题进入了创新者类别，哪些被提升到了早期采用者和早期主流类别。这些类别基于 Geoffrey Moore 的 “Crossing the Chasm” 一书。在 InfoQ，我们主要关注尚未跨越鸿沟的类别。以下是今年的图表：

自 InfoQ 团队 18 个月前讨论趋势报告以来（见下面的 2023 年趋势图），已经发生了一些重大的创新和发展。

本文主要展示了不同技术采用阶段的趋势图，并提供了去年发布趋势报告以来新增或更新的个别技术的详细信息。我们还讨论了哪些技术和趋势在采用图中得到了提升。

以下是自去年报告发布以来一些值得关注的变化：

创新者

在我们的采用图中，第一个类别是创新者，在这里我们会看到一些变化，这些变化主要是由高级 AI 自动化主导的。下面详细讨论了这些变化。

云工程中的 AI Agent

今年看到显著发展的一个领域是 AI 工具从简单的聊天机器人演变为复杂的、面向行动的 AI Agent。这些 Agent 旨在执行复杂的任务并与云资源进行交互，这超越了对话辅助，真正增强了工程团队。这一转变标志着迈向企业级就绪 AI 的重要进步，当然这仍然需要人类监督和强有力的治理。

Steef-Jan Wiggers 和 Matt Saunders 在今年的播客中讨论了 AI Agent：

Steef-Jan Wiggers

我认为，AI 的注入主要是在许多云服务中，我不确定它们总是会有帮助，但你肯定看到了 AI 的增长，从第一波引入到现在的 Agent 化，你会看到 Agent 出现在了一些云服务中。

Matt Saunders

我们现在看到在这个领域出现了许多工具，它们不仅仅是聊天机器人……现在，我们看到了像你提到的像 Pulumi 这样的工具，它推出了一个名为 Neo 的东西，本质上是云工程的 Agent。

可实用的、早期的治理自动化

创新者还在可实用的层面上引入 AI，以执行治理和简化内部流程，本质上这实现架构师和审查员角色的自动化，以减少摩擦和认知负荷。

我们的小组成员在播客中讨论了在实用层面上引入 AI 以执行治理。

Shweta Vohra

例如，如果我想为我的工程师强制执行一个清单，我现在可以将其自动化。以前，这涉及到向每个人进行解释……但现在我有机会将其包含在我的流水线中，引入一些 AI，并看看它们是否可以继续。

模型协议上下文（Model Context Protocol，MCP）

Anthropic 在 2024 年 11 月引入的 MCP 是一个开放性的标准，旨在帮助前沿的大型语言模型产生更好、相关度更高的回应。它提供了一个标准化的协议，用来在外部工具、系统和数据源与大型语言模型之间集成和共享数据，它有效地消除了分散和定制集成的需求。像 OpenAI、微软和谷歌这样的主要参与者已经宣布计划将对 MCP 的支持集成到他们的产品中。

小组成员讨论了 MCP 在云和 DevOps 中将扮演的角色。

Matt Saunders

我预计在未来一年左右会有一场 MCP 启示录。我们所在的地方，每个人都在采用 MCP，标准正在逐渐稳定下来，我们正在解决如何为 MCP 服务器提供细粒度访问的所有问题。我看到，凭借我们的 DevOps 和云知识，通过自动化流程和使用基础设施即代码，正在成为解决这个问题的重要贡献者，这样我们就可以以正确的方式让 AI 访问相关的事物。我认为我们有很多 DevOps 经验可以在这里使用。

早期采用者

在早期采用者类别中，我们想强调的是平台工程团队、跨云 / 云原生混合方法和开发者体验框架。

平台工程成熟度

随着平台工程概念的发展，组织正在超越简单的工具聚合，而是在构建内部的开发平台（IDP），将平台本身视为具有可衡量结果的产品。然而，真正具有连贯性的“平台即产品（platform as a product）”实现很少；它的成功取决于价值流思维、清晰的团队界限和减少工具碎片化。

Shweta Vohra:

我还没有看到一个成功的平台即产品。我知道，许多人支持构建的是一个完全成型的产品，那我们将其构建为平台即产品吧。原因在于，我所看到的现实情况是所有的事情仍然被孤立地构建着，这导致了工具碎片化。当然，不同的团队拥有不同的工具集，并相互独立地进行创建，但当他们这样做的时候，粘合剂总是一个问题。如果你只是将拼图块一个接一个地堆叠在一起，而没有一个合适的固定装置的话，那么没有一个拼图可以正确地固定。

在平台工程实践中，我看到了它的采用和成熟度的提升，每个人都在谈论开发者体验。至于采取一步还是多步，这取决于公司的文化，许多团队都在采用它。平台工程绝对是目前的一个时髦词汇。有些地方确实在开展相关的工作，通过引入我们需要的关注点，使管理变得更可控，或者在需要隔离的地方提供粘合剂，我们为此又增加了一点粘合剂。

跨云 / 云原生混合方式

早期采用者不仅仅使用多个云，他们正在拥抱一个由合规性和主权等外部约束驱动的策略性混合云和多云方案。他们的目标不仅仅是采用云，还要确保业务连续性，并遵守不同地理区域的法律。

在数字主权下，云的生态正在扩大。除了“三大”厂商之外，区域提供商正在出现；Kubernetes 成为事实上的基础，混合 / 多云是针对延迟、合规性和灾难恢复的默认设置。

Steef-Jan Wiggers

在 QCon 伦敦，我看到了关于零售混合云的演讲。比如，你不想在线连接仓库系统，因为你想要随时挑选订单。从这个角度来看，当涉及到物联网或边缘时，将看到在本地运行的东西，它们也会在云中运行。你仍然有设备积累遥测数据，并将其推向数据平台上。

过去，当云计算刚刚出现的时候，我的想法是，“是的，我们正朝着云计算的方向发展。”但这从来没有实现过，因为在我的日常工作中，80% 都是混合性的，当我处理一个完全的 SaaS 解决方案来交换数据时，可能只有 10% 或 20%。当然，CRM、Salesforce，还有另一个使用平台服务的 SaaS 云。是的，它们完全是在云上，我想说，你在保险公司做一个本地解决方案，就像我所做的那样。但大多数情况下，它都是与本地系统的混合连接。

当你去工厂时，你会收到采购或生产订单，这些订单会被送到工厂，他们基本上都是使用一台没有联网的机器。因此，它被输入、验证，并进入到机器中，机器进行优先级排序，完成工作，然后提供反馈。假设要重新打印墨水标签或其他东西，我甚至会使用很多墨水，然后向 EAP 报告。这是一个完全混合的解决方案，并将继续如此，因为机器不会进入云端。你仍然需要为它提供特定的订单，然后它可以根据你在内部的工作来确定优先级，然后它才会去实现。但是，混合云仍然存在。是的，它一点也没有消失。例如，当需要低延迟时，那么就完全是企业自建的环境，根本就没有使用云。

Shweta Vohra

是的，我认为混合云是一个客观存在的现实。Steef，你说得对。我接触了许多为 IBM、Accenture 和其他公司工作的混合云客户，这种方法使许多其他公司受益。我仍然注意到我们有大型机，它比他们的任何云产品都要强大得多。混合云已经成为现实。我看到人们在使用多个云……现在没什么大惊小怪的。我听说过，有人在问是应该锁定供应商还是使用多云。从趋势上看，人们应该选择一个云提供商作为基础，然后从其他云提供商那里补充各种服务。

例如，如果我要使用 AWS，那么我还将使用 Gemini 或谷歌的其他服务，甚至可能需要的其他服务。在多云方面，至少在我的经验中，我没有看到那些文章或趋势再次出现，质疑我们是否应该继续下去。在策略方面，我注意到，与其他尝试全云计算的人相比，有一件事很有效，那就是如果你关注你的主要工作负载，它们就像 80/20 规则一样。选择出那些具有 80% 影响力的 20%。我认为领导者可以试着专注于这些事情。这些都是我注意到的。

开发者体验框架（DevEx）

对衡量和提高开发人员效率的工具的大量资金投入表明，量化开发人员体验的框架（DevEx）属于早期采用者阶段。它们被视为将工程工作直接与业务价值联系起来的关键创新。

Daniel Bryant 和 Matt Saunders 的讨论提到了 DX 被 Atlassian 以十亿美元收购的重大新闻。

Matt Saunders

我们都知道，编写的代码行数并不是确定开发人员是否高效的好方法，也不应该将其用于那些衡量开发人员生产力的刻板方法中。但这些重大收购的意图表明，我们将在未来看到很多这样的事情。我不知道这是不是 AI 游戏，现在为时尚早。我在 Atlassian 生态系统中工作，但我也只收到了一天的通知。当这些元素结合在一起时，你可以设想与 wiki 和工单系统的深度集成，以了解人们实际在做什么。看看我们会得到什么产品和附加组件，这将是非常有趣的。

早期主流

我们将以下主题转移到了早期主流类别，因为这些技术已经变得更加成熟，并被各种组织的软件开发团队广泛采用。

• 专注于开发者体验

• 服务网格和 eBPF

• 持续测试

晚期主流

在我们采用曲线的最后一个类别，即晚期主流类别，也出现了一些新成员，因为这些技术现在已经被团队完全采用，并成为他们核心架构模式的一部分。

• FinOps

• 企业级 DevOps 工具链

• 可观测性

结论

FinOps、可观测性和企业 DevOps 工具链的成熟，并进入晚期主流阶段，标志着云和 DevOps 生态系统的一个重要拐点。基础现在是稳固的：团队已经在云原生基础设施上进行了标准化，将自动化作为默认选项，并规范化了持续交付的实践。

然而，正是这种成熟暴露了一系列新的挑战。跨组织的工具和责任的碎片化导致了认知超载和收益递减。许多领导者正在发现，下一波进步将不是来自采用更多的工具，而是来自整合和管理已经就绪的工具。

与此同时，人工智能 Agent 和模型上下文协议（MCP）等标准的出现标志着一种新的运维范式的开始，在这种范式中，自动化变得越来越自主，但永远不能完全独立于人类的判断。将人工智能驱动的执行与明确的护栏和平台治理相结合，这决定了这些技术是增强还是破坏生产力。

与此同时，数字主权和可持续性的问题继续将基础设施决策拉回混合云和多云的现实。这些制约因素迫使人们重新重视弹性、成本优化和数据控制，从而强化了 FinOps 和平台工程作为战略学科而非战术学科的重要性。

简而言之，DevOps 运动正在进入下一个阶段，这不是颠覆性的方式，而是深思熟虑的整合。这个新阶段的赢家将是那些将平台工程、人工智能自动化和以人为中心的治理整合成一个有凝聚力的价值流，将效率转化为流程，将复杂性转化为清晰性的人。

InfoQ Cloud and DevOps Trends Report - 2025 (https://www.infoq.com/articles/cloud-devops-trends-2025/)

声明：本文由 InfoQ 翻译，未经许可禁止转载。