Arova Nexus Phase 0
Arova Nexus Phase 0
角色： 林建宏（IT 維運工程師，值班中）+ AI Agent + 陳志豪（IT 主管）
場景： 凌晨 2:15，Graylog 偵測到資料庫伺服器 error log 異常增加（slow query timeout），同時 LibreNMS 偵測到該伺服器 CPU 飆升
橫跨模組： Dashboard → Incident → AI Copilot → Knowledge → Integration → Analytics
泰國廠的資料庫伺服器 DB-PROD-01 在凌晨 2:15 出現效能異常。Graylog 偵測到 slow query timeout error log 暴增，同時 LibreNMS 偵測到 CPU 使用率飆升至 98%。兩個監控系統分別發送 Webhook 告警到 Arova Nexus。
這是一個典型的多來源事件——同一個根因觸發了不同監控系統的警報，Arova 的 AI Agent 需要識別關聯並合併處理。
本次 5 筆警報合併為同一事件是正確的（共同根因 DB-PROD-01）。但若 AI 誤將「DB CPU 高」與不相關的「另一台 web server 記憶體滿」合併為同一事件，工程師可在 Stage 2 打開事件詳情頁後立刻修正：
02:15 AI Correlation 合併 5 筆警報 展開合併管理內容 → 看到 N 筆原始警報與來源若誤合併極端情況下把原事件全部警報都拆走，原事件保留但狀態設為「已結案（merged_out）」，保留 audit trail 供稽核回追。
林建宏手機收到 Email 通知 — 本事件為 SEV2，Email 內只有「前往 Nexus」深連結按鈕（無「✓ Acknowledge」— SEV1/2 強制進系統看 AI 摘要防盲 Ack · IN-037）。
深睡值班可 opt-in 多通道（IN-039）： 林建宏是深眠體質，擔心 SEV2 Email 睡過頭漏接，事先在個人偏好勾選「值班期間升級為多通道通知（SEV2-4）」。本次他值班且 opt-in → 除 Email 外同時收到站內通知 + 第二通道（公司設定為 Teams push）→ 手機震動 + 桌機通知雙重喚醒。非值班夜晚即使 opt-in 也不會升級，避免週末被打擾。
他點連結 → URL 為 /incidents/INC-2026-0423 事件詳情頁深連結 → 手機瀏覽器未登入 → 跳登入頁帶 redirect_uri → 登入成功後自動回事件詳情頁。省 2 個 click（原本要繞 Dashboard → 切事件佇列 → 點整列進詳情）。
林建宏進入事件詳情頁，標頭只顯示一個主動作 [確認]（情境化按鈕 IN-034 — 未確認狀態下只該有「確認」），overflow ⋯ menu 收「升級 / 誤報關閉」次要動作。
標頭下方 Next Action 橫幅（IN-035）顯示：⏭️ 點「確認」開始處理（已過 2 min / SLA 30 min） — 藍色背景表示時間充裕。
林建宏看 AI 摘要後點「確認」，狀態變為 Acknowledged。橫幅文案立刻變為：⏭️ 開始調查根因（Progress SLA 剩 28 min）。他手機上 hover 橫幅看到 tooltip（IN-035 新增）：
當前 SLA 類型：Progress
起算時間：Ack 02:17
剩餘：28 min
逾時 2x 將觸發 Investigation Stall（reassign 建議）
凌晨掃一眼就知這是 Ack 後的 Progress SLA 不是 Response SLA，不用翻 spec 查。
若本次警報嚴重度是 SEV3 或 SEV4（例：非核心 batch job 跑慢不影響使用者），Email 會另含「✓ Acknowledge」按鈕：
為什麼 SEV1/SEV2 不給 Email 一鍵 Ack？ 本事件（SEV2）強制工程師進系統看 AI 摘要再 Ack — 防盲 Ack 重大事件。對照 AP-011 ⚠ pre-action 設計思路。
Ack Token 過期 fallback 與簽核不同： 若 2 小時內沒點 Email Ack 連結過期，fallback 頁顯示「請登入處理」— 不重發 Token。Ack 有時效性，重發會給工程師「還有時間」的錯覺。
若林建宏瞥一眼覺得「又是 batch job 偶爾跑慢」，點「誤報關閉」，但 30 分鐘後同類警報再次觸發：
auto-reopened · 誤報 24 hr 內再觸發（判定可疑） · host: DB-PROD-01 · symptom: slow query timeout林建宏在 AI Copilot 側邊欄輸入：
「上次 DB-PROD-01 CPU high 是怎麼解決的？」
AI Copilot 搜尋歷史事件和知識庫，回應：
「INC-2025-1208：上次是 missing index 造成 full table scan。修復方式是加上 idx_transactions_date index。知識庫文章 KB-042 有完整的 DB slow query 排查 SOP。」
林建宏點開 KB-042，按照 SOP 操作：SSH 進 DB → 看 slow query log → 找到問題 query。
回事件詳情頁 處理紀錄 tab（IN-036 合併後的位置）→ 點 [+ 新增] → 💬 留言 → 寫「找到 slow query，是報表 batch job 的 query 沒有 index。」 → 留言僅在處理紀錄 tab 顯示（不寫 Timeline，避免淹沒系統事件）。
修完後再點 [+ 新增] → 🔧 修復嘗試 → 2 欄快填：📝 描述：新增 idx_report_date index + 🎯 結果：pending（系統自動抓 before 指標）→ 15 秒完成一筆（IN-025 MVP 最小表單）。
狀態從 Acknowledged → In Progress。
MVP 階段 Copilot 仍依賴工程師自己 SSH 查 slow query log。Phase 2 啟用 Graylog API 深度整合後，林建宏可直接在 Copilot 問：
「DB-PROD-01 過去 15 分鐘的 slow query timeout log 有哪些？」
Copilot 會自動：
transactions table，最長 52 秒，疑似缺 index」效果： 工程師不用切換 SSH / Graylog 介面即可完成 log 回溯 — 進一步壓縮 MTTR。本 Journey 主線仍描繪 MVP 工作流。
若林建宏 Ack 後被其他急事打斷（例：凌晨 2:30 電話響起另一起 SEV2），事件 INC-2026-0423 卡在「已確認」狀態：
本次主線為效能事件，但不同類型的事件在調查階段會走不同路徑：
| 事件類型 | 調查方式 | AI Copilot 角色 | 關鍵資料來源 |
|---|---|---|---|
| 效能事件（本次） | 查 slow query log → 找問題 query | 搜尋歷史案例 + 知識庫 SOP | Graylog log + LibreNMS metric |
| 資安事件 | 查設備清單 → 查 log 找惡意活動 | 查 CMDB 設備 + Graylog log | CMDB + Graylog log |
| 硬體故障 | 查 SNMP 狀態 + 硬體健康指標 | 查設備保固 + 歷史故障率 | LibreNMS SNMP + CMDB |
L1 分支說明： 若 AI Agent 仍在 L1 信任等級，系統只顯示「可安全結案」靜態提示，不啟動倒數；林建宏需手動點「Resolve」。本 Journey 假設團隊已信任 L2。
若林建宏加了 index 後 30 分鐘 CPU 仍 95% 沒下降：
🔧 修復嘗試 entry（IN-036 合併後位置），把結果從 pending 改為 failed，時間軸同步記錄結果[+ 新增] → 修復嘗試 → 2 欄表單快填：📝 描述：kill batch job 並重設 DB 連線池 + 🎯 結果：pending（系統自動從 LibreNMS 抓 before CPU 指標 98% 顯示於 entry 展開區，不讓林建宏填）場景：部分指標（例：Graylog）一直沒進入靜默（因為 log agent down 未偵測），但工程師已從另管道（SSH 直接看 DB）確認恢復。
| 事件類型 | 修復方式 | Recovery 訊號 | 結案判定 |
|---|---|---|---|
| 效能事件（本次） | 人工修復（加 index） | LibreNMS recovery alert 自動通知 | 人工確認 Graylog log + LibreNMS metric 皆恢復 |
| 資安事件 | AI 觸發自動化隔離（封 IP） | 被動觀察流量歸零 | 確認威脅消除 + 隔離解除後無復發 |
| 硬體故障 | failover 切換 + 報修換料 | 備機接手，服務恢復 | 新硬體上線 + 監控指標穩定 |
觸發時機在 Resolve 而非 Close — 工程師剛修完問題時現場記憶最鮮明，寫出的知識文章品質最高（對應 PG-04「事件轉知識庫」設計）。
為什麼改非阻擋 toast？ 凌晨值班工程師按「解決」剛要鬆口氣，被「是否加入 KB？」二選一 modal 強迫決策會打斷流程。改 toast 後：草稿自動產生（要寫的人有現成草稿）+ 不點任何按鈕也不影響（不寫的人不被打擾）+ 7 天保留期讓工程師日後可回頭補（不會立刻消失）。
為什麼 Resolve 觸發而不是 Close 觸發？ Close 通常是隔天主管才操作，工程師現場記憶已經退；Resolve 是工程師剛修完的當下，此時記憶最鮮明、細節最完整。
| Stage | 動作 | 模組 | Wireframe 頁面 |
|---|---|---|---|
| 1 | 5 筆警報自動合併 + AI 分類指派 | Incident + AI Native | — |
| 2 | 工程師看 AI 摘要 + Acknowledge | Dashboard + Incident | page-dashboard → page-detail |
| 3 | AI Copilot 查歷史 + 知識庫定位根因 | AI Copilot + Knowledge | page-detail + copilot-panel |
| 4 | 人工修復 + Recovery alert + AI 結案摘要 | Incident + Integration | page-detail |
| 5 | Resolve 當下工程師 draft KB + 主管隔天 Close | Incident + Knowledge | page-detail |
總時間： 40 分鐘（從觸發到解決）
模組參與度： 6 個模組協作完成一次 Incident Response
| 指標 | 使用 Arova 前 | 使用 Arova 後 |
|---|---|---|
| 警報到事件建立 | 15-30 分鐘（手動分類） | < 30 秒（AI 自動合併 + 分類） |
| 找到根因 | 30-120 分鐘（靠經驗翻紀錄） | 5-15 分鐘（AI 建議 + 知識庫 SOP） |
| 寫結案報告 | 15-30 分鐘（手動撰寫） | 0 分鐘（AI 自動產生） |
| 知識沉澱 | 通常跳過（太忙沒時間寫） | 1 分鐘（AI draft + 人工修改） |
| MTTR | 2-4 小時 | 30-60 分鐘 |