先定義端到端預算，再設定逾時
逾時不應直接採用 HTTP 函式庫或雲端 SDK 的預設值。先從使用者或上游服務可接受的總等待時間開始，扣除 API Gateway、應用程式處理、序列化、網路往返與回應組裝所需時間，剩下的才是依賴服務可使用的預算。如果同一請求會依序呼叫 ERP、CRM 與向量資料庫，每一段都不能拿到完整預算，否則最內層逾時時，上游期限早已用完。
連線逾時與回應逾時也應分開。連線逾時處理 DNS、TCP、TLS 或連線池取得失敗；回應逾時則限制已送出請求後等待首位元組或完整內容的時間。對串流式 AI 回應，還要區分建立回應的時間與串流停滯時間。上游取消請求後，取消訊號必須一路傳到下游，否則背景工作仍會占用執行緒、連線與推論額度。
重試只處理短暫且可安全重做的失敗
重試適合處理短暫網路中斷、連線重設、服務端明確要求稍後再試，或少量節點暫時不可用；它不適合權限錯誤、輸入驗證失敗、資源不存在，或依賴服務已經長時間過載。判斷條件應根據錯誤類型與協定語意，而不是看到任何非成功狀態就重送。
每次重試都會消耗剩餘期限與下游容量，因此必須同時設定嘗試次數、指數退避、隨機抖動與重試預算。若剩餘時間不足以完成下一次呼叫，就應立即回傳可處理的錯誤或降級結果。多層服務也不能各自重試；通常應選擇最了解操作語意的一層負責，避免 API Gateway、應用服務與 SDK 同時放大流量。
- 確認冪等性：查詢通常可以安全重試；建立訂單、付款、發送通知等操作必須使用冪等鍵，或先確認執行結果。
- 尊重下游訊號：若依賴服務提供重試等待時間或節流資訊，應納入排程，而不是立即重送。
- 限制整體重試量：以共享預算或令牌限制額外流量，正常請求不應被失敗請求的重試擠壓。
- 保留錯誤語意：記錄每次嘗試，但對上游呈現最終結果，避免監控把一次業務請求誤算成多次事故。
斷路器要反映容量問題，而不只是錯誤碼
依賴服務變慢時，請求可能仍然成功，但連線池、工作佇列與執行緒已逐漸塞滿。因此斷路器除了失敗率，也應觀察慢速呼叫、逾時與容量拒絕。統計視窗過短會因少量抖動頻繁開路；過長則無法及時保護系統。設定時至少要包含最小樣本量、觀察視窗、慢速門檻、開路時間，以及半開狀態允許的探測並行數。
斷路器的範圍也很重要。若所有 ERP 操作共用同一個斷路器，一個緩慢的報表查詢可能連帶阻擋簡單的庫存讀取；若切得太細，又會失去足夠樣本並增加維運複雜度。較實際的做法是依依賴服務、操作特性與資源池分組，並搭配並行上限或艙壁隔離。半開探測必須少量、可控制，而且不能由大量等待中的請求同時觸發。
用可觀測資料調校，並先設計降級行為
不要只看平均延遲。應同時觀察尾端延遲、排隊時間、連線池等待、各次嘗試耗時、最終成功率、斷路器狀態轉換與被拒絕的請求。日誌和追蹤資料要保留共同的請求識別碼，並清楚區分初次呼叫、重試與半開探測。否則團隊只會看到下游變慢，卻無法判斷時間花在網路、服務處理、客戶端排隊，還是重試退避。
調校前先決定失敗時要提供什麼：使用快取資料、延後同步、排入佇列、停用非必要功能，或快速回傳明確錯誤。設定變更應逐步發布，並以故障注入或測試環境模擬高延遲、部分失敗與完全不可用。實務上可用以下檢查順序，避免只修改單一參數：
- 確認端到端期限會跨服務傳遞，且取消後確實釋放資源。
- 確認只有可恢復且可安全重做的操作會被重試。
- 確認重試、一般流量與半開探測都有各自的容量限制。
- 確認斷路器開啟時存在可預期的降級結果，而不是把另一個依賴服務拖垮。
- 確認告警能區分依賴變慢、應用程式容量不足與錯誤設定。
好的設定不是一組永久不變的數字，而是一套可從服務目標、實際延遲分布與容量限制重新推導的規則。整合團隊的價值，也在於讓這些規則跨 API、雲端服務與企業系統保持一致。