角色: IT 工程師 + 陳志豪(IT 主管)
場景: 核心交換機故障,5 分鐘內 Graylog 和 LibreNMS 湧入 100 筆警報,IT 團隊看板一片紅
橫跨模組: Integration → Incident → AI Native → Dashboard
泰國廠的核心交換機(Core Switch)在凌晨突然故障。由於這台交換機連接了資料庫伺服器群和應用伺服器群,故障後 5 分鐘內,Graylog 和 LibreNMS 分別偵測到大量異常——application timeout、port down、CPU spike、memory alert、各服務 connection refused——總計湧入約 100 筆警報。
沒有 Arova 的情況下,IT 團隊看到看板一片紅,需要逐筆檢視 100 筆警報、手動分類、猜測根因,耗時 2-4 小時。
IT 主管陳志豪打開 Dashboard,看到的不是一片紅的警報,而是清晰的 3 個事件卡片:
陳志豪一眼就知道:優先處理 Core Switch,DB 和 App 的問題是連帶的。
本次 AI 標註 INC-001 為根因、INC-002/003 為衍生都是對的。但 AI 不保證每次都準,若 Alert Storm 中 AI 誤把某個獨立事件標為「衍生」,批次 resolve 時會連帶把它錯誤關閉。兩道防線避免這種誤操作:
1. 人工覆寫根因 / 衍生關係(IN-019):
2. 批次 Resolve 強制 Preview(IN-020):
場景示例:若其中 INC-003 其實是另一起獨立的 App 記憶體洩漏(與 Switch 無關),工程師在 preview 看到 INC-003 的 AI 信心度僅 0.6,uncheck 後單獨處理,避免被連帶錯誤關閉。
| Stage | 動作 | 花費時間 | 模組 |
|---|---|---|---|
| 1 | 100 筆警報湧入 | 0-2 分鐘 | Integration |
| 2 | AI 降噪:100 → 3 個事件 | 30-60 秒 | AI Native + Incident |
| 3 | IT 主管看到精煉後的 Dashboard | 即時 | Dashboard |
| 4 | 修復根因 + 批次 resolve 衍生事件 | 10-30 分鐘 | Incident + AI Native |
| 指標 | 使用 Arova 前 | 使用 Arova 後 |
|---|---|---|
| 警報湧入 | 5 分鐘內 100 筆 | 5 分鐘內 100 筆(一樣) |
| 人工分類時間 | 2-4 小時(逐筆檢視) | 30-60 秒(AI 自動) |
| 需查看的警報數 | 100 筆逐筆看 | 3 個精煉事件 |
| 找到根因時間 | 1-2 小時(猜測 + 試誤) | 1-5 分鐘(AI 標註根因) |
| 結案操作 | 逐筆關閉 100 筆 | 批次 resolve 3 個事件 |
| 全程 MTTR | 2-4 小時 | 30 分鐘 |
這是 Arova AI-native 架構最強的展示情境。PagerDuty AIOps 和 BigPanda 的核心賣點是 Alert Storm 降噪,但它們都是 SaaS-only。Arova 在地端也能做到——所有資料不離開客戶環境,完全符合金融業合規要求。