產品指南
事件管理（Incident Management）
Arova Nexus — Phase 0 Product Definition ｜ 2026-03-31

所屬模組： Incident Management（可選）
Wireframe： 開啟互動原型 → 側邊欄「事件管理」

解決什麼問題

系統出事時，IT 人員要同時看監控、查 log、打電話通報、手動記錄。整個過程沒有統一的追蹤，事後也無法回溯「當時到底做了什麼」。MTTR 居高不下。

核心能力

自動建立事件

監控系統（Datadog、Prometheus、LibreNMS、Graylog 等）偵測到異常時，透過 Webhook 自動建立事件。不需要人工抄寫告警資訊。

手動建立事件（IN-002）

事件列表頁標頭提供「+ 建立事件」按鈕，讓 IT Staff / IT Manager / Admin 可手動建立新 Incident（例如同事口頭通報、Webhook 未能偵測的問題、跨系統複合事件）。其他角色（End User / Service Desk Agent / Compliance Officer）隱藏此按鈕。

Modal 5 欄表單：

欄位 類型 必填 預設
標題 文字輸入 ✅ —
描述 多行 textarea ✅ —
嚴重度 dropdown（SEV1-4） — SEV3
影響範圍 多行 textarea — 空
指派給 使用者搜尋 + 「指派給自己」快捷鈕 — 空

提交成功： Modal 關閉 + 跳轉新建事件詳情頁；狀態 = 觸發、source = manual；時間軸記錄「<使用者> 手動建立事件」。

為什麼 5 欄不擴展？ Round 2 審視依「不加原則」嚴守 IN-002 原 AC 的 5 項；不加 host / priority / CMDB 關聯（End User 認知負擔優先；真要指派複雜事件可在詳情頁後續補欄位）。Happy path 只填必填 2 欄 + 點「指派給自己」快捷鈕，10 秒完成建立。

事件佇列

所有活躍事件的清單，預設顯示「指派給我的」未結案事件，按嚴重度排序。工程師登入後直接看到自己的待辦，不用在全部事件中篩選。

篩選 Tab 定義：

Tab 計算方式 說明
指派給我 assignee = 當前使用者 AND status ∉ {已解決, 已結案} 預設 tab，只看自己的待辦
全部 所有事件（含已解決、已結案） 完整列表
未確認 status = 未確認 剛觸發、尚未有人接手
已確認 status = 已確認 工程師已 Acknowledge 但尚未開始調查
調查中 status = 調查中 正在處理中
已解決 status = 已解決 工程師已修復，待主管結案
已結案 status = 已結案 主管已 review 並正式關閉

事件狀態生命週期：未確認 → 已確認（Acknowledge）→ 調查中 → 已解決（Resolve）→ 已結案（Close）

互動行為：點擊任一 tab 時，下方事件列表即時篩選為該 tab 條件的事件。Tab 括號中的數字為即時計數，隨事件狀態變更自動更新。

排序預設依嚴重度（SEV1 > SEV2 > SEV3 > SEV4），同嚴重度依建立時間排序。排序在所有 tab 下一致。

嚴重度分級

四級分類，每級都定義明確的客觀判準（使用者影響 × 業務影響），自動決定回應時間和解決時間 SLA、升級規則與 PIR 觸發：

等級 使用者影響 業務影響 回應時間 解決時間
SEV1 >50% 使用者無法使用；或核心交易中斷 直接營收損失；或合規違規 15 分鐘 4 小時
SEV2 部分功能不可用；或效能明顯劣化 使用者抱怨但可繞行 30 分鐘 8 小時
SEV3 非核心功能異常；或單一使用者受影響 內部營運略受阻 2 小時 2 工作日
SEV4 不影響使用；可排程修復 無立即影響 下一工作日 1 週

判準使用規則： AI Triage Agent 與人工判定時，必須在推理鏈中引用「使用者影響」或「業務影響」至少一條判準作為決策依據。無法對應任一條判準時，信心度標記為 < 0.6 並送人工審核，不得僅憑主觀描述決定嚴重度。

附註（Phase 0 客戶銜接用）：本平台 SEV1SEV4 即業界慣用的 P1P4 事件嚴重度命名（PagerDuty / Atlassian / Google SRE Book 標準）。此附註將於 Phase 1 GA 後 6 個月移除。

SLA 達標率計算（名稱統一為「SLA 達標率」，工單和事件共用同一公式框架，詳見 工單管理）：

告警合併與跨來源語意關聯

兩層合併機制：

  1. 規則合併：5 分鐘內來源和類型相同的告警自動合併，避免告警風暴
  2. AI Correlation Agent：跨來源的語意關聯。例如 Graylog 的 slow query timeout + LibreNMS 的 CPU 飆升 → AI 識別同指一台伺服器（信心度 0.92），建議合併為 1 個事件。信心度 > 0.85 自動合併，0.5~0.85 建立人工審核任務

合併管理與可逆操作（Unmerge）

AI / 規則合併都可能出錯，工程師可在事件詳情頁快速修正避免誤合併延長 MTTR。

存取位置： 合併管理內嵌於事件時間軸的「合併」entry 展開區（不佔獨立 tab，Less is More 實踐）。時間軸上 HH:MM AI Correlation 合併 N 筆警報為此事件 這筆 entry 可點擊展開，展開後即為合併管理內容。

展開內容： 推理鏈 + 拆分 / 移至按鈕 + 原始警報清單（checkbox、ID、來源、Payload 摘要、時間）。單一警報事件的時間軸則無此合併 entry。

拆分動作（IN-018）：

