事件應變:大事故真正的敵人是混亂

前面你學會了 on-call 止血、也學會了系統化除錯——但那是「一個人對付一個問題」。當一場大事故爆發(多人捲入、影響大、時間壓力高),你會發現最大的敵人往往不是技術問題本身,而是混亂。

大事故真正的敵人是「混亂」

技術問題總會被修好;但「五個人同時在改、沒人知道別人在做什麼」造成的混亂,會把一個十分鐘的問題拖成兩小時,甚至改出新的災難:

同一個故障,左邊沒人統籌、大家對系統亂射一通、還互相踩;右邊有指揮官分工,只有一個人動手改。混亂本身就是一種故障——而且是人造的、可以用流程避免的

事件指揮體系:一人一角

馴服混亂的辦法,SRE 直接借鏡了消防與災害應變的 Incident Command System(ICS,事件指揮體系):明確的角色分工,一個人只扛一件事:

分工的精髓:IC 掌握全局、做決策、分派任務,但不親自動手;Ops 是唯一動系統的人;Comms 擋掉「現在怎樣了?」的追問讓 IC 專心;Scribe 的時間軸就是之後 postmortem 的原料

幾個關鍵動作

有了角色,還有幾個讓事件應變順的關鍵:

早點宣告「這是一個 incident」。太多團隊拖著不肯承認出事(想說再等等、應該快好了),結果錯過啟動協調的時機。宣告事故不是認輸,是啟動一套幫你更快解決的機制。
一個共同的溝通管道(戰情室 / chat channel):所有人在同一個地方對齊,別讓資訊散在私訊。
明確的交接(handoff):IC 要下班/撐不住時,大聲把指揮權移交給誰,不能無聲消失。
平時演練:別讓真正的大事故,是你第一次用這套流程。
事後追蹤 outage(Ch16):把每次事件記錄、分類、看趨勢(哪類最常發生、MTTR 有沒有變好)——資料化,才談得上改善。

反思

大事故的瓶頸,常常不是技術,是協調

我看過不少事故,技術上的修法其實很簡單(回滾、重啟、切流量),真正把時間拖長的,是「五個人各自在動、沒人掌握全局」的混亂——重複的操作、互相衝突的改動、甚至有人把別人剛修好的又弄壞。這讓我體會:混亂本身就是一種故障,而且是人造的、可以用流程避免的。 救火時,一個清楚的指揮結構,往往比多找兩個厲害的工程師更能加速——因為它解的不是技術問題,是「人多手雜」這個更難纏的問題。

IC 最反直覺的一點:他不動手

新手當 IC 最容易犯的錯,是自己跳下去 debug——結果全局沒人看、其他人失去協調中心,反而更亂。IC 的價值,恰恰在於「不動手、只協調」:掌握全貌、分派任務、做決策、幫大家擋掉干擾。讓最會修的人專心修,讓最會統籌的人專心統籌。這跟我帶團隊的體會一模一樣:當 leader 忍不住跳進去當那個最強的個人貢獻者,團隊就失去了大腦。 忍住不動手、把自己升到協調層,是當指揮官(和當主管)最難、也最該練的一課。

早點承認「這是 incident」

拖延宣告事故,是我看過最常見、也最貴的錯。大家想省事、想不小題大作、賭它自己會好——結果等到不得不承認時,已經一團亂、還錯過了最該協調的黃金時間。我現在的原則是:寧可宣告了發現是小事,也別拖到大事才手忙腳亂。 而這件事能不能做到,其實回到上一篇的 blameless 文化——只有當「宣告事故」是安全的、被鼓勵的、不會被秋後算帳,人才敢及早拉起警報。技術流程和文化,在這裡是綁在一起的。