凌晨兩點除錯：真正有用的方法

凌晨兩點。你的手機剛收到 PagerDuty 的通知。線上環境出事了。你的大腦大概只剩 40% 的運算能力。

這不是耍聰明除錯的時候。這是用系統化、無聊但可靠的方法，那種你半睡半醒也能用的方法。

以下是我從太多深夜事故中學到的東西。

步驟 1：什麼改變了？

90% 的線上環境 bug 都是因為最近有什麼東西變了。一次部署。一個設定檔更新。一次資料庫遷移。一張過期的憑證。

在你開始讀 code 之前，先搞清楚跟上次正常的時候差在哪裡。

把目前的設定跟上一個已知正常的版本做比對。用文字比對工具只要 10 秒，不用瞇著眼睛對照兩個檔案。

認真說。我曾經花了 45 分鐘除錯一個「神秘」的 API 錯誤，結果只是 JSON 設定檔裡的逗號放錯位置。diff 一下幾秒就能抓到。

步驟 2：認真讀錯誤訊息

這聽起來很明顯。但做到的人很少。

你累的時候，看到錯誤訊息就開始假設。「喔大概是資料庫連線的問題。」然後你花 20 分鐘檢查資料庫。結果錯誤訊息寫的是 TypeError: Cannot read property 'name' of undefined。跟資料庫一點關係都沒有。

讀錯誤訊息。再讀一次。讀 stack trace。追蹤到確切的那行程式碼。

步驟 3：讓錯誤變得可讀

線上環境的 log 很亂。什麼都在同一行，JSON 物件沒格式化，時間戳記是 Unix epoch 格式。

把那堆 JSON 複製貼上到 JSON 格式化工具，突然就看得懂錯誤回應了。

我一直開著一個格式化工具的分頁。事故期間每幾分鐘就用一次，拿來看 API 回應、log 記錄和設定檔。

步驟 4：隔離問題，不要亂猜

疲憊的大腦最愛亂猜。「搞不好是這個。我改改看那個。」

忍住。你做的每一個隨機更改都增加了不確定性。現在你搞不清楚是原本的問題修好了，還是你的修正又引入了新問題。

相反地：用最小的輸入重現錯誤。拿掉所有不必要的東西。找到那一個真正關鍵的變數。

步驟 5：檢查那些無聊的東西

在你深入 code 之前，先檢查：

• DNS：解析正確嗎？
• 憑證：有沒有過期？
• 磁碟空間：伺服器滿了嗎？
• 記憶體：有東西在洩漏嗎？
• 外部依賴：外部 API 掛了嗎？

我在螢幕旁邊貼了一張便利貼寫著這五項。事故發生時我先檢查它們。它們是根本原因的次數比實際的 code bug 還多。

凌晨兩點的除錯工具箱

這些是警報把我吵醒時我會打開的瀏覽器分頁：

1. 文字比對——比對設定檔、環境變數、部署檔案
2. JSON 格式化工具——讀 API 回應和 log 記錄
3. 正規表達式測試器——用 pattern 搜尋 log
4. 純文字編輯器——記下我試了什麼

最後一個比你想的還重要。凌晨兩點你的短期記憶是垃圾。寫下你試了什麼、發生了什麼。未來的你會感謝現在的你。

事故之後

火撲滅之後，不要直接倒頭就睡。花五分鐘寫下：

• 什麼壞了
• 為什麼壞了
• 什麼修好了它
• 下次怎麼預防

你明天不會記得這些的。現在就寫下來。

---

最好的凌晨兩點除錯不是靠聰明。是靠系統化。diff 設定檔。讀錯誤訊息。格式化 log。檢查無聊的東西。寫下來。這就是全部的劇本。