上个月，我们基于GPT-5正式版搭建的线上系统出了一次严重的故障。从发现问题到完全恢复，前后持续了六个小时。那六个小时，是我职业生涯中最惊心动魄的六个小时。

这篇文章我想做一次完整的复盘，从故障的发生、应急处理、根因分析，到后续的改进措施，都详细记录下来。如果你也在使用大模型做线上服务，希望这篇文章能给你一些参考。

故障的发生

那天是周三，下午两点多，正是业务高峰期。我们的客服智能问答系统，突然出现了大量的异常响应。

用户反馈说，系统要么不回答，要么回答的内容完全不相关，有时候还会输出一些乱码。客服团队的工单量瞬间暴涨，用户投诉电话一个接一个。

我接到通知的时候，正在开一个项目会议。赶紧打开监控面板一看，吓了一跳：系统的错误率从平时的不到1%，飙升到了60%多，而且还在上升。响应时间也从平时的两秒，涨到了十几秒。

我第一反应是GPT-5的API出问题了。因为我们的系统高度依赖GPT-5的API，如果API出问题，整个系统都会受影响。我赶紧去看OpenAI的状态页，发现他们的服务状态显示正常，没有任何故障公告。

这就奇怪了。API状态正常，但我们的系统却大量出错。我开始深入排查。

第一轮排查

第一轮排查，我先看了系统的日志。

日志显示，大量的API调用返回了500错误，还有一些返回了超时。但也有一部分调用是成功的，而且成功的调用返回的内容是正常的。这说明不是API完全挂了，而是部分请求出了问题。

我仔细看了一下失败的请求，发现了一个规律：失败的请求，大部分都是比较长的prompt，或者是包含了特殊字符的prompt。而短的、简单的prompt，基本都能成功。

我怀疑是GPT-5正式版的某个更新导致了兼容性问题。因为我们用的是GPT-5的正式版API，OpenAI会不定期地更新模型。虽然他们说更新是向后兼容的，但有时候还是会出问题。

我去查了一下OpenAI的更新日志，发现当天上午他们确实发布了一个小版本更新，主要是优化了模型的推理速度。但更新说明里说，这个更新不影响输出结果。

我怀疑是这个更新引入了bug。我赶紧联系了OpenAI的技术支持，把我们的错误日志发给了他们。对方说需要时间排查，让我们先等等。

但业务等不了。错误率还在上升，用户投诉越来越多。我必须想办法先恢复服务。

应急处理

应急处理的第一步，是降级。

我们的系统有一个降级机制，当大模型API不可用的时候，可以切换到基于规则的问答系统。虽然效果差一些，但至少能保证基本的服务可用。

我赶紧启动了降级流程，把流量切到了规则引擎。切过去之后，错误率立刻降下来了，从60%多降到了5%以下。虽然用户体验下降了，但至少系统能用了。

降级之后，我开始做进一步的排查。我写了一个测试脚本，用不同的prompt去调用GPT-5的API，看看哪些会失败，哪些会成功。

测试了上百个prompt之后，我找到了问题的规律：当prompt的长度超过4000个token，或者包含某些特殊的Unicode字符时，API就会返回500错误。而短的、纯ASCII的prompt，基本都能成功。

这就解释了为什么我们的系统大量出错。因为我们的系统会把用户的问题、历史对话、知识库内容都拼接到prompt里，很多prompt的长度都超过了4000个token，而且用户的问题里经常包含特殊字符。

找到了规律之后，我开始想临时解决方案。

第一个方案是截断prompt。把超过4000个token的prompt截断，只保留前面的部分。这样虽然会损失一些上下文，但至少能让API调用成功。

第二个方案是过滤特殊字符。在调用API之前，把prompt里的特殊Unicode字符过滤掉或者替换掉。

我赶紧写了一个临时的修复版本，加上了prompt截断和特殊字符过滤。测试了一下，大部分请求都能成功了，错误率降到了10%以下。

然后我把这个临时版本部署上去，同时关闭了降级，让流量切回大模型系统。部署之后，监控显示错误率稳定在8%左右，虽然比平时高，但已经可以接受了。

这时候已经是晚上八点多了，从故障发生到现在，已经过去了六个小时。服务基本恢复了，但我知道，这只是临时方案，根因还没有找到。

根因分析

第二天，OpenAI的技术支持给了回复。

