服務路徑與事件邊界

示範事件是全域 rule rollout 後 CPU 激增與錯誤率上升。這類事故的難點在決策序列是否清楚、偵測本身反而容易：先限流、先回退、還是先分區隔離。

事中決策欄位固定用 Timestamp、Decision、Context、Evidence、Owner、Expected effect、Rollback condition。write-back 再補 target artifact、closure signal、review date。

實作步驟

1. 建立 incident intake：彙整告警、dashboard、客訴與 deploy event。
2. 啟動 decision log：每個會改變路由的動作都記錄欄位。
3. 每 10-15 分鐘更新一次 expected effect 是否達成。
4. 事故收斂後建立 write-back 條目：對應到 runbook、gate、signal 或 ownership 缺口。
5. 在下一次 readiness review 檢查 closure signal 是否達成。

判讀訊號

常見誤區

把 decision log 當成事後整理會失去事故價值。事故當下不記，事後只能用記憶補洞，容易產生 hindsight 偏差。

把 write-back 當成待辦清單也會失效。沒有 closure signal 的改善項目很快會退化成長期債務。

案例回寫

這條路徑可用 Cloudflare 2023 Workers KV Deployment Tool Misconfiguration 回寫。先看控制面變更如何擴散，再回到本章檢查決策欄位與回寫欄位是否能完整重放事故節奏。

這個案例主要支撐的是「控制面決策可回放」判讀，不直接支撐 provider dependency gate 門檻；放行策略回到 6.25/6.8。

跨模組路由

1. 與 8.19 的交接：欄位語言與 Incident Decision Log 對齊。
2. 與 8.22 的交接：回寫欄位與 Incident Evidence Write-back 對齊。
3. 與 6.24 的交接：控制面事故停損條件回到 Rule Rollout Safety Gate。
4. 與 4.20 的交接：證據來源統一到 observability evidence package。

下一步路由

要把控制面事故前移到資安治理，接著讀 7.27 Credential Rotation with Scoped Evidence 實作示範。

概念位置

Incident decision log 位在 on-call、incident communication channel 與 post-incident review 之間。它保存的是決策內容、時間、證據、owner、預期效果與回退條件，timeline 則保存事故事件順序。

可觀察訊號與例子

系統需要 incident decision log 的訊號是事故結束後很難說清楚某次 rollback、degradation 或 vendor escalation 的決策依據。常見例子是聊天頻道有大量討論，但缺少明確的「何時決定、基於哪些 evidence、誰執行、什麼條件下改路線」。

設計責任

Incident decision log 要支援 handoff、multi-incident coordination、stakeholder update 與 post-incident review。它的欄位應足夠輕量，讓事故現場能持續更新，同時足夠完整，能把缺口回寫到 runbook、steady state 與 action item closure。