動作 行為
拆出為新事件 checkbox 選 K 筆警報 → 建立新 Incident，K 筆移入新事件；原事件保留剩下 (N−K) 筆；雙方時間軸各記錄拆分動作；新事件自動重跑 AI Triage（嚴重度 / 摘要 / 指派），但不重跑 AI Correlation 避免迴圈
移至其他事件 選 K 筆 + 輸入目標 INC-ID → K 筆警報移至目標；原事件保留剩下；目標事件合併管理區更新；雙方時間軸記錄移入 / 移出
拆空原事件 若原事件全部警報都拆走，事件保留但狀態設為「已結案（merged_out）」並標註「全部警報已拆出」，不刪除事件以保留 audit trail

權限： IT Staff / IT Manager / Admin 可執行拆分；其他角色拆分按鈕隱藏，嘗試存取寫入未授權稽核日誌。

根因 vs 衍生事件標註與人工覆寫

大規模 Alert Storm 時（例如核心交換機故障導致 100 筆警報），Correlation Agent 不只合併警報，還會標註哪個事件是「根因」、哪些是「衍生」。衍生事件自動連結到根因事件。

人工覆寫（IN-019）： AI 標註不保證正確，Alert Storm 列表每條提供右鍵選單：

選項 行為
解除衍生關係 該事件脫離根因連結變為獨立事件；不會被後續批次 resolve 連帶關閉
變更根因為 INC-XXX 所有衍生關係轉移至新根因；原根因可降為衍生或獨立（使用者選擇）
設為根因 若目前是衍生，先解除衍生關係再升級為根因角色（建立空的衍生集合）

所有覆寫動作寫入雙方時間軸與稽核日誌，並計入 AI 回饋訊號（見「合併回饋閉環」）。

批次 Resolve Preview（IN-020）： 根因事件的「批次 resolve 衍生事件」動作 MUST 先顯示 preview dialog：

合併時間軸 Enrichment

時間軸中關於合併的 entry 預設摺疊為一行摘要（例：「02:15 合併 5 筆警報為此事件」）。點擊展開後顯示完整細節（IN-021）：

合併者類型 展開內容
ai_correlation（AI Correlation Agent） 合併者：AI Correlation Agent ・ 信心度：0.XX ・ 推理鏈：時間窗口 / 共同 host / symptom correlation ・ 原始警報清單連結
rule（IN-009 規則引擎） 合併者：規則引擎 ・ 套用規則名稱（例：5 分鐘同來源同類型） ・ 原始警報清單（無信心度欄位）
manual（工程師手動） 合併者：操作人姓名 ・ 操作時間 ・ 手動合併理由（若填寫）

推理鏈超過 500 字摺疊為「查看完整推理」連結，避免時間軸資訊爆炸。

合併回饋閉環

AI Correlation Agent 的合併準確率透過明確定義的回饋訊號持續改進（AIN-011 AC⑤）：

訊號類型 觸發條件
negative 拆分事件（IN-018）、解除衍生關係 / 變更根因 / 設為根因（IN-019）
positive Resolve 未曾被拆分或覆寫的 AI 合併事件

每筆訊號記錄：原合併 ID、信心度、推理鏈、操作人、操作時間，送入 AIN-021 隱式回饋資料流。AIN-025 月度重算信心度門檻時，引用上月累積的 positive / negative 比例；負向回饋率超過設定閾值時建議調升自動合併信心度門檻，並通知管理員審核核准後生效。

Alert Storm 處理

短時間內大量警報湧入（例如核心交換機故障導致上百筆警報）時，系統自動偵測並進入 Storm 模式，啟動更積極的合併策略：

Storm 偵測： 警報頻率超過門檻（預設 >20 筆/分鐘，管理員可調整）時，系統判定為 Alert Storm。

Storm 模式下的處理流程：

  1. 第一層規則合併（IN-009）：同來源、同類型的警報快速合併，粗篩減量
  2. 第二層 AI 關聯（AIN-011）：Correlation Agent 對粗篩後的事件進行跨來源語意分群（按 host / service / network segment），識別根因候選，合併為少數事件（通常 3-5 個），並標註根因 vs 衍生關係

降級策略： 若 AI 服務不可用或過載，自動降級為規則引擎合併（相同 host 歸為同一事件），確保不丟棄任何警報。所有未處理的警報先存入原始紀錄，待恢復後補充分析。

模式恢復： 警報頻率回到門檻以下後，系統自動退出 Storm 模式，恢復正常的 Correlation 處理流程。

AI Triage Agent

新事件建立後，AI Triage Agent 自動分類事件類型、建議嚴重度、智慧指派處理人。指派考慮值班狀態和專長領域（例如「林建宏值班中 + 最多 DB 相關經驗」→ 指派給林建宏）。嚴重度判定必須引用「使用者影響 / 業務影響」客觀判準並寫入推理鏈，判準無法對應時信心度 < 0.6 並送人工審核。準確率目標 > 85%。

自動升級

依嚴重度設定的時間內未 Acknowledge，自動升一級嚴重度。例如 SEV2 事件 30 分鐘內未確認 → 升級為 SEV1、SEV3 → SEV2、SEV4 → SEV3。升級規則可自訂。

SEV1 逾時特殊處理： SEV1 已是最高級無法再升，逾時未 Acknowledge 時改為通知「IT Manager + 另一位值班 IT Staff（備援）」，管理員可覆寫預設通知對象（例如金融業加 CISO、製造業加廠務主管）。

SEV1 通知多通道強制（IN-033）： 凌晨值班 Email 睡過頭機率不低，SEV1 逾時通知 MUST 同時透過至少 2 個通道發送：

SEV2-4 多通道個人偏好 opt-in（IN-039）： 防疲勞邏輯對多數人合理，但深睡值班工程師可能連 SEV2 效能異常警訊都想抓。加個人 opt-in 讓有疑慮者自己選，不強制全員。

AI 摘要 tab 5 段結構（Round 2 簡化）

新事件建立後 30 秒內，AI 自動產出分析摘要。AI 摘要 tab 採 5 段結構（Round 2 從原 7 段簡化）：

