為什麼 MCP 是人工智慧和基礎架構之間缺失的連結

我親身經歷了網路、虛擬化、雲端運算和人工智慧/機器學習的發展歷程。但我從未像現在這樣對正在發生的一切充滿熱情。

身為儲存架構設計師和 IT 維運負責人，我的職業生涯大部分時間都圍繞著周密的規劃、精心安排的變更窗口以及大量的手冊工作。複雜的全球 IT 環境承載著多年的營運歷史、累積的技術債以及無數「以後再清理」的決策。

Agentic AI 具有巨大的潛力，但一直存在著一個問題：AI 無法管理它不了解的基礎架構。

這時Model Context Protocol （MCP）就派上用場了。

幾個月前還只是設想的東西，現在已成為我們在 NetApp IT 部門積極使用的工具。MCP 已成為我們 AI 輔助運作的基礎，為 AI 代理程式提供所需的基礎架構背景，以便分析問題、查詢ONTAP環境、找出根本原因，並以過去無法實現的方式加速疑難排解。

最初對未來的願景，已經迅速成為我們今天運作方式的一部分。

MCP 解決的 AI 問題

人工智慧在推理方面非常出色，但僅靠推理在企業基礎架構中是不夠的。

AI 模型無法自動理解您的 ONTAP 叢集、SnapMirror 關係、儲存設備拓撲、運作標準以及數十年來累積的組態決策。缺乏這些背景資訊，AI 只能靠猜測。它可以搜尋文件、推斷意圖並提出建議，但缺乏與即時基礎架構進行有效互動所需的維運知識。

MCP 改變了方程式。

簡而言之，MCP 為 AI 代理程式提供了一種結構化的方式，以理解 ONTAP 等系統並與之互動。它提供執行有意義工作所需的命令、功能和操作知識，而非依賴假設。

可以將 MCP 視為人工智慧和基礎架構之間的翻譯器。MCP 無需每次收到請求時都強制人工智慧模型搜尋 ONTAP，而是提供了一種可靠的方式，使其能夠了解哪些行動可用、系統如何組態以及如何安全地與之互動。

從「如果……會怎樣？」到「我們正在做」

當我最初開始談論 AI 增強型儲存設備作業時，很多內容聽起來都像是理論性的。

想像一下，在系統停電期間，儲存設備、連網、運算、雲端和應用程式的 AI 代理程式協同工作。每個代理程式都了解自己的領域。各自調查基礎架構的一部分。然後，這些代理程式將各自的發現相互關聯，協助找出根本原因。

這就是我們的願景。現在，我們已經實現了它。

在 NetApp IT 部門內部，我們使用代理工作流程，它可以獲取 ServiceNow 工單、讀取執行摘要、用基礎架構上下文豐富它、透過 MCP 查詢 ONTAP、交叉檢查相關網域，並在幾分鐘內產生 RCA 風格的分析。

例如，有用戶報告無法裝載 NAS 路徑。工單中並未提及是 NFS。也沒有指明是 ONTAP。更沒有具體說明要調查哪個叢集、SVM、Volume 或區域。

代理程式最終還是找到了問題所在。它利用 MCP 分析了 ServiceNow 和 CMDB 資料，檢查了 ONTAP，驗證了 UNIX 端，並確定問題出在 NFS 匯出規則。它甚至在產生高可信度的跨網域分析之前，就確認了主機的其他裝載點都能正常運作。

Agentic AI 實際運作

任何處理過 P1 級事件的人都知道其中的模式。工單提交後，相關人員參加一個協作橋接。各個團隊開始檢查各自的領域。儲存團隊檢查儲存設備。網路團隊檢查交換器。運算團隊檢查主機。應用程式團隊查看日誌。

現在想像一下這樣的情景：

• 一張 ServiceNow 票證會觸發 AI 調查
• 協調代理程式讀取問題聲明
• 儲存設備代理程式使用 ONTAP MCP 來檢查相關的叢集、SVM、Volume、匯出、SnapMirror 關係和效能資料。
• UNIX 或 Windows 代理程式檢查主機端
• 網路代理程式檢查儲存網路和第 2 階層。
• 協調員負責比較不同領域的研究結果
• 系統會發布調查總結，並向工單或作戰室提出後續步驟建議。

如今，我們的大部分操作都是唯讀的，尤其是在生產事故處理工作流程中。唯讀操作風險低，但影響巨大。如果 AI 能夠快速告訴工程師應該從哪裡入手、哪些地方發生了變化、哪些組態錯誤以及最可能導致事故的原因，僅此一項就能顯著縮短回應時間。

