做AI应用的人，大概都经历过第三方API故障的惊魂时刻。我上个月就经历了一次，而且是在最关键的时候。

我们团队做了一个AI视频生成的工具，底层用的是Pika 1.0的API。上线三个月，一直跑得挺稳。但上个月的一个周五下午，Pika的API突然出了问题，导致我们的服务几乎瘫痪。

这篇文章，就来完整复盘这次故障。从故障发生、影响评估、应急处理，到根因分析和后续改进，尽量客观地记录整个过程。如果你也在做基于第三方AI API的应用，希望这篇文章能给你一些提醒。

故障发生

那天是周五，下午三点多，正是一周中业务最忙的时候。

我们的产品是一个AI短视频生成工具，用户输入文字或者上传图片，就能生成一段短视频。平时，生成一段视频大约需要1到2分钟，用户提交任务后可以等待，也可以关闭页面稍后回来看结果。

故障发生的时候，我正在开一个需求评审会。突然，运维同学在群里发了一条消息："视频生成服务出问题了，大量任务失败。"

我赶紧打开监控面板，看到了几个异常指标：

  • 视频生成任务的失败率，从平时的2%以下，飙升到了60%以上
  • 平均生成时间，从平时的90秒，变成了超过5分钟
  • 任务队列积压，待处理的任务超过了两千个
  • 用户投诉量在15分钟内增加了几十条

我立刻意识到问题的严重性。周五下午是用户使用的高峰期，如果服务持续不可用，影响会很大。

初步排查

我第一反应是我们自己的服务出了问题。但排查了一圈之后，发现我们的服务器CPU、内存、网络都很正常，数据库也没有慢查询，消息队列也没有堆积。

问题出在Pika的API调用上。

我们的日志显示，调用Pika API的时候，大量请求返回了500错误，或者超时。还有一部分请求，返回了200状态码，但生成的视频是损坏的，无法播放。

我立刻去Pika的官方状态页查看，发现状态页显示"全部正常"，没有任何故障公告。我又去Pika的Discord社区看了一下，发现已经有很多用户在反馈同样的问题了，但官方还没有回应。

这时候，我基本确认了：这是Pika服务端的故障，不是我们的问题。但问题是，我们的服务完全依赖Pika的API，Pika出问题，我们的服务就跟着瘫痪。

影响评估

故障持续了大约半个小时之后，我们做了一次影响评估。

用户影响：

  • 大约有3000个用户的视频生成任务失败
  • 其中大约有500个是付费用户，他们购买了生成次数
  • 用户投诉超过了200条，主要集中在"生成失败""等了很久没结果""扣了次数但没生成视频"

业务影响：

  • 当天的视频生成量下降了70%
  • 新用户注册量下降了40%
  • 有几个付费用户申请了退款
  • 应用商店的评分出现了几条一星差评

更麻烦的是，故障发生在周五下午，很多用户是周末要用视频。如果故障持续到晚上，影响会更大。

应急处理

确认是Pika的问题之后，我们立刻启动了应急预案。

第一步，通知用户。我们在应用内加了一个公告，告诉用户当前视频生成服务不稳定，正在紧急处理。同时，给所有受影响的用户发了一封邮件，说明情况，并承诺会补偿生成次数。

第二步，暂停新任务提交。为了避免任务队列继续积压，我们暂时关闭了新任务的提交入口。已经提交的任务，继续尝试处理。

第三步，联系Pika官方。我通过官方的工单系统和Discord，同时联系了Pika的技术支持，详细描述了我们遇到的问题，包括错误码、请求样本、发生时间。希望他们能尽快定位和修复。

第四步，准备备用方案。我们之前接入了另一个视频生成API作为备用（Runway），但一直没有正式启用。这次故障，我们决定临时启用备用方案。我让后端同学快速配置了一下，把一部分流量切到了Runway。

第五步，补偿方案。我们决定，给所有受影响的用户补偿双倍的生成次数，付费用户额外赠送一个月的会员。这个方案虽然会有一些损失，但能挽回用户的信任。

应急处理做完之后，我们能做的就是等待Pika修复。那种感觉很无力：问题不在我们这边，我们再努力也没用，只能等第三方修复。

故障恢复

故障持续了大约三个小时。

晚上六点多，Pika的API开始逐步恢复。我们观察了一会儿，确认失败率降到了正常水平，生成时间也恢复了正常。然后，我们逐步恢复了新任务的提交，把切到Runway的流量切了回来。

但恢复之后，还有一些遗留问题：

  • 故障期间提交的任务，有一部分状态不一致，需要手动处理
  • 有一些生成了一半的视频文件，需要清理
  • 补偿的生成次数，需要批量发放给用户
  • 用户的投诉和退款申请，需要逐个处理

这些遗留问题，我们团队加班到晚上十点多才处理完。

故障恢复之后，Pika官方发了一封道歉邮件，解释了故障原因：他们的一个推理集群出现了硬件故障，导致部分请求失败。他们已经修复了问题，并且会加强监控和容灾。

根因分析

虽然故障的直接原因是Pika的硬件问题，但复盘之后，我们发现自己的架构也有很多问题。

第一个问题，过度依赖单一供应商。我们的视频生成服务，100%依赖Pika的API。虽然之前接入了Runway作为备用，但一直没有正式启用，也没有做过故障切换的演练。一旦Pika出问题，我们就只能被动等待。

第二个问题，缺少降级策略。当Pika的API失败率升高的时候，我们的系统没有自动降级的机制，还是继续往Pika发请求，导致任务队列越积越多。如果有自动降级，在失败率超过阈值的时候自动切换到备用服务，影响会小很多。