# 段落 預設狀態 內容
1 📋 AI 分析 展開 合併摘要 / 可能原因 / 建議行動三個 inline sub-label（[摘要] 一段文字 + [可能原因] 有序列表 + [建議行動] 有序列表）
2 告警關聯 摺疊 合併警報數量、來源、信心度、推理鏈
3 相似歷史事件 摺疊 過去類似 INC 連結與根因
4 相關知識文章 摺疊 AI 推薦的 KB 文章（最多 3 篇，相關度 > 60%）
5 AI 結案摘要 Resolve 後展開 根因 / 修復方式 / 影響 / 受影響服務 / 預防措施 + 資料來源標記

為什麼合併前 3 段？ 原 7 段中「摘要 / 可能原因 / 建議行動」緊密相關，單獨成段各占 section header 視覺負擔。合併為單一「📋 AI 分析」段落（內用 inline sub-label）減少 2 個標題列視覺，對齊 PagerDuty / Atlassian JSM AI 的業界常見 3-4 段格式。摺疊段落各自讀者意圖不同（告警 = 當前結構 / 歷史 = 過去類似 / KB = SOP / 結案 = Resolve 後），不合併以保留可辨識性。

AI 產出邏輯： AI 產出為單一 structured block 含三個 sub-section，rendering 層忠實展示為 inline sub-label；MUST NOT 產出三個獨立 section header 區塊（詳細規格見 IN-011）。

相關知識文章推薦（摺疊段落詳細規格）

AI 摘要產生時同步搜尋知識庫，在「相關知識文章」摺疊段落內顯示相關的 KB 文章（最多 3 篇，相關度 > 60%，按相關度排序）。超過 3 篇可點「更多」展開。無相關文章時顯示「無相關文章」。工程師不需要主動問 Copilot，打開事件就能看到可參考的 SOP 和歷史解法。

相關度計算：向量餘弦相似度（cosine similarity）——將事件摘要和 KB 文件分別轉為 embedding 向量，計算兩者的餘弦相似度 × 100%。門檻 60% 以下不顯示。

AI 摘要 tab 底部提供 Graylog deep link 入口按鈕「🔍 在 Graylog 查看完整 log →」，作為 Round 2 刪除的 Log 分析 tab 的等效替代：

為什麼不做內嵌 Log 分析 tab？ Splunk / Graylog 是專業 log 查詢工具，MVP 做半殘版本雙輸；AI Copilot 對話查 log 更符合 AI Native 定位。完整內嵌 tab 能力留待 Phase 2 依客戶回饋決定是否實作。

依來源類型的 Recovery 判定

不同監控來源的資料語意本質不同，recovery 判定方式也不同：

來源類型 範例 恢復訊號取得 Hysteresis 預設
metric-state LibreNMS（SNMP 指標狀態機） 收到 alert.clear 或等義 state-transition event 3 分鐘
log-event Graylog（log 事件流） 在設定時間窗內無匹配 error log（靜默判定） 10 分鐘
explicit-status 自訂 webhook payload 含 status=recovered 或等義欄位 3 分鐘

為什麼 Graylog 沒有自動 clear event？ Log 是「事件流」不是「狀態」。「不再出現 slow query」只能用 heuristic 推斷，所以採靜默時間窗（預設 10 分鐘內無新觸發就視為恢復）。LibreNMS 是 metric-based，指標回到正常會主動發 clear event，可信度高所以 hysteresis 較短。

Hysteresis 中斷： 若某來源已進入觀察期但尚未完成，期間又收到同主機同指標的 alert，系統 MUST 重置該來源的 recovery 判定為「尚未恢復」，並在時間軸記錄統一格式（§ 3.6）：recovery hysteresis 觀察期中斷 · source: <source> · 因同主機同指標 re-alert。避免因短暫 flap 就結案。

修復嘗試記錄（Fix Attempt · 最小表單 IN-025）

事件詳情頁「處理紀錄」tab 點 [+ 新增] → 修復嘗試 開表單（IN-036）。MVP 採最小填寫負擔設計 — 凌晨 3 點值班工程師只需 15 秒完成一筆。選填，Phase 2 視填寫率評估調整。

MVP 表單僅 2 欄：

欄位 說明
📝 描述 必填 free-text（例：「新增 idx_report_date index」）
🎯 結果 dropdown：pending / success / failed / partial（預設 pending）

為什麼不讓使用者填執行時間 / before / after 指標？

提交行為： 同步寫入兩處

累積紀錄作為 PIR 素材、知識庫沉澱和 Analytics 輸入。

Phase 2 評估機制： MVP 上線滿 3 個月後 PM 檢視填寫率指標：

處理紀錄 tab（合併留言 + 修復嘗試 · IN-036）

事件詳情頁 tabs 結構 MUST 為恰好 3 個：AI 摘要 / Timeline / 處理紀錄（Round 2 簡化：原 Log 分析 tab 已延後 Phase 2，log 深入查詢改由 AI 摘要 tab 底部 Graylog deep link 入口或 AI Copilot 對話吸收）。不再顯示獨立 Comments tab 或獨立「修復嘗試」區 — 兩者合併至處理紀錄 tab。

為什麼合併？ 既有設計留言與修復嘗試是雙入口紀錄 — 工程師記「加了 index」可能寫留言也可能寫修復嘗試，稽核時兩邊都沒記或只記一邊。合併後單一 [+ 新增] 入口選類型，稽核完整性提升。

tab 內容結構（對齊 SD-026 工單溝通 tab 設計）：

元素 規格
佈局 Single thread timeline 樣式，依時間倒序（最新在最上）
類型標 每筆 entry 帶 tag：💬 留言（free-text）/ 🔧 修復嘗試（IN-025 最小表單）
新增入口 單一 [+ 新增] 按鈕 → dropdown menu（留言 / 修復嘗試）；MUST NOT 提供兩個分開按鈕
留言支援 僅內部可見 標示（對齊 SD-007）、附件

