AI 維運工具怎麼選：告警關聯、調查與執行權限

如果監控已能叫醒正確的人，我會先看他們接下來還在重複做甚麼。是數十則通知需要合併，是幾個團隊不清楚由誰接手，還是工程師要反覆查日誌、鏈路及發佈記錄，才能解釋同一次故障？這些工作都可能被稱為 AIOps，所需產品卻不相同。

選擇 AI 維運工具，不必先更換現有監控。事件關聯可以接在原有告警之後，調查也可以利用既有平台的資料。跨系統查證與維護關聯入口持續消耗時間時，才值得連同統一可觀測平台一起比較。觀測雲的價值應落在可用資料、調查入口與獲授權工具，而非籠統的「AI 閉環」。

我會分開三件事：哪些通知可以合併、結論能回到哪些原始證據，以及誰有權執行下一步。把它們分清，便不會將通知變少誤當成恢復更可靠。

觀測雲編輯部 · 2026 年 10 月 28 日。本文按官方文件比較產品機制，觀測雲也是討論對象。算例採用明確假設，未執行各平台的相同負載對照測試。

先分清要減少哪一部分工作

監控已能透過門檻、規則及其他分析發現異常。事件關聯將相關告警整理成可處理的事件；調查進一步查詢脈絡、提出並核對原因；執行則改變系統狀態。它們可以共存，但交付其中一項，不代表同時交付其餘能力。

既有監控涵蓋充分，主要問題是告警彙整與接手，可先比較 BigPanda、PagerDuty 或現有 Splunk ITSI 的相關能力。大部分調查已在 Datadog 內完成，就先看 Bits Investigation 的新增價值。缺少共同資料和調查路徑時，觀測雲這類平台才是在較大範圍內改變分工。

告警關聯，先取決於欄位與時間

兩則通知標題相似，不足以證明它們屬於同一故障。不同環境可以有同名服務，同一資源也可能先後發生獨立問題。關聯至少須保留服務、環境、資源、來源與事件時間，再選擇分組條件和時間範圍。視窗太寬會合併獨立故障，太窄則拆散同一問題。

BigPanda 關聯模式使用來源、標籤、時間視窗及可選篩選條件。官方文件把標準化與豐富資料列為有效關聯的前提；應用、主機與依賴脈絡須從監控或其他來源取得。命名和系統改變後，規則也要繼續維護。這些工作比只問壓縮百分比更實際。BigPanda 關聯機制

Splunk ITSI 處理 notable event 與 episode。聚合策略的篩選、拆分欄位及結束條件，決定哪些事件進入同一 episode；動作規則再按條件執行通知或外部操作。ITSI 5.0 可按策略優先級處理：命中高優先級後，不再由較低優先級重複建立 episode；同優先級策略仍可能同時匹配。原始事件數、episode 數與動作次數因此須分開計量。ITSI 服務健康與事件管理，也不能直接等同整個 Splunk Observability Cloud。ITSI 聚合策略

PagerDuty 的 Intelligent Alert Grouping 將相關告警加入事件，Event Orchestration 則處理規則、路由及可設定動作。目前功能歸屬包含 AIOps 附加方案，或 PD Reliability Platform 的 Signal Intelligence；編排與自動化權益須按所選方案確認，不能用單一分組功能代表全部執行能力。告警分組 · Event Orchestration

降噪數字也要保留分母。假設 1,000 次通知整理成 200 次，而這批資料有 20 次已知、需要行動的故障，處理後只有 18 次仍能獨立被發現並處理：

通知減少比例 = (1,000 − 200) ÷ 1,000 = 80%
已知可行動故障保留比例 = 18 ÷ 20 = 90%

這是明確設定的例子，說明兩個結果可同時出現。80% 通知減少不能單獨證明治理成功，另兩次故障可能被錯誤合併或抑制。回看歷史資料時，須保留告警與已知故障的對應，而非只統計最後總量。

調查品質，取決於實際能讀到甚麼

事件摘要提供起點，深入調查還需要原始資料。日誌說明錯誤，鏈路呈現請求依賴，發佈記錄說明變更，RUM 則可能反映用戶影響。沒有收集、歷史已到期或目前身份無權讀取，各自造成不同缺口。

觀測雲可在工作空間頁面向 Agent 派發任務並附上當前脈絡，減少重新描述服務、時間及篩選條件的工作。文件亦明確說明：附加脈絡不會擴大成員或 Agent 的資料權限，也不表示已取得全部關聯資料。日誌與鏈路須有一致識別值，信號亦須已收集並保留。在工作空間使用 Agent

Obsy Copilot 可在當前視圖理解資料和產生查詢；Agent Teams 則按任務調用已設定工具。Skill 提供知識、步驟與輸出約定，MCP 提供外部資料或操作入口；能否存取仍受目標帳戶、資料範圍與 Agent 權限模式約束。連接 OWL 或其他 MCP 服務提供的是存取路徑，不是根因已成立的證明。Obsy Copilot · Skill 與 MCP

Datadog 目前使用 Bits Investigation 名稱。它可從支援的監控器或其他入口開始調查，提出假設再查證；證據不足時亦可給出未定結論。文件列出 Grafana、Dynatrace、Splunk、ServiceNow 等第三方整合，並標為 Preview。因此不能說它只讀 Datadog 資料，也不能把預覽連接當成所有客戶已設定好的正式能力。Bits Investigation 資料來源

