大模型线上事故如何止损、定位、复盘与演练？

面试时怎么答

线上事故按发现、止损、定位、恢复、复盘、演练六步讲最清楚。止损可以回滚模型/Prompt、关闭高风险工具或切只读；定位要用 Trace 对齐模型、索引、路由和策略版本。日志必须脱敏，复盘要落到 Owner、Runbook 和同类故障演练，而非只写时间线。

可以这样答：

事故处理的闭环是：发现、止损、定位、恢复、复盘和演练。说大模型事故不能只查模型，还要通过 Trace 对齐 Prompt、路由、知识索引、工具权限和安全策略版本。第一目标是限制影响面，可切只读、禁用高风险工具或回退稳定制品；代价是部分能力下降。复盘中要按严重度定义值班人和 Runbook，保留脱敏证据，并用 MTTD、MTTR、受影响请求数、回滚成功率和同类事故复发率检验体系。

核心回答

事故处理顺序是确认影响、建立指挥、止损、稳定、定位、恢复和复盘。由明确的 Incident Commander 统一优先级，Operations 执行技术动作，Communications 对内外同步，记录员维护时间线；避免多人同时改配置却没人知道当前系统状态。

止损优先使用可逆且预演过的手段：入口限流、Kill Switch、禁用高风险工具、切换降级模型/静态流程、回滚模型或 Prompt、隔离租户。恢复后保全脱敏的 Trace、版本、配置与指标，做无责复盘，把根因、促成条件和检测/响应缺口转成有负责人和截止时间的改进项。

展开说明

• 分级：按用户/数据/安全/成本影响定 Severity 和升级路径，模型回答“看起来奇怪”不能代替影响评估。
• 止损：先降低爆炸半径，再做复杂根因实验；生成错误、数据越权、工具误操作和 GPU 故障需要不同 Runbook。
• 变更纪律：每个动作记录操作者、时间、假设、预期与结果，失败后可撤回；事故中避免多变量同时调整。
• 证据：敏感 Prompt/输出只做最小必要留存和授权访问，不能为排障复制到无保护聊天或工单。
• 复盘：关注系统为何允许错误发生和扩大，不以“某人操作失误”结束分析。

Game Day 应在受控环境演练模型不可用、错误版本发布、Prompt 注入扩散、工具误调用、限额失效和区域故障，并验证告警、权限、回滚与沟通链路。

版本边界：Google SRE 给出通用事件管理原则，具体角色、法规通知时限、取证和安全响应流程需按组织与地区制定；Runbook 必须与当前平台版本同步演练。

工程实践

为每种高风险故障准备一页式 Runbook，顶部写触发条件、立即止损、禁止动作、回滚验证和联系人。每次发布保留可追溯版本与一键回退路径；按季度演练并测 MTTD、确认影响时间、止损时间、恢复时间和行动项按期完成率。

常见追问

1. 为什么事故中要先止损再找根因？ 根因分析可能很慢且会走弯路，持续影响用户的成本更高；可逆降级先缩小损失，也为稳定取证创造条件。
2. Kill Switch 应该放在哪里？ 放在能快速切断高风险能力且不依赖故障组件的位置，例如网关禁用工具写操作或切到安全 Workflow，并做分租户/功能粒度控制。
3. 无责复盘是否意味着不追究责任？ 它意味着重点改进系统、流程与防护而非羞辱个人；对故意违规仍可按制度处理，但不能用“人为错误”替代技术根因分析。

一句话复习

大模型事故靠明确指挥和可逆降级先止损，再用版本化证据定位，以无责复盘和 Game Day 把经验变成可验证防线。

参考资料

• 官方指南：Google SRE: Managing Incidents
• 官方指南：Google SRE: Postmortem Culture