在軟體工程的世界裡，生產環境發生事故（Incident）是不可避免的。但對於許多工程師，尤其是 Junior 工程師來說，面對系統崩潰、指標暴跌以及高層關注的壓力，往往會陷入恐慌，導致判斷失誤。
本文根據 Meta 生產工程師 Kyle Lexmond 的經驗分享，將事故處理從單純的「技術修復」提升到「人本管理」的維度，探討如何在高壓環境下維持冷靜，並建立一個能讓團隊持續成長的事故應對文化。
區分緩解與根因分析
在事故發生時，許多工程師最容易犯的錯誤就是試圖在第一時間「找出為什麼會這樣」並「徹底修復它」。在 SRE（Site Reliability Engineering，網站可靠性工程）的實務中，必須嚴格區分兩個階段：緩解（Mitigation）與根因分析（Root Cause Analysis）。
緩解是指採取任何手段讓服務恢復正常，停止對客戶的影響。例如：切換到備援區域、關閉故障的功能開關（Feature Flag）、增加伺服器資源或暫時限制流量。
根因分析則是事後才進行的，目的是找出問題的本質並防止再次發生。
在事故現場，你的唯一目標是緩解。如果你在壓力巨大的情況下執著於分析根因，會極大地增加認知負荷（Cognitive Overload），導致你錯過簡單的恢復手段，甚至在嘗試複雜修復時引入新問題。
事故中的心理壓力與認知陷阱
當事故發生時，工程師會感受到來自多方面的壓力：個人自尊（我的服務怎麼會掛掉）、專業責任（其他團隊依賴我）以及公司層級的壓力（對外形象受損）。這種壓力會導致兩種危險狀態：
第一是失去情境感知（Situational Awareness）。當你過於專注於某個特定任務（例如檢查某台伺服器的日誌）時，可能會忽略整體趨勢。例如，你可能沒發現故障範圍正在從單一可用區（AZ）擴散到整個區域。
第二是認知癱瘓。當專家們聚集在一起卻發現無法理解系統行為時，會產生強烈的自我懷疑，導致決策速度大幅下降。
為了對抗這些陷阱，實務上建議引入事故管理員（Incident Manager）。這個角色不參與技術調查，而是專門負責協調溝通、同步狀態、對接高層，讓技術人員能專注於緩解措施，避免被不斷詢問的進度壓力干擾。
建立韌性系統的實務建議
為了減少高壓事故的發生，可以從系統設計與團隊文化兩方面著手。
瑞士起司模型（Swiss Cheese Model） 不要依賴單一的防禦機制。想像每一層防禦像一片有孔的起司，雖然單層都有漏洞，但只要疊加多層（例如：輸入驗證、超時控制、斷路器 Circuit Breaker、監控告警），漏洞就不會剛好對齊，從而防止單點故障演變成災難。
建立無責文化（Blameless Culture） 如果公司將事故與獎金掛鉤或懲罰開報事故的人，工程師會傾向於隱瞞問題或延遲宣告事故。這會導致問題在被發現前擴散到無法控制的程度。正確的做法是：鼓勵儘早宣告事故，將其視為協調資源的手段，而非失敗的標記。
優化緩解路徑 確保你的告警（Alert）是高信號且可操作的。不要只發送「CPU 過高」的通知，而應提供對應的 Runbook（操作手冊），讓值班工程師能快速執行標準化步驟，降低在壓力下的思考成本。
事故後的成長路徑
每一次事故都是一次昂貴的學習機會。在事後回顧（Post-mortem）中，重點不應是「誰寫錯了這行程式碼」，而應是「系統為什麼允許這行程式碼導致全域崩潰」。
如果同類事故反覆發生，這通常意味著團隊對該部分的系統模型（Mental Model）存在認知缺失。這時應將「防止此類事故再次發生」列為最高優先級的開發任務，而非僅僅修補漏洞。
總結給工程師的建議
面對事故時，請記得：先緩解，後分析；儘快尋求協助，不要試圖獨自扛起所有壓力；並在平時透過設計冗餘與完善手冊，將未來的壓力提前消解。
來源：infoq.com - The Human Toll of Incidents & Ways To Mitigate It
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。