間歇性 bug 是工程師的試煉場。錯誤訊息明確的問題，通常一兩個小時就能修；真正讓人懷疑人生的，是那種「每週一早上九點左右出現一次、其他時間都好好的」的詭異現象。這類問題之所以難，不是因為複雜，而是因為它打破了我們最依賴的工具——重現。
先別急著看 code，先把問題形狀畫出來
面對重現不穩的問題，最常見的錯誤是立刻跳進 code base 翻找可疑邏輯。這種做法在簡單 bug 上很有效，但對間歇性問題幾乎都會失敗，因為你連要找什麼都還不知道。
比較有效的做法是先收斂「症狀的形狀」：
- 時間維度：什麼時段出現？是否對應某個排程、批次任務、外部 API 的尖峰？
- 資料維度：是不是只有某類用戶、某個區間的訂單、某種語系的輸入會中招？
- 環境維度：只在 production？只在某台機器？某個 region？
舉個例子，假設一個電商後台每週一早上會有「商品列表載入特別慢」的回報。直覺會懷疑流量尖峰，但如果觀察一下發現週一早上其實流量並不高，那「流量」這個假設就被排除了，注意力應該轉向：是不是有什麼只在週一早上跑的排程？例如報表彙整、cache 重建、或者某個 cron job 正在做 full table scan。
把症狀的形狀畫清楚，候選嫌疑犯通常會從幾十個收斂到兩三個。這一步省下的時間，遠多於你「直接看 code」省下的時間。
區分「症狀」與「根因」，不要修錯地方
第二個常見陷阱，是把症狀當成根因修掉。例子很多：
- 某個 API 偶爾 timeout，於是把 timeout 從 5 秒拉到 30 秒。問題「消失」了，但其實只是被蓋住，幾週後變成更難查的 cascading failure。
- 某個 queue 偶爾塞車，於是加 worker。短期見效，但根因可能是某個 query 在特定資料分佈下退化成全表掃描，加再多 worker 也只是延後爆炸時間。
- 某個前端畫面偶爾白屏，於是加 retry。retry 蓋掉了背後 race condition 的訊號，讓問題更難被觀察到。
我們的經驗法則是：任何「調大數字」「加 retry」「加 try-catch 吞掉」的修法，都應該先被當作暫時止血，而不是修復。止血之後，必須回頭問一句：為什麼這裡會超時？為什麼這裡會塞？
一個排查間歇性效能問題的最小骨架，大概長這樣：
# 示意：實際請依你的 APM / log 工具調整
import time, logging
def traced(label):
def deco(fn):
def wrap(*args, **kwargs):
t0 = time.perf_counter()
try:
return fn(*args, **kwargs)
finally:
dt = (time.perf_counter() - t0) * 1000
logging.info(f"{label} took {dt:.1f}ms")
return wrap
return deco
@traced("load_product_list")
def load_product_list(user_id):
...
重點不是這段程式本身，而是「在每個你懷疑的邊界都加上時間量測」。間歇性問題的本質是訊號太少，你要做的是先把訊號補齊，再去解釋它。
我們的觀察
排查疑難雜症的能力，跟讀過多少書、用過多少框架關係不大，反而跟「願不願意慢下來」高度相關。願意先花半小時把症狀的形狀畫清楚、願意在修掉之前多問一句「這真的是根因嗎」，多數詭異 bug 都會在這個過程中自己現形。真正可怕的不是 bug，是把症狀當根因、然後把問題埋到下一季再爆炸。