Pager 沒響卻聽見警報？Oncall 工程師的睡眠與焦慮指南

身為要 Oncall 的工程師，下面這幾種狀況大概都不陌生：pager 沒響，腦海中卻隱約聽到警報，拿起手機才發現是錯覺；半夜被叫醒進客戶會議，腦袋還沒清醒就被要求回答問題；下班想閉眼放空 5 分鐘，腦袋反而比工作時更停不下來；oncall 都已經結束了，還是會無意識地點開值班時那些沒處理完的調查。

剛開始我以為這些反應只是個人韌性不夠或職業倦怠 (burnout)，後來把相關文獻翻過一輪才發現，這些反應在臨床和職業健康研究裡都有名字、有研究、也有對策。這篇文章是我整理的閱讀與實作筆記，把 oncall 相關的現象、研究證據、以及可以開始做的個人對策放在一起。

如果能對 SRE、軟體工程師、TSE / Customer Support、DevOps、平台工程師，或任何要扛 pager 的角色有幫助，就太好了。oncall 焦慮從來不是純粹的個人問題，所以下面會先談結構性問題（alert design、rotation 設計），再回到個人層面能做的事。

TL;DR：如果你只想先做三件事

如果只能挑三件事去做，優先順序如下：

• 先檢查 alert 設計：如果一輪 oncall 超過 2 個真正需要處理的 incident、或大量 alert 不需要 action，問題優先在系統設計，不在個人韌性。
• 建立 wake-up protocol：半夜被 page 不要直接坐到電腦前。先用水、冷水、光、動作把睡眠惰性降到最低，必要時再用咖啡因。
• 把 oncall 週當成 60–70% 工作量：不安排深度工作、重要面試、高風險決策，把 standby 當成工作狀態，而不是失敗的休假。

剩下的章節是這三件事的研究依據、機制解釋與細節操作。

mindmap
  root(("Oncall 工程師<br>身心生存指南"))
    為什麼這麼累<br>機制與名稱
      Phantom Vibration<br>幻覺震動
      Hypervigilance<br>過度警覺
      Operant Conditioning<br>操作制約
    結構先於個人
      每輪班最多 2 個 incident
      警報分級與調校
      單地 8 人或雙地各 6 人
      Runbook 維護與更新
    睡眠是底線
      Sleep Inertia<br>剛醒等同酒駕
      Wake-up Protocol<br>水 冷水 光 動
      就寢規律 ±1 小時
      睡前 60-90 分鐘收尾
    Standby 是隱形勞動
      待命本身就在工作
      Attention Residue<br>注意力殘留
      Ready-to-resume Plan
      只在響的時候反應
    Oncall 週的節奏
      規劃 60-70% 工作量
      低認知負擔活動
      Page 後爭取 5 分鐘 buffer
      極低門檻成就清單
    不同角色的痛點
      SWE 或 Platform Engineer<br>深度工作被打斷
      SRE 或 DevOps<br>警報量加跨團隊
      Customer 或 TSE<br>客戶情緒加廣產品線
    何時找專業協助
      恐慌發作或解離
      持續失眠或幻聽
      用酒精藥物紓解
      CBT 或 EMDR 治療

Oncall 焦慮有名字和研究依據

我值 oncall 的時候，常常會莫名焦慮，甚至自我懷疑：「為什麼別人 oncall 都好好的，只有我這麼焦慮？」和主管、同事聊過幾次之後，我整理出幾個可能的原因：

• 對事情的不確定性感到焦慮
• 擔心遇到未知的技術問題或事件時，不知道該怎麼處理
• 怕搞砸了一切

這些心理因素會驅動一連串生理反應。比如說，明明值班時段很安靜，我有時候卻會莫名感覺手機在震動、聽到警報聲或訊息鈴聲，誘發緊張與焦慮。但這些反應不是個人韌性不足，而是大腦對長期、不可預測的警報訊號所做的合理適應。

有些心態上的調整也許有助於緩解焦慮，例如：

• Pager 響起時，沒有人期待你當下就把根本原因徹底解決；重點是先止血，或找人一起止血
• 先想清楚：就算 Pager 搞砸、或問題暫時解不出來，最糟的後果是什麼。把最壞情境具體化後，通常就沒那麼可怕。
• 別人急，但我不急。我需要比周遭的人更平靜，才能把問題解決。

