罗辑思维曾经讲到一个故事，第一次世界大战到了最后，德皇希望停战，但是，德军参谋部回复说没有制定停战的预案，也就是没有方案B，因此，战争只能继续，战败后德皇也落得倒台的命运。
方案B，顾名思义，也就是主要方案的备份方案，不仅适用在战争场景。像德军参谋部这样不制定方案B，无非几个理由，一是举韩信背水一战的案例，认为只有一个方案，才能激发出团队的斗志；二是没有必要杞人忧天，浪费资源；三就是主要方案都捉襟见肘，没有余力来做。
对于互联网系统来讲，特别对于核心服务，要提供7X24小时的服务能力，并且，互联网服务可用性，涉及的方面特别多，不仅是服务器，还有网络，不仅自身的服务，很多还依靠基础服务，不仅自身可能出问题，还有黑客攻击等等，因此，只是依靠一个主要的方案，保障高可用，难度是非常大的，风险也极大，制定方案B就显得非常重要了。对于核心服务，重要性不言而喻，因此，是非常必要的，即使非常紧急的项目，系统刚刚上线没有，后面也要迭代跟上。
在著名的互联网公司，对于方案B，也都是非常重视的，例如在腾讯，核心系统都要有降级方案，在京东，都要有应急方案，叫法不同，但是含义都大同小异。
互联网公司研发维护的系统多则上千，少则数十个，所有的系统都构建方案B，一则从资源投入上不现实，二则确实没有必要，首先要选择哪些系统需要，一般都是核心系统，不能承受宕机无服务的，例如电商的购物车结算系统，物流的分单系统等。
其次，即使对于对于核心系统，也需要细心选择哪些功能是真正的不可降级功能，能够做到核心功能和辅助功能分开部署，一单出现资源问题，可以优先讲辅助功能降级来保障核心功能。
然后，针对不同的应用类型，可以选择不同的方案，例如互联网常见的Web服务和Worker系统，就有不同的选择。对于Web服务，特别是数据库，一般不仅仅是备份容灾，而是要做到多活的方案。对于Worker系统，也要用MQ，或者缓存作为主要方案，而数据库作为备份方案。
最后，系统制定了方案B，并且进行了上线，一定要进行线上测试，确定是个可以执行的方案，否则，一单出现需要系统降级的情况，会发现之前的方案B并不可用，就后悔晚矣。
凡事预则立，不预则废。在互联网系统的构建过程中，一定要重视方案B的设计和实施，才能在关键时刻，解救公司业务于危机之中，避免重大损失。