現在是週六凌晨三點，你正沉浸在難得的深層睡眠中。突然，床頭櫃上的手機像心臟病發作一樣，開始瘋狂地震動，螢幕在黑暗中閃爍著刺眼的光芒。你睡眼惺忪地拿起手機，發現螢幕已經被一連串來自公司 Slack 的紅色警報通知給淹沒。

[Alert] API Gateway: Abnormal traffic pattern detected.

[Alert] MongoDB Atlas: Connection pool saturated.

[Alert] MongoDB Atlas: Disk I/O at 100%.

[PagerDuty] INCIDENT #1234 - CRITICAL - Core User API unresponsive.

你的心跳瞬間漏了一拍，睡意全消。你立刻從床上彈起來打開筆電，連上公司的網站，螢幕上只剩下那個冰冷的錯誤頁面：「503 Service Unavailable」。

緊接著，你的手機和電腦上的通訊軟體開始同步爆炸。

技術主管直接打了語音電話過來，背景音滿是鍵盤的敲擊聲；客服主管在 Slack 上瘋狂私訊你，傳來一堆憤怒用戶的截圖；行銷主管則在另一個群組裡 @all，焦急地問著廣告費是不是在白白燃燒。

資訊從四面八方湧來，沒有統一的窗口，沒有既定的流程。你看著螢幕上混亂的訊息、手機上閃爍的未接來電，聽著窗外寂靜的夜色，感覺自己就像災難電影中那個第一次上戰場、完全不知所措的菜鳥指揮官。恐慌、混亂、壓力像海嘯一樣，瞬間將你淹沒。

症狀診斷

當你經歷這場午夜驚魂時，你的專案正遭受最致命的急症：系統心肌梗塞。

這個病症的根源，並非是 Bug 本身，因為任何系統都必然會出錯。真正的病根，在於團隊缺乏一套事先演練過的緊急應變計畫。

在災難發生的當下，一個沒有準備的團隊，會像一群無頭蒼蠅，陷入混亂的惡性循環：

• 工程師在多方壓力下，手忙腳亂地尋找問題。
• PM 為了回應各方詢問，不斷地去打擾正在救火的工程師。
• 錯誤的資訊在不同頻道間流竄，造成更大的混亂與誤判。

千萬不要在此刻成為混亂的傳聲筒與擴音器，我們需要立刻化身為冷靜的**急診室醫師，**拿出我們的專案急救箱，有條不紊地開始執行搶救流程。

此刻你的工作重點不是只問「為什麼會發生這種事？」，而是能夠立刻回答「我們現在該做什麼？」

處方籤

這份處方，就是你的專案急救箱。請務必在專案還很健康的時候，就和團隊一起把這個箱子準備好，並放在隨手可及之處。

第一劑：建立戰情室，集中資訊

災難發生時，最忌諱的就是資訊散落在四處。

• 你該做：立刻建立一個專屬的溝通頻道（例如 Slack 的 #war-room-20250831 頻道）或視訊會議連結，並將所有相關人員（工程師、維運、客服、主管）都拉進來。並公告：從此刻起，所有關於這次事件的討論，只在這個頻道進行。

第二劑：指派救災角色，明確分工

在緊急時刻的混亂是來自於權責不清，你需要立刻指派幾個關鍵的臨時角色！

• 指揮官：通常由技術主管或最資深的工程師擔任。他的唯一任務，就是帶領技術團隊解決問題，他擁有最高的技術決策權，並且不需要對外溝通。

• 溝通官：這個角色就是身為 PM 的你。你的唯一任務，就是負責對內部所有熱鍋上的螞蟻們溝通，你要保護指揮官不被外界打擾，並定期將戰情室的進度，轉換成各方能理解的語言，同步出去讓他們理解。

• 記錄官：指派一位細心的團隊成員，負責記錄戰情室中所有的重要決策、行動與時間點。這份紀錄將是事後複盤的無價之寶。不過在人力極度緊繃的情況下，這個角色也常會由身兼溝通官的 PM 一併承擔。若如此，PM 應盡量使用預設的模板或簡潔的條列式來記錄，避免在溝通與記錄之間手忙腳亂。

  • 簡易記錄模板：[時間戳記] [誰] [做了什麼決策/發現了什麼]
  • 範例示意：
    • [01:35] 阿傑決定先嘗試重啟服務。
    • [01:42] 重啟無效，決定執行版本回退。
    • [01:55] 版本回退完成，服務恢復。

第三劑：執行救災 SOP，穩定局勢

你的急救箱裡，必須有一份事先就和團隊討論好的標準作業流程 SOP，下面提供一個範例可以參考，而實際的 SOP 在不同的團隊協作上一定會有變化的空間。