Timeline tab 寫入策略（差異）：

設計語言統一： 工單（SD-026）「溝通」tab 與事件（本段）「處理紀錄」tab 採同樣 single thread + 類型標模式。

Email 通知 → 事件詳情深連結 + SEV3/4 一鍵 Acknowledge（IN-037）

事件通知 Email 的「前往 Nexus」按鈕 URL MUST 為事件詳情頁深連結（例：/incidents/INC-2026-0423），不連到 Dashboard 或事件佇列首頁。使用者從 Email 到詳情頁省 2 click（原本要繞 Dashboard → 切佇列 → 點整列）。

未登入瀏覽器行為： 跳登入頁帶 redirect_uri，登入成功後自動 redirect 至事件詳情頁（對齊 OAuth2 standard）。已登入 SSO session 則直達詳情頁。

SEV 分流 — Email 內按鈕：

嚴重度 Email 按鈕 Ack 機制
SEV1 僅「前往 Nexus」深連結 強制進系統看 AI 摘要再 Ack（防盲 Ack 重大事件）
SEV2 僅「前往 Nexus」深連結 同上
SEV3 「前往 Nexus」+ 「✓ Acknowledge」 Token 驗證一鍵 Ack，不需登入
SEV4 同 SEV3 同 SEV3

為什麼 SEV1/2 不給 Email 一鍵 Ack？ 對應 AP-011 ⚠ pre-action 防盲設計思路 — 重大事件 Email 盲 Ack 後工程師可能以為「處理了」就繼續睡，造成 SLA 延誤。強制登入多 5 秒但避免真實風險。若未來客戶堅持，Phase 2 評估 Settings flag「SEV1/2 允許 Email 一鍵 Ack」（本 MVP 不做）。

SEV3/4 一鍵 Ack 執行流程：

  1. Email 內「✓ Acknowledge」按鈕內含 JWT Token（一次性、有效期、沿用 AP-004 機制）
  2. 工程師點擊 → 系統驗證 Token → 完成 Ack（狀態：未確認 → 已確認）
  3. 瀏覽器顯示 acknowledgement 頁：「✓ 已確認 INC-XXX · [前往詳情頁] [關閉]」
  4. 時間軸記錄「HH:MM <工程師> 透過 Email 一鍵 Acknowledge · 裝置：<mobile/desktop>」
  5. 若需調查，工程師按 [前往詳情頁] 進系統；若只想 Ack 先繼續睡，關閉分頁即可

Token 過期 fallback（與 AP-009 不同）：

行動裝置 RWD： Email 按鈕觸控區 ≥ 48px 高度（對齊 AP-011 標準），防相鄰「前往 Nexus」與「✓ Acknowledge」誤觸。

Recovery Readiness Score（主文三態文案 · IN-023）

事件詳情頁 Recovery 區塊主文為三態語意文字，讓工程師不用學加權公式就能判斷能否 Resolve。百分比 demote 為輔助資訊（hover tooltip / 小字），保留給 Analytics / Phase 2 自動化機制引用。

三態主文：

條件 主文 顏色
全來源 recovered ✓ 可安全結案 綠色大字
任一 observing 且無 not_recovered ⏳ 觀察中（剩 N min） 黃色大字
任一 not_recovered ✗ 尚未恢復 灰色大字

「剩 N min」= 所有 observing 來源中最長的剩餘時間（最保守估計；例：LibreNMS 剩 2 min、Graylog 剩 8 min → 顯示 剩 8 min）

演算法（後端不變）： Score = Σ(來源狀態得分 × weight) / Σ(weight) × 100%

UX 視覺化： 事件詳情頁 Recovery 區塊呈現（主從順序調整後）：

為什麼把主從顛倒？ 既有設計主文是百分比進度條，但工程師真實使用中只想知道「能不能 Resolve」這個二進位問題 — 看「75% 黃條」得先知道加權公式、閾值門檻才能判讀，認知負擔過重。三態文字直接給答案。

長時間低分警示（IN-026）： 事件狀態為 In Progress 且 Readiness Score 連續 30 分鐘 < 50%（閾值可調），系統主動顯示警示卡「Readiness Score 連續 30 分鐘 < 50%，修復可能未生效，建議轉派或請支援」，並提供快捷按鈕：「轉派給 ...」、「通知 IT Manager」、「標記最近修復嘗試為 failed」。時間軸記錄「低分警示觸發 at HH:MM」。

倒數自動 Resolve

在 AI Agent 信任等級為 L2 時，Readiness Score 達閾值（預設 90%）且事件狀態 ≥ 已確認後，系統自動啟動倒數計時，結束後自動 Resolve：

項目 規格
啟用條件 AI Agent L2 + Readiness Score 達閾值 + 事件狀態 ≥ 已確認
倒數時長 預設 10 分鐘，可調 5-30 分鐘
期間可取消 「取消自動結案」按鈕 → 停止倒數、保留當前狀態
期間可立即結案 「立即 Resolve」按鈕 → 直接 Resolve
30 秒通知 站內 + Email（給 assignee）
結束行為 自動 Resolve；時間軸記錄「auto-resolved after N min recovery window（Recovery Agent）」
結案摘要 AI 產生並標註「自動產生」
嚴重度限制 管理員可依嚴重度啟用 / 停用（例：SEV1 不自動、SEV2~4 自動）

為什麼只在 L2 啟用？ 符合 Arova「漸進式信任委派」產品定位（L0 觀察 → L1 通知 → L2 輔助），L2 定義為「高信心度自動執行」，auto-resolve 是此定義的自然延伸。L0 / L1 僅顯示靜態「可安全結案」提示，等待使用者手動 Resolve。

