開啟 3 天免費試用
註冊即可免費體驗全部高級功能。
*只限新用戶；每位用戶只可獲得一次試用。
如何用 AI 編寫故障排查決策樹，讓每個分支都有證據和停止條件
Olivia Park
2026年9月4日· 9 分鐘讀完
要編寫可靠的 AI 故障排查決策樹，先凍結已驗證的 expected/actual、影響範圍和系統邊界，再把可觀察訊號變成互相可區分的分支。每個節點都要定義低風險檢查、允許答案、下一節點、所需權限、證據，以及停止、回退或升級條件。AI 可以整理結構和發現缺口，但不能提供系統事實或批准高風險操作。
通用證據與審批邊界可參考實用 AI 指南。如果連問題描述都不穩定，先把報告轉成可重現步驟。
關鍵要點
- 從預期行為、實際證據、影響、時間窗和系統邊界開始。
- 只問操作人員能觀察或測量的問題。
- 同級分支應可區分，並列出全部允許答案。
- 先執行唯讀、低風險檢查，再考慮狀態變更或廣泛收集。
- 每個節點記錄權限、副作用、證據、停止、回退和升級規則。
- 拒絕循環、死路、缺失終態和無人負責的高風險操作。
- 發佈前以脫敏歷史案例或完全合成案例冷跑。
甚麼讓故障排查決策樹值得信任？
故障排查樹是一系列受控、建基於證據的問題和操作，用來把已知症狀縮窄至安全的下一步，並不承諾找出所有 root cause。Google SRE 把排障描述為結合系統知識觀察狀態、提出假設，再以能證實或反駁假設的測試反覆收斂。［1］
這棵樹只能與系統真源一樣可靠。通用 AI 知識可以提出類別，但目前架構、runbook、遙測定義、owner、權限和回退步驟必須來自系統記錄。「資料庫大概過載」不可觀察；「指定佇列指標在規定時間窗是否高於獲批事故門檻」才可作為節點。
| 節點欄位 | 必須回答的問題 |
|---|---|
| Node ID | 如何不依賴標題文字穩定引用節點？ |
| 可觀察問題 | 操作人員可直接檢查甚麼事實？ |
| 允許答案 | 哪些結果完整而且彼此可區分？ |
| 低風險檢查 | 如何安全取得答案？ |
| 下一節點 | 每個答案分別去哪裏？ |
| 權限 | 哪個角色可運行檢查或操作？ |
| 副作用 | 哪些狀態、負載、資料或用戶體驗會改變？ |
| 證據 | 必須記錄甚麼時間、範圍和結果？ |
| 停止條件 | 何時必須停止自助排查？ |
| 回退條件 | 哪項變更由誰如何撤銷並驗證？ |
| 升級條件 | 把哪些證據以甚麼緊急程度交給誰？ |
決策樹與AI 根因分析不同：前者在當前排障中選擇下一條診斷路徑；後者在證據充分後解釋促成因素和預防措施。
步驟 1：凍結問題陳述與安全邊界
問題報告應包含預期行為、實際行為、可用的重現證據、受影響群體、首次和最近時間，以及相關變更。Google SRE 亦建議有效報告說明 expected、actual 和條件許可時的 reproduction。［1］
Tree ID: file-upload-timeout-v1
受眾：staging 前線支援
預期：獲批測試檔案在規定 timeout 內完成
實際：合成測試上載返回 timeout marker
範圍：只限 staging upload service；無正式環境權限
證據來源：獲批 dashboard、request ID、deployment record
允許檢查：唯讀狀態與有界合成重試
禁止操作：正式環境重啟、資料庫寫入、權限變更
升級 owner：upload-service on-call
回退 owner：release operator
技術覆核：Kevin Wu
先分流，再診斷。若可能發生資料破壞、安全事件、大範圍中斷或失控變更，第一個分支應停止自助流程並進入事故應變。Google SRE 強調重大事件中先穩定服務、保留證據，再深入追查 root cause。［1］
不要把憑證、私隱日誌、客戶記錄或未脫敏事故詳情放進 AI 提示詞。使用脫敏系統圖和合成案例；必須分析日誌時，採用安全 AI 日誌分析流程。
步驟 2：收集系統真源並列出候選訊號
收集目前架構圖、組件 owner、已知失敗模式、指標定義、批准命令、依賴狀態來源和恢復程序，記錄 revision 和覆核日期。兩份文件衝突時，停止並由 owner 指定真源。
只有提供獲批 source packet 後，才讓 AI 整理候選訊號。每個建議必須引用 source ID，否則標為 unsupported 並刪除，不能把不獲支援的技術事實轉成分支。
有用訊號必須可觀察且能區分路徑，例如請求是否到達規定邊界、回應碼屬哪個合約類別、依賴健康訊號是否 healthy/unhealthy/stale/unavailable、配置 revision 是否匹配、症狀能否在隔離環境重現，以及影響一名用戶、一個版本還是廣泛區域。
「網絡似乎不好」屬於意見，應改成有定義和時間窗的觀察。AI confidence、情緒或猜測原因都不能作條件，操作人員必須能在不相信模型直覺的情況下給出答案。
步驟 3：用 AI 編寫故障排查決策樹的可區分節點
優先使用資訊量高、風險低的問題清晰分割範圍，例如單一帳戶還是多數帳戶、單一客戶端版本還是所有版本、單環境還是多環境。幾乎全部案例都走同一邊的節點價值有限。
證據可能不可用，不要強行使用 yes/no：
| 節點 | 問題 | 允許答案 | 下一步 |
|---|---|---|---|
| N10 | 獲批健康訊號對目前時間窗是否有效？ | healthy / unhealthy / stale / unavailable | N20 / E90 / N11 / E91 |
| N11 | 能否用指定唯讀檢查刷新訊號？ | refreshed / permission denied / source failed | N10 / E92 / E93 |
| N20 | 有界合成請求能否在 staging 重現？ | yes / no / inconclusive / not authorized | N30 / N40 / E94 / E95 |
每個答案都必須有目的地。「其他」通常應前往收集證據或升級，不能成為任由 AI 解讀的文字框。同級答案可以同時為真時，要改成帶優先次序的多選，或拆成順序節點。
可讓 AI 檢查答案重疊、術語未定義、觀測不可用和只重複症狀的分支，但不能讓它發明門檻；門檻必須由系統 owner 提供。
步驟 4：綁定安全檢查、權限與證據
每個問題都要指定最少侵入的獲批檢查。優先讀取已有健康資料、配置、版本和 trace，不先重啟組件或產生負載。查詢必須限制環境、時間、對象、結果大小和 timeout。
NIST SSDF 圍繞清晰角色、流程、記錄和安全回應組織軟件實踐。［3］ 決策樹不因此成為 SSDF 實現，但相同紀律可防止臨時診斷變成未經 review 的高權限操作。
Check ID: C20
命令或 UI 來源：approved runbook section 4.2
環境：staging only
權限：support-readonly
輸入：synthetic request ID 與 15-minute window
副作用：dashboard query only
證據：status、source timestamp、query scope
逾時／結果上限：已記錄的數值
停止：permission denied、stale source 或 unexpected schema
升級：附 node ID 和 evidence references 交給 service owner
Permission denied 是證據，不是尋找繞過方法的提示。不能建議借用憑證、關閉控制、擴大查詢或反覆進行高成本測試。破壞性清理、正式環境實驗、權限變更和不可逆 migration 應移出自助樹。
節點若有可逆變更，還要定義獲授權 owner、前置條件、回退操作、成功訊號和最長觀察窗。「有需要便回退」沒有觸發器和驗證，仍然不完整。
步驟 5：定義決策樹終態與升級證據包
每條路徑應結束於少數明確終態：已解決並驗證；有 owner 和到期日的臨時 workaround；繼續可能擴大損害而停止；由授權人執行並驗證 rollback；攜完整證據升級；或先收集具名缺失證據。
除非證據支援因果關係，否則不能寫「已找到根因」。決策樹經常只能定位失敗邊界或下一位 owner，這已足夠恢復服務或升級。詳細因果分析可留待事後進行。
升級包包括 tree/node revision、問題、影響、時間、所走路徑、觀察結果、證據引用、已嘗試操作、副作用、目前狀態、未知項和緊急程度，並刪除秘密和無必要個人資料。
美國 EPA 的 SOP 指引把受控程序視為文件化操作，而不是臨場知識。［4］ 決策樹可補充完整 SOP，但複雜操作應連結 owner 批准的程序，不能複製出另一份會獨立漂移的步驟。
步驟 6：檢查圖結構和安全缺陷
把樹當成圖而不只是文章。每個節點有穩定 ID，每條邊有允許答案，然後確認無 dangling node、無沒有出口的非終態、每個答案按優先規則只到一個下一步、所有路徑可達終態、循環有上限和出口、終態不重返診斷、權限不隱式升級、變更操作有回退和驗證、證據失效有安全路徑，以及高風險情況先升級再實驗。
AI 可以列舉節點和邊並指出疑點，但 ID 唯一性、缺失引用、不可達節點和 cycle 應交給確定性檢查。NIST 生成式 AI Profile 要求以場景測量、人工監督和文件控制管理虛構與資訊完整性風險。［2］ AI 的圖檢查只能算候選 finding。
亦要檢查認知負擔。一個節點若有十二個技術答案，即使形式完整，在壓力下也難以使用。拆成較小觀察，把緊急停止條件提前，把證據要求放在對應決定旁。
步驟 7：冷跑、批准並維護決策樹
使用脫敏歷史模式或完全合成場景冷跑，不能為追求真實感而暴露私人事故記錄。至少覆蓋正常解決、訊號不可用、權限不足、歧義症狀、嚴重停止條件，以及不診斷而直接升級的案例。
讓 Kevin Wu 核對每項檢查是否可由目標受眾執行、是否符合目前系統真源、是否產生指定證據。安全或營運 owner 另行審批權限、副作用、回退和升級。保留分歧並修改決策樹，不要引導 reviewer 走預設路徑。
每次記錄 case ID、tree revision、路徑、意外分支、缺失證據、不安全建議、終態、reviewer 和決定，把失敗加入迴歸案例。確認為程式碼分支後可用AI 除錯指南，已批准操作程序可透過SOP 清單工作流程轉成執行核對。
發佈不可變版本，並為架構、owner、權限、遙測、門檻、依賴、runbook 和失敗模式變化設定覆核觸發器。系統範圍消失或證據來源不可信時退役。
總結
- 先凍結症狀、影響、系統邊界和安全條件。
- 只從目前系統真源建立可觀察分支。
- 為每個答案綁定有界檢查、權限、副作用、證據和下一節點。
- 每條路徑結束於解決、workaround、停止、回退、收集證據或升級。
- 以確定性方法檢查 ID、邊、循環、終態、權限和高風險操作。
- 發佈前冷跑合成或脫敏案例並由 owner 覆核。
常見問題
AI 能從問題描述直接診斷根因嗎？
它可以提出假設，但假設不是診斷。根因聲稱需要系統知識，以及從獲批來源和測試取得的證實或反駁證據。
每個排障問題都應該是 yes/no 嗎？
不應該。訊號可能 healthy、unhealthy、stale、unavailable 或 inconclusive，應定義真實答案集和每個安全去向。
如何讓分支互斥？
每個節點只觀察一個維度，定義術語和時間窗，並以案例測試同級答案。若答案重疊，應拆節點或設明確優先次序。
證據不可用時怎麼辦？
不要猜。只嘗試獲批的低風險刷新，然後記錄缺失來源與範圍並停止或升級。
決策樹可包含重啟命令嗎？
只有清晰授權 owner、精確範圍、副作用、前置條件、rollback、成功訊號和停止規則時才可能包含。高風險正式環境操作應保留在受控 runbook。
如何安全測試決策樹？
在隔離環境使用脫敏歷史模式或完全合成案例，覆蓋歧義、過期證據、權限不足、嚴重停止和升級路徑。
決策樹等同 SOP 嗎？
不等同。決策樹根據觀察選擇診斷路徑；SOP 給出指定流程的受控操作。複雜操作應由樹連結到批准程序。
何時應立即升級？
可能發生安全入侵、資料遺失或破壞、安全傷害、大範圍影響、權限缺失、證據不可靠或操作超出受眾範圍時，應立即升級。
多久覆核一次決策樹？
按風險設定週期，並在架構、owner、權限、遙測、門檻、依賴、runbook 或失敗模式變化時重跑迴歸案例。
來源
- Google SRE — Effective Troubleshooting — https://sre.google/sre-book/effective-troubleshooting/
- NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
- NIST — Secure Software Development Framework Version 1.1 — https://csrc.nist.gov/pubs/sp/800/218/final
- US EPA — Guidance for Preparing Standard Operating Procedures — https://www.epa.gov/quality/guidance-preparing-standard-operating-procedures
Sources checked 2026 年 9 月 4 日。