此外，先弄清楚這些反應的名稱與文獻證據，是處理它們的第一步，當你知道「幻聽 alert」有 95% 的同行也會經歷，自我責備往往會少很多。

Phantom vibration syndrome（幻覺震動症候群）

Rothberg 等人（2010）發表在 BMJ 的橫斷面調查估計，約 68% 的醫療人員曾經歷過幻覺震動（Rothberg et al., 2010, BMJ ¹）。Lin 等人（2013）發表於 PLOS ONE 的研究也指出：他們追蹤 74 位醫療實習生，實習開始時已有 78.1% 經歷 phantom vibration、27.4% 經歷 phantom ringing；到了實習第三個月，比例分別升至 95.9% 與 84.9%，第六個月仍維持在 93.2% 與 87.7%。在這項研究中，焦慮與憂鬱分數雖然也在實習期間同步上升，但作者特別指出，幻覺震動與鈴聲的盛行率變化並不能簡化為焦慮或憂鬱的直接結果，而比較像是高壓環境下常見的知覺適應現象（Lin et al., 2013, PLOS ONE ²）。Chen 等人 2014 年的橫斷面研究進一步發現，幻覺震動症候群與職業倦怠呈獨立關聯，可能是工作壓力的早期指標，而非單純由焦慮或憂鬱造成（Chen et al., 2014 ³）。

當大腦被訓練成「任何震動或鈴聲都可能是緊急警報」，訊號偵測門檻會被拉低，容易把雜訊（衣服摩擦、心跳、冷氣聲）誤判為警報。oncall 結束後還在聽幻覺警報不是神經質，而是大腦的偵測模型還沒回到原本的校準。

Hypervigilance（過度警覺）

從 AWS 離職後，我現在聽到 Amazon Pager 警報的聲音還是會被嚇到；相比之下，Google 的警報聲溫和得多。這不是在比品牌，只是想舉一個直覺的例子：警報的聲音設計，會直接形塑神經系統的反應。當警報聲刺耳、急促、音量又大，大腦會把它當成危險訊號，久而久之形成制約反應；之後只要聽到接近的音頻或節奏（甚至只是手機通知音、電梯聲），交感神經就會先被啟動，心跳加快、肌肉緊繃、呼吸變淺。反過來說，如果警報被設計得「能辨識但不嚇人」，再搭配分級（最緊急的才用最強的聲音，其他用溫和提示）與合理的噪音控管，身體就不會被反覆訓練成長期的過度警覺狀態。

Hypervigilance 是 PTSD 的核心症狀之一，但它不需要創傷事件就能被誘發。Oncall 環境本身就具備所有訓練過度警覺的條件：觸發不可預測、風險高、睡眠被打斷或片段化、缺乏明確的下班邊界。

Dettmers 等人 2016 年在 Journal of Occupational Health Psychology 的研究做了一件關鍵的事：他們比較員工在「非工作時間需要保持可用」與「不需要保持可用」這兩種日子。結果顯示，光是 extended availability（延伸可用性）本身就會限制恢復經驗，並與隔天早上的情緒與皮質醇 (Cortisol) 變化有關（Dettmers et al., 2016 ⁴）。Ziebertz 等人的大型調查研究也指出，與其說 oncall 的負擔只取決於時數，不如說「不可預測性帶來的壓力」、「待命期間無法放鬆」與「活動受限」更能解釋疲勞、工作家庭干擾與主觀表現困難（Ziebertz et al., 2015 ⁵）。

換句話說，神經系統並不太區分 standby 和 on duty。這也解釋了為什麼我多次在 oncall 期間試圖閉眼冥想，反而更焦慮：平常我們用工作、會議、滑手機等外部刺激蓋過內在的警戒訊號，一旦坐下來閉眼，背景的 “hypervigilance” 就會浮到意識層，就像耳鳴的人在安靜房間裡耳鳴最大聲。

Operant conditioning（操作制約）

Pager 鈴聲、Slack ping、手機震動，已經被杏仁核學習成高強度的條件刺激。即使 oncall 結束，這條「訊號 → 焦慮」的反射迴路還在，要等大腦慢慢把這個連結淡忘（心理學稱為 extinction，消弱反應）才會減弱。這解釋為什麼很多人 oncall 結束後幾天仍然會習慣性檢查手機，條件反射不會因為輪班結束就立刻消失。

結構性問題優先：先檢查警報設計

