算法服务故障复盘应留下什么算法服务故障复盘应从可验证的事实开始什么时候发现异常哪些用户路径受影响哪些指标和日志支持判断采取了什么动作以及恢复如何确认。不要用未经证实的规模、时长或单一“根因故事”替代时间线。请求超时、CPU 上升和 GPU 空闲可能同时出现但还需要 trace、线程栈、输入特征和依赖状态来区分真正原因。输入处理是值得单独检查的一层。图片的文件大小不能代表解码后的像素和内存文本字符数也不等于 tokenizer 后的长度。服务应在解码和模型执行之前根据业务允许的格式、尺寸、页数、token 数与工作量做限制限制值来自容量测试和产品需求不宜写成所有服务通用的常数。将防护拆成可验证的层次入口层检查认证、内容类型、文件大小与请求速率解析层检查图片尺寸、压缩炸弹风险和文本长度执行层使用队列、超时、取消与资源隔离恢复层记录失败类别、保护依赖并给用户明确反馈。进程隔离可以限制某些原生库问题但强制终止会丢失内存状态与未完成工作应与幂等、清理和容量策略配合而不是作为默认修复手段。def validate_request(image_info, token_count): if image_info.pixels MAX_PIXELS: raise ValueError(图片尺寸超过服务支持范围) if token_count MAX_INPUT_TOKENS: raise ValueError(文本输入超过服务支持范围) async def run_with_timeout(job): return await asyncio.wait_for(job, timeoutREQUEST_TIMEOUT)超时只会停止调用方等待下游操作是否真正取消要由具体客户端和运行时确认。取消后应记录结果、释放队列名额和临时资源并避免把同一请求无限重试。对于可能修改状态的任务还需使用幂等键与补偿流程不能简单地再提交一遍。复盘行动必须能验收复盘将“观察到的现象”“确认原因”“仍待验证的假设”分开。行动项要有负责人和验收条件例如为图片解析添加边界测试为模型 worker 增加请求取消传播为输入大小建立仪表盘为原生扩展的崩溃增加隔离实验。修改后在受控环境重放脱敏样本观察新限制是否拦住异常输入而没有误伤正常请求。同时保留事件的查询链接、版本、配置、证据摘要和恢复步骤。下一次故障发生时团队可以从相同的边界开始排查而不是只记住一句“以前有过毒丸请求”。复盘真正留下的是可执行的检测、保护和恢复路径。还应检查告警和观察本身是否可靠。若关键指标采样缺失、日志缓冲溢出或通知没有送达复盘需要将这些可观测性缺口作为单独问题处理。恢复后用同样的请求路径和时间窗口验证服务、依赖和队列是否全部收敛而不是只确认进程重新启动。对于高风险变更安排一次小范围演练模拟超大输入、依赖超时或取消请求确认入口拒绝、worker 清理和用户反馈符合预期。演练结果连同失败场景写入测试集后续版本修改时自动回归。这样保护措施不会只停留在事故发生后的临时补丁。