一、芒格怎么说

「我从不依赖单一信息来源做重大决策。如果没有至少两个独立的理由支持，我就不会动。」

（原文）”I never make an important decision based on just one source of information.

If I don’t have at least two independent reasons to support a conclusion, I don’t act.”

—— 查理·芒格，Poor Charlie’s Almanack，Peter Kaufman 编，2005年，第11讲·人类误判心理学

二、学科权威定义

定义一｜系统工程学

「冗余是在系统中增加超出正常运行所需数量的额外组件，使得当某部分失效时，备用部分能够接管功能，保证整体系统不中断。」

（原文）”Redundancy is the duplication of critical components or functions of a system with the intention of increasing reliability of the system, usually in the form of a backup or fail-safe, or to improve actual system performance.”

—— INCOSE（国际系统工程协会），Systems Engineering Handbook，第4版，John Wiley & Sons，2015年，第4.3章·可靠性工程

定义二｜信息论

「冗余是消息中超出严格传递信息所必要内容之外的部分；正是这些额外内容，使系统能够在噪声干扰下仍能正确解码，实现容错传输。」

（原文）”Redundancy is that fraction of the message which is determined not by the free choice of the sender, but rather by the accepted statistical structure of the language—it serves to correct errors introduced by the channel.”

—— Claude E. Shannon，A Mathematical Theory of Communication，Bell System Technical Journal，1948年，Vol.27，p.398

定义三｜可靠性工程

「单点失效（Single Point of Failure）是指系统中一旦发生故障就会导致整个系统停止运作的单一节点；消除单点失效是可靠性设计的首要目标。」

（原文）”A single point of failure (SPOF) is a part of a system that, if it fails, will stop the entire system from working. SPOFs are undesirable in any system with a goal of high availability or reliability.”

—— Patrick D. T. O’Connor & Andre Kleyner，Practical Reliability Engineering，第5版，Wiley，2012年，第6章，p.201

三、底层机制

独立故障概率的乘法法则——冗余的数学根基

冗余之所以有效，根植于一个简单的概率事实：独立事件同时发生的概率，等于各自概率之积。如果一个存储节点的年失效概率是1%，两个独立备份同时失效的概率就是0.01%，三个则降至0.0001%。这不是线性改善，是指数级的可靠性提升。这就是为什么飞机要有双引擎、核电站要有多重冷却系统——不是因为单个部件不可靠，而是因为「不可接受的结果」要求概率趋近于零。

三个层次的冗余

• 结构冗余：物理层面的备份。双引擎飞机、RAID磁盘阵列、双路供电。备份组件实体存在，主系统失效时自动接管。

• 信息冗余：同一信息通过多条独立路径存储或传递。重要文件多地备份、法律文件要求两个证人签字、科学实验要求重复验证。任何一条路径失效，信息不丢失。

• 时间冗余：用时间窗口换取纠错机会。决策前设定「冷静期」、让结论「过夜」再审视、合同设置反悔期——给自己一个「撤回」的备份机会。

为什么系统天然抗拒冗余？

因为冗余在平时看起来是「浪费」——额外的硬盘永远闲置，备份的文件从不打开，多花的时间毫无回报。这是效率与韧性之间的永恒张力：精益生产削减一切冗余，系统在正常状态下达到最高效率；但一旦断链，没有任何缓冲，直接归零。冗余的成本是持续可见的小钱，它防范的是低概率的大灾——而人类大脑天生低估低概率事件，这使得冗余在决策时总是「感觉不值」。

「不可接受的结果」是划定冗余底线的唯一标准

冗余不是越多越好——它有成本。正确的问法是：哪些结果对我来说是绝对不可接受的？围绕这些结果设计冗余，其他地方可以精简。飞机不需要三套娱乐系统，但需要三套液压系统；你不需要把每封邮件存三份，但确实需要把不可替代的数据放在三个独立的地方。

四、真实案例

1.【案例一】1986年挑战者号航天飞机爆炸

【案例】

1986年1月28日发射前夜，NASA工程师罗杰·博伊斯约利（Roger Boisjoly）发出正式备忘录，警告O形密封圈在低温（当天约-1°C）下会失效，强烈建议推迟发射。但整个决策链中只有他一个人提出了这一警告——工程意见没有独立的冗余验证机制，管理层在时间压力下采信了「没有其他人反对」的沉默。

【结果】

1986年1月28日，挑战者号发射73秒后解体，7名宇航员全部遇难。事后总统调查委员会（Rogers Commission）明确指出：决策系统缺乏独立工程评估的冗余渠道，导致单一工程师的警告被制度性忽视。

【来源】

Report of the Presidential Commission on the Space Shuttle Challenger Accident，美国政府出版局，1986年，第5章；Roger Boisjoly备忘录，1985年7月31日，现存于美国国家档案馆；Diane Vaughan，The Challenger Launch Decision，University of Chicago Press，1996年

2.【案例二】2010年深水地平线石油泄漏

【案例】

