宕机通常是多重失效环环相扣，事后反思要警惕"单一根因"归罪

一次真正造成严重后果的宕机事故，几乎从来不是单一原因导致的，而是好几 个独立的失效恰好同时或先后发生、串成了一条链条：书中举的例子是，来 求助恢复数据的人，往往不只是遭遇了一次存储故障或DBA误操作，还同时 缺一份可用的备份——单靠任何一个环节的失效，本来都不至于造成数据 真正丢失，是两个环节同时失效才酿成了后果。这说明防范宕机的思路应该 是”确保链条里的每一环都各自安全”，而不是只盯着”最直接触发这次事故的 那一个动作”去堵漏洞。这也解释了为什么”五个为什么”这类刨根问底找单一 根因的事后复盘方法容易被滥用——它天然倾向于把一连串独立失效硬压缩成 一条因果链、最终定位到一个”元凶”，而现实中的宕机往往是多个环节各自 独立失效、恰好叠加在一起的结果，把复盘焦点收窄成”找到那一个真正的 原因”或”揪出那个该负责的人”，反而会掩盖住其余同样需要修复的薄弱环节。 另一个容易被忽视的教训是：越贵、越精密的系统本身也会成为新的失效点 ——书中提到即使是花费巨资的SAN存储、精心设计的集群系统，同样见过 大规模失效的案例，”用了更高级的技术”不等于”这个环节从此绝对安全”。 真正决定恢复速度和事故影响范围的，往往不是某一套具体工具，而是团队 有没有为”多个环节同时失效”这种现实情况做好准备。