角色： 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 小時。

旅程步驟

Stage 1：大量警報湧入（0-2 分鐘）

Graylog 發送 ~60 筆 Webhook
  - 各服務的 connection refused / timeout logs
  - DB connection pool exhausted
  - API gateway 502 errors

LibreNMS 發送 ~40 筆 Webhook
  - Core Switch port down（多個 port）
  - 多台伺服器 CPU spike（DB、App、Web）
  - Memory alert（因連線重試導致記憶體暴增）
    ↓
Arova Source Adapter 接收並轉換
    ↓
100 筆 Raw Alert 建立

使用者情緒： 🔴 系統警報爆炸，以前這種情況要花半天才能理清

涉及模組： Integration（Webhook 接收）、Incident（IN-001 自動建立）

Stage 2：AI 降噪（自動，30-60 秒）

Correlation Agent 分析 100 筆警報：
  - 時間窗口：全部在 5 分鐘內
  - 網路拓撲：全部來自同一個 network segment
  - 按 host / service / 症狀分群
    ↓
結果：合併為 3 個 Incident

  🔴 INC-001 Core Switch Failure
     │  根因事件 · 信心度 94%
     │  合併 20 筆 switch 相關警報
     │  （port down × 12、switch CPU × 4、SNMP unreachable × 4）
     │
     ├─ 🟠 INC-002 Database Connectivity（衍生）
     │     合併 30 筆 DB timeout 警報
     │     （connection refused × 18、pool exhausted × 8、
     │       slow query timeout × 4）
     │
     └─ 🟠 INC-003 Application Service Degradation（衍生）
           合併 50 筆 app 層警報
           （API 502 × 22、connection timeout × 18、
             memory alert × 10）

AI 標註：
  - INC-001 為「最可能根因」
  - INC-002、INC-003 為「衍生事件」，連結到 INC-001

使用者情緒： 🟡→🟢 AI 在 1 分鐘內將 100 筆警報精煉為 3 個事件

涉及模組： AI Native（AIN-011 Correlation Agent）、Incident（IN-009 告警合併）

Stage 3：IT 主管看到的畫面

IT 主管陳志豪打開 Dashboard，看到的不是一片紅的警報，而是清晰的 3 個事件卡片：

┌─────────────────────────────────────────────────────┐
│ ⚠️ Alert Storm 已自動降噪                            │
│                                                     │
│ 過去 5 分鐘收到 100 筆警報，已合併為 3 個事件         │
│ 根因判斷：Core Switch 故障                           │
│ 信心度：94%                                          │
│ 建議優先處理 INC-001                                 │
│                                                     │
│ 事件分類：                                           │
│ 🔴 INC-001 Core Switch Failure        [根因] P1     │
│ 🟠 INC-002 Database Connectivity      [衍生] P2     │
│ 🟠 INC-003 App Service Degradation    [衍生] P2     │
│                                                     │
│ 100 筆原始警報 → 3 個精煉事件（降噪 97%）           │
└─────────────────────────────────────────────────────┘

陳志豪一眼就知道：優先處理 Core Switch，DB 和 App 的問題是連帶的。

使用者情緒： 🟢 恐慌消散，清晰的優先順序帶來從容感

涉及模組： Dashboard（DB-001, DB-014）、AI Native（AIN-001 AI 簡報）

→ Wireframe： page-dashboard（AI 每日摘要 + 待處理事件）

Stage 4：聚焦處理（10-30 分鐘）

工程師按 AI 建議優先檢查 Core Switch
    ↓
進入 INC-001 事件詳情 → 看到 [根因] 標籤
    ↓
AI 摘要：「Core Switch 多個 port down，
  同時影響 DB 和 App 層。建議先確認 Switch 實體狀態。」
    ↓
工程師到機房 → 發現 Switch 電源模組故障 → 更換
    ↓
Switch 恢復 → 所有 port 回復正常
    ↓
LibreNMS 發送 recovery alerts
    ↓
INC-002、INC-003 的相關警報自動消失
    ↓
AI 自動提示：
  「根因事件 INC-001 已修復。衍生事件 INC-002、INC-003
   的監控指標已恢復正常。建議批次結案。」
    ↓
工程師點「批次 Resolve」→ 系統 2 秒內同時更新三個事件
    ↓
AI 自動產生三份結案摘要

使用者情緒： 🟢 聚焦在根因，不被警報海淹沒，一次修復連帶解決所有問題

涉及模組： Incident（IN-006, IN-007）、AI Native（AIN-011, AIN-024）、Integration（recovery webhook）

→ Wireframe： page-detail（根因/衍生標籤 + 批次 resolve）

旅程摘要

全程數據

核心價值

這是 Arova AI-native 架構最強的展示情境。PagerDuty AIOps 和 BigPanda 的核心賣點是 Alert Storm 降噪，但它們都是 SaaS-only。Arova 在地端也能做到——所有資料不離開客戶環境，完全符合金融業合規要求。