他们确认，当天的小版本更新确实引入了一个bug，在处理长prompt和特殊字符的时候，会导致内部错误。他们已经在修复了，预计当天就能发布修复版本。

果然，当天下午，OpenAI发布了修复版本。我们测试了一下，长prompt和特殊字符的问题都解决了。我们把临时的截断和过滤逻辑去掉了，系统恢复了正常。

虽然问题解决了，但我觉得需要做一次深入的根因分析，避免类似的问题再次发生。

根因分析的结果，表面上是OpenAI的更新引入了bug，但更深层的原因，是我们的系统对大模型API的依赖太强，容错能力太差。

具体来说，有以下几个问题。

第一，没有多模型备份。我们的系统只依赖GPT-5一个模型，没有其他模型作为备份。一旦这个模型出问题，整个系统就受影响。

第二，没有完善的降级机制。虽然我们有规则引擎的降级，但降级的体验太差，而且切换是手动的，不够及时。

第三，没有充分的测试。大模型API的更新，我们没有在测试环境提前验证，直接就用到了生产环境。

第四，监控不够细致。我们的监控只看整体的错误率，没有细分到prompt长度、内容类型等维度，导致问题出现之后，不能快速定位原因。

第五，没有和模型服务商建立有效的沟通渠道。出了问题之后，我们只能通过普通的技术支持渠道联系，响应速度很慢。

改进措施

针对这些根因，我们做了一系列的改进措施。

第一，引入多模型架构。我们接入了多个大模型，包括GPT-5、Claude、文心一言等。当一个模型出问题的时候，可以自动切换到另一个模型。这样即使某个模型出故障，系统也能正常运行。

第二，完善降级机制。我们做了多级降级：大模型出问题的时候，先切换到其他大模型；所有大模型都出问题的时候，再切换到规则引擎。而且切换是自动的，根据错误率和响应时间自动判断，不需要人工干预。

第三，建立测试环境。我们搭建了一个独立的测试环境，每次模型服务商更新之后，先在测试环境跑一遍完整的测试用例，确保没有问题再更新到生产环境。

第四，细化监控。我们在监控里加了很多维度，包括prompt长度、token数量、内容类型、用户类型等。这样问题出现的时候，能快速定位是哪类请求出了问题。

第五，建立应急响应流程。我们制定了大模型故障的应急响应流程，明确了谁负责排查、谁负责降级、谁负责和服务商沟通。出了问题之后，按照流程来，不会手忙脚乱。

第六，和模型服务商建立企业级支持。我们购买了OpenAI的企业级支持服务，有专门的技术支持经理，出了问题能更快地得到响应和解决。

这次故障的教训

这次故障，给了我很多教训。

第一个教训是，不要过度依赖单一的大模型。大模型虽然强大，但它也是一个外部服务，可能会出问题。一定要有备份和降级方案，不能把所有鸡蛋放在一个篮子里。

第二个教训是，大模型的更新可能会引入不兼容的变化。虽然服务商说更新是向后兼容的，但实际上可能会有各种问题。一定要在测试环境充分验证之后，再更新到生产环境。

第三个教训是，监控和告警要提前做好。不要等用户投诉了才发现问题。要建立完善的监控体系，在问题刚出现的时候就能发现，及时处理。

第四个教训是，应急响应能力很重要。再完善的系统，也可能出问题。出了问题之后，能不能快速响应、快速恢复，比系统本身不出问题更重要。

第五个教训是，要和服务商建立良好的合作关系。出了问题，服务商的响应速度很关键。企业级支持虽然贵一些，但在关键时刻能帮你节省很多时间。

写在最后

这次故障，虽然惊心动魄，但也让我们的系统变得更健壮了。

大模型是一个强大的工具，但它也是一个不稳定的外部依赖。在使用大模型做线上服务的时候，一定要有充分的容错和降级机制，不能想当然地认为它永远可用。

技术的发展就是这样，不断地出问题，不断地解决问题，然后系统变得越来越稳定。每一次故障，都是一次成长的机会。

如果你也在使用大模型做线上服务，希望我的这次经历能给你一些启发。做好多模型备份、完善降级机制、充分测试、细化监控、建立应急流程，你的系统就能更稳定地运行。

最后用一句话来结束这篇文章："故障不可怕，可怕的是不从故障中学习。"

愿每一个做线上服务的工程师，都能少出故障，出了故障也能快速恢复。