題幹與適用場景
這道題考察的是事故結束後的學習閉環,不是讓你複述一次故障排查。回答需要覆蓋影響、時間線、觸發與貢獻因素、處置過程、行動項、評審和共享。假設事故已經緩解,證據包括告警、部署記錄、變更、日誌、值班記錄和使用者影響數據;具體嚴重度和截止時間由候選人先釐清。
無責不等於沒有責任。無責復盤假設參與者在當時掌握的資訊下有合理意圖,分析系統、流程、工具和資訊缺口;同時仍要明確事件負責人、行動項負責人和完成期限。若存在惡意、違規或合規調查,應與學習型復盤分開處理,避免把兩種目的混在同一場會議。
適用對象包括 SRE、後端、平台、技術負責人和需要跨團隊推動改進的工程師。通用職位也可能透過這道題觀察候選人能否把失敗轉成可遷移的流程改進,而不是講英雄故事或把問題推給某個人。
面試官考察點
第一,能否先界定復盤目標和範圍。Google SRE 將復盤視為記錄影響、理解根因和貢獻因素、落實預防措施的工具;「服務已恢復」只是起點。
第二,能否用事實而非事後判斷還原時間線。每個時間點都應標註來源、時區和置信度,把「某人粗心」改寫成當時可見的訊號、權限、預設值或流程缺口。
第三,能否同時保留無責原則和可執行性。行動項要有單一負責人、優先級、追蹤項和可驗證終態;「加強監控」「提高警覺」都不足以證明改變已經發生。
第四,能否處理壓力和衝突。業務方要追責時,先區分行為調查與系統學習,再用影響、證據和風險說明為什麼公開歸罪會減少回報意願,最後明確誰負責修復和審批風險。
回答前需要釐清的問題
- 事故的嚴重度和使用者影響是什麼? 影響使用者數、持續時間、資料完整性和 SLO 違約決定復盤深度。
- 復盤的目的是什麼? 是學習和防復發,還是同時有合規、惡意行為或績效調查?不同目的要分開主持。
- 誰能參加和查看文件? 需要包含受影響服務、值班、發布、支援和業務代表,同時處理敏感資料。
- 證據保存在哪裡? 確認日誌、告警、部署記錄、工單、通訊和狀態頁的保留期限與時區。
- 行動項如何進入團隊工作流程? 了解任務系統、優先級規則、負責人和完成驗收方式,避免復盤後沒人跟進。
30 秒回答框架
「我先確認事故範圍、影響和復盤目的,區分學習型復盤與需要單獨處理的違規調查。會議前凍結並核對告警、變更、日誌和通訊,按時間線讓參與者補充事實。會上使用無責語言,分析觸發、貢獻因素、處置中做得好和做得差的地方,而不尋找替罪羊。結論寫成帶類型、優先級、單一負責人、截止時間和驗證指標的行動項,提交正式評審並分享給受益團隊。若有人要求立刻歸罪個人,我會先呈現證據和風險,保證必要的調查獨立進行,同時繼續推進系統和流程改進。」
分步驟深入解答
第一步:定義觸發條件和參與者
在事件結束後確認是否達到復盤門檻,例如使用者可見中斷、資料損失、人工回滾、恢復時間超閾值或監控失效。指定一名主持人和一名文件負責人;主持人負責討論安全,文件負責人負責證據和版本。邀請直接參與者、受影響團隊和能落實行動項的負責人,不把會議變成圍觀式審判。
第二步:先收集證據,再寫敘事
按統一時區建立事件時間線,每條記錄包含時間、事件、來源和置信度。把「發現問題」「採取緩解」「恢復服務」「確認影響結束」分別標出。不要先寫「根因是某人操作錯誤」,而是記錄當時看到的介面、預設配置、權限、培訓和審批路徑。
時間 | 事實 | 來源 | 置信度
10:02 | 部署開始 | 發布系統 | 高
10:07 | 錯誤率超過閾值 | 指標面板 | 高
10:11 | 回滾完成 | 變更記錄 | 高第三步:區分觸發、貢獻因素和未發生的防線
觸發是讓事故開始的近因,貢獻因素解釋為什麼影響擴大或持續,防線缺口說明為什麼沒有提前發現或阻斷。用「為什麼當時這個選擇看起來合理」「哪項資訊缺失」「哪個檢查點本可阻止擴大」提問。可以使用五問或故障樹,但不要把複雜事故壓縮成單一根因。
第四步:復盤處置過程
分別記錄做得好、做得差和僥倖避免的部分。處置動作要看是否縮小爆炸半徑、是否及時升級、溝通是否讓相關方作出決定。不要只讚美恢復速度,也要檢查是否因為缺少回滾開關、權限邊界或清晰角色而延長影響。
第五步:把行動項寫成可驗證承諾
Google SRE 的示例強調行動項需要類型、優先級、單一負責人、追蹤編號和可驗證終態。至少覆蓋預防、檢測、緩解、恢復或學習中的一種;每項都要能在截止時回答「完成了嗎」。
| 行動項 | 類型 | 負責人/期限 | 驗證終態 |
|---|---|---|---|
| 發布前阻止無回滾配置 | 預防 | 發布平台負責人 / 2 週 | 阻斷測試在 CI 中通過,違規發布無法合併 |
| 增加錯誤率與影響面告警 | 檢測 | 值班負責人 / 1 週 | 演練觸發告警,通知在 5 分鐘內送達 |
| 建立一鍵回滾開關 | 緩解 | 服務負責人 / 3 週 | 受控演練能在目標時間內恢復 |
| 更新事件角色和升級表 | 學習 | 事故經理 / 1 週 | 下一次演練由新人按文件完成交接 |
第六步:評審、分享和追蹤
由服務負責人和相關技術負責人評審完整性、影響評估、根因深度和行動項優先級。定稿後放入可搜尋的事件庫,按權限處理使用者隱私。把行動項連結到正常工作流程,定期檢查逾期、重複事故和完成後的驗證結果;未評審、未分享或沒有追蹤的文件很難產生組織學習。
第七步:處理「找責任人」的壓力
先承認業務方需要問責和風險控制,再說明兩條並行路徑:合規或惡意行為由授權調查人依據證據處理;復盤會議聚焦系統如何允許事故發生及如何防止復發。可以明確指出個人執行的動作,但避免用性格、能力或羞辱性語言解釋結果。行動項仍要有負責人,負責人表示承擔推進責任,不等於承擔個人過錯。
高品質示範回答
「我會先確認事故等級、使用者影響、資料風險和復盤目的。如果只是學習和防復發,我會把任何績效或違規調查獨立出來。會前凍結日誌、告警、部署記錄、工單和通訊,統一時區,建立帶來源的時間線;我會邀請值班、發布、支援、受影響服務和行動項負責人。
會議開始先約定無責規則:我們分析當時可見的資訊、系統和流程,不給人貼標籤。然後按時間線核對事實,區分觸發、貢獻因素、防線缺口,以及處置中做得好、做得差和僥倖避免的部分。對於每個結論,我會問它能否導出一個改變系統、工具或流程的動作。
行動項至少寫明預防、檢測、緩解或恢復類型、優先級、單一負責人、截止時間、追蹤編號和驗收證據。例如把「加強監控」改成「在錯誤率和受影響實例比例同時超過閾值時觸發告警,並在演練中確認五分鐘內送達」。定稿由相關負責人評審,按權限分享至事件庫,進入團隊 backlog,定期檢查是否完成和是否真的降低風險。
如果業務方要求當場找出責任人,我會說明問責調查需要獨立、基於證據,並展示歸罪會讓資訊更晚出現的風險;同時我不會迴避事實或負責人。最終做到既保留調查路徑,也讓系統改進在本次復盤後真正發生。」
常見錯誤
- 把無責理解成無人負責 → 行動項無人推進 → 區分個人過錯調查與行動項負責人。
- 只寫單一「根因」 → 忽略讓影響擴大的條件 → 拆分觸發、貢獻因素和防線缺口。
- 按記憶講故事 → 時間線被事後視角污染 → 先凍結證據並標註來源與置信度。
- 寫「加強監控」 → 無法判斷何時完成 → 補上閾值、通知時限、演練和驗收證據。
- 所有行動項同一優先級 → 關鍵風險沒有先處理 → 按影響、復發機率和工作量排序。
- 只邀請事故當事人 → 跨團隊資訊和受影響方缺席 → 邀請能補事實和落實改變的人。
- 復盤文件寫完即結束 → 行動項會被日常工作淹沒 → 關聯工作流程並檢查逾期與復發。
- 用羞辱性語言推動問責 → 人們會減少回報 → 用證據描述系統缺口,調查另行處理。
追問及應對
追問 1:無責復盤會不會縱容明顯的違規操作?
不會。無責復盤決定學習目標和改進方式;惡意、故意繞過控制或合規問題應由授權流程單獨調查。復盤仍記錄事實、權限和控制為何沒有阻止風險,並為行動項指定負責人。
追問 2:怎樣判斷行動項不是形式主義?
看它是否有單一負責人、截止時間、追蹤記錄和可驗證終態。預防項可以用阻斷測試,檢測項可以用演練觸發,緩解項可以用恢復時間目標;只寫「提高意識」無法驗收。
追問 3:事故還沒完全理解時能否先發布復盤?
可以先發布標註不確定性的事實版本,記錄已知影響、時間線、目前假設和待驗證問題;後續補充貢獻因素與行動項。及時、誠實的草稿比等待數月後憑記憶補寫更有價值。
追問 4:如何決定復盤共享範圍?
預設分享給能從中學習或落實行動的人,同時移除個人隱私、客戶機密和不必要的敏感資料。跨團隊評審能發現相似風險;若有法務或安全限制,記錄限制原因和可分享摘要。