Oncall 心態指南：Dropbox 與 AWS 頂尖工程師的事故應對與 postmortem 心法

在前一篇 Pager 沒響卻聽見警報？Oncall 工程師的睡眠與焦慮指南 裡，那篇談的是 oncall 的代價與防禦，這篇想談談 oncall 的心態。我最近聽了兩個訪談，一篇是前 Dropbox 最資深工程師 James Cowling，另一篇則是 AWS Distinguished Engineer Marc Brooker。兩則訪談都非常有啟發性，最讓我意外的是，我發現他們的共同點在於：這些頂尖工程師不但不排斥 oncall 和事故應對，有些人甚至反其道而行，主動把手舉起來爭取這份工作，比如 Marc Brooker 自己就選擇持續參與 on-call rotation 長達 15 年。

這也逼我重新想一個問題：事故應對這件事，本身有沒有可能沒那麼需要排斥？ 也許我一直把它當成純粹的負擔與威脅，而錯過了它作為「學習入口」和「當責展現」的另一面。這篇是我的閱讀與反思筆記。

TL;DR：三個心態轉換

如果只想帶走三件事：

• Oncall 是最好的學習場域：Marc Brooker 說他關於分散式系統的實作知識，大部分來自 oncall 與讀 postmortem。把每次事件當成「系統真實行為」的第一手學習資料，而不是純粹的麻煩工作。
• 區分救火與學習：重複關同類型的 ticket 是該被自動化的訊號；不尋常的事件才是值得頂尖工程師花時間深挖的金礦。
• 用承擔取代抱怨：James Cowling 的核心心態是「沒有別人，就是我們」。事故應對不是被迫救火，而是「我來把問題解決」的選擇，重新塑造整個工作體驗。

mindmap
  root(("Oncall 正向心態"))
    Oncall 是學習場 (Marc Brooker)
      實作知識來自 oncall
      看系統真實行為
      看客戶真實用法
    區分兩種工作
      重複 ticket 要自動化
      不尋常事件要深挖
      目標是理解不是關單
    Postmortem 的力量
      先真正搞懂發生什麼
      多層次問為什麼
      跨事件找 pattern
      把教訓變成工具
    警惕英雄主義陷阱
      被 page 100 次引以為傲
      內部像高度當責
      外部是沒修根因
    當責取代抱怨 (James Cowling)
      沒有別人就是我們
      高度當責別自己全包
      要不要現在就修
      投入一個 cause

一、頂尖工程師為什麼主動靠近 oncall

訪談裡主持人直接問 Marc Brooker：很多資深工程師會想辦法「談判退出 oncall」，因為單位時間的產出看起來不夠有影響力，甚至很多感覺都是麻煩事，那你為什麼還待了 15 年？

Marc 的回答幾乎顛覆了我原本的觀點：

I would say that the majority of my in practice knowledge about how to build distributed systems has come from being on call and analyzing and deeply understanding these post mortems and COEs. — Marc Brooker

他的論點是：剛出社會的工程師通常有很好的 CS 基礎、程式能力、數學能力，但缺的是「系統實際上怎麼運作、怎麼壞掉、客戶怎麼用 (甚至怎麼亂用)」的接地知識；而 oncall 正是取得這種知識最直接的管道。

換句話說，oncall 不只是維運成本，它同時是一條高頻寬的學習通道。當你站在事件第一線，你看到的是系統在真實壓力下的行為，而不是設計文件裡的假設。對想成為更強工程師的人來說，這反而是別人拿不走的優勢。

二、區分「救火」與「學習」：不是所有 oncall 都等值

但在訪談中，Marc 也強調這並不是叫你去當無腦救火隊。他很明確地把 oncall 工作分成兩類：

• 重複、可預期的 ticket：一直關同一張單，代表這是該被自動化的 toil。建自動化現在比以前更容易、更強大，這種工作不值得耗費資深專家的時間。
• 不尋常、意料之外的事件：這才是值得深入和研究的部分。Marc 認為 oncall 的目標之一，應該是「遇到系統裡奇怪或非預期的狀況時，深入理解它，再把學到的東西帶回去改善系統，並向整個公司與社群傳播」。

If you have folks in your teams who are on call and they’re just closing the same ticket over and over and over, well, that’s where you need to just build some automation. — Marc Brooker

這個區分對我很有啟發：上一篇 Pager 沒響卻聽見警報？Oncall 工程師的睡眠與焦慮指南 談的是砍掉雜訊 (一輪班超過兩個需要處理的事故就該檢討警報設計)；而這個論述則強調：把砍掉雜訊後省下的注意力，投資在真正值得理解的事件上。

Oncall 的價值不在你關了幾張單，而在你理解了多少原本不懂的系統行為。

三、好的 postmortem 長什麼樣

Marc 估算他整個職涯讀過大約 3,000 - 4,000 份業界 postmortem 與 Amazon 內部的 COE (Correction of Errors)。他說「每一份就算只學到一點點，也會慢慢累積、留下來」。

那什麼叫一份好的 postmortem？