oncall 焦慮很多時候不是個人韌性問題，而是警報設計的問題。如果工作環境結構性已經讓人崩潰，再多個人技巧也只是把崩潰時間往後拖。

Expect to handle no more than two events per on-call shift (e.g., per 12 hours): it takes time to respond to and fix outages, start the postmortem, and file the resulting bugs. More frequent events may degrade the quality of response, and suggest that something is wrong with (at least one of) the system’s design, monitoring sensitivity, and response to postmortem bugs. — Google SRE Book, Service Best Practices

也就是說，一個輪班最多兩個 incident 是 Google 認為「可學習、可恢復」的上限。超過這個量，工程師就無法好好分析、好好寫 postmortem，學不到東西，而且會很快疲乏。Google 同時建議單地 oncall 團隊至少 8 人（在「on-call 不超過 25% 工時」的前提下，剛好支撐 primary/secondary 雙輪值）；若採跨地理區域的 follow-the-sun 輪值，每地至少 6 人（總計 12 人以上），避免長期夜班 page。

業界真實狀況通常離這個標準很遠。我自己的經驗是，如果一個輪班收到超過 5 個需要實際處理的警報、超過 30% 的警報不需要任何後續動作、同一個服務每天反覆觸發（flap）多次、runbook 不存在或已過期、或者少於 5 個工程師分擔 24/7 輪值，那麼重點應該優先放在改善警報設計，而不是個人技巧。這些都是團隊層級的問題，在團隊回顧會議或 postmortem 上提出來、推動警報調校、爭取人力，比一個人苦撐健康得多。

睡眠是 oncall 的底線

如果 oncall 時間橫跨半夜，對睡眠的破壞不只是「半夜被叫醒」，它同時破壞了三件事：被叫醒當下的認知能力、整個 oncall 週期的睡眠規律性、以及 oncall 結束後的入睡能力。

Sleep inertia：被叫醒進會議別期待自己能保持理智

Sleep inertia（睡眠惰性）指的是醒來後一段時間內，認知能力和反應速度暫時下降的狀態。多數人早晨的睡眠惰性持續 15–30 分鐘，嚴重時可達數小時（Hilditch & McHill, 2019, Nature and Science of Sleep ⁶）。

最戲劇性的是 Wertz 等人 2006 年發表在 JAMA 的研究。他們直接比較「剛睡醒」跟「已經連續清醒」狀態下的認知表現，結論很反直覺：剛睡醒那段時間的認知缺損，可能比延長清醒造成的疲勞更嚴重（Wertz et al., 2006, JAMA ⁷）。研究主筆 Wright 在新聞稿裡的說法更直接：這段時間的影響可能跟法定酒駕差不多。更壞的消息是，Scheer 等人 2008 年的研究發現，在生理夜間（biological night）被叫醒時睡眠惰性的強度最大（Scheer et al., 2008, J Biol Rhythms ⁸），這正是 oncall 半夜 page 你進客戶會議的場景。

換句話說，你不是不夠專業，而是在認知能力剩一半、酒駕等級的狀態下被要求執行工作。半夜表現不好不是個人問題，是生理事實。

Wake-up protocol：先降低剛醒前幾分鐘的混亂與決策負擔

這個流程適用於兩種情境：oncall 早班的起床，以及半夜被 page 之後必須立刻進入客戶會議或做關鍵決策。如果只是半夜被叫起來確認警報、處理完還會回去睡，就只做下面的物理喚醒（水、冷水、光、動、呼吸），跳過咖啡那一段，否則會破壞接下來的睡眠。

我們無法控制什麼時間點被呼叫，但可以控制環境。比如前一晚先把環境準備好：床邊放一杯水（500ml），起床第一件事直接喝完；起床時打開燈光，「光」是最強的喚醒訊號；一套 oncall 衣服放在椅子上，省去想穿什麼的決策成本。這些都是降低「起床後的決策負擔」，因為剛醒的腦袋本來就不適合做決策。被叫醒之後：

• 先把那杯水喝完（脫水會放大睡眠惰性）
• 冷水洗臉 30 秒，可觸發哺乳類潛水反射（mammalian dive reflex），可能幫助降低生理唤起與焦慮。目前並沒有堅實證據顯示它能直接縮短 sleep inertia，但主觀上多數人會覺得清醒一點
• 如果天亮了，走到窗邊看天光 30–60 秒，即使陰天戶外照度也比室內高 10–100 倍
• 整個流程大約 3–4 分鐘，比直接坐到電腦前的清醒度差很多