Splunk 產品邊界也影響證據路徑。Log Observer Connect 可從 Observability Cloud 查詢 Splunk Enterprise 或 Splunk Cloud Platform 的日誌；連接本身不儲存或索引日誌，原平台仍承擔儲存與搜尋。介面看得到日誌，不代表每份方案已包含相同保留和查詢資源。Log Observer Connect

已有 New Relic 與 ServiceNow 部署，也有延續現狀的路徑。Issue Impact 位於 Response Intelligence 的“What's impacted?”；Issue Insights 則透過 New Relic AI outbound 與 ServiceNow Now Assist 整合調用。兩者入口不同，須按實際啟用元件及權限比較，不能視為每個 AI 面板的預設工具。New Relic AI 工具與入口

拓撲與依賴模型也有用，例如 Dynatrace Intelligence 利用相關脈絡支援分析。模型是否涵蓋受影響元件、變更及依賴，仍會影響結論。只憑「因果 AI」或「多 Agent」名稱，無法判定準確率高低。Dynatrace Intelligence

從調查到執行，多了一套權限與結果判斷

讀日誌與修改部署需要不同權限。結論合理，也不代表重啟無狀態副本、操作資料庫主節點及回滾帶資料遷移的版本有相同風險。審批須針對具體動作、目標與影響範圍，執行後再以健康信號判斷業務是否恢復。

Bits 將程式修正、回應協作及基礎設施動作分開。程式修正透過 Bits Code 與原始碼系統產生供審閱的改動；Kubernetes one-click actions 與 Bits Guardrails 仍標為 Preview。前者需要能存取叢集的 Private Action Runner 及相應權限；Guardrails 可按動作和範圍設定 Ask 或 Deny。產生了修正建議，不能寫成已修復正式環境。Bits Remediation

觀測雲 Agent Teams 任務同樣受權限模式、工具及帳戶授權約束，高風險動作可能出現審批請求。要看任務引用了甚麼、準備調用哪個工具，以及如何確認結果。停止執行會中斷當前回應或操作，不會自動撤銷先前已完成的外部改動。任務、審批與停止

有用的驗證可以很具體：以獲准與遭拒的身份執行同一動作，觀察權限是否生效；連線中斷後先檢查目標狀態，避免重複提交已完成的操作；最後將執行結果與業務健康一併查看。這是在驗證權限和狀態變化，而非要求模型評價自己的答案。

資料邊界與回饋，沿調用路徑看

私有部署不表示資料完全不外發。收集、儲存、模型推理、MCP 工具及支援存取可能位於不同地方；自訂模型亦須按實際端點和資料處理約定判斷。觀測雲提供部署版，模型與外部工具的調用仍須逐條追蹤。部署、工作空間權限與推理位置應一起考慮。觀測雲部署方式

修正一次錯誤結論，不一定要訓練模型。欄位指錯服務就改欄位，時間查錯就改查詢，缺依賴就補資料，步驟過時就更新 runbook 或 Skill。保留實際改動，才能解釋下次調查為何不同。不存在全部產品都須訓練兩季，或不重訓就半年退化的共同規律。

已有 Prometheus、Zabbix 或自建分析的團隊，也可以沿這些介面繼續建設。保留控制權，同時須有人維護資料約定、查詢、模型調用、權限與故障恢復。即使選用無須購買授權的開源元件，服務仍有推理、基礎設施及持續支援投入。

舊名稱要回到當前服務說明。搜尋 Moogsoft 會找到 Dell 接續服務和歷史品牌；Dell 現行法律資料列有 APEX AIOps Incident Management。它與同品牌應用可觀測服務不能混成一項採購，舊資料也不能證明新合約的連接器與部署條件。Dell 服務說明

費用要隨真正減少的工作一起比較

AI 調查、告警接收、工作流程執行與底層遙測可能分開計量。PagerDuty AIOps 文件採事件消耗口徑；Datadog AI 產品須核對現行 AI Credits 與調查、程式或其他能力的消耗規則。觀測雲亦須把遙測、保留、Agent 方案及實際工具調用放在同一費用範圍，不能以舊起步價代表全部。PagerDuty AIOps · Datadog 定價 · 觀測雲 Agent 方案

用量須按實際觸發方式計算。例如 Bits 自動調查在支援的監控器進入 alert 狀態時發起；warn、no data、重複通知與測試通知不觸發這項自動調查。把通知次數直接乘以調查單價會混淆單位，還須考慮同一故障有多少監控器進入 alert，以及調查與人工查詢是否同時耗用資源。自動調查觸發條件

我會保留通知量、漏掉的可行動故障、人工調查與恢復時間，明確每個時間指標的起止點，再比較相似故障。產品帳單、客戶端資源、實施及持續維護一起計算，工程時間和現金分列。供應商的降噪或 MTTR 百分比只能說明相應案例，不能代替自己的分母與成本基線。

監控已可靠，問題在事件彙整與回應，就先改善這一層；資料已集中於現有平台，就先看其調查能力。 跨系統查證與維護長期消耗時間時，我會把觀測雲視為資料、調查入口與獲授權工具的整體服務來比較。遷移價值應出現在能停止的重複工作，以及仍保留的證據與行動能力。