華經資訊企業股份有限公司 技術中心高級工程師/吳長俊
如果您有實際參與過大型 IT 環境的維運，應該很熟悉這樣的情況：系統沒有真的掛掉，但監控平台開始出現大量告警。
網路延遲、CPU 使用率、資料庫連線、API Timeout、Application Error……不同系統各自送出通知。當工程師開始逐一檢查時，才發現原來這些問題可能都來自同一個底層故障。這也是現在 IT 維運越來越困難的原因之一。過去的環境相對單純，一套應用程式可能對應幾台伺服器、一套資料庫，以及固定的網路設備。現在則完全不同。Cloud-Native、Microservices、Kubernetes、API Gateway、Container，以及多雲環境逐漸成為企業架構的一部分。系統的彈性提高了，但維運的複雜度也跟著上升。問題往往不是「沒有資料」，而是資料太多，而且彼此之間沒有被有效串起來。這也是 AIOps 開始受到重視的原因。
AIOps（Artificial Intelligence for IT Operations）並不是單純在既有監控平台上再加一個 AI Dashboard。它真正要處理的問題，是如何從大量 Metrics、Logs、Traces、Events 以及 Infrastructure 資料中，找出真正值得工程師注意的資訊，進一步協助判斷問題、預測趨勢，甚至執行部分已經標準化的修復工作。
如果把 AIOps 拆開來看，我認為可以先從三個能力理解：預測、事件分類與關聯，以及自動修復。
預測：不要等到系統出問題才開始處理
傳統監控最常見的做法，就是設定 Threshold。例如：CPU 使用率超過 85%，持續 5 分鐘就發出警報。這個方式很直觀，也仍然有它的價值。問題在於，固定門檻並不知道當時的系統到底處於什麼狀態。例如電商在促銷期間，CPU 長時間維持在 85% 可能是正常現象；但如果凌晨兩點，平常只有 30% 的系統突然持續升到 60%，真正值得注意的反而可能是這個變化本身。因此 AIOps 的預測能力，重點不只是「現在有沒有超過門檻」，而是：「現在的狀態，是否偏離了系統原本應有的行為模式？」
Dynamic Baseline：讓系統自己理解「正常」
AIOps 可以利用歷史 Metrics 建立 Dynamic Baseline。
例如 CPU、Memory、IOPS、Latency、Network Throughput 等指標，可能本來就存在明顯的時間週期：
• 工作日與週末不同
• 白天與晚上不同
• 月初與月底不同
• 平日與促銷活動期間不同
透過 Time-Series Analysis，甚至 ARIMA、LSTM 等模型，可以逐步建立系統在不同時間條件下的正常範圍。這樣一來，監控的概念就從「超過 85% 才告警」，變成「目前的行為與過去正常模式相比，是否出現異常？」這個差異看起來不大，但對大型環境的維運其實非常重要。因為真正有價值的告警，往往不是告訴你「現在已經壞了」，而是在問題還沒有影響到使用者之前，讓你知道：
這個趨勢可能正在往錯誤的方向發展。
Capacity Forecasting：容量管理也可以提前做
預測不一定只拿來找故障。對 Infrastructure 團隊來說，Capacity Planning 同樣是一個非常實際的應用。假設某個關鍵服務的 Memory 使用量，每週大約增加 2%。短期看起來可能完全沒有問題。但如果這個趨勢持續幾個月，最後一定會碰到容量上限。
傳統監控通常要等到資源使用率接近 90% 或 95% 才發出警告。這時候工程師可能只剩幾天甚至幾個小時可以處理。AIOps 則可以從歷史資料與成長趨勢估算：「依照目前的使用趨勢，這個節點大約還能維持多久？」這時候 IT 團隊可以提前安排擴容、調整資源配置，或者回頭檢查是不是某個 Application、Process 或 Database Query 導致資源持續增加。這才是預測能力真正有價值的地方：不是預測得多神，而是讓維運團隊多一些處理問題的時間。
事件分類與關聯：真正困難的往往不是發現問題
IT 維運最常遇到的問題之一，其實不是沒有告警。而是告警太多。假設一台 Database Server 發生故障，上游可能同時出現：
• API Timeout
• Application Error
• Connection Failure
• Load Balancer Error
• Kubernetes Pod Restart
• Service Unavailable
如果每一個系統都獨立發出 Alert，最後可能得到數百甚至數千筆事件。工程師看到的結果可能是：「整個系統好像同時有很多地方壞掉了。」但實際上，真正的問題可能只有一個。這就是 Event Correlation 很重要的原因。
從 Metrics、Logs、Traces 找出同一件事情
現代 Observability 通常會從三個主要資料來源開始：Metrics、Logs、Traces。單獨看其中任何一種資料，都很難完整描述問題。例如 Metrics 告訴我們：Database Latency 正在增加。Logs 可能告訴我們：Connection Pool 已經接近上限。Trace 則可能進一步顯示：大量 Request 都卡在同一個 Database Call。把這些資訊放在一起，才比較有機會知道真正發生了什麼。
AIOps 在這裡扮演的角色，不是單純「把告警變少」，而是建立事件之間的關聯。
1. Time Correlation
第一個維度通常是時間。如果幾十個不同系統的異常都集中發生在同一個時間點，就值得進一步檢查它們之間是否存在關聯。例如：
10:03 Network Latency 增加
10:03 Database Connection Error
10:04 API Timeout
10:04 Application Error
這些事件很可能不是四個獨立問題。
2. Topology Correlation
第二個維度是 Infrastructure Topology。假設：Application A → Service B → Database C → Storage D
如果 Storage D 發生問題，往上層可能會出現大量連鎖反應。這時候真正重要的問題不是：「哪幾百個服務正在報錯？」而是：「這幾百個錯誤是不是同一個底層問題造成的？」
如果 AIOps 平台有完整的 Dependency Map，就可以沿著服務與基礎架構之間的關係，把相關事件收斂在一起。這也是為什麼 AIOps 和單純的 Monitoring 不太一樣。
Monitoring 告訴你：「哪裡不正常。」AIOps 更希望進一步回答：「這些不正常之間有沒有關係？」
3. NLP 與事件內容分析
另外一個常見方向，是利用 NLP 分析 Logs 與 Alert Message。例如不同設備可能使用不同的錯誤訊息描述同一類問題。如果只用字串比對，很容易被不同格式的 Log 分散。透過文字相似度與 Clustering，可以把相近的事件聚在一起，協助工程師更快找到真正需要處理的 Incident。但這裡需要特別注意：事件降噪不是把告警刪掉。
好的 Event Correlation 應該是把「相關事件」整理在一起，而不是單純降低告警數量。否則很容易從 Alert Fatigue 變成另一個問題：真正重要的告警反而被過濾掉。
Root Cause Analysis：從「發生什麼?」走到「為什麼發生?」
事件收斂之後，下一個問題就是 RCA（Root Cause Analysis）。傳統維運最常見的方式，是工程師自己開幾個 Dashboard：一邊看 Network，一邊看 Server，再切到 Database，接著查 Application Log，最後回頭確認最近是不是有人做過Deployment。
這種方式在小型環境還可以，但當系統規模越來越大，靠人工逐一比對就會變得非常耗時。AIOps 可以透過 Dependency Map、歷史事件、時間關聯以及其他分析模型，協助縮小問題範圍。例如：
Application Error 增加 → API Latency 增加 → Database Query Time 增加 → 最近剛完成版本部署。
這時候系統可以把「新版本 Deployment」列為較高優先級的可疑原因。這並不代表 AI 一定能直接告訴你正確答案。實務上更合理的期待應該是：把原本需要工程師花 30 分鐘到 1 小時排查的範圍，縮小到幾個最值得檢查的方向。這對 MTTR 的改善，往往比單純追求「完全自動找出 Root Cause」更加實際。
自動修復：AIOps 真正進入「閉環」的地方
如果前面的流程可以理解成：監控 → 分析 → 判斷。
那麼 Automated Remediation 就是再往前一步：監控 → 分析 → 判斷 → 執行。這就是所謂的 Closed-Loop Operations。
不過我認為這裡有一個觀念非常重要：不是所有問題都適合直接交給 AI 自動處理。例如 Restart 一個無狀態 Application Pod，風險可能相對低。但如果是 Database Failover、Storage Configuration、Network Routing 或 Production Data 操作，風險就完全不同。因此實務上的 AIOps 導入，通常會採取漸進方式。
從 Runbook Automation 開始
企業可以先把常見而且規則明確的問題整理成 Runbook 或 Playbook。例如：
• Service 無回應 → Restart Service
• Pod CrashLoop → 重新部署
• 磁碟空間不足 → 清除已確認的暫存檔
• 流量突然增加 → 調整 Pod Replicas
• 新版本錯誤率異常 → 執行 Rollback
AIOps 偵測到符合條件的事件後，再透過 API、Webhook 或既有Automation Platform 執行對應動作。這樣的方式比較容易控制風險。
Human-in-the-Loop 才是很多企業比較實際的第一步
如果操作風險比較高，可以先讓 AI 提出建議，而不是直接執行。例如：
「偵測到 Database Primary Node 異常。建議切換至 Standby Node。目前判斷信心：High。」工程師確認之後才真正執行。
這種 Human-in-the-Loop 模式，通常比一開始就追求 Zero-touch Operations 更容易在企業環境落地。等到團隊累積足夠的事件資料，也確認自動化流程可靠，再逐步增加自動執行的範圍。
幾個比較容易理解的 Self-Healing 場景
流量突然增加。AIOps 從歷史趨勢判斷未來一段時間流量可能明顯增加。系統可以透過 Kubernetes API 增加 Pod Replicas。流量恢復正常後，再把資源調整回原來的規模。這裡真正的價值不只是「自動增加 Pod」，而是讓資源調整從人工反應變成依照需求動態處理。
Service 還活著，但其實已經不能工作。有些 Process 並沒有真的停止。從 Server 的角度看，Process 還在，但 Application 已經無法正常回應 Health Check。
這類問題人工處理時容易拖一段時間。如果系統已經有明確的 Health Check 與 Recovery Policy，就可以讓 AIOps 或 Automation Framework 自動執行隔離、Restart 或重新部署。
新版本上線後自動 Rollback，這是 AIOps 與 CI/CD 結合後非常實用的場景。例如新版本部署完成後，正常錯誤率為 0.1%，部署後突然上升至 5%，同時 Latency、Error Rate、Application Log 都出現異常。如果系統已經定義好明確的判斷條件，就可以自動觸發 Rollback。這樣的設計其實比「AI 自己決定要不要退版」更容易控制。AI 負責分析與判斷。Automation 負責執行。而企業則可以透過 Policy 控制風險。
企業導入 AIOps，最容易忽略的其實不是 AI
很多企業談 AIOps 時，第一個想到的是：「我們應該買哪一個 AI 平台？」但真正開始做之後，往往才會發現問題不是模型不夠強，而是資料根本沒有整理好。
Metrics 在一個平台。Logs 在另一個平台。Network Monitoring 又是另一套。Application Monitoring 再用另外一套工具。CMDB 裡面的資料可能又沒有更新。這種環境下，即使導入很好的 AI，最後也可能只能得到有限的結果。因此 AIOps 導入比較適合按照 Crawl → Walk → Run 的方式進行。
Crawl：先把資料整理起來
第一階段先處理：Monitoring、Logs、Metrics、Traces、Events、Configuration、Asset / Dependency。先確保資料可以被收集、標準化與關聯。
Walk：先把告警與事件做好
第二階段可以先從 Event Correlation、Noise Reduction、Incident Management 開始。這個階段的目標不一定是自動修復。反而可以先觀察：
• Alert 數量是否降低
• Incident 是否更容易收斂
• RCA 是否更快
• 工程師排查時間是否縮短
• False Positive 是否下降
這些指標比較能反映 AIOps 到底有沒有真正產生價值。
Run：開始建立自動化閉環
當團隊已經對資料、模型與事件關聯建立一定程度的信任之後，再開始導入 Automated Remediation。這時候可以從低風險、高重複性的工作開始，例如 Restart、Scale-out、Rollback、Clear Cache、Service Recovery。等到這些流程穩定之後，再慢慢往更複雜的 Infrastructure Operation 延伸。
GenAI 會讓 AIOps 發生什麼變化？
AIOps 下一個明顯的變化，很可能來自 Generative AI。以前工程師可能需要自己查：Dashboard → Log → Trace → CMDB → Deployment Record → Knowledge Base。
未來比較自然的操作方式可能會變成直接問：「為什麼購物車服務最近 30 分鐘錯誤率突然增加？」系統再把 Metrics、Logs、Traces、Deployment History 與 Infrastructure Dependency 串在一起，整理成一個比較容易理解的答案。甚至進一步：「如果要修復，目前有哪些方式？」或者：「幫我產生這次問題的 Runbook。」這種能力對維運團隊真正有價值的地方，不只是「可以跟 AI 聊天」。而是讓原本分散在不同系統裡面的資訊，有機會透過自然語言被重新組織起來。
AIOps 的價值，不是把工程師變得不重要
我認為這是談 AIOps 時最需要釐清的一件事情。AIOps 並不是要把 IT Engineer、SRE 或 Infrastructure Team 全部自動化。相反地，真正成熟的 AIOps 應該把工程師從大量重複性的工作中解放出來。例如：每天查看大量相似的 Alert、反覆搜尋同樣的 Log、手動確認服務是否需要 Restart、每次 Deployment 出問題都重新執行同一套排查流程。
這些事情如果已經有明確規則，就沒有必要一直依賴人工。真正值得工程師投入時間的，應該是架構設計、容量規劃、可靠性、災難復原、效能優化，以及那些沒有辦法單純靠 Runbook 解決的複雜問題。所以，如果要用一句話來說明 AIOps，我會這樣定義：
AIOps 不是讓 IT 維運完全自動化，而是讓維運團隊更早知道問題、更快找到問題，並把能夠標準化的處理流程逐步自動化。從這個角度來看，AIOps 真正帶來的改變，不是多了一個 AI 工具。而是 IT Operations 開始從「出了問題再處理」，逐步轉向：
提前發現 → 快速定位 → 自動處理 → 持續學習。這才是 AIOps 比較值得期待的地方。
如果您正在評估企業目前的 AIOps 成熟度，建議不要先從「要不要導入 AI」開始，而是先問三個問題：
1. 我們現在收集到的資料，是否真的足以支援跨系統分析？
2. 發生 Incident 時，我們需要花多少時間才能找到 Root Cause？
3. 哪些維運工作已經高度標準化，可以安全地交給 Automation？
把這三個問題回答清楚，通常就能找到 AIOps 最適合開始的地方。
AIOps 導入檢核表
AIOps 的起點不是 AI，而是把維運工作做得更有系統。AIOps 的核心並不是單純加入 AI，而是把 Metrics、Logs、Traces、Events 與 Infrastructure 資料串起來，讓維運團隊更早發現異常、更快縮小問題範圍，並逐步將高重複、低風險的處理流程自動化。
AIOps 導入檢核表:
□ 是否已整合 Metrics、Logs、Traces、Events 等主要資料來源？
□ 是否存在可維護的 Infrastructure / Service Dependency Map？
□ 是否能區分 Alert、Event 與 Incident，避免單純以告警數量衡量成效？
□ 是否已建立可重複執行且有明確風險邊界的 Runbook？
□ 哪些 Automation 可以先採 Human-in-the-Loop？
□ 哪些低風險流程可以進一步進入 Closed-Loop Operations？
□ 是否有 MTTR、False Positive、Alert Volume、Recovery Time 等可量化指標？