大事故失控，很少是因為沒人努力——而是每個人都埋頭做自己那塊、沒人管全局。事件指揮（源自美國 Incident Command System）用角色分離把一群善意的人變成協調的隊伍，目標只有一個：降低衝擊、儘快恢復。
🧠 Intuition
TIP
明確劃分角色反而給每個人更多自主——不必互猜別人正在做什麼。IC 掌全貌、Ops 動手修、Comms 對外、Planning 顧長線；凡沒被委任的職責，預設由 IC 自己扛。
- 事件指揮官（IC）：維持高階全貌、編組任務、依優先級分派、替 Ops 排除卡點。IC 最重要的動作是維護一份活的事件文件（多人可同時編輯，最重要的資訊放最上面）。
- 運維（Ops Lead）：與 IC 配合執行實際修復。鐵律——事件期間只有 Ops 可以動系統，杜絕單兵冒進。
- 溝通（Comms Lead）：對外唯一窗口，定期發更新，讓 VP／利害關係人看到高階狀態而不被細節淹沒。
- 規劃（Planning Lead）：顧長期面——開 bug、安排交班、追蹤「系統偏離常態」的清單以便日後還原。
⚖️ Tradeoffs
無流程的救火 — 三個經典失控陷阱
- 過度聚焦技術：第一線工程師埋頭看 log，沒餘力看整體、也沒人統籌。
- 溝通不良：沒人知道別人在做什麼，VP 得不到統一資訊、開始丟無關卻難反駁的建議。
- 單兵冒進（freelancing）：善意的人自己想到解法就直接推上線，沒跟現場協調，把情況變更糟。
- 結果：每個人都「在做該做的事」，事件卻越滾越大——這正是角色分離要根治的病。
受管理的事件 — 早宣告、明確交班、常演練
- 何時宣告：滿足任一即視為事件——需要第二個團隊介入、故障對使用者可見、或集中處理 1 小時仍未解。寧可早宣告、之後簡單關閉。
- 指揮所與時間軸：War Room 或留原座位以 IRC／email 同步皆可；用 IRC/bot 自動留時間軸，是事後檢討的寶物。
- 明確交班：下班前必須口頭把指揮權交出——同步現況、明說「你現在是 IC，OK？」，對方明確答覆前不離線，並向全體公告。
- 會退化的能力：事件管理不練就生疏。把框架套到日常（如跨時區變更管理）、DiRT 演練、輪流扮演不同角色，練到成第二天性。
🔑 Takeaways
- 大事故失控多因缺協調而非缺努力；事件指揮用 IC／Ops／Comms／Planning 四角色分離來根治。
- 兩條鐵律：只有 Ops 能動系統（防冒進）、IC 維護一份活文件（防資訊散落）。
- 早宣告、明確交班、常演練——這三件事是縮短 MTTR、讓緊急時刻壓力可控的關鍵。
No notes yet — jot your takeaways or Q&A here.