第三个问题，任务处理机制不完善。我们的视频生成任务，是同步等待Pika返回结果的。如果Pika超时，任务就一直挂在那里，占用资源。而且，任务失败之后没有自动重试机制，需要用户手动重新提交。

第四个问题，监控不够全面。我们只监控了自己服务的指标，没有监控Pika API的健康状态。如果能实时监控Pika的响应时间和错误率，就能在故障刚发生的时候就发现，而不是等用户投诉了才知道。

第五个问题，用户沟通不及时。故障发生后，我们过了将近20分钟才发公告。在这20分钟里，很多用户反复尝试生成，浪费了时间和生成次数，也增加了投诉量。

这些问题，平时看起来不严重，但一旦出故障，就会放大影响。

改进措施

基于这次故障的教训，我们做了一系列改进。

第一，正式启用多供应商策略。我们把Runway作为正式的备用服务，并且又接入了一个国内的视频生成API。现在，我们同时接入了三家视频生成服务，根据可用性和成本动态分配流量。任何一家出问题，都能自动切换到其他家。

第二，实现自动降级和故障切换。我们开发了一个智能路由层，实时监控每家API的响应时间、错误率、成本。当某家API的错误率超过阈值时，自动把流量切到其他家。恢复之后，再逐步切回来。整个过程不需要人工干预。

第三，完善任务处理机制。把同步等待改成了异步任务队列。用户提交任务后，立即返回任务ID，后台异步处理。任务失败后自动重试，重试三次还失败的，标记为失败并通知用户。同时，增加了任务超时机制，避免任务无限期挂起。

第四，增强监控。增加了对每家API的健康监控，包括响应时间、错误率、成功率、生成质量。设置了多级告警，任何一家API出现异常，立刻通知值班人员。同时，增加了业务指标的监控，比如生成成功率、用户投诉量、退款率等。

第五，优化用户沟通。制定了故障沟通的SOP：故障发生后5分钟内，在应用内发布公告；15分钟内，给受影响的用户发邮件；每30分钟更新一次进展；故障恢复后，24小时内给出故障说明和补偿方案。

第六，定期故障演练。每个季度做一次故障演练，模拟某家API宕机、网络中断、数据库故障等场景，测试我们的降级和恢复机制是否有效。通过演练，发现潜在的问题，提前修复。

AI视频生成服务的稳定性挑战

这次故障也让我对AI视频生成服务的稳定性，有了更深的思考。

AI视频生成，是一个计算密集型的任务。生成一段几秒钟的视频，可能需要几十秒甚至几分钟的GPU计算。这意味着，AI视频生成服务的稳定性，比传统的API服务更难保证。

挑战主要有几个方面：

第一，GPU资源有限。视频生成需要大量的GPU资源，而GPU很贵，任何服务商都不可能无限扩容。高峰期的时候，很容易出现资源不足、排队等待的情况。

第二，生成质量不稳定。同样的输入，每次生成的结果可能不一样。有时候生成的视频质量很好，有时候会出现画面扭曲、人物变形、逻辑错误等问题。这种质量的不稳定，比服务宕机更难处理。

第三，生成时间不确定。有的视频几十秒就能生成，有的需要好几分钟。用户的等待体验很难保证。

第四，供应商迭代快。AI视频生成的技术发展很快，供应商经常更新模型和API。有时候更新会引入新的bug，或者改变生成效果。这给应用的稳定性带来了挑战。

第五，成本高。视频生成的成本比文本生成高很多，一次生成可能要几毛钱甚至几块钱。如果大量任务失败，成本损失也很大。

面对这些挑战，做AI视频生成应用的团队，必须在架构上做好容错和降级，不能把所有希望寄托在供应商的稳定性上。

一些建议

基于这次经历，给做AI应用的团队一些建议。

第一，不要把鸡蛋放在一个篮子里。不管是文本生成、图像生成还是视频生成，都不要只依赖一家供应商。至少接入两家以上，做好故障切换的准备。

第二，设计好降级方案。当AI服务不可用的时候，要有降级方案。比如，视频生成失败了，可以给用户返回一张静态图片；AI回复失败了，可以给用户一个预设的回复。降级虽然体验不好，但比完全不可用好。

第三，做好异步处理。AI生成通常比较耗时，一定要用异步任务队列，不要让用户同步等待。这样，即使AI服务出问题，也不会阻塞整个系统。

第四，监控要全面。不仅要监控自己的服务，还要监控第三方API的健康状态。同时，要监控业务指标，比如生成成功率、用户满意度等。

第五，和供应商建立良好的沟通。遇到故障的时候，能直接联系到供应商的技术人员，比在社区里等回复高效得多。如果是重要的客户，可以和供应商签订SLA，获得更好的服务保障。

第六，做好用户沟通。故障不可怕，可怕的是出了故障不告诉用户。及时、透明的沟通，能大大降低用户的不满。

写在最后

这次Pika 1.0的故障，是一次惊心动魄的经历，也是一次宝贵的学习机会。

它让我们认识到，在AI时代，应用的稳定性不仅取决于自己的代码，还取决于第三方AI服务的稳定性。而AI服务的稳定性，目前还不如传统的云服务成熟。

作为AI应用的开发者，我们必须在架构上做好充分的准备：多供应商、自动降级、异步处理、全面监控、良好沟通。只有这样，才能在第三方服务出问题的时候，把对用户的影响降到最低。

故障本身不可怕，可怕的是从故障中学不到东西。每一次故障，都是一次提升系统稳定性的机会。只要认真复盘、持续改进，系统就会越来越健壮。

希望这次复盘的经验，能给大家一些参考。如果你也经历过类似的AI服务故障，欢迎交流分享。