1. 評估衝擊
   在救火的同時，你需要快速釐清災情的嚴重程度。你可以透過詢問指揮官或相關團隊，快速回答以下問題：
   • 影響範圍：是全部用戶還是部分用戶（例如：iOS 用戶）？是哪個國家或地區的用戶？
   • 核心功能：用戶是否無法登入或付款？還是只是次要功能異常？
   • 商業衝擊：對公司營收、品牌聲譽的即時影響有多大？
2. 緊急止血
   在找到病根前，首要目標是讓病人先恢復心跳。你需要和指揮官快速討論出最快的止血方案，常見的選項有：
   • 版本回退 Rollback：這是最安全、最推薦的首選。
     • 適用時機：當問題高度懷疑是由最近一次的程式碼更新或系統部署所引起時。
     • 核心原因：先退回到上一個已知的穩定版本，讓服務恢復正常運作，再慢慢找問題。這是風險最低、也最能快速驗證問題點的方式。
   • 重啟服務 Restart：這是快速的臨時解方，但很可能治標不治本。
     • 適用時機：當問題表現為服務逐漸變慢、無回應，且懷疑是記憶體洩漏、連線池耗盡等資源消耗型問題時。
     • 核心原因：重啟能快速釋放被佔用的資源，讓服務暫時恢復活力，為找出根本原因爭取時間。
   • 緊急修復 Hotfix ：這是最高風險的選項，需要極度謹慎。
     • 適用時機：當問題並非由最近的版本變更引起，而是由外部因素導致時（例如：DDoS 攻擊導致流量癱瘓、第三方服務異常、潛藏已久的 Bug 被特殊操作觸發），且回退和重啟都無法解決根本問題時。
     • 核心原因：在確認問題來源後（如識別出攻擊 IP），直接採取應對措施（如與維運團隊合作啟用防火牆規則、切換 CDN 防護模式），以最快速度阻斷異常流量，解決問題。若是潛藏 Bug，則是在確認修改範圍極小、風險可控的前提下，直接部署微小的修補程式。
3. 找出病根
   在服務暫時穩定後，才開始深入調查問題的根本原因。
4. 解決問題
   部署修復程式，並持續監控。
5. 事後複盤
   在事件結束後，召開複盤會議，找出可以改進的地方，避免未來重蹈覆轍。

臨床實戰

好，讓我們回到那個讓你無法好好睡覺的週六凌晨。

當警報響起時，如果你身邊有這個專案急救箱，你可以怎麼做？

1. 啟動戰情室：
   你沒有在原本混亂的頻道裡回覆，而是立刻開了一個新的 Slack 頻道 #war-room-incident-1234，把所有人拉進來，並公告：「各位關於本次服務中斷，所有討論將在此集中進行。」
2. 指派救災角色：
   你立刻在頻道中 @所有人：「現在，我們啟動緊急應變計畫。@技術主管(阿傑)，請你擔任指揮官，帶領團隊專心救災，所有技術決策由你定奪。我將擔任溝通官，負責跟大家匯報所有狀況，如果有任何需要釐清的項目，都請告訴我。@小梅，請你擔任記錄官，幫我們記下所有重要的時間點。」
3. 執行救災 SOP：
   你可以對指揮官阿傑說：「阿傑，請先評估，我們最快的止血方法是什麼？版本回退可行嗎？」
   在阿傑帶領團隊執行回退的同時，你必須當下在剛剛建立的專屬頻道中，發布狀況更新：「【狀況更新 03:30 AM】各位主管，目前服務中斷，技術團隊已成立戰情室全力搶修中。初步的行動是先將系統回退至前一個穩定版本，目標在 30 分鐘內先恢復服務。詳細原因仍在調查，我會在 04:00 AM 提供下一次更新。」

有了明確的緊急應變流程，你的團隊可以更加冷靜且有條理地面對危機，避免慌亂中做出不當決策。這套標準作業程序不僅可以縮短服務中斷的時間，更能確保團隊成員在高壓環境下依然保持清晰的思考，並有系統地解決問題。即便是凌晨三點被叫醒面對一場全面性的系統崩潰，有了這個急救箱，你也能夠從容應對，將混亂的情況逐步引導回正軌。

特別門診：災後重建

一場災難，如果沒有帶來學習，那就只是一場純粹的災難。傳統的檢討會人多嘴雜，大家因為害怕究責而不敢說真話，你可以透過以下三個步驟，整理出最終要給老闆的檢討報告。

第一帖：會前訪談，一對一還原真相

在召開任何會議前，單獨找幾位在第一線救火的核心成員（工程師、維運、QA），進行一對一訪談。

