营运与维护 · 实作指南
为重试设定预算，别让流程无限循环
提供方变慢时，同时限制重试时间、请求次数与业务影响。
重复努力可能放大故障
假设文件工作流的浏览器、API 和背景工作都会重试模型呼叫；单看各层似乎合理，合在一起却可能在故障时放大请求。先盘点哪些地方已有重试，包括套件预设。再为每项远端操作指定负责层，计算总尝试上限，而不是每遇到逾时就多加一个循环。重试的目的应是处理暂时故障，不是掩盖验证错误或永远不能成功的权限问题。
同时限制三个维度
建议预算包含总耗时、尝试次数及副作用暴露。低风险读取与结果不明的外部写入，不应共用完全相同政策。AWS Builders Library 提供退避与随机延迟背景，但机制仍要服从业务期限。会议已结束才生成报告，继续重试可能没有价值。最後状态应告诉负责人：已停止、等待核对，或可安全重新开始，不能只留下看似还在工作的动画。
流程一览
重试前先分类错误
把格式错误、无权存取、用量限制、连线失败及写入结果不明分开。资料不完整应退回能修正的人，不要重复消耗提供方呼叫。外部写入不明则先核对。建立简短的错误对应处理表，按每家 API 实际行为验证。所有例外一律重试虽然容易写，却很难维护，也容易让真正需要人员处理的工作埋在大量暂时失败里。
验证系统真的会停下来
测试长时间故障，确认请求最终进入有界终止或审查状态。每项业务请求总共呼叫多少次提供方，比工作者失败次数更有意义。恢复测试也要防止延误任务同时涌入。适合的预算取决於急迫性和目标系统语义，不是从教学抄一个通用数字。企业需要知道超限後谁接手，以及哪些工作应取消、延後或改走人工路径。
把重试总成本一起算
试点成本报告应包含重试呼叫、队列等待和人工核对。经过大量尝试终於成功的流程，仍可能不划算。把重试预算与少量例外直接交人工处理比较，再决定是否值得每次都自动再试。这能避免只看最终成功率而忽略成本。重试政策还应按业务优先级分配，重要且仍有价值的工作优先，不让过期任务占住全部容量。
来源与延伸阅读
编辑原则
本系列以 AI 辅助原创撰写，并对照连结的公开来源。实作建议与假设情境属编辑分析，并非客户实绩。来源发布日期及产品细节可能与本系列整理日期不同。