为什么 MCP 是人工智能和基础设施之间缺失的关键环节

我经历过互联网、虚拟化、云和 AI/ML 的演变。但我从未像现在这样对正在发生的事情感到如此充满活力。

精心的规划、深思熟虑的变更窗口和大量的手动工作，定义了我作为存储架构师和 IT 运营主管的大部分职业生涯。复杂的全球 IT 环境承载着多年的运营历史、累积的技术债务，以及无数"我们稍后再处理"的决策。

Agentic AI 具有巨大的潜力，但一直存在一个问题：AI 无法管理它无法理解的基础设施。

这就是Model Context Protocol (MCP)的用武之地。

几个月前还只是愿景的东西，如今已成为我们在 NetApp IT 部门积极使用的工具。MCP 已成为我们 AI 辅助运营的基础，为 AI 代理提供所需的基础架构上下文，使其能够分析问题、查询ONTAP环境、找出根本原因，并以前所未有的方式加速故障排除。

最初作为未来愿景的东西很快就成为我们今天运营方式的一部分。

MCP 解决的人工智能问题

人工智能非常擅长推理，但在企业基础设施中，仅靠推理是不够的。

AI 模型不会自动了解您的 ONTAP 集群、SnapMirror关系、存储拓扑、操作标准或数十年积累的配置决策。如果没有这些背景信息，AI 将不得不进行猜测。它可以搜索文档、推断意图并提出建议，但缺乏与实时基础架构进行可靠交互所需的操作知识。

MCP 改变了这一局面。

简而言之，MCP 为 AI 代理提供了一种结构化的方式来理解 ONTAP 等系统并与之交互。它提供了执行有意义的工作所必需的命令、功能和操作知识，而无需依赖假设。

将 MCP 视为 AI 与基础设施之间的转换器。MCP 无需在每次收到请求时强制 AI 模型研究 ONTAP，而是为其提供一种可靠的方法，以了解哪些操作可用、系统如何配置以及如何安全地与其交互。

从"如果怎样？"到"我们正在做"

当我第一次谈论 AI 增强的存储操作时，其中大部分听起来都是理论上的。

想象一下，用于存储、网络、计算、云和应用程序的 AI 代理在中断期间协同工作。每个代理都了解自己的领域。每个代理都会调查其基础架构的相应部分。然后，这些代理将各自的发现相互关联，并帮助确定根本原因。

这就是愿景。现在我们已经实现了它。

在 NetApp IT 内部，我们使用代理工作流，可以获取 ServiceNow 工单、读取描述、通过基础设施上下文丰富描述、通过 MCP 查询 ONTAP、交叉核对相关域，并在几分钟内生成 RCA 风格的分析报告。

在一个示例中，用户报告他们无法挂载 NAS 路径。工单没有说明是 NFS。它没有标识 ONTAP。它没有指定要调查哪个集群、SVM、卷或区域。

代理仍然找到了解决方案。它使用 MCP 分析了 ServiceNow 和 CMDB 数据，检查了 ONTAP，验证了 UNIX 端，并确定问题是 NFS 导出规则。它甚至在生成高置信度跨域分析之前，确认了来自该主机的其他挂载均正常运行。

Agentic AI 的实际应用

任何处理过 P1 事件的人都知道这种模式。一张工单进来了。人们加入了一个桥接会议。各团队开始检查自己负责的领域。存储团队查看存储。网络团队查看交换机。计算团队查看主机。应用程序团队查看日志。

现在想象一下：

• ServiceNow 工单触发人工智能调查
• 协调员代理读取问题陈述
• 存储代理使用 ONTAP MCP 检查相关集群、SVM、卷、导出、SnapMirror 关系和性能数据
• UNIX 或 Windows 代理检查主机端
• 网络代理检查存储架构和第 2 层
• 协调员比较跨领域的调查结果
• 系统会发布调查摘要，并建议将后续步骤反馈至工单或作战室

如今，我们所做的大部分工作都是只读的，尤其是在生产事件工作流程中。只读风险较低，但影响较大。如果 AI 可以快速告诉工程师在哪里查找、更改了什么、配置错误是什么，以及最有可能导致事件的原因，那么仅凭这一点就可以改变响应时间。

