Arova Nexus Phase 0
Arova Nexus Phase 0
角色： 陳志豪（IT 主管）+ IT 工程師 + 王美華（合規主管） 場景： P1 事件「核心銀行系統交易延遲」已結案，需要產生 PIR 報告供內部檢討和金管會稽核備查 橫跨模組： Incident → AI Native → Service Desk → Analytics
泰國廠的核心銀行交易系統發生 P1 事件——新上線的報表模組耗盡了 DB 連線池，導致交易系統延遲 90 分鐘，影響超過 12,500 筆交易。事件已由 IT 團隊修復並結案。
金管會規定，所有 P1 事件必須留存事後檢討報告（PIR），供未來稽核備查。以前這份報告要開會討論 + 手動寫 Word，耗時 3-5 天。
P1 事件結案後，系統自動提示：
事件 INC-2026-0325 已結案
↓
系統提示：「此為 P1 事件，是否產生事後檢討報告？」
↓
IT 主管陳志豪點「產生 PIR」
使用者情緒： 🟡 不是強制的彈窗，而是體貼的提醒——P1/P2 事件才會出現
涉及模組： Incident（IN-016）
AI 彙整事件的所有紀錄，自動產生結構化的 PIR 報告：
AI 彙整資料：
• 事件完整時間軸（從建立到結案的每一步）
• 所有留言和討論紀錄
• AI Agent 的分析和建議紀錄
• AI Copilot 對話紀錄中的根因探索過程
• 知識庫中引用的相關文章
↓
30 秒後產生 PIR 報告草稿：
┌─────────────────────────────────────────────────┐
│ 事後檢討報告 (Post-Incident Review) │
│ INC-2026-0325：核心銀行系統交易延遲 │
│ │
│ 1. 事件概述 │
│ 時間：2026-03-25 10:15 - 11:45 (90min) │
│ 嚴重度：P1 (Critical) │
│ 影響範圍：核心交易系統、ATM、網銀 │
│ 受影響交易數：12,500+ 筆 │
│ │
│ 2. 時間軸 │
│ 10:15 - Graylog 偵測應用層 timeout │
│ 10:17 - AI Correlation 判斷為 DB issue │
│ 10:20 - 自動通知 P1 主管 + 工程師 │
│ 10:25 - 工程師確認 DB connection pool │
│ exhaustion │
│ 10:35 - 臨時修復：調整連線數上限 │
│ 10:45 - 系統恢復，所有交易恢復 │
│ 11:45 - 根本原因修復確認，事件結案 │
│ │
│ 3. 根因分析 │
│ 直接根因：新上線的報表模組在背景執行大量 │
│ DB query，耗盡了連線池 │
│ 根本原因：該模組上線前未進行 DB 負載測試 │
│ AI 分析信心度：98% │
│ │
│ 4. 影響評估 │
│ 受影響服務：3 個 │
│ 持續時間：90 分鐘 │
│ 客戶投訴：[待補充] │
│ 業務影響金額：[待補充] │
│ │
│ 5. 處理過程評估 │
│ 警報到通知：2 分鐘（達 SLA ✅） │
│ 回應時間：10 分鐘 │
│ 根因發現：20 分鐘 │
│ 臨時修復：35 分鐘 │
│ 完全解決：90 分鐘 │
│ AI 介入：Correlation Agent 準確識別為 │
│ DB 問題，節省約 15 分鐘分類時間 │
│ │
│ 6. 預防措施建議（AI 產生） │
│ 短期：所有新模組上線前需 DBA 簽核 + 負載測試 │
│ 中期：建立 DB query 自動檢測告警 │
│ 長期：實施連線池動態擴展 │
│ │
│ 7. Action Items │
│ [高] DBA 檢查報表模組 query │
│ Owner: [待指派] Due: [待設定] │
│ [高] 建立新模組上線 checklist │
│ Owner: [待指派] Due: [待設定] │
│ [中] 部署 DB 連線監控告警 │
│ Owner: [待指派] Due: [待設定] │
└─────────────────────────────────────────────────┘
使用者情緒： 🟢 AI 30 秒產生了完整初稿，以前要開會 3 天才寫得出來
涉及模組： AI Native（AIN-024）、Incident（IN-016, IN-017）
IT 主管和工程師 review AI 產生的 PIR
↓
補充 AI 沒有的 context：
• 業務影響金額（財務部門提供：NT$300-500 萬）
• 客戶投訴數和緩和措施（客服提供：8 件）
• 工程團隊的經驗教訓
↓
確認「處理過程評估」中的 AI 貢獻度統計：
• AI 自動分類準確率：100%
• AI 推薦相似案例：2 件
• Copilot 提供的 SOP：KB-087
• AI 加速定位時間節省：約 15 分鐘
↓
指派 Action Items 的 Owner 和 Due Date
↓
過程中隨時可 [儲存草稿]（草稿自動保存，可稍後繼續）
↓
確認內容完整 → 點 [定稿]
↓
┌─────────────────────────────────────────────────┐
│ 簽核 │
│ │
│ ☑ 事件所有人（DBA Lead 李工程師） 2026-04-03 │
│ ☑ IT 主管（陳志豪） 2026-04-03 │
│ │
│ 簽核完成 → PIR 正式存檔 │
└─────────────────────────────────────────────────┘
使用者情緒： 🟢 只需要審查和補充 AI 無法取得的業務資訊，不用從零開始寫。草稿自動保存，不怕中途被打斷
涉及模組： Incident（IN-016）
PIR 報告簽核完成 → 存入系統，關聯到原始事件 INC-2026-0325
↓
陳志豪點「下載 PDF」→ 存檔備查
↓
Action Items 自動建立為追蹤工單：
• TKT-0892 DBA 檢查報表模組 query（Owner: 李工程師, Due: 3/26）
• TKT-0893 建立新模組上線 checklist（Owner: PM 張經理, Due: 4/01）
• TKT-0894 部署 DB 連線監控告警（Owner: SRE 劉組長, Due: 4/15）
責任人自動收到通知
↓
系統提示：「是否將修復方法加入知識庫？」
→ 李工程師點「是」→ AI 根據 PIR 自動 draft 知識文章
→ 下次類似 DB 連線問題，AI 自動推薦這篇文章
↓
合規主管王美華在 Dashboard 可看到：
「3 筆 PIR Action Items 待追蹤」
↓
3 個月後金管會稽核時：
一鍵取出 PIR 報告（PDF）+ 已完成的 Action Items 證據
使用者情緒： 🟢 PIR 不再是寫完就忘的 Word 檔，Action Items 有系統追蹤到完成
涉及模組： Service Desk（SD-001 工單建立）、Dashboard（DB-014）、Analytics（稽核備查）
| Stage | 動作 | 花費時間 | 模組 |
|---|---|---|---|
| 1 | P1 事件結案，系統提示產生 PIR | 即時 | Incident |
| 2 | AI 自動產生 PIR 草稿 | 30 秒 | AI Native + Incident |
| 3 | 人工審查、補充業務資訊、指派 Action Items | 30 分鐘 | Incident |
| 4 | 存檔 + Action Items 自動建立追蹤工單 | 即時 | Service Desk + Dashboard |
| 指標 | 使用 Arova 前 | 使用 Arova 後 |
|---|---|---|
| 報告產生時間 | 手動開會 + 寫 Word 3-5 天 | AI 產生草稿 30 秒 |
| 人工審查時間 | 5 天開會討論 | 30 分鐘 review |
| 報告完整性 | 常遺漏時間軸細節 | 完整時間軸 + AI 分析紀錄 |
| Action Items 追蹤 | Excel 或口頭追蹤，容易遺忘 | 自動建立工單，系統追蹤 |
| 稽核準備時間 | 需翻找 PIR Word 檔 | 系統內一鍵取用 |
| 全程時間 | 3-5 天 | 30 分鐘 |
金融業金管會稽核會逐件審查 P1 事件的 PIR。「AI 一鍵產生 PIR + Action Items 自動追蹤」是省 3-5 天人力的直接 ROI，且確保每個預防措施都被執行到位，不再是「寫完就忘」。與 J11（合規稽核報告）搭配，形成完整的稽核準備體系。