營運與維護 · 實作指南
為重試設定預算，別讓流程無限循環
提供方變慢時，同時限制重試時間、請求次數與業務影響。
重複努力可能放大故障
假設文件工作流程的瀏覽器、API 和背景工作都會重試模型呼叫；單看各層似乎合理，合在一起卻可能在故障時放大請求。先盤點哪些地方已有重試，包括套件預設。再為每項遠端操作指定負責層，計算總嘗試上限，而不是每遇到逾時就多加一個循環。重試的目的應是處理暫時故障，不是掩蓋驗證錯誤或永遠不能成功的權限問題。
同時限制三個維度
建議預算包含總耗時、嘗試次數及副作用暴露。低風險讀取與結果不明的外部寫入，不應共用完全相同政策。AWS Builders Library 提供退避與隨機延遲背景，但機制仍要服從業務期限。會議已結束才生成報告，繼續重試可能沒有價值。最後狀態應告訴負責人：已停止、等待核對，或可安全重新開始，不能只留下看似還在工作的動畫。
流程一覽
重試前先分類錯誤
把格式錯誤、無權存取、用量限制、連線失敗及寫入結果不明分開。資料不完整應退回能修正的人，不要重複消耗提供方呼叫。外部寫入不明則先核對。建立簡短的錯誤對應處理表，按每家 API 實際行為驗證。所有例外一律重試雖然容易寫，卻很難維護，也容易讓真正需要人員處理的工作埋在大量暫時失敗裡。
驗證系統真的會停下來
測試長時間故障，確認請求最終進入有界終止或審查狀態。每項業務請求總共呼叫多少次提供方，比工作者失敗次數更有意義。恢復測試也要防止延誤任務同時湧入。適合的預算取決於急迫性和目標系統語義，不是從教學抄一個通用數字。企業需要知道超限後誰接手，以及哪些工作應取消、延後或改走人工路徑。
把重試總成本一起算
試點成本報告應包含重試呼叫、隊列等待和人工核對。經過大量嘗試終於成功的流程，仍可能不划算。把重試預算與少量例外直接交人工處理比較，再決定是否值得每次都自動再試。這能避免只看最終成功率而忽略成本。重試政策還應按業務優先級分配，重要且仍有價值的工作優先，不讓過期任務佔住全部容量。
來源與延伸閱讀
編輯原則
本系列以 AI 輔助原創撰寫，並對照連結的公開來源。實作建議與假設情境屬編輯分析，並非客戶實績。來源發布日期及產品細節可能與本系列整理日期不同。