上周不知道是从哪个网红源头，搞出一个新闻，说美国一家大银行被爆破了，结果导致存款数据都没了，贷款数据都还在。如果是金融从业者或者是DBA，其实这些都是一眼假。然而这个谣言经过短视频网站的传播，竟然真的有朋友跑来问我，这是真的吗？
两地三中心
熟悉国内金融监管的朋友都知道，中国的金融数据中心建设和保护等级，都是早在二十年前就有了明确规定，一栋楼能扛住多少级地震都是有硬性要求的，更别说两地三中心这种老生常谈。而中国的金融信息化建设以及各种制度的建设，早期也都借鉴了欧美银行业。其中谣言里的那家银行，更是有着百年历史，无论是金融数据中心的建设以及系统的高可用，都很早就建立了非常完善的制度。这些都是中国的金融信息从业者所值得学习和借鉴的。
以前我在外资券商工作的时候，两地三中心也仅仅是最基本的要求。当时的主数据中心在北京，同城备用数据库也在北京，但是物理距离却相隔了几十公里。灾备中心在上海，有着同样的安全等级要求，不会因为是灾备环境而降低建设的要求。
数据库都是严格使用Active Dataguard或者SQL Server的Mirror以及其他高可用手段，确保主备数据之间能够时间秒级别的同步。
除此之外，每年的灾备演练同样是被严格纳入日程的，有专门的团队去排期整个亚太地区的灾备演练，确保每一个国家或地区的生产环境，每年最少可以灾备演练2次，同城一次，异地灾备一次。其中真的会随机切断某些系统的生产线路，俗称isolation tests，来确保在主数据中心完全不可访问的情况下，为业务提供完整的服务。
而灾备演练的过程中，会发现各种问题，将这些问题统一归集并出具整改意见，定期复盘并且在下一次灾备演练中进行验证，同样也是灾备演练团队严格的KPI。老实说，刚开始工作我挺羡慕，因为他们做的事情还是比较固定，但是时间久了就会发现，这中间要协调要处理的事情是无法估算上限的，而且考虑到不同国家不同地区不同成本中心的实际情况，去推进这些整改真的十分困难，而且费力不讨好。而一旦出了事故，灾备规划团队的责任也是逃不过。
所以无论谣言传的多么具体多么真实，这些反直觉的东西都是经不起推敲的，尤其是存在了百年以上的大型跨国银行，对于金融IT风险的抗受能力，都比我们想的更高。在我看不到的地方，还有很多优秀的同事数十年如一日在不断重复不断演练不断排查不断整改。
多地多活
传统的两地三中心建设，毫无疑问地给了金融信息系统建设带来了更高的可用性，但是它的弊端也非常明显，就是成本和资源利用效率的问题。
相当长的时间里，我当时公司的本地备用数据中心和异地灾备数据中心的资源，都是处于睡眠状态的。数据库服务器可以通过ADG特性来用于做查询出报表，以及根据业务需要，将一些资源实现互备，比如1号RAC跑的是A系统的生产库和B系统的灾备库，2号RAC跑的是A系统的灾备库和B系统的生产库，但是对于应用服务器、存储服务器、网络带宽多多少少都有一些高成本的冗余存在。
当然，监管部门也意识到了这个问题，几年以前，也发布了多地多活数据中心架构的参考案例，这些年无论是同行还是我现在所在的公司，都在规划并建设这件事情。然而多地多活的建设，监管的案例也仅仅是其中一种模式，实际上也有更多的东西可以探索。
比如我现在仍然还是3个数据中心，既想要保证资源不空转太多，又要留有一定程度的冗余，还要确保紧急情况下，切换数据中心的操作风险降到最低，怎么做最合适，怎么规划最合理，这中间都存在着巨大的空白地带。不同公司的业务类型、成本投入都有着巨大的差异，有时候我只参考别人的公司的方案，仍然感觉只能是一个参考，实际动手的时候还要费一番功夫。经过几个月的思考，我也提出几点属于自己的见解，抛砖引玉。
拍脑子的方案
假设我现在有三个数据中心ABC，A和B在同城，C在异地，而我有3个主要的业务线和诸多后台系统。那么怎么规划让这它在成本、业务支持、操作风险都找到一个合适的平衡点？
首先A和B是同城，可以用于做生产和同城备用机房，C在异地作为异地灾备，这个没有太大的操作空间，重点关注的是A和B怎么分配。
那么A和B就要同时支持3个业务条线的系统以及后台系统，根据业务负载情况，A机房用于业务线1和2的生产，留有一部分冗余给业务3和后台系统的备用系统，其中后台系统获得资源的优先级更低。这些冗余资源平时可以用于测试环境。
B机房用于业务线3和后台系统的生产，不留冗余给其他系统，一旦B机房出现不可访问，立刻停掉A机房的测试环境，启动业务3的冗余，后台系统因为优先级不够，只启动业务需要的最小系统规模，甚至不启动，放到C机房。
C机房承载了3个业务条线以及后台系统的灾备，一旦同城发生地震火灾完全毁掉，C必须有能力完全接管所有业务。那么如何让它活起来？一个是用于测试，将灾备的虚机资源分配最小化，多出来的资源用于测试用途。另一个办法是，判断3个业务条线以及后台系统，对于网络延迟以及带宽要求的洼地在哪，往往是后台系统，因为和直接赚钱的业务关联不大。
那么重新规划一次，我们尝试一下这种模式：
A机房，承载业务线1和业务线2的生产环境，业务线3的备用环境。
B机房，承载业务线3的生产环境后台系统的灾备环境，以及测试环境。
C机房，承载所有业务线的灾备环境以及后台系统的生产环境。
如果A机房或者B机房其中一个故障，那么切换对应的生产到同城另一个，此时仅仅影响测试环境的资源。
如果A机房与B机房同时不可访问，那么C机房成为所有业务线的生产机房，后台系统仅保留支持业务运营的最小规模。
如果C机房故障，那么切换后台系统到B机房，仅仅影响测试环境。
如果C机房故障，此时A或B也有一个故障，那么业务系统仍然有一套可用，但是后台系统和测试环境可能会有其中一个不可用。这也是整个规划中可能最糟糕的结果，但是如果一个公司3个机房故障2个，那么现实中究竟会发生些什么，恐怕也就不得而知了。
最后结尾，我想说的是，这个规划也不是万全之策，只是我从一个谣言出发，脑洞收不住的结果，如果各位有更好的方案，非常期望能够指正。