低分手動 Resolve 二次確認（IN-027）： 使用者手動點 Resolve 時若 Readiness Score < 80%，系統強制彈出二次確認 modal：列出未恢復或觀察中的來源名稱與狀態；使用者必須填寫「強制 Resolve 理由」才可繼續。取消則保留原狀態；確認後 Resolve 但時間軸記錄「強制 Resolve（Score=N%），理由：<填寫內容>」，稽核日誌同步留存。

Auto-reopen 觀察期

Auto-resolve 後的觀察期內，若同根因再次觸發，系統自動 reopen 原事件而非建立新事件：

嚴重度 觀察期預設
SEV1 60 分鐘
SEV2 30 分鐘
SEV3 / SEV4 15 分鐘

Reopen 條件： host + service + 同類 symptom 三者匹配才 reopen；跨 root cause 的新警報建立新事件。Reopen 時新警報併入原事件合併管理區。觀察期外再觸發則建立新事件，新事件 AI 摘要引用原事件作為「相似歷史事件」。

時間軸 entry 統一格式（§ 3.6）： auto-reopened · Recovery 觀察期內同根因再觸發 · host: <host> · symptom: <symptom> — 含 host / symptom metadata 讓稽核員不需再翻合併管理頁。

與 IN-010 自動升級的協調

自動升級（IN-010）與倒數自動 Resolve（IN-022）作用於事件生命週期的不同階段，透過狀態 gate 區分：

事件狀態 適用的自動化
未確認（New） ✅ 自動升級（IN-010）／ ❌ auto-resolve 倒數
已確認 / 調查中 / 已解決 ❌ 自動升級／ ✅ auto-resolve 倒數候選（若 Readiness Score 達閾值）

避免同一事件既被升級又被 auto-resolve 造成邏輯衝突。

Progress SLA 與 Investigation Stall

IN-010 自動升級只監控「未 Ack」階段；Ack 後若工程師卡住、離場、睡著，沒有機制察覺會造成事件擱置。Progress SLA（IN-028）補足此缺口：

Progress SLA 預設值（Ack 後至 In Progress）：

嚴重度 Progress SLA
SEV1 15 分鐘
SEV2 30 分鐘
SEV3 1 小時
SEV4 下工作日

逾時處理： 逾時 → 發通知給 assignee + IT Manager；SEV1 同時通知備援 IT Staff（與 SEV1 回應逾時通知對象一致）。同一事件在 Progress SLA 內只通知一次避免疲勞。

Investigation Stall 自動 reassign 建議（IN-029）： 狀態停留同一階段超過 Progress SLA 2x（SEV1 30 min / SEV2 1 hr / SEV3 2 hr / SEV4 隔工作日）→ 事件詳情頁顯示 reassign 建議卡，通知 IT Manager「一鍵核准 reassign 至備援」按鈕。

核准流程： Manager 點「核准」→ assignee 變更為預設備援 IT Staff（由 Manager 事先在 Shift / On-call 設定指派）→ 新 assignee 收到通知 → 時間軸記錄「Manager <姓名> 核准 reassign：原 <舊> → 新 <新>，理由：Investigation Stall」。無 Manager 核准時系統不自動 reassign，確保人事決策由人做。

誤報回溯機制

IN-005 支援誤報關閉，但被判誤報的警報若短期再觸發原本會建立新事件，缺乏 context。本段補足（IN-030 + IN-031）：

24 小時 Auto-reopen： 誤報關閉後 24 小時內（統一不依嚴重度差異化，與 Recovery auto-reopen 區分）收到同 host / service / 同類 symptom 的新警報 → auto-reopen 原事件；事件詳情頁顯示「誤報判定可疑」紅色標籤。時間軸 entry 統一格式（§ 3.6）： auto-reopened · 誤報 24 hr 內再觸發（判定可疑） · host: <host> · symptom: <symptom> — 與 IN-024 Recovery auto-reopen 對齊，prefix（Recovery / 誤報）區分觸發規則。24 hr 外再觸發建立新事件，新事件 AI 摘要引用原事件作為「相似歷史事件（曾被判誤報）」但不標可疑。

Pattern 偵測： 某 host / service / symptom 組合在 7 天內被誤報關閉 ≥ 3 次 → Triage Agent 對該 pattern 的自動分類信心度降級（預設 -0.2，下限 0.3）→ 通知 IT Manager：「此 pattern 近 7 天誤報 N 次，建議檢查監控門檻 / 告警規則」。該 pattern 連續 14 天無誤報 → 信心度自動恢復至降級前水準，時間軸與稽核日誌記錄。

Analytics 指標： 報表新增「誤報率」（誤報事件數 / 總事件數）、「誤報後再觸發率」（24 hr 內再觸發誤報 / 誤報總數），可依嚴重度 / 來源 / 時間範圍篩選。

AI 結案摘要

事件 Resolve 時，AI 自動產生結案摘要，包含：事件根因、修復方式、影響時間、受影響服務、建議預防措施。主管 review 後可直接 Close，不需要工程師手動撰寫結案報告。

資料來源引用（IN-032）： 每條敘述 MUST 附資料來源標記，讓稽核與使用者能追溯 AI 摘要內容的事實基礎，避免 AI 幻覺被當事實採納：

標記 含意 點擊展開顯示
[CMDB] 來自資產關聯資料庫 關聯實體清單與屬性
[Graylog: <query>] 來自 log 查詢 查詢結果前 3 筆 log + 完整 query 連結
[LibreNMS: <metric>] 來自監控指標 指標時段折線圖
[Incident timeline] 來自本事件時間軸 對應時間軸 entry 連結
[AI 推論] AI 綜合多來源推論，無單一直接資料源 推理鏈（列出參考的多個來源）
[來源暫不可用] 摘要產生時該來源暫不可用 失效原因與稽核連結

展開形式： Inline popover（不彈 modal 避免中斷閱讀，Less is More 實踐）。