第一層：先真正搞懂發生了什麼，不要用你帶進來的偏見去「假設」原因。

If you can’t understand what happened, well, that teaches you something about your logging and metrics and observability. — Marc Brooker

也就是說，如果你連事件本身都還原不出來，那這件事本身就在告訴你：你的 logging、metrics、observability 可能有缺口。

第二層：多層次地問為什麼。 不能停在 proximal cause (最表層的近因)：

• 有一個 code bug → 好，修掉。但不能停在這。
• 為什麼測試與驗證沒抓到？流程哪裡可以改？
• 為什麼我們的測試流程長這樣？為什麼當初對系統行為做了那個假設？

一份好的 postmortem 不只修掉那一行程式，還會修到測試流程、團隊與組織流程等不同層次。

第三層：跨事件找 pattern。 當你在多份 postmortem 看到同一類問題反覆出現，就該往上抽象：能不能做成一個 service、一個 library、一個 community of practice，或用技術手段直接消除「一整類」問題？Marc 舉了 Aurora DSQL 的例子，他們設計時大量回顧關聯式資料庫相關的 postmortem，刻意把「client 暫停、斷線，卻長時間持有 transaction lock」這類常見故障模式，從架構層級就設計掉。

How do we turn all of these lessons into new services and into service improvements? — Marc Brooker

訪談中也提到了 AWS 內部的週三 COE 會議：跨團隊、含資深 leader 一起讀 postmortem、討論學到什麼、如何套用到全公司。Marc 認為這個機制是 AWS 成功背後「近乎因果」的核心因素之一，因為它強迫公司把最好的工程師的時間，投入到「深入理解系統為什麼這樣運作」上。

四、警惕「英雄主義」陷阱：感覺很好，卻是錯的

這段對我這種容易陷入「我撐住了就是負責」心態的人特別重要。Marc 觀察 postmortem 文化差的團隊，通常落在兩種失敗模式：

失敗模式一：對 outcome 的關注不足。 不夠在意「這個產品有沒有跑得很好、客戶有沒有真的滿意」。這是文化與領導層級的問題，在於是否設定正確的標準評估。

失敗模式二 (更難改的)：把維運英雄主義常態化。

We don’t need to fix these root causes because our on calls are superheroic and they’re going to stay up all night and they don’t mind being paged 100 times a week. — Marc Brooker

Marc 說，這種文化從內部看像是高度當責：這些人超投入、超強、熬夜 hack、被 page 一百次也不抱怨，看起來都是好訊號。但從外部看就會發現：我們根本沒在修根因，只是把一群最強、最有責任感的人，整批投進一個極度昂貴的 break-fix 迴圈。

最危險的是，這些英雄主義讓整體團隊運作感覺太好了。那種「我們很在乎客戶、很拚」的感覺，會讓人很難承認其實是在錯誤的層級上付出。真正該做的是把這股能量向外延伸，拉去想 postmortem、想根因、做更策略性的改善；一旦打破迴圈，反而會多出大量時間去把產品做好。

半夜被叫醒撐住、被 page 一百次還引以為傲，不是值得追求的勳章，而是一個該被檢討的系統訊號，畢竟個人韌性救不了結構性問題。

五、James Cowling：把抱怨換成「我來修」的當責

如果說 Marc Brooker 給了我「oncall 是學習場」的視角，那 James Cowling 給的就是面對 incident 與系統問題時的根本心態。

他回憶 Dropbox infra 團隊只有七八個人的時候，有人從 Google 加入，會說「應該要有人去建個 logging framework，不然我沒辦法做事」。James 的反應是：

Well, who is someone? Because it’s just us. It’s just us. We build it or we don’t build it. There’s no other idiots out there. We’re the idiots. — James Cowling

這種「沒有別人，就是我們」的當責 (accountability)，是一種能套用到事故應對上的心態。很多時候我們會把事故處理當成一種「被丟過來的負擔」，潛意識在等「應該有更適合的人來處理」。但很多時候，那個「應該要有人」就是當下接到 page 的你。

James 自己帶團隊時，曾特別針對 oncall 和被 page，試著把這種當責「做給大家看」：

Very specifically, with regards to on-call and people getting paged, I wanted people to have high ownership. I’d be the first one to respond to a page. I would always be writing up the reports, really falling over myself to show how I wanted people to be. But from their perspective, all they see is that the lead is just doing all these jobs. — James Cowling

他希望大家一有狀況就馬上接手，於是自己衝最前面：第一個回 page、報告全包、bug 搶著修。結果卻有點適得其反，身邊的人看到的不是「那我也該跳上去」，而是默默認定「這大概是 James 的工作」「也許他才懂怎麼弄，我不會」。這也點出一個容易被忽略的地方：當責沒辦法靠一個人全部扛下來示範，你愈是把每通 page 都攬在自己身上，別人愈容易把 incident response 當成某個特定人的事，而不是自己的事。

「這有什麼意義？誰在乎？反正就是個龐大的組織，我做什麼都改變不了」