你的目的不是問「這是誰的錯？」，而是問「可以帶我走一次你當時看到的時間軸嗎？」。你要做的是拼湊出客觀的事實經過，並理解他們當時面臨的困難與資訊落差。這個步驟能讓你在心理安全的環境下，收集到最真實的情報。

第二帖：拼湊客觀事實，而非收集主觀意見

在訪談後，你的下一步是整合所有情報，建立一份客觀的事件時間軸。這份文件只包含事實，不包含任何猜測或評論。

首先需要整理所有的資料，如系統 Log、警報紀錄、戰情室的對話紀錄、以及一對一訪談的內容。

以下是產出範例：

• 03:01 - 系統發出第一筆 CPU 過高警報。
• 03:05 - PagerDuty 通知值班工程師阿傑。
• 03:10 - 阿傑登入系統，發現資料庫連線數異常。
• 03:15 - PM 建立戰情室。

客觀的事件時間軸，將成為後續討論的唯一事實根據，它能盡量將團隊的注意力從「是誰的錯」，轉移到「當時發生了什麼」。

第三帖：聚焦流程的複盤會議

現在相關資料都整理的差不多了，如果有需要的話，還可以召開一場小規模的複盤會議，這個會議的參與者建議僅限於核心的技術團隊。

會議討論流程

1. 開場定調：重申「無責備原則」，強調目標是優化流程。
2. 展示時間軸：帶領團隊快速過一遍客觀的事件時間軸，確保大家對事發經過有共同的認知。
3. 找出系統性問題：針對時間軸上的關鍵節點，引導團隊進行「5個為什麼」的討論。例如：「從警報發出到有人處理，中間有 9 分鐘的延遲，為什麼？ -> 因為通知只發到 Slack，而阿傑當時沒在看 -> 為什麼通知機制這麼單一？...」
4. 腦力激盪解決方案：針對找出的根本原因，開放團隊討論可能的改善方案。

第四帖：撰寫中立性的報告

透過上面的步驟，相信你已經掌握足夠的內容來撰寫事後復盤檢討報告。

一份結構清晰的事件複盤報告，我會建議內容應該包含以下這些項目：

1. 事件摘要：簡述發生了什麼、影響多大、持續多久。
2. 詳細時間軸：附上整理好的客觀時間軸。
3. 根本原因分析：「5個為什麼」的最終結論。
4. 改善行動項目：一份包含「具體行動」、「負責人」、「完成時限」的追蹤表格，這才是會議最重要的產出。

而在撰寫報告時，最重要的事情就是要保持中立的語氣和用詞。這不僅能夠確保報告的客觀性，也能讓團隊成員在閱讀後感到安全，願意誠實地面對問題並尋求解決方案。

如何保持中立？

• 聚焦於事實與流程：描述「發生了什麼」而非「誰做錯了什麼」。例如，使用「資料庫連線池飽和發生在凌晨 3:05」而非「小明沒有正確設定連線池參數」。
• 使用系統性語言：強調是「系統設計」或「流程缺失」導致了問題，而非個人因素。例如「通知機制缺乏冗餘」而非「值班工程師沒有看到通知」。
• 避免負面詞彙：不用「錯誤」、「失誤」等字眼，改用「改進機會」、「學習點」等前瞻性表述。
• 區分事實與假設：提出假設時，清楚標示「這是一個假設」，避免將猜測呈現為事實。

不中立的表達方式：

• 「由於工程師小明在上線前沒有進行壓力測試，導致系統在高流量下崩潰。」
• 「產品經理應該更早提出需求，如果有更充足的開發時間，就不會出現這個問題。」

中立的表達方式：

• 「系統在高流量環境下出現穩定性問題。未來可將壓力測試納入標準發布流程。」
• 「專案時程未能完全涵蓋實作複雜度。我們可以導入更結構化的需求評估機制。」

透過保持中立的視角，你才更能夠引導團隊建立聚焦於系統改進而非個人責備的文化，一份優秀的事件複盤報告應該讓讀者關注的是「下一次我們該如何做得更好」，而非「上一次是誰搞砸了」。

最後的醫囑

線上服務就像人的身體，總有一天會生病，我們無法祈禱它永遠健康，但我們可以做到的是，平時就做好健康檢查，並為自己準備好一個隨時可用的急救箱。

一場突如其來的線上災難對 PM 來說，雖然是很可怕的夢魘，但也是展現你最高價值的舞台。在風平浪靜時，任何人都能開船；唯有在驚濤駭浪中，才能看出誰是那個能穩住軍心、帶領大家活著靠岸的船長。

Hotfix belike