稽核留存： 稽核日誌 MUST 完整留存每次摘要引用的資料源 ID（CMDB entity ID 清單 / Graylog query hash / metric time range）。

Resolve / Close 兩步結案

工程師 Resolve（問題已修復）→ 主管 Review AI 結案摘要 → Close（正式結案）。兩步分離確保主管有機會 review 事件處理品質。

批次結案（主管專用 · IN-038）

主管隔天進佇列可能累積 5-10 筆「已解決」待 Close；日常結案多數是「看一眼 AI 摘要沒問題 → 放行」的例行動作。個別點進詳情頁的 click 稅是無意義負擔。批次結案直接搬既有 AP-007 / IN-020 模式，省主管每日 3-6 分鐘。

勾選 UI（限主管 / Admin 可見）：

Sticky Toolbar（對齊 AP-010）：

勾選 ≥ 1 筆後頁面底部浮出：

✓ 已選 N 筆  [批次結案] [取消選取]

無「批次重新打開」（低頻動作，詳情頁個別處理）。無「批次退回」（已解決往回是 re-open，不是 reject）。

Confirm Preview Modal（對齊 AP-007 + IN-020）：

點「批次結案」彈出 preview，列出每筆待結案事件：

即將批次結案 6 筆：

☑ INC-2026-0423 · SEV2 · DB 效能 · ✓ 常規 · AI 結案：索引缺失已修復
☑ INC-2026-0424 · SEV3 · 備份任務失敗 · ✓ 常規 · AI 結案：磁碟空間已擴容
☑ INC-2026-0425 · SEV1 · 防火牆 Deny · ⚠ SEV1 · 建議確認是否需要 PIR review
☑ INC-2026-0426 · SEV3 · DB 觀察 · ⚠ Score 65% · 強制 Resolve 過，建議再檢視
☑ INC-2026-0427 · SEV4 · 日誌清理 · ✓ 常規 · AI 結案：磁碟已回收
☑ INC-2026-0428 · SEV2 · 備份回報 · ✓ 常規 · AI 結案：備份成功

[確認結案 6 筆] [取消]

風險標籤 3 類：

標籤 顏色 條件 行為
✓ 常規 綠 SEV2-4 + 正常 Resolve（Score ≥ 80%） 無警示
⚠ SEV1 黃底 SEV1 事件 顯示「建議確認是否需要 PIR review」（不阻擋）
⚠ Score N% 黃底 強制 Resolve（IN-027 Score < 80%） 顯示「強制 Resolve 過，建議再檢視」（不阻擋）

為什麼 SEV1 允許批次？ 不排除是因為 SEV1 月均 1-3 筆稀少，批次對總量影響小；黃底警示 + PIR 自動提示雙重保障「主管不會草率放行」。若主管確實想單獨深看 SEV1，uncheck 移除即可；若例行結案（例：PIR 已走完只缺最後 close），保留勾選省 click。完整選擇權留給主管，系統不代替決策。

為什麼預設全選？ 對齊 IN-020 批次 resolve 衍生 + AP-007 批次核准的一致模式 — 批次 = 多數動作相同 + 少數例外，全選 + uncheck 比反向「全不選 + check」快。

執行行為（稽核雙向引用）：

批次結案寫入兩層稽核 entry，對齊 AP-007：

Layer 內容
批次操作 entry batch ID / 主管 / 時間 / 批次大小 N / 事件 ID 清單
每筆事件時間軸 entry 「HH:MM <主管> 批次結案（batch: BATCH-YYYYMMDD-NNN）」反向引用

稽核員可雙向追溯：batch ID → 涉及事件；事件 ID → 是否批次的一部分。

PIR 觸發承 IN-016：

批次上限： 預設 20 筆（Admin 可調 5-50，硬上限 50 防 UI 卡頓）。超過上限時第 21 筆勾選跳 toast「批次上限 20，建議分次處理」。

不支援批次：

事後檢討報告（PIR · 輕量化流程 IN-016）

PIR 是 Incident 解決後的深度回顧。Round 2 對既有設計做兩項輕量化：SEV 分流提示 + 預設單簽。

SEV 分流提示（新）：

嚴重度 結案後行為
SEV1 自動提示「是否產生事後檢討報告？」（維持既有）
SEV2 不主動提示 — 詳情頁 overflow menu 保留「產生 PIR」按鈕供主管主動觸發
SEV3 / SEV4 沿用既有（不提示）；overflow menu 仍可觸發

為什麼 SEV2 退為 optional？ SEV2 事件量遠大於 SEV1（中型客戶月均 SEV2 10-30 筆 vs SEV1 1-3 筆），每筆都跳提示 → 主管通知疲勞 → 真正需要 PIR 的 SEV2（復發、影響大、政治敏感）反而被無腦關掉。改成主動觸發後，被觸發的 SEV2 PIR 使用率期望 > 60%（因為主動選擇）。SEV2 PIR 能力不消失，只退為主管按需觸發。

Phase 2 評估： MVP 上線 3 個月後 PM 檢視 SEV2 PIR 主動觸發率 — 觸發率 > 40% 評估恢復自動提示；< 10% 確認 optional 決策正確。

AI 彙整事件的完整時間軸、留言紀錄、AI Agent 分析、Copilot 對話紀錄、引用的知識庫文章和關聯的外部工單，30 秒內產生結構化的 PIR 草稿。

報告結構（7 個章節，合規結構不動）：

  1. 事件概述（標題、受影響範圍、業務影響）
  2. 完整時間軸（檢測 → 升級 → 處理 → 解決）
  3. 根因分析（主要原因 + 次要因素）
  4. 影響評估（受影響使用者數、停機時間、業務損失）
  5. 處理過程評估（動作效率 + AI 貢獻度統計）
  6. 預防措施建議（AI 生成 + 工程師補充）
  7. Action Items（指派責任人 + 完成期限）

