三类故障来源及各自的应对特点

[[故障与失效的区分决定容错设计的目标]]中提到故障不可避免，但不同来源的故障有着 截然不同的性质，应对手段也随之不同。硬件故障通常是随机的、相互独立的（一块磁盘的 损坏不太可能预示另一块也要坏），应对手段主要是冗余——RAID、双路电源、备用发电机， 用冗余把”单个硬件故障”和”整体失效”解耦，这种方法简单易懂，足以支撑机器多年不间断 运行；但随着机器数量增多（如硬盘MTTF约10-50年，一万块磁盘的集群平均每天就会坏一块）， 硬件故障率本身会上升，因此还需要在硬件冗余基础上叠加软件容错，让系统能容忍整台机器 失效。软件系统性错误则完全不同：它不是随机的，而是跨节点相关的，同样的bug可能同时 让所有实例崩溃（如2012年闰秒导致的Linux内核bug让许多应用同时挂掉），根源通常是软件 对运行环境做了某种长期成立、但某一刻突然不再成立的假设；应对没有速效药，只能靠仔细 审视假设、彻底测试、进程隔离、允许崩溃重启、持续监控生产环境行为这类多管齐下的办法。 人为错误是第三类且常被低估的来源——一项研究发现运维配置错误才是导致服务中断的首要 原因，硬件故障只占10-25%；应对靠的是从设计上最小化犯错机会（好的抽象和API）、把 最容易犯错的地方和可能导致失效的地方解耦（提供沙箱环境）、多层次测试、允许从错误 中快速回滚恢复、以及详尽的监控遥测。

结构图：

flowchart TD
    A[故障来源] --> B[硬件故障: 随机独立]
    B --> B1[冗余: RAID/双电源/备用发电机]
    B1 --> B2[机器增多后叠加软件容错]
    A --> C[软件系统性错误: 跨节点相关]
    C --> C1[根因: 长期成立的假设突然失效]
    C1 --> C2[审视假设+彻底测试+进程隔离+崩溃重启+监控]
    A --> D[人为错误: 运维配置错误是中断首因]
    D --> D1[最小化犯错机会的设计+解耦+沙箱+多层测试+快速回滚+遥测监控]