如何確保團隊能有效面對與處理事故?

先前我們在 軟體工程師該如何值班 (on-call)? 一文談到工程師可以如何做好輪班以應對事故，也在 軟體工程師該如何做好事故檢討? 談過事故之後如何有效做好檢討。不過在這兩篇文章之前，還有一個主題是工程團隊必須面對的，那就是「如何確保團隊能有效面對與處理事故」。

Google 的 SRE 專書中把事故回應管理 (Incident Response Management) 拆成三個階段，分別是準備 (Prepare)、回應 (Response) 與學習 (Learn)。把這三階段對應到先前的主題文，軟體工程師該如何值班 (on-call)? 一文在談回應、 軟體工程師該如何做好事故檢討? 一文在談學習，在這篇文章，我們會專注來談如何做好準備。

建立讓團隊能順利應對事故的基礎

事故處理不能等到真的發生事故時才採取行動，如果事前的準備做得夠充足，當事故真的發生了，團隊將能用從容的方式應對，也能更快速有效地解決事故。這也是為什麼，推薦團隊務必要先做好準備、建置能順利應對事故的基礎。

降低事故處理時的噪音

如同上方 Google 的 SRE 專書中的附圖，在事故回應 (Response) 階段的最開始是偵測事故 (Detect)。理想的狀況下，事故應該由系統自動偵測，如果等到終端使用者回報，那往往會太慢。如果要讓系統能有效偵測到事故，就需要做好監控相關的設置。

在實務上，設置監控最常見的問題，是先前在 軟體工程師該如何做好監控 (monitoring)? 一文中我們有談過的警報風暴 (alert storms)。試想，假如今天負責輪班的工程師，三不五時就收到警報說有事故，然後每次排查後都發現是虛驚一場，這類噪音不僅消耗輪班工程師的時間，還可能會讓心態因此鬆懈 (收到警報時可能會覺得又是假警報，就不認真應對)。

因此，要讓事故處理時，負責輪班的工程師能夠最有效針對問題解決，其中最關鍵的點是要降低事故處理時的噪音。

要讓警報的噪音降到最低，就意味著不該什麼都設成警報。實務上推薦的做法可以從兩個角度切入。第一個是優先針對 SLO 來設定會打擾值班人員的警報 (備註：對 SLO 不熟的讀者，可以回顧 SLO 是什麼? 為什麼 SLO 對軟體團隊很重要? 一文)；至於不直接影響 SLO 的訊號，則可以放在儀表板、低優先級通知，或作為排查時的輔助資訊，而不是一律升級成需要即時處理的警報。第二個則是要明確設置優先級 (例如 P1、P2、P3)，並明確設定哪些是值班人員該處理的 (例如到 P4 就不該勞煩值班人員)

在每次收到假警報時，值班人員也要回過頭來調整，例如把相關警報靜音，或者調整發出警報的閾值，確保未來不會再出現類似的假警報。除此之外，在設置警報時，要去梳理警報之間的關係，避免類似的警報同時出現，造成過多噪音。

讓緩解問題能加速的基礎

除了降低警報噪音之外，團隊也需要建立一些能加速排查與緩解問題的基礎。這些準備平常看起來可能不緊急，但在事故真的發生時，往往會能協助團隊快速止血。

其中最重要的一項準備，是為團隊建立事故處理指南 (runbook)，在指南中要清楚註明針對每種警報都有對應的處理建議 (例如當 X 警報發出，建議優先查看 Y)。在指南中要清楚明定不同的分級，例如哪些事故屬於 P1 要立即應對、哪些是屬於 P4 事故，可以不用當下立刻處理，可以先註記即可。

團隊也要確保這本指南隨時更新。當值班工程師遇到某次事故是沒辦法跟著指南來處理時，就應該在處理完該事故後順手更新指南，把最新資訊補上去，讓未來值班的人遇到相同問題時能更快緩解。

除此之外，好的軟體工程實踐也會對緩解問題有幫助。舉例來說，在做部署時，要盡量避免一次部署大幅度的更動，而是該切成小批次的部署 (推薦回顧 如何把關好上線流程?)。當團隊採用小批次部署時，如果出事故時回滾，也能夠更加鎖定是哪次部署，同時回滾時也能減少對其他已經部署的功能的影響。

在部署時，也推薦搭配功能旗標 (不熟的讀者可以回顧 什麼是功能旗標 (feature flags)? 為什麼要用功能旗標? )，這樣能有效做到功能隔離，這時如果功能 X 出問題，可以透過功能旗標把該功能關閉，而不影響功能 Y。這種做法能讓關掉出事故功能時，決策變簡單很多，因為當不會影響功能 Y，就不用再跟產品端確認，是否能接受功能 Y 也一起被關掉。

明確的分工

當事故發生時，如果有明確的分工，團隊會更快進入狀況，進而避免大家慌在那邊不知所措，或者很多人同時有很多聲音導致場面混亂。在分工上，在實際發生事故時，至少要有三個核心角色，分別是事故指揮官 (Incident Commander)、溝通負責人 (Communications Lead)，以及技術處理負責人 (Operations Lead)。