AI 貢獻度統計： 在處理過程評估中，系統自動統計 AI 在該事件中的貢獻——分類準確率、推薦的相似案例數、KB 文章命中、Copilot 協助定位的時間節省估算。這些數據幫助主管量化 AI 的價值。

PIR 編輯器視覺精簡（Round 2）： PIR 編輯器採表單式（非 wizard 式）視覺：

編輯與定稿： AI 草稿產生後，工程師可編輯各欄位、調整根因分析、新增或修改 Action Items。支援「儲存草稿」（草稿自動保存，可稍後繼續）和「定稿」兩種操作。

簽核：預設單簽 by 主管 + Admin 雙簽 flag（新）

PIR 本意是主管 review 事件處理品質 — Owner（工程師）補完根因、Action Items 是提供素材，不需要簽名背書。MVP 預設流程：

階段 行為
AI 產生草稿 主管觸發（SEV1 自動提示 / SEV2 主動觸發）
Owner 編輯補完 工程師編輯根因、Action Items；每次編輯寫稽核日誌
定稿 狀態變「待主管 review」
主管簽核 單一動作 — 主管打勾後 PIR 正式存檔

責任歸屬： 主管簽 = 認可此版本全部內容（含 Owner 編輯）。若事後發現事實錯誤，由主管承擔 review 責任；Owner 編輯動作仍可稽核追溯。

Admin 雙簽 flag（金融業合規）：

為什麼放在事件管理而非 approval-engine？ PIR 簽核是 Incident-specific metadata 配置；通用簽核引擎針對工單 / 變更 / 帳號。分開管避免混淆。

匯出： PIR 可轉換為 PDF 下載，供合規歸檔和稽核備查。

Action Items 追蹤： 定稿後，Action Items 自動建立為追蹤工單，標題、優先度、責任人、期限從 PIR 帶入，責任人收到通知。確保每個預防措施都被執行。PIR 關聯到原始事件，稽核時一鍵取用。

錯誤處理： AI 生成失敗時，系統提供空白結構化模板引導手動填寫。資料不完整時（如缺留言紀錄），AI 標記缺口並警告，仍產生報告但標示不完整區域。

事件轉知識庫（非阻擋 Toast，IN-006/017）

事件 Resolve 時，AI 背景自動產生知識庫草稿（含事件摘要、修復步驟、相關 error code），不再彈阻擋 modal 強迫工程師決策。右下角顯示 5 秒 toast：

✅ 已解決 · AI 已起草 KB 文章 [檢視草稿] [略過]

觸發時機選在 Resolve 而非 Close，因為工程師剛修完問題時記憶最鮮明，寫出的知識文章品質最高。SEV1/SEV2 事件另有 PIR 定稿後的知識庫存入（根因分析型），兩者互補；KB 草稿（修復方法）與 PIR（根因分析）不互斥。

為什麼改非阻擋？ 凌晨值班工程師按「解決」剛要鬆口氣，被「是否加入 KB？」二選一強迫決策會打斷流程。實際情況工程師可能想「先結案、KB 之後寫」，非阻擋 toast 兩者兼顧（自動產 draft，要寫的人有草稿可用，不寫的人不被打擾）。

標頭動作按鈕情境化（IN-034）

事件詳情頁標頭的動作按鈕依事件狀態 + 角色 + 衍生關係決定主動作（顯眼）與次動作（overflow ⋯ menu），同時最多 2~3 個主動作避免凌晨疲勞誤點：

事件狀態 主動作（顯眼） overflow ⋯
未確認 [確認] 升級 / 誤報關閉
已確認 / 調查中 [解決] [+ 修復嘗試] 升級 / 轉派
已解決（主管專屬） [結案] 產生 PIR / 重新打開
已解決（非主管） （無主動作） 重新打開（限工程師判斷修復失敗）
已結案 （無主動作） 產生 PIR（限 SEV1/SEV2 且未產過 PIR 時）
根因 + 有衍生 額外 [批次解決衍生] —

主動轉派 vs IN-029 自動轉派： 主動轉派是工程師當下意識到「此事件不是我專長」，可直接從 overflow 觸發；IN-029 是系統偵測 Investigation Stall 後 IT Manager 一鍵核准 reassign。兩者並存互補。

重新打開的限制： 僅「已解決」可 reopen（修復實際失敗時用）；「已結案」MUST NOT 提供（主管已正式定案，需新建關聯事件並引用原事件作「相似歷史事件」）。

Next Action 提示橫幅（IN-035 · 含 SLA hover tooltip）

事件詳情頁標頭下方一行依狀態文案的「下一步」提示，幫助凌晨值班工程師或新人快速判斷。Hover banner 顯示 tooltip 貫穿 Response / Progress / Stall 三個 SLA 時鐘接力邏輯（§ 3.2 統一）：

狀態 文案
未確認 ⏭️ 點「確認」開始處理（已過 N min / Response SLA M min）
已確認 ⏭️ 開始調查根因（Progress SLA 剩 N min）
調查中 ⏭️ 修復後記錄結果（Progress SLA 剩 N min · Recovery Score 目標 100%）
已解決（主管） ⏭️ Review AI 結案摘要後點「結案」
已結案 （不顯示橫幅）

原「調查中」缺 Progress SLA countdown 的 gap 補齊：工程師 In Progress 時仍能看到 SLA 剩餘時間，不用跳其他頁查。

視覺樣式（Round 2 簡化：inline 輕量 · 非 card）：

為什麼改 inline？ 目標客戶 60% 資深 + 40% 初階（J20 王工程場景）。全寬 card 樣式對熟手是視覺負擔，但初階需要 banner 價值。Inline + 灰階降對比讓熟手掃過去不干擾、初階仍可見；SLA 色階保留讓所有人一眼看到超時警訊。