關於咖啡因攝取，只有在「確定不會再回去睡」的場景才喝，也就是 oncall 早班起床、或天快亮被 page 進客戶會議。坊間常聽到「起床先別立刻喝咖啡，會與皮質醇高峰衝突、容易產生耐受性」這類說法，但目前的研究證據其實相當薄弱（皮質醇覺醒反應的個體差異很大，咖啡因耐受性與攝取時間點的因果關係也尚未有定論）。實務上，比較安全的做法是先把物理唤醒（水、冷水、光、動）做完，等身體真正開始醒、需要進一步提神時再喝，而不是把咖啡當開機鍵。如果是半夜被 page 起來處理 incident、結束還要回去睡，就不應該喝咖啡影響睡眠。

睡眠規律比睡眠時長更重要

很多人以為睡眠就是「夠不夠長」。但 Windred 等人 2024 年發表在 SLEEP 期刊、用 UK Biobank 超過 60,000 名受試者的大型研究有一個反直覺的發現：睡眠規律性比睡眠時長更能預測死亡風險（Windred et al., 2024, SLEEP ⁹）。具體數字上，相較於規律性最差的五分位族群，最規律的族群全因死亡率風險低 20–48%、癌症死亡率低 16–39%、心血管代謝死亡率低 22–57%，而且這個效應強於總時長的影響。

對 oncall 工程師來說，這個發現的意涵是：oncall 排班可能很難改，但你可以把就寢時間當主變數來控制。我的做法是先決定起床時間，再反推上床時間，公式很簡單：

就寢時間 = oncall 開始時間 − (60 分鐘暖機 + 8 小時睡眠 + 15 分鐘入睡延遲)

舉例來說：

• 8 AM 開始 oncall 的話 22:30 上床
• 6 AM 開始 oncall 的話 20:45 上床
• 9 AM 開始 oncall 的話 23:30 上床

關鍵不是「幾點睡」，而是讓 oncall 週與非 oncall 週的就寢時間差異控制在 1 小時內。最常見的誤區是 oncall 一結束就熬夜「補償自己」，這會把規律性破壞得比 oncall 期間還嚴重，等於前面的努力白費。週末就寢時間與平日差異控制在 1 小時內也是同樣的道理，社交時差（social jet lag）對代謝、心血管、認知的負面影響有明顯的劑量反應關係。

睡前 60–90 分鐘的收尾時段我會做幾件事：停止工作和 Slack（讓大腦從交感切回副交感），調暗燈光（啟動褪黑激素（melatonin）自然分泌），不滑手機（藍光加焦慮內容雙重打擊），不喝酒（酒精破壞 REM，對 oncall 焦慮特別致命），房間溫度維持 18–20°C（核心體溫下降是入睡訊號）。這些聽起來都很常識，但 oncall 期間越焦慮越會偷懶不做，反而把睡眠搞得更糟。

Oncall 期間的可持續節奏

我很常會因為在 oncall 期間試圖「放鬆」，然後因為放鬆不下來而對自己生氣，且常常覺得時間過了一事無成，焦慮加倍。特別是周末必須待命不敢亂跑的心情，但 Standby 本身就是一種有效的工作狀態，不要試圖把它過成休假。

待命 = 隱形勞動

你的身體其實一整天都在工作：皮質醇偏高、注意力分配在「Pager 會不會響」上、決策能力被預留給可能的事故。但這種勞動沒有 code commit、沒有 ticket close、沒有照片可以發 IG，所以大腦找不到證據證明這天有做事。

Attention residue（注意力殘留）

Leroy（2009）發表在 Organizational Behavior and Human Decision Processes 的研究提出「注意力殘留（attention residue）」的概念：當你從任務 A 切換到任務 B，部分注意力仍會停留在 A 上，特別是當 A 還沒完成、或沒有明確的收尾點時。這個殘留會在統計上顯著降低你在 B 上的認知表現（Leroy, 2009, OBHDP ¹⁰）。

（補充：原始研究只證明「有顯著下降」，並沒有量化成「腦力剩一半」這種直觀比例，後者是流行寫法的簡化。）

Oncall 是注意力殘留的極端情境：A（隨時可能來的 page）永遠不會關閉，所以你做的每件「私人時間」都帶著殘留。看書記不住、追劇沒劇情、跟朋友訊息心不在焉，不是你不專心，而是大腦的注意力被預留在一個永遠開著的任務上。這個延伸是我自己對 oncall 情境的解讀，不是 Leroy 原始實驗的結論。