James 接著談到一個更大的障礙：他看過太多 junior engineer 在大公司待久了，慢慢變得憤世嫉俗、覺得做什麼都沒意義。這種無力感正是讓人把 oncall、事故應對一律當成「事不關己的負擔」的源頭。

James 給的反例，是回到他自己的親身經驗：

Some of the happiest times in my life have been dedicating myself to a cause, trying really hard, and trying to do the right thing. — James Cowling

他補充，這聽起來或許有點老派，但真的做得到，尤其當你刻意去靠近一群「就是想把事情做對」的人。如果你在大公司裡被政治搞得很挫折，與其犬儒以對，不如四處找找看有沒有這樣的團隊。

對他來說這種心態不是天真或妥協，而恰恰是工程的本質，不是去堆一個複雜花俏、好拿來升遷的東西，而是「把那個能解決問題、最酷的東西做出來」。

支撐這種心態能持續的，包含另一個關鍵：把抱怨轉成「把問題接起來、把事情推動」。James 描述自己在 Dropbox 早期投入到近乎瘋狂 (一開始一天工作 16 小時，雖然他並不鼓勵這樣)，久了大家都知道他是真的在乎，他也因此累積了足夠的信任資本，敢直接表達意見，他說自己怕的不是丟工作，而是怕看著錯誤的決定被做出來。後來他帶了很多 staff+ 工程師，常遇到有人抱怨「某某地方很沒效率、我們沒在做對的事」，他不會跟著一起抱怨，而是用一個巧妙的反問，把「抱怨」重新定義成「選擇優先順序」的解決問題框架：

Do you think we should solve this problem right now? — James Cowling

如果該解，就告訴我要從哪個團隊抽人、關掉哪個產品；我來重新調度資源，現在就解。這句話其實是在提醒你：與其停在抱怨，不如把問題拉回「要不要由我們來解、怎麼解」：如果它真的重要，那就把它扛起來、投入時間把它做完；如果不是，也坦白承認此刻有更該做的事，把焦點放回更值得的地方。

James 的結論是：真正會往上走的人，通常不是最會抱怨的人，而是那些願意站出來說：「我覺得這方向不對、這裡有個更好的做法、我願意負責把它推到底」的人。

如果把這套邏輯套用到 oncall，事故應對就不只是被迫救火，而是一次「我來把問題解決」的選擇。當我把它從「被指派的威脅」改寫成「我願意把問題接起來處理」，那種被動的焦慮感將會減少。

六、我們可以怎麼調整自己的 oncall 心態

結合這兩篇訪談，以及上一篇的結構與睡眠視角，總結幾個我們可以重新定義 (reframe) 對 oncall 工作的認知：

• 把每次 incident 當第一手教材：事後花時間問自己「這次學到什麼原本不知道的系統行為？」，把它寫進個人 runbook 或筆記。Oncall 真正的產出是從事故中的學習質量，而不是關掉 Ticket 的數字。
• 分流注意力：遇到重複性 toil，先想「這能不能自動化」；遇到沒看過的怪事，允許自己慢下來深挖，那才是高價值時段。
• 寫多層次的 postmortem：不要停在 code bug，往測試流程、團隊流程、甚至「為什麼當初這樣假設」一路問下去；跨事件看到可以優化的模式時，就提議把它做成工具。
• 拒絕英雄主義：被 page 一百次不是榮耀。如果我發現自己反覆在救同一把火，那就是該在回顧會議上提出結構性修復的訊號，而不是咬牙撐住的理由。
• 用當責取代等待：接到 page 時，別再等「應該會有更適合的人來處理」，而是提醒自己「就是我們，沒有別人」。事故應對不是接下別人丟來的包袱，而是主動把問題接起來、負責到底。

結語

兩位工程師的職涯路線差很多，但講到 oncall，看法卻意外地接近。兩者的共通點均透露出它不是一件該想辦法閃掉的苦差事。Marc Brooker 願意持續 oncall 十五年，是因為他把事故和 postmortem 當成累積系統知識最快的管道；James Cowling 的版本更樸素，就是那句「沒有別人，就是我們」的心態，遇到問題與其空等，不如自己接起來。

oncall 的代價當然是真的，焦慮、被打斷的睡眠、隨時待命的壓力，上一篇也花了不少篇幅談怎麼防禦。只是把這兩段訪談擺在一起會發現，光是排斥它其實什麼也改變不了。這些訪談告訴我們，也許只要換個角度，重新認識這項工作，並在每次 incident 裡多弄懂一些原本不理解的系統行為，就能以全新的視角看待它，建立起更正向積極的心態，也就不再覺得這是一份苦差事。

參考資料

• Dropbox’s Former Most Senior Eng: Building Great Systems and Advice for the AI Era — James Cowling (The Peterman Pod, 2026-05-25)
• AWS Distinguished Eng: Learnings From 3000 Incidents And How Engineering Is Changing — Marc Brooker (The Peterman Pod, 2026-04-13)
• 延伸閱讀：Pager 沒響卻聽見警報？Oncall 工程師的睡眠與焦慮指南