警示色階（SLA countdown 片段）：

Hover tooltip 顯示 SLA 細節（新增）：

當前 SLA 類型：<Response / Progress>
起算時間：<建立 / Ack> YYYY-MM-DD HH:MM
剩餘：N min（或已超時 M min）
逾時 2x 將觸發 Investigation Stall（reassign 建議 · IN-029）

為什麼補 tooltip？ 三個 SLA 時鐘（IN-010 Response 升級 / IN-028 Progress / IN-029 Stall 2x 觸發 reassign）在不同狀態接力，工程師看到數字跳動不知從何起算。Tooltip 一次講清來龍去脈，熟手掃一眼即懂。

為什麼不加 Stall pre-warn 色階（1.5x 橘色）？ 過度設計；超時後 banner 已紅色警示，Stall 觸發時另有 reassign 建議卡（IN-029）是明確視覺信號，不需 banner 再加新色。

文案語氣選指令式（「點...」）而非建議式（「建議：先...」）： 凌晨值班疲勞下明確指令降低判斷成本；熟手不喜歡可在個人偏好設定關閉。

關聯管理

事件可以關聯相關的工單。事件解決時，可一鍵批次處理所有關聯工單。

關聯 KB sidebar（IN-041）

事件詳情頁右側 sidebar 新增「📚 關聯 KB」卡片，統一呈現事件的兩類 KB 資產。互補不合併 — 兩類讀者、時機、深度皆不同。

sidebar 位置（從上到下）： Progress SLA → 🔧 修復嘗試 → 🟢 Readiness Score → 📚 關聯 KB

兩類 KB：

類型 icon 色系 來源 讀者 時機
📘 修復方法 藍 IN-006/017 Resolve 時 AI 產的草稿 工程師 下次遇類似事件當下（5 分鐘內要用）
📗 根因分析 綠 IN-016 PIR 定稿後存入 KB 主管 / SRE / 架構師 季度 review / 預防規劃

狀態 badge：

呈現範例：

📚 關聯 KB (2)
├ 📘 修復方法  已發布
│  KB-058 DB slow query 排查 SOP
├ 📗 根因分析  草稿
│  來自 PIR INC-2026-0423（尚未定稿）
[+ 新增關聯]   [檢視全部]

互動：

空狀態（無關聯 KB）：

📚 關聯 KB (0)
暫無關聯 KB
解決事件時 AI 會自動產草稿
[+ 新增關聯]

自動更新：

為什麼不合併兩類 KB？

事件調查過程中發現需要建立新工單時（例：需要申請變更、需要使用者端驗證、需要追蹤後續個案），可從事件詳情頁 overflow ⋯ menu 點「建立關聯工單」快速建單。採 create-related 模式（新建 + 雙向 link），非 convert（原事件狀態不變）。對稱於工單側 SD-027「升級為 Incident」的 escalate-and-link。

權限與可見性：

Quick-Create Dialog：

點擊後彈出 quick-create form，預填：

欄位 預設值 可編輯
標題 事件標題 ✅
描述 事件 AI 摘要一句 ✅
工單類型 Request（可選 Change） ✅ 必選
優先級 SEV1/2 → 高；SEV3 → 中；SEV4 → 低 ✅ 可覆寫

兩按鈕：[建立並關聯] [取消]

執行行為（atomic）：

  1. 新工單建立，source = related_from_incident，source_incident_id = <事件 ID>
  2. 自動走 IN-013 雙向關聯機制
  3. 工單 assignee 由 Triage Agent（AIN-013）自動分派
  4. 原事件狀態 MUST NOT 變更
  5. 雙方時間軸：
    • 事件側：「建立關聯工單 REQ-XXX (<類型>) by 」
    • 工單側：「由事件 INC-YYY 建立 at HH:MM」
  6. 工單 assignee 收通知「新工單 REQ-XXX 由事件 INC-YYY 建立」

與 IN-013 差異：

操作 入口 Dialog 內容 結果
IN-013 關聯既有工單 事件詳情頁側邊 搜尋既有工單 ID / 標題 既有工單被 link
IN-040 建立關聯工單 事件詳情頁 overflow menu Quick-create form 新工單建立 + link

兩者互補：已有工單 → IN-013；沒有工單需要建 → IN-040。

建立的工單 resolve 不影響原事件： 工單與事件各自獨立生命週期。事件側「關聯工單」區可查看工單狀態；事件 resolve 時可走 IN-014 批次處理關聯工單。

ITSM 正規化雙向對稱：

方向 動作 原 record 狀態 新 record 關係
工單 → 事件 Escalate（SD-027） 變「已升級」，SLA 停止 新事件 雙向 link
事件 → 工單 Create Related（IN-040） 不變 新工單 雙向 link

兩者皆非 true conversion（對齊 ITIL v4 / AIOps 原則，詳見 PG-00 術語表）。

使用者場景

凌晨 2:00，防火牆偵測到大量 Deny 流量，透過 Webhook 自動建立 SEV1 事件。
AI 在 30 秒內產出摘要：「來源 IP 集中於 10.20.30.0/24，疑似內部設備感染。建議排查該網段。」
值班人員小李的手機收到通知，打開 Nexus 確認事件。
在 AI Copilot 問：「這個網段有哪些設備？」AI 查 CMDB 回答。
找到感染設備，執行隔離。標記事件為「已解決」。
隔天寫事後回顧，存入知識庫。

版本規劃

版本 功能
v0.1 MVP 事件 CRUD + Webhook 接收 + AI 摘要 + 告警合併 + 自動升級
v0.2 工單關聯 + 批次處理
v0.3 AI Incident Correlation Agent（語意關聯）
v1.0 影響分析（CMDB 拓撲）+ 事後回顧存入知識庫
← 上一篇工單管理（Service Desk） 下一篇 →自動化（Automation Platform）