後續 Leroy 與 Glomb（2018）在 Organization Science 提出 ready-to-resume plan 作為對策：被打斷時，花一兩分鐘寫下「我做到哪、下一步要做什麼」，明確的書面收尾能讓大腦相信任務不會丟失，就能比較乾淨地切換到下一件事（Leroy & Glomb, 2018, Organization Science ¹¹）。應用到 oncall 上：每次處理完一個事件、要回到原本的活動之前，花一分鐘記下「事件編號、目前狀態、下一步觀察什麼條件、什麼情況會再被叫」，比直接放下手機回到家事或閱讀輕鬆得多。

我自行嘗試的策略

可以嘗試應用認知行為治療法 (Cognitive Behavioral Therapy, 縮寫作 CBT)，反轉對於值班的看法：例如心態上把週六 6AM-6PM 直接畫成「工作時間」。下班後（6PM 後）才是你的週末。這樣你不會用「正常週末」的標準去評價它，也就不會覺得失敗，一個被工作占用的日子通常就不太長得像自由的日子。

Oncall 時也可以給自己一個極低門檻的「成就清單」：

• 走路 15 分鐘（不離家太遠）
• 讀完一章書 / 一篇文章
• 煮一杯像樣的咖啡 / 拍一張照片
• 寫三行日記

每天勾一項就算數，給予大腦可觀測的證據：今天有發生事情。沒有這個錨點，待命狀態會把整天吞掉，心理很容易感受一事無成。

我會把 oncall 週當成 60–70% 工作量的一週來規劃：不排需要深度討論的會議、需要長時間專注的深度工作、學新技術、面試，保留緩衝時間應付頻繁的工作切換。比起照常排 100% 然後因為 incident 一直崩潰，這個做法可持續得多。

至於 oncall 期間怎麼度過 standby 時間，重點是用「低認知負擔活動」取代純放鬆。冥想對處於過度警覺狀態的人，前期通常會放大焦慮，因為它逼你去注意內在訊號。改用讓大腦有 70% 被佔住、留 30% 可以接 page 的活動會輕鬆很多，例如散步（戶外尤佳）、煮飯洗碗整理房間、拼圖這類簡單手工、聽 podcast 而不是純音樂（大腦有東西抓著就不會放空亂想）。這些活動的共同特徵是有節奏、有回饋、低決策負擔。

另一個常見的壞習慣是每 5 分鐘檢查 dashboard 或 Slack，這是強迫式的反覆確認，會強化焦慮迴路。原則很簡單：只在響的時候反應。如果你不信任自己的警報系統，那是警報設計的問題（回到前面那段），不是用更頻繁的手動檢查能解決的。

被 page 進會議前，先爭取 5 分鐘緩衝

Oncall 通常會設定對應的 Response SLO：在這個機制下，若在一定時間內沒有回應，就會繼續升級。不論是 incident channel、客戶會議，或主管把案子升級給你，除非是火燒屁股的 P0 等級事件需要直接加入，否則都應妥善利用 SLO 的設計，為自己保留緩衝時間進行反應。這也意味著，我在接到 Pager 並完成 Ack 之後，可以：

• 先上個洗手間、倒杯水，再回到鍵盤前
• 先稍微收尾手邊的事項，或簡單記錄目前進度
• 如果是熟悉的服務，順手翻最近一次相似事件的 postmortem 或對應的 runbook，把「上次怎麼處理」放進工作記憶

我也常想著：別人急，但我不急。我需要比周遭的人更平靜，才能把問題解決。如果有人一直在催，可以嘗試溝通：

Give me 5 minutes to spin up — I’ll join with context.

如果是半夜被叫醒，這 5 分鐘多少能降低睡眠惰性的傷害，並建立最低限度的狀況掌握。帶著背景晚到 5 分鐘，遠遠好過狀況不明就準時加入。

不同角色的補充建議

不同 oncall 角色面對的痛點不太一樣，下面針對幾種典型角色補充。

Software Engineer 或 Platform Engineer

主要的 oncall 痛點是深度工作被打斷，但 incident 頻率不一定高。比較有效的做法是 oncall 週完全不排專注時段或重要的 PR review；standby 期間挑小任務做（code review、文件、技術債、學習），順便利用 oncall 的空檔改善自己 service 的警報和 runbook，這對下一輪 oncall 的同事也是直接的回饋。

