3.4 故障假设原则

故障假设是构建可靠系统的基础原则。本节介绍这一原则的核心概念,以及对不同故障类型的处理策略、检查点机制、监控告警和完整的故障恢复流程。

3.4.1 原则的核心

故障假设 意味着:在设计系统时, 主动假设每一步都可能失败,并提前设计如何处理这些失败。这不是悲观主义,而是现实主义的系统工程。

与其相反的方法是对比如下:

设计方法
处理方式
结果

乐观设计

假设一切都会正常运行

当出现意外时,系统直接崩溃;用户蒙受损失,系统陷入不一致状态

故障假设

假设会出现意外

当出现意外时,系统有预案;优雅地降级,数据保持一致

3.4.2 为什么故障假设如此重要

故障假设原则的重要性可以从理论基础和实际数据统计两个角度理解。以下内容探讨了支撑这一原则的核心思想和在生产环境中的数据证据。

墨菲定律的启示

墨菲定律说:“任何可能出错的事情,最终都会出错,而且会在最糟糕的时刻出错。”

在智能体系统中,这尤其真实,因为我们处理的是概率系统。LLM不是确定的,网络不是可靠的,外部API也会偶尔宕机。

数据统计

在一个真实的生产系统中:

  • API调用失败率:通常在0.1-1%

  • 网络超时率:通常在0.01-0.1%

  • 数据库连接失败:通常在0.001-0.01%

乍一看这些比率很低,但在高并发系统中,这意味着什么?

假设系统每天处理100万个任务,每个任务平均进行10个API调用:

50,000次失败每天都会发生。如果系统没有为这些失败做准备,那就是50,000个用户的糟糕体验。

3.4.3 故障的类型和处理策略

如图所示,系统需要针对不同类型的故障采用不同的处理策略,从临时故障的重试到级联故障的断路器防护:

图 3-5:故障类型和处理策略

类型1:临时故障

网络超时、API临时不可用等,通常过一段时间就会恢复。

处理策略:重试

类型2:永久故障

API被删除、数据库不存在、权限不足等,重试也无法解决。

处理策略:降级/回退

类型3:部分故障

在一个分布式系统中,一部分组件失败,但其他部分仍在运行。

处理策略:分离和隔离

类型4:级联故障

一个组件的故障导致其他组件也失败,最终整个系统崩溃。

处理策略:断路器

3.4.4 检查点和事务

对于长流程的操作,需要设置检查点,以便从中间进行恢复。

3.4.5 监控和告警

故障假设的最后一部分是:快速检测故障

3.4.6 故障恢复的总结

故障恢复包括以下几个关键阶段。如图所示,完整的故障处理流程包括从故障检测到学习改进的全过程:

图 3-6:完整的故障恢复流程

3.4.7 Claude Code 案例:分层防御与远程可控性

Claude Code 的 7 层递进式记忆架构充分体现了故障假设原则的实战应用。其设计从这一哲学出发:“每一层都假设下一层可能失败”,并通过分层防御来最小化成本和故障影响:

远程功能标志(GrowthBook):每个内存层都由远程功能标志控制,允许在生产中即时禁用故障的子系统。例如,若第 6 层“梦想”机制出现故障,工程师可以在 30 秒内远程禁用它,所有会话自动回退到第 5 层。无需部署、无需用户干预。

3 失败断路器:第 6 层梦想 Agent 自带自动熔断——连续 3 次失败后自动禁用,恢复计时器启动。这防止了一个故障的梦想进程导致大范围用户受影响。

锁文件互斥与陈旧检测:梦想整合使用 PID+时间戳锁文件。若进程异常退出,新进程检测到锁文件中的 PID 已死亡,自动清除陈旧锁并继续,避免死锁。

这三个机制的组合体现了完整的故障处理流程:监控检测(每次失败递增计数器)→ 故障隔离(本地锁防止重复执行)→ 自动恢复(断路器后的定时重试)→ 可观测性(远程功能标志露出控制面)→ 学习改进(失败计数及日志可用于事后分析)。

3.4.8 总结

故障假设原则的关键要点:

  1. 接受故障会发生,而不是希望它们不发生

  2. 为每种故障类型设计处理机制:重试、降级、隔离、断路器

  3. 设置检查点和事务,允许从中间恢复

  4. 持续监控和告警,快速检测故障

  5. 从故障中学习,不断改进系统韧性

  6. 构建远程可控性,使故障响应无需部署(如 GrowthBook 功能标志)

这个原则将一个脆弱的系统变成了一个真正“可靠”(reliable)的系统。

最后更新于