如果银行被挖断光纤 2小时够吗？

这是怎么了？昨天的支付宝，和今天的携程。在互联网+时代的今天，终于有了重新判定的一天。在互联网的商业模式背后，如果没有弹性的IT系统、足够强大的灾难备份，一切互联网+，都是过眼云烟，从这个角度讲，互联网+，首谈技术，先别扯商业模式。

回到事件本身，在嘲笑支付宝的时候，最应该反思的其实是银行业，换位思考，如果被挖断光缆的是某个银行，2个小时，够用吗？

2个小时惊魂 银行业应借此检讨

先把事件回放：5.27日下午，约17时左右，支付宝被反映故障；18时许，支付宝通过官方微博给出回应，解释是因为电信运营商光纤被挖断。19时许，支付宝服务恢复正常。22时许，支付宝官方微博正式回应复原了整个事件。

围绕整个事件有很多讨论，讨论的中心最主要的有两点：“为什么光纤被挖断，会造成整个机房瘫痪”、“为什么支付宝的业务恢复用了两个小时”。

归纳一下：其实，只是两个问题的事儿。第一个问题，应该是电信运营商的光纤灾备出现问题？第二个问题，为什么支付宝用了2个小时恢复了业务？

某企业级技术大拿是这么评价的：“这应该是中国金融史上，首次完全意义的灾难成功切换案例。在此之前，中国金融行业投入重金建设的灾备系统基本上有这么两类用武之地（一般来说，增建一个灾备数据中心的建设成本是单数据中心成本的1.1-1.2倍）：

要么，实现计划内灾备切换演习，全副武装、如临大敌、不开一枪、全身而退。要么，因系统升级造成的被动灾备切换。

事实证明，此前遭遇问题的银行业并没有做到更好。例如2013年闹得沸沸扬扬的某行DB2升级造成的系统回滚切换。万幸的是，这是发生在凌晨的系统升级故障，当时没有实时交易发生；某行也准备了各种应急预案，只是恢复的时间超出了计划，网点推迟了一个小时开业而已；而另一家西部的区域银行就没有这么强的科技实力了，同样是DB2升级失败，系统恢复时间用了37小时40分钟（37小时啊，吼吼，坐火车都到莫斯科了）

像昨晚支付宝这种突发情形下的灾备切换还真是头一遭，而且居然成功了。支付宝虽然运气差了点，但技术能力还真不是一般金融机构能拼的。

异地多活  现在有谁能做到？

在支付宝微博答复中，有一个新名词——“异地多活”。在传统了灾备方案中，一般提的都是同城灾备、异地灾备、两地三中心。与传统的灾备技术相比，异地多活的特点是：在不同地点的数据中心都可以同时支持业务，而且每个地点发生的交易都是真实业务流量，而不是常见的一主一备，如果主中心没有问题，备份中心永远都是“备胎”。

这种多活数据中心的好处是：因为所有的数据中心都在支持交易，所以能节约IT成本；另外传统方式中备份系统都不在真实的交易活动状态，所以很难判断它的状态到底怎么样，在出现问题时，都不一定敢切过去。

大规模的“异地多活”，据说目前全球除了阿里能做到，也就Google和Facebook实现了，还是非金融类的业务。中国银行业，只有某国有大行在去年6月份实现了上海同城两个数据中心的双活，是“同城双活”，还没有实现“异地多活”，而且在灾难真正发生时，切换效果如何，还有待验证。

昨天是支付宝“异地双活”第一次真刀实枪的上战场，支付宝因为要满足金融行业的很多要求，特别是对交易一致性、数据完整性等方面的要求，目前还处于小范围试用阶段，没有全体上线，例如昨天杭州机房瘫痪后，有一部分流量跑在支付宝异地机房。因此，在昨天支付宝2小时整体恢复之前，并不是所有交易都停止的，并且基于“异地多活”技术，实现了这部分用户的无感知切换。

对另外没有通过“异地多活”技术切换的交易流量，支付宝选择了最稳妥的做法：首先进行了完整的数据校验，保证所有客户的客户信息、账户信息、资金信息、交易信息都是正确的，一切确认完成后，才重新“开门迎客”。这个过程耗时了一个多小时，不过相比较支付宝数亿客户所对应的校对数据量，这个时间还是可以接受的。

侧面印证切换效果的是：被挖断的光纤修到半夜才恢复，而支付宝的业务在晚间19点多恢复正常。

客观来讲，支付宝的这次表现，是一次说不上完美、但很成功的真实灾难切换，也是中国金融史上第一次在完全突发情形下，成功完成切换的真实案例。整个切换过程中，没有一条客户数据丢失，也体现了金融级的数据高可用要求，虽然切换的时间对用户来说长了点，但“就像是一次跳水，整体完成的质量很高，只是落水时水花没有压好，水花稍微大了点。”

如果被挖断光缆的是银行，恐怕处理的情况不会比支付宝更好。先去解决了“异地多活”再说吧！