AI 帮助我们解决"不人道"的问题

另一个主要机会是技术债务。

每个企业都面临一些问题，这些问题并非因为概念上的复杂性而难以解决。它们之所以困难，是因为规模太大、过于繁琐，或者过于分散，人类无法高效地解决。

例如，我们可以要求 AI 审计数十个 ONTAP 集群和数百个节点的本地帐户。这不是一项简单的电子表格操作。上次登录信息可能存在于安全日志中，而不是直接存在于用户帐户中。人工需要收集导出内容、合并数据、查看日志、比较时间戳并手动构建有用的报告。

使用 ONTAP MCP，我们可以用自然语言提问，并在几分钟内获得整个集群的分析结果。原本需要数小时手动收集、电子表格处理和日志审查的任务，现在只需一个简单的提示即可完成。

同样的想法也适用于老化的快照、孤立的 SnapMirror 目标卷、不一致的配置、缺失的保护关系、生命周期规划和容量清理。

这些问题可能多年得不到解决，因为手动追踪它们的代价太高。支持 MCP 的 AI 为我们提供了一种修复这些问题并持续保持修复状态的方法。

如果自动化缺口留下滞留的目标卷，则答案不应是一次性清理。答案应该是一个代理工作流，定期检查该情况、报告该情况，并最终通过已批准的控制措施帮助修复该情况。

我们正在从手动清理转向持续维护。

自然语言改变了谁能够实现自动化

自动化不再局限于编写代码的人。

在这次旅程的早些时候，我为我的团队制作了一个演示，我开玩笑地称之为"Storage Hotness"。突破在于通过 MCP 将模型连接到 ONTAP。我将 AI 代理连接到 ONTAP 模拟器，并开始输入简单的英语请求：

• 创建卷
• 调整卷的大小
• 建立 SnapMirror 关系
• 告诉我发生了什么变化

近十年来，我几乎没有直接操作过 ONTAP，但我却在通过自然语言管理存储。那一刻帮助团队看到了什么是可能的。

我们的角色在不断变化。工程师不会离开，但工作正在发生变化。我们正在成为 AI 辅助操作的管理者、审核者和质量控制者。学会使用这些工具的人将会成倍扩大其影响力。仍被手动工作流程所束缚的人将难以跟上。

为什么 NetApp IT 是证明这一点的合适场所

NetApp IT 处于独特的位置，因为我们使用与客户相同的技术。

我们在真正的全球企业环境中运行 ONTAP、StorageGRID、E-Series、Amazon FSx for ONTAP、Cloud Volumes ONTAP、Data Infrastructure Insights 以及其他 NetApp 技术。

我们不是在仅限实验室的场景中探索用于存储的人工智能。我们正在将其应用于实际的基础设施、实际的事件、实际的技术债务和实际的运营压力。

由于我们在企业规模上运营这些技术，因此我们亲眼目睹了 MCP 如何加速故障排除、发现搁置的容量、识别配置漂移或解决多年积累的技术债务。

当我们看到代理在几分钟内生成有用的 RCA 风格分析时，我们了解这可以如何改变 IT 团队应对服务中断的方式。

当某些事情不起作用时，我们也会从中吸取教训。

可与您对话的存储

我们比许多人意识到的更接近这样一个未来：基础设施由意图来管理。

高管们会问："我们有多少容量？"

工程师会问："哪些生产卷缺少保护？"

运营团队会问："在这次事件之前发生了什么变化？"

存储团队会问："我们的闲置容量在哪里？"

人工智能代理将收集上下文、查询环境、分析结果并提出行动建议。这不会取代工程判断，而是对其进行增强。

未来不是 AI 取代存储工程师。未来，存储工程师将指挥一批 AI 代理，这些代理能够以人类手动操作无法企及的规模执行检查、分析、关联和修复。

这是我职业生涯中第一次重写数据中心的运营层。MCP 是连接 AI 推理与实际基础设施行动的一座桥梁。没有它，AI 仍然是一个助手。有了它，AI 成为运营力量倍增器。

这一次，这不是理论上的。我们已经在这样做了。