Arova Nexus Phase 0
Arova Nexus Phase 0
角色： 王工程（初階 IT 工程師，入職 3 個月）+ AI Agent + 李維運（IT 主管，在外開會） 場景： 泰國廠產線核心交換機 Core-SW-01 電源模組故障，Graylog 偵測到大量 app timeout，LibreNMS 偵測到 8 個 port down。王工程第一次獨立面對 P1 事件 橫跨模組： Integration → Incident → AI Copilot → Knowledge → Analytics
泰國廠 IT 團隊只有 5 人，其中資深工程師 2 人、初階工程師 3 人。王工程入職 3 個月，之前只處理過 P3/P4 的小事件。今天下午 2 點，資深工程師都在巡檢其他廠區，只有王工程值班。
產線核心交換機 Core-SW-01 是連接 ERP、MES、SCADA 閘道的關鍵設備，一旦故障整條產線的 IT 系統都會受影響。
Core-SW-01 電源模組 PSU-A 故障，瞬間產生大量告警。
14:00:00 Core-SW-01 PSU-A 故障
│
├─ LibreNMS 發送 8 筆 Webhook：
│ port 1-8 down（連接 ERP/MES/SCADA Gateway）
│ CPU 0%（設備失去回應）
│
├─ Graylog 發送 35 筆 Webhook：
│ ERP: "Connection timeout to 10.1.1.1"（×12）
│ MES: "Database connection lost"（×8）
│ SCADA GW: "PLC communication failure"（×15）
│
↓ 共 43 筆告警湧入 Arova
│
14:00:15 AI Correlation Agent 分析（信心度 96%）：
「43 筆告警來自同一網段 10.1.1.0/24，
時間窗口 15 秒內，指向 Core-SW-01」
│
→ 合併為 3 個 Incident：
INC-0501 Core-SW-01 硬體故障（🏷️ 根因）
INC-0502 ERP/MES 連線中斷（🏷️ 衍生）
INC-0503 SCADA Gateway 通訊失敗（🏷️ 衍生）
│
14:00:20 AI Triage Agent 分類：
嚴重度：P1（核心網路設備 + 產線影響）
類型：Hardware Failure / Network
指派：王工程（值班中）
│
14:00:25 通知發送：
→ 王工程：Email + Toast + Slack
→ 李維運（主管）：Email + Slack（P1 事件自動通知主管）
使用者情緒： 🟢 43 筆告警 → 3 個事件，AI 在 25 秒內完成（以往需要 30 分鐘人工分類）
涉及模組： Integration（Webhook 接收）、Incident（IN-001, IN-009）、AI Native（AIN-011 Correlation, AIN-012 Triage）、Notification
王工程手機收到 Slack 通知，打開 Arova 事件詳情頁。
┌─────────────────────────────────────────────────────────┐
│ INC-0501 Core-SW-01 硬體故障 │
│ 嚴重度：P1 (Critical) 狀態：New AI 信心度：96% │
│ 🏷️ 根因事件 · 關聯 2 個衍生事件 │
│ │
│ 📋 AI 摘要： │
│ Core-SW-01（Cisco C9300）在 14:00 失去回應。LibreNMS │
│ 報告 8 個 port 同時 down + CPU 0%，Graylog 記錄到 35 │
│ 筆上游服務連線逾時。所有受影響服務都在 10.1.1.0/24 網段。│
│ 研判為硬體故障（非設定變更或流量異常）。 │
│ │
│ 影響範圍：ERP、MES、SCADA Gateway（3 個核心服務） │
│ 預估影響：產線 A/B 全線 IT 系統中斷 │
│ │
│ 💡 AI 建議行動： │
│ 1. ⚡ 緊急：到機房檢查 Core-SW-01 實體狀態 │
│ （電源 LED、風扇聲音、Console 回應） │
│ 2. 確認是否為電源或風扇模組故障 │
│ 3. 若為單一 PSU 故障，更換備用 PSU 模組 │
│ 4. 若為整機故障，啟動備援交換機 Core-SW-02 │
│ │
│ 📖 相關知識文章： │
│ • KB-031 Core Switch 故障 SOP 相關度 95% │
│ • KB-018 網路設備更換備品流程 相關度 82% │
│ • KB-045 產線 IT 緊急應變程序 相關度 78% │
│ │
│ 🕐 相似歷史事件： │
│ • INC-0312 (2025-11) Dist-SW-02 風扇故障 — 15 分鐘修復 │
│ 修復方式：更換風扇模組 │
└─────────────────────────────────────────────────────────┘
王工程雖然入職 3 個月沒處理過 P1，但 AI 摘要告訴他：
王工程點「確認」接手事件。
使用者情緒： 🟢 第一次遇到 P1 有點緊張，但 AI 摘要像資深同事在旁邊指導
涉及模組： Incident（IN-005, IN-007）、AI Copilot（AIC-002, AIC-003）、Knowledge（KB-008）
王工程到機房前，先用 AI Copilot 快速了解更多。
┌─────────────────────────────────────────────────────────┐
│ AI Copilot │
│ │
│ 👤 王工程：Core-SW-01 有幾顆電源模組？備品在哪裡？ │
│ │
│ 🤖 根據 CMDB 資料： │
│ Core-SW-01 (Cisco C9300-48T) 配置 2 顆 PSU： │
│ • PSU-A: PWR-C1-1100WAC（主電源） │
│ • PSU-B: PWR-C1-1100WAC（備援，目前 Standby） │
│ │
│ 備品位置（根據 KB-018）： │
│ 泰國廠 MDF 機櫃 Rack-A 底層備品箱，型號 PWR-C1-1100WAC │
│ 庫存：2 顆 │
│ │
│ 👤 王工程：如果 PSU-A 壞了，PSU-B 應該會自動接手吧？ │
│ 為什麼所有 port 都 down 了？ │
│ │
│ 🤖 好問題。正常情況下 PSU 冗餘應該讓 PSU-B 自動接手。 │
│ 但 LibreNMS 顯示 CPU 0%（設備完全無回應），這表示 │
│ 可能不是單純 PSU 故障，而是： │
│ 1. 兩顆 PSU 同時故障（罕見但可能） │
│ 2. PSU-A 故障時產生電湧損壞主機板 │
│ 3. PSU-B 其實之前就已故障（未偵測到） │
│ │
│ 建議：到機房先看兩顆 PSU 的 LED 狀態。 │
│ • 兩顆都滅 → 可能是 PDU/電源迴路問題 │
│ • 只有 PSU-A 滅 → 嘗試拔插重置或更換 │
└─────────────────────────────────────────────────────────┘
AI Copilot 做了資深工程師才會做的事：追問「為什麼冗餘沒生效」，幫王工程建立正確的排障思路。
使用者情緒： 🟢 AI 的追問比我自己想得更深入
涉及模組： AI Copilot（AIC-001, AIC-002）、CMDB（CM-001 資產資訊）、Knowledge（KB-018）
王工程到機房檢查：
王工程按 SOP：
交換機恢復後，王工程想確認上游服務是否都恢復正常。
┌─────────────────────────────────────────────────────────┐
│ AI Copilot │
│ │
│ 👤 王工程：ERP 和 MES 的連線有恢復嗎？ │
│ │
│ 🤖 查詢 Graylog log（Phase 2 能力）... │
│ │
│ ERP (10.1.1.10)： │
│ • 14:00-14:18 共 127 筆 "Connection timeout" error │
│ • 14:18 起 error 停止，最後一筆正常 log: 14:19 │
│ • ✅ 已恢復 │
│ │
│ MES (10.1.1.20)： │
│ • 14:00-14:18 共 89 筆 "Database connection lost" │
│ • 14:19 起恢復連線，但有 3 筆 "Reconnection attempt" │
│ • ✅ 已恢復（自動重連成功） │
│ │
│ SCADA Gateway (10.1.1.30)： │
│ • 14:00-14:18 共 215 筆 "PLC communication failure" │
│ • 14:20 PLC 通訊恢復 │
│ • ✅ 已恢復 │
│ │
│ 💡 所有 3 個服務已恢復。建議可以解決此事件。 │
│ │
│ ⚠️ 注意：PSU-B 靜默故障未被 LibreNMS 偵測到，建議 │
│ 建立預防措施：啟用 PSU 冗餘狀態的 SNMP 監控 trap。 │
└─────────────────────────────────────────────────────────┘
標註： 這個 Stage 展示的是 Phase 2 Graylog 深度整合的能力。MVP 階段工程師需要自己到 Graylog 介面查 log，Phase 2 後可以直接在 Copilot 中用自然語言查詢。
使用者情緒： 🟢 不用切換到 Graylog 介面，直接在 Arova 確認所有服務恢復
涉及模組： AI Copilot（AIC-009 Graylog 查詢，Phase 2）、Integration（Graylog 深度整合）
LibreNMS 發送 recovery alert，Arova 自動更新事件時間軸。
┌─────────────────────────────────────────────────────────┐
│ 時間軸 │
│ │
│ 14:00 LibreNMS 偵測 8 port down + Graylog 35 筆 error │
│ 14:00 AI 合併 43 筆告警為 3 個事件（信心度 96%） │
│ 14:00 AI 分類 P1 + 指派王工程 │
│ 14:02 王工程確認接手 │
│ 14:07 王工程到達機房 │
│ 14:10 確認 PSU-A 故障 + PSU-B 靜默故障 │
│ 14:15 更換 PSU-A（主電源恢復） │
│ 14:18 更換 PSU-B（備援恢復） │
│ 14:19 🟢 LibreNMS 報告 8 port 恢復（Recovery alert） │
│ 14:20 💡 監控系統報告已恢復，建議可結案 │
│ 14:22 王工程點擊「解決」 │
│ 14:25 李維運遠端審查 AI 結案摘要 → 「結案」 │
│ │
│ 總 MTTR：25 分鐘（以往同類事件平均 2-4 小時） │
└─────────────────────────────────────────────────────────┘
王工程點「批次解決」，一次關閉根因 INC-0501 + 衍生 INC-0502/0503。
使用者情緒： 🟢 第一次獨立處理 P1，25 分鐘搞定！
涉及模組： Incident（IN-016 結案、IN-006 批次解決）
系統偵測到 P1 結案，建議產出 PIR。
┌─────────────────────────────────────────────────────────┐
│ 事後檢討報告 (PIR) — AI 自動草擬 │
│ │
│ 1. 事件概述 │
│ 2026-04-09 14:00-14:25，Core-SW-01 電源模組故障導致 │
│ 產線 A/B IT 系統中斷 25 分鐘，影響 ERP、MES、SCADA 三 │
│ 個核心服務。 │
│ │
│ 2. 根因分析（AI 信心度 96%） │
│ PSU-A 硬體故障 + PSU-B 靜默故障（冗餘失效）。PSU-B 故障 │
│ 未被 LibreNMS SNMP 偵測到（trap 未啟用）。 │
│ │
│ 3. 影響評估 │
│ • 受影響服務：3 個（ERP、MES、SCADA Gateway） │
│ • 中斷時間：25 分鐘 │
│ • 影響產線：A/B 線暫停 IT 相關作業 │
│ │
│ 4. 預防建議 │
│ ① 啟用 PSU 冗餘狀態 SNMP trap 監控 │
│ ② 建立每月 PSU 健康檢查排程 │
│ ③ 評估核心交換機備援架構（Stack 或 VSS） │
│ │
│ 5. Action Items │
│ ┌──────────────────────┬────────┬────────────┬─────┐ │
│ │ 項目 │ 負責人 │ 到期日 │ 狀態│ │
│ ├──────────────────────┼────────┼────────────┼─────┤ │
│ │ 啟用 PSU SNMP trap │ 王工程 │ 2026-04-16 │ ⬜ │ │
│ │ 建立 PSU 月檢排程 │ 李維運 │ 2026-04-23 │ ⬜ │ │
│ │ 評估交換機備援方案 │ 李維運 │ 2026-05-09 │ ⬜ │ │
│ └──────────────────────┴────────┴────────────┴─────┘ │
│ │
│ [送出簽核] [下載 PDF] │
└─────────────────────────────────────────────────────────┘
PIR 由 AI 在 30 秒內自動草擬。王工程補充現場照片（PSU LED 狀態），李維運遠端在手機上簽核。
接著，李維運在「分析報表」頁面產出 ISO 27001 合規報告，此事件的完整稽核軌跡自動包含。
使用者情緒： 🟢 以前寫 PIR 要 2-3 天，現在 AI 30 秒就寫好了
涉及模組： Incident（PIR）、Analytics（ISO 27001 報告）
| 指標 | 以往（無 AI） | 本次（AI 輔助） | 改善 |
|---|---|---|---|
| 告警分類時間 | 30 分鐘（人工逐條看） | 25 秒（AI 自動） | 98%↓ |
| 根因定位 | 1-2 小時（問資深同事） | 2 分鐘（AI 摘要） | 97%↓ |
| 修復時間 | 1-2 小時（找 SOP + 試錯） | 15 分鐘（按 AI 建議 + SOP） | 85%↓ |
| 總 MTTR | 2-4 小時 | 25 分鐘 | 90%↓ |
| PIR 撰寫 | 2-3 天 | 30 秒（AI 草擬）+ 10 分鐘（人工補充） | 99%↓ |
| ISO 報告 | 3-5 天 | 10 分鐘（範本 + 自動填充） | 99%↓ |
| 初階工程師能否獨立處理 P1 | ❌ 需等資深 | ✅ AI 引導下可獨立完成 | — |
| 模組 | Stories | 說明 |
|---|---|---|
| Integration | INT-001 | Graylog + LibreNMS Webhook 接收 |
| Incident | IN-001, IN-005, IN-006, IN-007, IN-009, IN-016 | 事件建立、AI 摘要、批次解決、結案、告警合併 |
| AI Native | AIN-011, AIN-012, AIN-024 | Correlation Agent、Triage Agent、結案摘要 |
| AI Copilot | AIC-001, AIC-002, AIC-003, AIC-009 | 自然語言查詢、上下文感知、KB 搜尋、Graylog 查詢（Phase 2） |
| Knowledge | KB-008, KB-018, KB-031, KB-045 | 語意搜尋、SOP 推薦 |
| Analytics | AN-009 | ISO 27001 合規報告 |
| Notification | NT-002, NT-003 | Email/Toast/Slack/Webhook 通知 |
| CMDB | CM-001 | 設備資訊查詢 |
本次事件中的 AI 角色是 L1 通知（分析 + 建議，人工執行）。未來路線圖：
| 階段 | AI 在本事件中的行為 | 條件 |
|---|---|---|
| MVP (L1) | 分析 + 建議「檢查 PSU」→ 王工程手動修復 | 現在 |
| V1.5 (L2+) | 建議「執行 PSU 健康檢查 Workflow」→ 王工程點確認 | 準確率 >85% 連續 30 天 |
| V2.0 (L3) | 偵測到 disk full → 自動執行 log 清理（Runbook 範圍內） | 準確率 >90% 連續 60 天 |
| V2.5 (L3+) | 偵測到未知故障模式 → AI 自主判斷修復策略 | 長期目標 |