事故指揮官會掌握大局，清楚知道目前整體事故解決進度。這個角色不一定要是職級最高的人擔任，而是要由能掌握全局、協調資訊、分派任務並推動決策的人擔任。在某些團隊裡，這可能是技術負責人；但在更成熟的事故管理流程中，這個角色通常會依照當下事故脈絡、經驗與可用性來決定。

事故指揮官會集對解決事故有幫助的人，並分派任務讓團隊能動起來排查問題。與此同時，如果被分派任務的人遇到困難，事故指揮官也要提供對應的協助。

溝通負責人則是會記錄下目前事故解決的狀態，讓利害關係人能知道最新進度，並作為對外聯繫窗口。當有了溝通負責人，事故指揮官可以專注在控場，而不用擔心向利害關係人更新進度時遺漏細節。近期在有 AI 工具的幫助下，可以直接利用 AI 來紀錄與更新。舉例來說，在排查視訊會議中，搭配 AI 生成會議逐字稿，同時每 5 - 10 分鐘根據會議的逐字稿，來整理相關的紀錄，並將更新自動推送到相關的溝通頻道中。

舉例來說，假如今天在電商網站中的結帳頁面突然出現大量下單失敗訊息，事故指揮官會先快速掃過該頁面的相關資訊，然後迅速召集相關人員，包含負責該頁面的前端、後端工程師、對應的客服負責人。接著，會迅速指派要排查的方向，例如請前端工程師去檢查最近一次的部署、請後端工程師去看相關的 API 與 log，然後請客服人員根據當下的記錄，起草對使用者的說明文案。

在召集人員時，確保參與問題排查的人員視角足夠多元。事故往往涉及整體系統，而團隊中每個人僅掌握系統的部分知識，因此通常需要匯集眾人知識，才能釐清系統當下的實際狀況。例如如果資料庫目前超載，資料庫團隊僅能查出查詢模式被變更，但無法說明改變原因，這時就需要詢問實際寫查詢的應用層團隊。

有多元視角也能確保避免單一視角的固著 (fixation)。通常個人容易從特定角度看問題，若看的視角與解決問題所需角度不相符，很可能導致最後難以找出真正的問題。

因此，推薦平時團隊應該要維護一個聯絡清單 (可以維護在上面提到的事故指南中)，例如當某個頁面出問題，應該要拉哪些人。找人的精細度也推薦不要只是單純分前端與後端，而是可以細到後端的 API、資料庫、演算法等不同角色。有了這份清單，不代表每次出事故就要拉所有人，而是可以分階層，例如第一時間一定要拉誰進來，如果過多久查不出原因，還可以再多拉誰進來。

為團隊成員建立心理安全

上面談到流程、分工，以及排查問題的思維，在這些之外，要讓團隊成員能夠在遇到事故時，可以有效排查並解決，「為團隊成員建立起足夠的心理安全」也非常重要。

在《快思慢想》一書當中，諾貝爾獎得主 Daniel Kahneman 把人類的思考系統拆成兩大類別，一種是更貼近自動化的快思考，另一個則是帶著更多推理邏輯的慢思考。快思考能夠幫助降低思考過載對腦的負擔，畢竟如果連起床去刷牙這段路的每個決策點都要深思的話，人很容易就會被過多的決策淹沒，導致做不了太多事。而慢思考則能幫助把事情想得更詳盡完整，透過深思各種面向細節，讓決策的品質更高。

在面對事故時，理論上應該要用慢思考，避免因為倉促的決策亂槍打鳥，而是能真的去找出核心。要能做到這一點，關鍵在於負責輪班的工程師，能否保持冷靜、不慌亂。從團隊的角度來看，就需要減少輪班者在處理事故時要面對的壓力。

具體來說，在 Google 的 SRE 相關實務分享中也提到，團隊負責人需要確保輪班成員都有足夠的心理安全 (psychological safety)，這種安全感能夠讓輪班成員不會焦急地處理事故，因而能減少倉促的快思考。

Google 的團隊分享，建立這類安全感最有效的方法，是讓輪班成員清楚知道以下三點：

• 上報管道：假如輪班成員自己解決不了，可以找誰求援
• 定義明確的事故解決流程：輪班者知道各種問題該從何下手解決，就會少一點慌張焦慮
• 不指責人的事故檢討：我們在 軟體工程師該如何做好事故檢討? 一文有詳談，推薦回顧

在實務上，上面提到的第二點，通常會需要有定期的預演，才能夠強化團隊成員對於應對事故的熟練度；不然即使知道流程，也很可能因為不熟悉，實際做起來仍然慌張。對此，讓我們在下個段落來談，平常可以如何透過預演，來深化團隊成員對事故處理流程的理解。

閱讀更多

除了上面提到的方法，如果對這個主題感興趣，我們在 E+ 會員方案的文章中，會進一步談如何做好事故預演。歡迎加入 E+ 會員方案閱讀與交流。