AI 幫助我們應對「非人類」問題

另一個主要商機在於技術債。

每個企業都會遇到一些問題，這些問題的困難不在於概念上的複雜。它們規模太大、過於繁瑣或過於分散，以至於人類難以有效率地解決。

例如，我們可以讓 AI 稽核數十個 ONTAP 叢集和數百個節點上的本機帳戶。這並非簡單的電子表格操作。上次登入資訊可能儲存在安全性日誌中，而不是直接儲存在使用者帳戶中。人工需要收集匯出資料、合併資料、審查日誌、比較時間戳，並手動產生一份有用的報告。

借助 ONTAP MCP，我們可以用自然語言提問，並在幾分鐘內獲得整個機群的分析結果。過去需要花費數小時進行手動收集、試算表處理和日誌審查的任務，現在只需一個簡單的提示即可完成。

同樣的道理也適用於老化的快照、滯留的 SnapMirror 目的地 Volume、不一致的組態、缺少的保護關係、生命週期規劃和容量維護。

這類問題往往多年無法解決，因為手動處理太過繁瑣。而基於 MCP 的 AI 技術為我們提供了一種解決並持續維護這些問題的方法。

如果自動化流程的缺陷導致滯留的目的地 Volume，那麼一次性的清理並非解決之道。正確的做法應該是建立一個代理工作流程，定期檢查這種情況，及時報告，並最終透過已批准的控制措施來協助修復問題。

我們正在從手動清理轉向持續維護。

自然語言改變了誰能夠實現自動化

自動化不再局限於撰寫程式碼的人。

在這個專案初期，我為團隊搭建了一個演示程序，我開玩笑地稱之為「Storage Hotness」。突破點在於透過 MCP 將模型連接到 ONTAP。我將 AI 代理程式連接到 ONTAP 模擬器，然後開始輸入純英文請求：

• 建立 Volume
• 調整 Volume 大小
• 建立 SnapMirror 關係
• 告訴我發生了什麼變化

我差不多十年沒直接操作 ONTAP 了，卻能用自然語言管理儲存設備。那一刻讓團隊看到了無限的可能性。

我們的角色正在演變。工程師不會消失，但工作內容正在改變。我們正在成為 AI 輔助操作的協調者、審查者和品質控制者。學會使用這些工具的人將會倍增自身的影響力。而那些仍然固守手動工作流程的人將難以跟上時代的腳步。

為什麼 NetApp IT 是證明這一點的最佳場所

NetApp IT 部門處於獨特的地位，因為我們使用的技術與客戶使用的技術相同。

我們在真實的全球企業環境中執行 ONTAP、StorageGRID、E 系列、Amazon FSx for ONTAP、Cloud Volumes ONTAP、Data Infrastructure Insights及其他 NetApp 技術。

我們並非僅在實驗室環境中探索人工智慧在儲存設備的應用。我們將其應用於真實的基礎架構、真實的事故、真實的技術債和真實的維運壓力。

由於我們在企業規模上運營這些技術，我們親眼目睹了 MCP 如何加速疑難排解、發現閒置容量、識別組態漂移或揭示多年累積的技術債。

當我們看到代理程式在幾分鐘內產生有用的 RCA 式分析時，我們就明白這會如何改變 IT 團隊應對停電的方式。

當某些事情行不通時，我們也能從中學習。

您可以與之對話的儲存設備

我們距離基礎架構由意圖管理的未來，比許多人意識到的要近得多。

高層會問：「我們有多少容量？」

工程師會問：「哪些生產 Volume 缺少保護？」

營運團隊會問：「在此次事件發生之前，發生了哪些變化？」

儲存團隊會問：「我們的閒置容量在哪裡？」

AI 代理程式會收集上下文資訊、查詢環境、分析結果並提出行動建議。這並非取代工程師的判斷，而是對其進行增強。

未來並非人工智慧取代儲存設備工程師。而是儲存設備工程師指揮人工智慧代理程式集群，這些代理程式能夠以人類手動永遠無法企及的規模進行檢查、分析、關聯並最終修復問題。

這是我職涯中第一次見證資料中心的維運階層被重寫。MCP 是連接 AI 推理與實際基礎架構行動的橋樑。沒有它，AI 只能是輔助工具。有了它，AI 將成為運維能力的倍增器。

這一次，不再是紙上談兵。我們已經在實踐了。