做容灾，冷备是不是个好方案？

主备、冷备、热备、双活、多活、同城、异地、多云，等等等等，这些保证业务高可用和容灾名词，我们经常会听到，不绝于耳。

但是，真的当我们自己要去建设，选择方案时，就发现不知道该怎么选择和搭配了。

结合近期我们的一些讨论，准备用几篇文章简单分享下我们的理解，今天先聊冷备。

冷备是不是个好方案？

这里的冷备我们可以理解为，是主站系统核心链路的镜像站点，应用、各类分布式服务以及底层基础设施都是独立，且启动的。

它跟主站唯一的差别就是，正常情况下，不承载任何线上流量。

理论上，只要有状态的数据（也就是各类分布式服务，如数据库、缓存、消息等组件）同步好，接入层流量能够灵活调度，当出现问题的时候，切入口流量，就可以顺畅的切过去。

看上去很美好，但是实际操作起来，基本不可行。

这里有一个关键点，就是业务应用，应用的代码和配置是随时在变化的。

原则上，我们可以通过持续交付和运维自动化等等手段，确保每次变更都能够同步到备站点，并通过流程约束不允许有外部操作。

所以，手段上，我们可以做到非常完备，流程上，我们可以设计的非常严密。

但是，我们始终绕不开的一个命题，只要不承载真实的线上业务流量，我们就无法证明这个系统是可用的。

何况，有可能是好几个月我们都不会发生真实的切换动作，所以，一个几个月没有经过线上流量检验的系统，在真正需要切换时，不会有任何人敢决策直接切换的。

当然，以上是我们的直接推断，确实行不通。但是我们仍然要经过一些详细的论证，从其它角度看是否有解。

从另外一个角度的论证过程

当时我们讨论在冷备的前提下，应该怎么保证系统的可用性，没想到，论证的过程，反而进一步证实了冷备只是一个美好的愿望。

1、通过模拟压测的方式。

但是我们知道，压测的模型是根据线上业务模型来定制的，但是业务场景和逻辑每天都在发生变化，压测模型的同步有时是跟不上业务模型变化的。

况且这个日常工作量要靠人，无法做到自动生成，所以基本不可持续。

再就是，压测的结果检验是通过技术指标衡量，而非业务指标，也就是是否200ok，或者出现5xx之类的错误。

业务逻辑上是否正确，并没有办法确保。这种情况就极易造成数据污染。数据故障的影响范围远远超过服务不可用的影响。

所以，压测可以最大程度评估系统容量，但是无法保证系统业务正确性。

2、切换后，接入线上流量前，QA介入验证。

理由同上，工作量大，也无法覆盖到所有场景，时间不可控，完全起不到冷备节点的快速承载业务效果。

3、定期模拟演练，确保系统周期范围内可用

但是这里就有一个前提，冷备站点的建设目标，并不是全量建设，而是在极端状况下，确保核心业务临时可用，当主站点恢复后，仍然要切回去。

这里暗含的一个意思就是，一旦需要做这个动作，业务必然有损，而且涉及范围非常大，这就意味着，每一次演练都要付出极大的业务代价。

从这个角度，产品运营及决策者们是不会允许你经常干这种事情的。

到这里，你会发现，连日常演练的条件都不具备了。

4、一个绕不开的限制条件

数据同步必然是单向的，为了保证数据一致，通常要确保备用站点是禁写的，以防止各类误操作引起的数据污染。

所以，即使上面几个方案可行，基础条件上又不满足，因为根本无法写入数据，关键的业务逻辑根本不具备验证条件。

最后，结论

冷备只能是冷备，关键时刻并不能起到快速承载业务的效果，在业务容灾建设时，这个思路其实是不可行的。

但是对于部分组件，比如数据库、大数据、文件，这些存储类的部件，做冷备是有重大意义的。

也就是，后面我们在提到冷备时，应该叫做数据冷备、文件冷备、源代码冷备才有意义，或许会更准确些。