SRE 或 DevOps

主要的 oncall 痛點是警報通知量加上跨團隊協作。如果團隊願意採用 Google SRE 的「2 incidents per shift」原則來校正警報設計則能夠有效降低不必要的勞務型工作 (Toil)；每次 oncall 結束做一次個人回顧，問自己哪些 alert 是雜訊、哪些 runbook 該補。Postmortem 文化是減壓最有效的長期工具，不究責的回顧能讓 incident 變成學習，而不是創傷。

Customer Engineer 或 Technical Solution Engineer 角色

這類角色比較特殊，尤其在面對 VVIP 或 Premium 客戶時更是如此。這個角色的挑戰在於：你不只要解決問題，還要管理客戶情緒；產品線範圍太廣，無法每個都熟；客戶往往期待立即回應。

這時候可以把這個角色定義成 incident commander，而不是 SME。VVIP oncall 的工作是搞清楚問題的影響範圍（多嚴重、影響誰）、降低客戶焦慮（讓他們知道有人在處理）、找對的人（把問題交給負責的 team）、維持固定的溝通頻率（每 X 分鐘更新一次）。「我不知道」是合理的回答，只要後面接著「但我會找到知道的人」。對客戶的標準話術可以是：

I’m not the SME for this specific component, but I’m pulling in [team] now. In the meantime, let me confirm the impact so we can prioritize correctly.

這句話的好處是誠實說不熟（建立信任）、給出下一步（降低焦慮）、把話題重新導向你能掌控的問題。另外，非 oncall 時間建立個人 runbook 對 TSE 角色特別重要：每次遇到不熟的產品花 15 分鐘記下它是做什麼的（一句話）、常見的失效模式（3 個）、該找誰（team / Slack channel / on-call rotation）、dashboard 在哪。兩三個 oncall 週期累積下來，你將會有一份比官方 runbook 更實用的個人速查表。

何時該找專業協助

雖然 oncall 焦慮在某個範圍內是合理的職業適應，但下面這些訊號出現時，請尋求專業的醫療建議：

• oncall 結束後 1–2 週仍然無法放鬆或停止檢查 Slack
• 開始害怕下一次 oncall（不只是不喜歡）
• 影響到非工作時間的關係、興趣、食慾
• 出現恐慌發作（突然心跳加速、呼吸困難、覺得快死了）
• 用酒精、藥物、暴飲暴食來抒解
• 出現解離、揮之不去的侵入性念頭、或入睡前的警報幻聽

這些狀態不一定等同於正式的 PTSD 診斷，但在臨床語言裡，已經可以用 hypervigilance、occupational stress、睡眠障礙、焦慮反應、甚至創傷相關症狀來理解。對於 PTSD 或創傷相關症狀，trauma-focused CBT 與 EMDR 都是常見且有證據基礎的治療選項；實際需要幾次治療，仍取決於症狀嚴重度與個人背景。英國 Royal College of Psychiatrists 也提到，PTSD 的心理治療常見安排約為 8–12 次，但複雜情況可能需要更久。最重要的是不要拖到「我快崩潰」才去看；預防性地接觸專業協助，效果更好也更便宜。這不是脆弱，是職業傷害——就像 RSI 是長期打字的職業傷害，hypervigilance 是長期 oncall 的職業傷害。

結語

Oncall 是現代分散式系統的必要稅，但這個稅可以、也應該被設計得可持續。如果只能挑三件事：這週盤點 alerts，把不需要立即處理的關掉聲音或改成視覺提示；下次 oncall 嚴格執行 wake-up protocol（水 → 冷水 → 光 → 動 → 呼吸）；長期把就寢時間規律性控制在 ±1 小時內。

身體出現幻覺警報、被叫醒時無法決策、standby 時無法放鬆，這些都是有研究、有名稱、有對策的生理反應，不是個人韌性問題。結構性層面（alert tuning、rotation 設計、blameless culture）是團隊的責任，個人層面（睡眠、營養、運動、心理工具）是你能掌控的部分，兩者缺一不可。

每個人的工作環境、生理節奏、團隊文化都不一樣，這篇整理也不見得每一條都適合。重點是先理解這些反應背後的機制，再挑出適合自己情境的工具反覆試驗。

參考資料