從偵測到復原，管理完整事件

依影響宣布事件

當某個狀況中斷服務、降低服務品質，或威脅服務到需要協調應變的程度，就構成事件。組織定義嚴重等級與升級規則，再依使用者影響、受影響資料、持續時間和範圍套用。

不要等到完全釐清根本原因，才請求協助。清楚說明已觀察影響，就足以開始協調。區分資安疑慮與已確認結論。

發布前準備應變途徑。主要服務不可用時，仍須能取得聯絡方式、存取程序、操作手冊和溝通管道。用虛構事件演練這條途徑。

先分配責任，避免互相衝突的變更

事件協調負責設定優先順序與管理決策。技術應變人員調查並緩解問題。溝通則讓受影響者掌握資訊。Google SRE 將這些責任描述為不同角色。小團隊可以兼任，但仍須涵蓋所有工作。事件應變。

維護一份共用時間軸，記錄時間、觀察、操作、執行者和結果。區分事實與假設。使用共同時區，並標記不可靠的時間戳記。

走過一個虛構事件

以下均為 UTC 時間。匯出失敗影響多位客戶時，組織指定事件協調者。

有用的首次更新會說明受影響功能、已知範圍、緩解措施和下次更新時間。沒有證據時，不承諾修復時間。共用更新中避免包含客戶紀錄。

09:10 時，事件性質改變了。只恢復成功匯出已不足夠。團隊需要評估可能的資料揭露、控制存取、保存證據，並讓適當決策負責人參與。

緩解問題，同時保留控制

適用時使用經過測試的操作手冊。版本回復、容錯移轉或存取憑證變更前，先檢查前提條件。舊應用程式版本可能無法理解目前資料結構描述。跨區域容錯移轉，也可能帶過去同一份毀損資料。

AI 助手可以在核准邊界內，整理經遮蔽的證據或比較假設，但應變人員必須驗證結論。記錄檔與工單是不可信輸入，不是授權執行其內容的依據。

緊急存取應具有已授權目的、有限期間和稽核紀錄。情況緊急，不代表代理程式建議的命令正確。

分開結束復原與後續工作

宣布服務恢復前，驗證使用者流程、資料完整性、存取邊界，以及監控是否仍反映最新狀況。記錄剩餘限制。資安問題尚未釐清時，繼續調查。

之後，檢視讓事件得以發生的條件。分配具體後續工作、負責人和驗證條件。無責備檢討尋求正確解釋與有用改變，但不會免除完成這些變更的責任。事後檢討實務。

繼續閱讀資安維運與讓回饋形成閉環。