Retry Policy

重試策略是什麼，跟單純的失敗重跑有什麼不同？

重試策略是自動化流程遇到失敗時，決定該不該自動重試、重試幾次、每次間隔多久的一套規則，而不是遇到失敗就無條件立刻重跑一次。一個完整的重試策略至少要回答三個問題：這種失敗值不值得重試（有些失敗重試也沒用）、重試幾次算合理上限、每次重試間隔該怎麼安排。

跟單純的失敗重跑最大的差別，在於「間隔設計」和「上限機制」。單純重跑通常是失敗就立刻再試一次，如果問題是暫時性的（例如網路瞬斷），立刻重試可能還沒等網路恢復就又失敗了；重試策略則會設計逐次拉長的間隔，給問題自己恢復的時間，並且設定重試上限，超過上限就停止並改為通知人工處理，而不是無限重試下去。

重試策略有哪些限制，哪個最容易被忽略？

最容易被忽略的是「不是所有失敗都適合用重試策略解決」。重試策略處理的是暫時性、有機會自己恢復的失敗，例如網路短暫中斷、對方伺服器暫時過載。如果失敗的原因是邏輯本身寫錯——例如判斷條件寫反了、資料格式從一開始就不對——這種失敗不管重試幾次，結果都會是一樣的錯誤，重試在這種情況下只是浪費時間和運算資源，真正該做的是修正邏輯本身，而不是加大重試次數。

第二個容易被忽略的限制是，重試次數不是設得越多越保險。如果重試次數設得太多、間隔也拉得很長，可能會讓一個原本該被立刻注意到的問題，因為系統還在默默重試，被拖到很晚才真正被人發現，這種延誤在某些情境下（例如客戶付款失敗）代價可能很高。重試策略需要在「給問題自己恢復的機會」和「問題持續存在時盡快讓人知道」這兩者之間取得平衡，不是一味增加重試次數。

什麼情況該設計重試策略，什麼情況不需要？

適合設計重試策略的核心情境是「這個動作依賴外部系統，且外部系統偶爾會有暫時性、非本質性的問題」。例如呼叫第三方 API、跟資料庫連線、發送網路請求，這些動作偶爾會因為網路波動或對方系統短暫過載而失敗，但問題通常在幾分鐘內就會自己恢復，這種情境下加上重試策略，能自動處理掉大部分不需要人工介入的暫時性失敗。

不需要重試策略的情況，是失敗的原因本質上不會隨時間改變。例如因為輸入資料格式不對而失敗、因為邏輯判斷寫錯而得到錯誤結果，這些失敗不管等多久、重試幾次，結果都會一樣，重試策略在這裡完全發揮不了作用，該做的是直接修正問題根源。簡單判斷法：問自己「這個失敗有沒有可能，過幾分鐘後自己就消失了」，有可能就適合重試策略，不可能就該直接修正邏輯。

進階使用者怎麼設計重試策略，才能兼顧自動恢復和及時發現真正的問題？

進階使用者的關鍵做法是「重試間隔採用指數遞增，而不是固定間隔或線性遞增」。具體做法是第一次重試等待較短時間（例如 1 分鐘），如果還是失敗，第二次等待時間乘以某個倍數（例如 5 分鐘），第三次再乘以倍數（例如 30 分鐘），這種指數遞增的間隔設計，能在問題剛發生、最有可能是短暫波動時快速重試一次，如果持續失敗，代表問題可能不是短暫的，逐漸拉長間隔既能給問題更多恢復時間，也能避免短時間內對同一個系統發送大量重試請求造成額外負擔。

另一個進階技巧，是把「重試次數用完但問題依然存在」這件事，設計成明確的升級路徑，而不是就此沉默結束。具體做法是重試策略跟升級路徑機制搭配使用，重試上限用完後，自動觸發一則通知，附上這段時間內每次重試失敗的具體錯誤訊息，讓接手處理的人一眼就能看出問題可能出在哪裡，而不是只收到一句「這個任務失敗了」，卻要自己回頭翻紀錄才知道發生了什麼事。