題幹與適用場景
請設計一個面向多團隊的事件指揮平台：它要接收告警、建立事件、分配回應角色、同步內部與外部溝通，並在恢復後保留可稽核的時間線。請說明一致性、權限、通知風暴和恢復目標。
這道題適合系統設計、SRE、平台工程和後端職位。它考察在故障壓力下如何把偵測、指揮、協作和檢討連成可恢復系統。事件指揮平台的核心不是聊天工具，而是有明確負責人、狀態轉換、證據時間線和降級路徑的控制平面。面試中的容量可按「每分鐘告警量、同時進行事件數、參與者數、通知渠道和保留期限」釐清。
面試官考察點
- 是否把事件管理與原始監控、聊天和工單系統分層。
- 是否定義事件狀態、冪等鍵、單一事實來源和並行編輯規則。
- 是否將 incident manager、tech lead、通信負責人和記錄員職責分離。
- 是否處理告警去重、相關事件合併、通知風暴和權限邊界。
- 是否提供降級、跨區域故障恢復、稽核完整性和資料保留策略。
- 是否用 MTTA、MTTR、告警雜訊和溝通延遲驗證設計結果。
30 秒回答框架
「我會把平台分為告警接入、事件編排、即時協作、通知和檢討儲存。接入層按來源和時間窗口去重，編排層以事件為單一事實來源，使用版本號保證狀態與角色變更可稽核。事件經理負責指揮，技術負責人處理診斷，通信負責人對外同步，記錄員維護時間線。訊息先寫入持久事件日誌，再透過可重播串流推送；通知按優先級和訂閱限流。跨區域故障時允許唯讀或人工降級，恢復後用時間線產生檢討。」
分步深入解答
第一步：明確邊界和非功能目標
告警來源可以是指標、日誌、合成監控、客服升級或人工建立。平台負責把訊號組織成事件和回應流程，不取代監控計算、聊天內容儲存或部署系統。先確認 SLO：事件建立延遲、關鍵通知送達率、時間線寫入持久性、跨區域恢復時間和稽核保留期。
容量問題要區分平時和大規模故障：例如每分鐘數萬條告警、數百個並發事件、每個事件數百名參與者，以及同時發送簡訊、郵件、行動推播和 Webhook。極端峰值需要背壓和優先級，不能讓低優先級通知阻塞事件經理的控制操作。
第二步：接收、去重和關聯告警
接入端為每條訊號保留來源、規則版本、時間戳、指紋和原始載荷。客戶端重試和網路重放要求 API 支援冪等鍵；伺服器用租約或唯一約束避免同一指紋重複建立事件。去重窗口不能永久吞掉新故障，應按服務、環境和時間動態設定。
關聯邏輯可以先按服務拓撲、部署版本、區域和共同標籤聚合，再允許事件經理手動拆分或合併。自動關聯必須記錄依據和版本，不能靜默改變既有事件範圍。原始告警不可覆蓋，後續聚合結果作為派生狀態保存。
第三步：設計事件狀態機和角色
事件至少包含 detected、triaged、mitigating、monitoring、resolved 和 closed 等狀態，並定義允許的轉移、操作者和必填證據。狀態不是單個布林值；它應與影響範圍、目前假設、下一步動作和更新時間一起記錄。
回應角色要與身分分離：incident manager 負責優先級和決策，tech lead 負責技術調查，communications lead 負責內部與外部更新，scribe 維護時間線。角色變更要追加稽核事件，舊負責人不能無聲消失。重大操作採用租約和版本號，避免兩個值班人員同時提交互相覆蓋的指令。
第四步：建立即時協作和單一事實來源
所有狀態、角色、行動項目和溝通摘要先寫入事件日誌或事務資料庫，再透過訊息匯流排推送到 WebSocket、SSE、電子郵件和行動渠道。客戶端可以樂觀展示，但收到版本衝突時必須重新讀取伺服器狀態；不能把瀏覽器記憶體當作最終事實。
時間線應保存操作者、伺服器時間、事件版本、動作類型、摘要和關聯告警。長文字聊天可以外接儲存，但關鍵決策和恢復證據要進入結構化時間線。讀模型可以按事件生成目前視圖，重播日誌後仍能還原狀態。
第五步：處理通知風暴與權限
通知策略按事件優先級、使用者值班表、渠道可靠性和已確認狀態限流。低優先級告警進入摘要，高優先級通知使用指數退避、渠道升級和確認逾時；同一事件不應讓一名值班人員收到數百條重複訊息。通知佇列要和控制平面隔離，避免簡訊供應商故障阻塞狀態更新。
權限至少區分觀察者、回應者、事件經理、通信負責人和管理員，並按租戶、服務和環境限制存取。外部狀態頁只讀投影經過脫敏的影響和進展，不直接暴露內部假設、客戶資料或憑證。所有讀取和匯出都應記錄稽核事件，緊急破窗操作需要原因和事後複核。
第六步：設計降級、恢復和檢討
平台本身故障時，必須保留電話橋、靜態運行手冊或備用事件表等人工路徑。控制平面優先保證建立事件、認領角色和寫入時間線；非關鍵分析、搜尋和歷史報表可以暫時不可用。跨區域部署採用主寫與非同步複製或分片寫入，需明確衝突合併和故障轉移後重新取得租約。
恢復後產生檢討草稿：偵測、確認、緩解、恢復和關閉各階段的時間，關鍵決策、告警品質、溝通對象和後續行動。檢討記錄不能篡改原始時間線；修訂應追加版本。指標包括 MTTA、MTTM、MTTR、重複告警比例、角色認領延遲、通知送達率和行動項目按期完成率。
資訊增益與邊界
事件指揮平台的增益來自責任、狀態和證據的結構化，而不是把所有聊天搬到一個頁面。它不能保證根因正確，也不能取代監控品質和人員訓練。設計必須承認通知渠道、身分服務、區域網路和平台自身都可能同時故障，因此要有最小可用控制面和人工回退。
高品質示範回答
「我會先定義平台邊界和目標：它組織告警與回應，不取代監控、部署或普通聊天；關鍵目標是建立延遲、通知送達、時間線持久性、跨區域恢復和稽核保留。接入端保留原始告警，使用來源指紋和冪等鍵去重，按服務、區域、版本和拓撲關聯，但所有自動聚合都可解釋、可拆分。
事件編排層以版本化狀態機為核心，狀態和角色變更追加到持久日誌。事件經理負責優先級和決策，技術負責人負責診斷，通信負責人負責更新，記錄員維護時間線。客戶端透過可重播串流取得狀態，版本衝突時重新讀取，瀏覽器快取不作為事實來源。關鍵通知與控制操作使用分離佇列，按優先級、值班表和確認狀態限流。
權限按租戶、服務和環境隔離，外部投影只暴露脫敏影響。跨區域故障時優先保留建立、認領和寫時間線，搜尋與報表可以降級到唯讀或離線。恢復後從不可篡改的時間線產生檢討，計算 MTTA、MTTR、告警雜訊和行動項目完成率。如果平台不可用，電話橋和靜態運行手冊仍能讓團隊繼續指揮。」
常見錯誤
- 把平台當聊天工具 → 關鍵狀態埋在訊息中且無法稽核 → 結構化狀態機和事件時間線。
- 告警全部即時廣播 → 通知風暴阻塞真正的控制動作 → 去重、優先級、確認和限流。
- 角色只存在於前端 → 多人操作會互相覆蓋且責任不清 → 伺服器租約、版本和追加稽核。
- 自動合併不可解釋 → 事件範圍錯誤時無法回溯 → 保留原始告警和聚合依據。
- 只設計正常區域 → 平台故障時團隊失去指揮渠道 → 最小控制面與人工回退。
- 檢討覆蓋原始記錄 → 無法驗證時間和決策 → 原始日誌不可變，修訂追加版本。
追問及應對
兩名事件經理同時接管怎麼辦？
使用帶過期時間的接管租約和單調版本號，伺服器只接受目前租約持有者的控制寫入。接管失敗的一方讀取最新狀態並顯示目前負責人；緊急破窗需要權限、原因和稽核記錄。
通知供應商宕機會不會影響事件狀態？
不會讓通知佇列成為狀態寫入的前置條件。先持久化事件和待發送通知，再由獨立 worker 重試、切換渠道或進入人工電話流程；控制平面仍可讀取和更新。
如何避免自動關聯漏掉真正的新事件？
關聯只產生候選關係並保留原始訊號，使用時間、服務、區域和拓撲等多個證據。高影響或低信心訊號進入人工確認；規則版本和拆分操作都寫入時間線。
外部狀態頁應該即時顯示什麼？
只投影經過權限和隱私過濾的影響範圍、目前階段、下一次更新時間和恢復進展。內部假設、客戶識別、憑證、未確認根因和詳細日誌留在受控內部視圖。