作者 | Matt Saunders

譯者 | 劉雅夢

策劃 | 丁曉昀

米其林（Michelin）中國運(yùn)維集團(tuán)寫了一篇關(guān)于 他們?nèi)绾螌?shí)施 AIOps 平臺(tái)的文章。文章詳細(xì)描述了在最終與全球 IT 治理對(duì)齊的過程中克服的失誤和組織阻力，并解釋了企業(yè)如何能夠超越供應(yīng)商的推銷，實(shí)現(xiàn)實(shí)際部署。

米其林中國 IT 運(yùn)維團(tuán)隊(duì)的架構(gòu)師 Matthew Liu 描述了他們的實(shí)施是如何從個(gè)人信念開始的，而不是從執(zhí)行官命令開始的。監(jiān)控、遙測、事件管理和成熟的云托管已經(jīng)到位；然而，盡管進(jìn)行了流程優(yōu)化，事件量和手動(dòng)檢查的數(shù)量仍在增加。這種差異意味著變革的動(dòng)力是直接了當(dāng)?shù)摹獣r(shí)機(jī)就是“現(xiàn)在”。

他們的方法使用了 Dify，這是一個(gè)用于構(gòu)建 AI 應(yīng)用程序的低代碼平臺(tái)，部署在阿里云上，并使用 Anthropic 的模型上下文協(xié)議與其他工具集成。

在尋求正式批準(zhǔn)之前，Liu 先進(jìn)行了工作演示。他構(gòu)建的一個(gè)聊天機(jī)器人幫助數(shù)據(jù)庫管理員進(jìn)行健康檢查和慢查詢分析。另一個(gè)幫助 Kubernetes 管理員處理日常任務(wù)。這些原型使用 MCP 服務(wù)器直接從 Dify 代理內(nèi)部查詢 ServiceNow 工單。Liu 繼續(xù)解釋說，這顯著加快了開發(fā)速度，使團(tuán)隊(duì)能夠在短短幾個(gè)小時(shí)內(nèi)將 ServiceNow 連接到 Dify 并創(chuàng)建工作 AIOps 原型。

早期演示引起了人們的興趣，但也暴露了更深層次的組織挑戰(zhàn)。當(dāng) Liu 試圖量化預(yù)期收益并找到使用 AI 改進(jìn)的關(guān)鍵績效指標(biāo)時(shí)，他遇到了一些阻力。團(tuán)隊(duì)不愿意提供數(shù)字，因?yàn)樗麄儞?dān)心減少努力會(huì)導(dǎo)致人員減少，而且管理層會(huì)在解決方案成熟之前提高平均解決時(shí)間（MTTR）的目標(biāo)。

由于沒有量化的目標(biāo)，Liu 將 Dify 重新定位為一個(gè)低代碼探索平臺(tái)，運(yùn)維團(tuán)隊(duì)可以自己構(gòu)建工作流程，因?yàn)?Dify 不需要專業(yè)的應(yīng)用開發(fā)技能，運(yùn)維團(tuán)隊(duì)可以將他們的經(jīng)驗(yàn)構(gòu)建到提示和工作流程中。從公司的角度來看，這將建立 AIOps 素養(yǎng)，同時(shí)使知識(shí)更明確和更可重用。

IT 管理層認(rèn)為工具探索沒有解決實(shí)際的運(yùn)維問題，但批準(zhǔn)了 Liu 的模塊化架構(gòu)。這將三個(gè)可替換的層分開：Dify 應(yīng)用構(gòu)建器、LLM 推理層和基于 MCP 的工具連接到 ServiceNow、GitHub 和阿里云資源。該平臺(tái)部署在經(jīng)過驗(yàn)證的阿里云著陸區(qū)內(nèi)，重用現(xiàn)有的安全組件。

該團(tuán)隊(duì)預(yù)先定義了數(shù)據(jù)類別，確認(rèn)核心商業(yè)機(jī)密不會(huì)被發(fā)送到平臺(tái)。管理層要求 Liu 與中國 IT 運(yùn)維負(fù)責(zé)人合作，明確價(jià)值，然后給予正式批準(zhǔn)。團(tuán)隊(duì)在兩個(gè)旗艦用例上工作。在外部，他們與一個(gè)在合同續(xù)簽期間執(zhí)行手動(dòng)定期檢查的供應(yīng)商合作，目標(biāo)是使用 AI 自動(dòng)化這些檢查。在內(nèi)部，他們開發(fā)了一個(gè)數(shù)據(jù)庫管理員聊天機(jī)器人，DBA 團(tuán)隊(duì)在看到它的實(shí)際應(yīng)用后表示有興趣采用它。