深水地平线钻井平台在深海作业时，防喷器（Blowout Preventer，BOP）是阻止井喷的最后一道屏障——也是唯一一道。该设备存在已知的设计缺陷和维护问题，但没有独立备用防喷器，构成了典型的单点失效（Single Point of Failure）。

【结果】

2010年4月20日，防喷器在关键时刻失效，引发爆炸，11人遇难，近500万桶原油泄入墨西哥湾，成为史上最大海上石油泄漏事故。美国国会事故调查委员会在最终报告中将「单点失效设计」列为根本原因之一。

【来源】

National Commission on the BP Deepwater Horizon Oil Spill and Offshore Drilling，Final Report，美国政府出版局，2011年，第4章

3.【案例三】亚马逊AWS多可用区架构（2006年起）

【案例】

亚马逊在设计AWS云基础设施时，将数据中心划分为地理上相互独立的「可用区」（Availability Zone），同一地区内通常有3个或以上可用区，任何一个可用区的停电、火灾或网络故障，都不会影响其他可用区的服务。

【结果】

2011年4月，AWS美东数据中心发生大规模故障，但使用了多可用区部署的客户几乎不受影响；只有单可用区部署的客户服务中断数小时。此后，「多可用区部署」成为行业标准配置写入AWS最佳实践文档。

【来源】

Amazon Web Services，AWS Well-Architected Framework，可靠性支柱，2012年首版，持续更新；AWS 2011年4月故障事后报告（Post-Incident Report），公开发布于aws.amazon.com

五、如何用它思考

• 1. 识别生活和工作中的单点失效：问自己：哪件事如果只靠这一个支撑，失效了就无法挽回？列出来。

• 2. 围绕「不可接受的结果」划底线：不是所有事情都需要冗余——先确定哪些结果对你来说绝对无法承受，优先给这些事设计备份。

• 3. 信息来源要求独立性：两个消息来源如果都来自同一渠道（比如同一个人转述），等于零冗余。只有真正独立的第二来源才算数。

• 4. 定期测试备份是否真的可用：备份存在≠备份可用。硬盘备份要定期验证能否读取；应急计划要定期演练。没有被验证的冗余，是虚假的安全感。

进阶问题

• 你最重要的数据、信息、能力，现在存在几个独立的地方？

• 如果其中一个今天消失，你能从另一个地方完整恢复吗？

六、我的例子（附AI诊断）：

例子原文

「个人信息和公司信息都要做好备份，这种叫做灾备，灾难备份。

我自己经历过很多次用某个APP，结果这个APP下架，里面的信息无法再恢复，造成了严重损失。

所以要定期做好备份工作。

如果有多处备份，但不可接受的结果发生时，还能有回旋的余地。

这种日常做好备份，看起来有些麻烦和概率很低，

但是能极大增加避免不可接受结果发生的概率。」

我的分析

我的例子精准命中了冗余原则最核心的三个机制：

第一，识别出了单点失效的本质

APP平台是单一存储节点，平台下架 = 数据通道永久关闭，没有任何备份路径。这在工程学上叫做SPOF（Single Point of Failure），是可靠性设计中最优先消除的风险。你的经历说明：平台本身的持续存在，是你的数据安全的隐含前提——但这个前提从来没有被保证过。

第二，准确描述了冗余被抗拒的心理根源

「看起来有些麻烦和概率很低」——这正是所有系统天然抵制冗余的原因。备份的成本是持续、可见、即时的；灾难是偶发、隐性、遥远的。人类大脑在这种权衡中几乎必然低估灾难概率，导致「感觉不值」。你已经意识到这个认知偏差，并选择克服它——这是真正理解了冗余原则。

第三，「不可接受的结果」是你划定备份底线的正确标准

你用的这个词非常精准。冗余不是「什么都备份」，而是「围绕不可接受的结果设计备份」。个人信息和公司信息一旦丢失无法重建，属于「不可接受的结果」，因此值得付出备份的持续成本。这个判断框架是对的。

一个延伸建议

真正的灾备还需要独立性和可验证性——备份在同一台设备上不算独立冗余（设备丢失=全部丢失）；备份存在但从未验证过能否恢复，是虚假的安全感。灾备的标准：至少两处地理独立的备份，且定期实际测试恢复流程。

七、一句话总结

冗余不是浪费，是你为「不可接受的结果」提前支付的保险费——而且这笔保险比任何金融产品都可靠。

参考书目

• Charles Perrow，《正常事故》Normal Accidents: Living with High-Risk Technologies，Princeton University Press，1984年（豆瓣：https://book.douban.com/subject/1418840/）

• Claude Shannon & Warren Weaver，The Mathematical Theory of Communication，University of Illinois Press，1949年

• INCOSE，Systems Engineering Handbook，第4版，Wiley，2015年

• Patrick D. T. O’Connor & Andre Kleyner，Practical Reliability Engineering，第5版，Wiley，2012年

• Diane Vaughan，The Challenger Launch Decision，University of Chicago Press，1996年（豆瓣：https://book.douban.com/subject/1734966/）