随着年龄增长，我越来越意识到，我们这个行业其实从未真正改变，变的只是术语。过去我们谈论“服务器”和“集群”，现在则谈论“节点”和“代理”。故障的形式并没有变，变的是故障发生时的代价。
早在“云”这一概念出现之前，容错和韧性就一直是应用交付背后默默发挥作用的支柱。节点故障？执行故障转移。需求激增？横向扩展。服务无响应？绕过故障服务进行路由。这些经验至今仍然适用，但AI让它们变得更加紧迫，一旦忽视，后果也会严重得多。
在介绍“应用交付十大挑战”中的ADC02”时，我们提出了经过数十年实践验证的几个明确要点：冗余至关重要，负载均衡至关重要，自动化至关重要，而最关键的是，优雅降级至关重要。
这些原则不仅适用于AI时代，更是关乎生存的准则。AI应用和智能体系统会以新的方式发生故障，但故障原因和解决之道却与应用交付本身一样由来已久。虽说应用交付的历史还没我这么长，但也快了。
性能
在传统基础设施中，缺乏容错能力意味着系统在负载下响应缓慢，或在组件停止运行时直接超时。在AI环境中，后果会进一步放大。模型无法平稳降级，反而会形成瓶颈。GPU故障、节点停滞或数据链路中断，都可能在整个推理链中引发级联故障。
训练和推理流水线尤其容易受到影响：一个运行异常的预处理器或数据加载器，就可能导致所有下游进程无法获得数据。由于AI工作负载在设计上采用同步机制，每一层都要等待上一层完成，因此延迟会迅速累积。性能下降不仅意味着响应变慢，还会导致系统的认知能力衰退。系统可能开始出现回答被截断、推理不完整或结果不一致等问题，而这一切可能只是因为某项服务没有备用或重试路径。
可用性
过去，高可用性意味着服务器冗余和自动故障转移。如今，它意味着冗余模型和分布式推理集群。单一模型端点已不再是一项服务，而是一个隐患。当该节点发生故障时，依赖它的每个API调用也会失败，而且往往不会发出任何提示。
AI服务通常由多层组成，包括向量存储、嵌入生成器、推理引擎、路由器和编排逻辑。每一层都可能成为新的故障点。如果缺少冗余或智能流量引导，任何一层出现故障都可能导致整个技术栈瘫痪。如果“AI智能体”无法在依赖项失效后自主恢复，那么构建出的将是一个代价极其高昂的单点故障。
可靠性
韧性不仅关乎正常运行时间，还意味着在压力下保持一致的行为。对于AI而言，即使环境并不理想，也要保持输出一致。当数据源出现延迟，或推理节点在提示处理中途重启时，模型仍应以可预测的方式响应。
如果没有适当的容错机制，系统就会出现漂移：其逻辑会随时发生不一致。一个请求超时，另一个成功，第三个则无限期挂起。在传统系统中，这只是个麻烦；但在AI系统中，尤其是智能体系统中，这会造成混乱。智能体依赖可预测的反馈循环；一旦这种节奏被打乱，推理链也会随之中断。
AI韧性实践指南
好消息是，韧性建设的蓝图并未改变，只是如今需要在节奏更快、相互依赖程度更高的环境中实施。
1. 在每一层构建冗余。
不仅要实现硬件冗余，还要实现模型冗余。为每个模型运行多个推理端点，并尽可能采用不同的模型系列。为关键任务设置模型回退机制，避免单一架构问题导致系统离线。
2. 在编排层实现自动恢复。
对于可在数秒内扩展或发生故障的系统，手动干预速度太慢。将检测和重新平衡逻辑直接内置于编排层，以便在端点中断或GPU停滞时自动转移工作负载。
3. 智能负载均衡。
传统负载均衡注重均匀分配流量。在AI领域，关键在于感知性能。可根据延迟、令牌吞吐量、GPU运行状况、模型版本或区域进行负载均衡。路由不仅要考虑连接数，还应考虑实时容量和模型稳定性。请务必避免使用轮询算法。
4. 采用优雅降级设计。
AI系统应在故障时仍能发挥作用。当某个模型不可用时，应将请求路由到规模更小、成本更低或能力较弱的版本，而不是直接失败。当智能体无法再访问某项技能或API时，应进行适应性调整，而不是崩溃。
5. 对AI技术栈进行混沌测试。
韧性不能只停留在理论层面。主动制造故障：下线推理节点、破坏输入数据、限制带宽，或在容器运行过程中将其终止。然后观察会发生什么。AI流水线需要达到过去仅用于微服务的同等混沌工程水平，因为它们现在本质上就是微服务，只不过外面包裹着数学模型。
将相同原则应用于新技术栈
AI系统无法伪装韧性。过去让Web应用在数据中心中断期间持续运行的原则，如今也能让自主系统在模型崩溃和网络混乱时保持正常运作。您无法控制故障何时发生，只能决定如何恢复。
事实上，这一切并不新鲜。还是同样的故事，只是如今风险更高。云让一切走向分布式，AI则让一切变得脆弱。如今，服务中断与“AI故障”之间的区别只在于如何定义。如果希望智能系统持久运行，就应将其构建在能够经受故障考验的基础设施之上。冗余并非过时的遗留方案，而是一重保障。负载均衡并非老派做法，而是不可或缺。优雅降级也不是可选项，而是安全保障。21世纪初保障Web层持续运行的同一套方法，也将在2026年帮助AI层保持可靠。
因为无论我们编写多少代码，采用多么复杂的数学方法，或是系统表现得多么像有感知能力，一个残酷而简单的事实始终不变：只要存在故障的可能，故障就会发生。而如果系统恢复得足够快，用户甚至可能根本不会察觉。
深入了解全球组织面临的十大应用交付挑战。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