行業(yè)分析師強(qiáng)調(diào)，成功的 AIOps 實(shí)施需要的不僅僅是技術(shù)能力。在 CIO 的一篇文章中，F(xiàn)orrester Research 的 Will McKeon-White 指出，最成功的 AIOps 實(shí)施都具有跨部門的用例；組織需要來自 IT 之外的業(yè)務(wù)領(lǐng)域的輸入。

技能方面的挑戰(zhàn)仍然很大。Elastic 的 Gagan Singh 指出，AIOps 可能需要機(jī)器學(xué)習(xí)和數(shù)據(jù)分析等專業(yè)技能，而這些技能在市場上可能并不容易獲得。采用簡化信號(hào)攝取和模型訓(xùn)練的工具，無需專門的數(shù)據(jù)科學(xué)團(tuán)隊(duì)，有助于組織更快地通過 AIOps 提供價(jià)值。

盡管存在安全方面的擔(dān)憂，但 MCP 的采用正在加速。MCP 服務(wù)器的下載量從 2024 年 11 月的 10 萬左右增長到 2025 年 4 月的 800 多萬，現(xiàn)在有超過 5800 臺(tái) MCP 服務(wù)器可用。Block、Bloomberg 和 Amazon 的大規(guī)模部署表明，企業(yè)正在采用 MCP；然而，安全研究人員也發(fā)現(xiàn)了多個(gè)突出的問題，包括提示注入，工具權(quán)限可以在組合時(shí)泄漏文件，以及類似的工具可以默默地替換受信任的工具。

Mirantis 的 Randy Bias 認(rèn)為，MCP 需要變得安全、可治理和可觀測，以便在企業(yè)規(guī)模上使用智能體進(jìn)行關(guān)鍵任務(wù)用例和訪問敏感數(shù)據(jù)源。安全和合規(guī)團(tuán)隊(duì)不能允許任意的、未經(jīng)審查的智能體訪問關(guān)鍵數(shù)據(jù)系統(tǒng)，如電子醫(yī)療記錄、財(cái)務(wù)數(shù)據(jù)和客戶個(gè)人身份信息。如果不解決這些問題，企業(yè)可能會(huì)看到影子智能體的興起，類似于早期云計(jì)算時(shí)代出現(xiàn)的陰影 IT。

米其林的案例表明，AIOps 的成功實(shí)施更多是通過與治理相一致的漸進(jìn)式學(xué)習(xí)，而不是通過宏偉的愿景。在 CIO 文章中，AArete 的 John Carey 強(qiáng)調(diào)，組織通常時(shí)間緊迫且資源有限，因此 AIOps 需要徹底且有計(jì)劃。在沒有明確定義挑戰(zhàn)的情況下推出技術(shù)，可能會(huì)冒著投資于無法提供預(yù)期價(jià)值的解決方案的風(fēng)險(xiǎn)。同樣在 CIO 文章中，Axiom Consulting Partners 的 Donncha Carroll 建議公司花時(shí)間詳細(xì)說明他們將要解決的問題的性質(zhì)以及它將如何影響業(yè)務(wù)。確認(rèn)更傳統(tǒng)的解決方案不適用或無效，可以避免投資于無法實(shí)現(xiàn)既定愿景的實(shí)施。根據(jù)企業(yè)管理學(xué)院的一項(xiàng)調(diào)查，80% 的公司正在尋找新的 AIOps 平臺(tái)，一半計(jì)劃在未來一年內(nèi)更換，這表明即使是滿意的用戶也認(rèn)識(shí)到當(dāng)前產(chǎn)品有改進(jìn)的空間。

Liu 的回顧總結(jié)證實(shí)，該計(jì)劃已經(jīng)啟用了一個(gè)與 MCP 對(duì)齊的 AIOps 平臺(tái)，該平臺(tái)現(xiàn)在在阿里云上運(yùn)行。平臺(tái)已經(jīng)通過了安全和治理的障礙，團(tuán)隊(duì)已經(jīng)開始與運(yùn)維團(tuán)隊(duì)和供應(yīng)商就旗艦用例進(jìn)行了具體工作。在生產(chǎn)中實(shí)現(xiàn) AIOps 的路徑需要與他們的全球 IT 戰(zhàn)略保持同步，同時(shí)還要解決當(dāng)?shù)氐倪\(yùn)維問題。

我們想要安全且低成本地測試 AIOps 是否能在一兩個(gè)具體領(lǐng)域減輕痛苦。成功是：我們學(xué)到了什么可行，什么不可行，我們有可以重用的模式。 ——米其林的 Matthew Liu

https://www.infoq.com/news/2025/12/michelin-aiops/

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。