两地三中心和三地五中心听起来很美，现实却很残酷

昀哥2020年12月5日

 

一 大家总是高估技术进步的速度低估技术的复杂度

多活，多数据中心，听着很起劲。但是……现实很残酷。

我来带大家回忆一下。

 

2015年8月12日天津港大爆炸，当时腾讯天津数据中心距离爆炸中心点仅有1.5公里（如下图所示），它是腾讯当时在亚洲最大云计算数据中心，2010年刚刚投入运行，共计8万平方米，约20万台服务器，腾讯内部称它为“天津数据备份中心”，承载了微信、即时通讯等业务的部分数据需求。

 

（爆炸冲击波巨大）

 

（爆炸中心周围的企业分布）

 

当时巨大的冲击波使得这个数据中心的“柴油发电机的门，墙都扭曲了，非常危险”以及“整个冷机系统宕机，冷冻水管爆管，地下水发生严重水浸”，工作人员也因为人身安全而不得不撤出现场，如果这个数据中心出现意外，很多存储在这个数据中心的数据都没了，包括你的朋友圈数据，当时腾讯也没有做备份（可不，本身就是备份，备份差点儿被炸）。

 

（第二天也就是8月13日，员工们又带着N层N95口罩返回了数据中心）

 

在这以后，数据安全问题得到了腾讯重视。有人给马化腾提出建议，可以在贵州建一个大数据的灾备中心，因为贵州有很多优势：水电充足，电力很便宜；它有很多山洞，恒温恒湿。所以后来腾讯又在贵州专门建立了新的，更大规模的数据中心。

 

2015年的支付宝也没好到哪里去：

2015年5月27日，因市政施工挖断支付宝杭州数据中心光缆，虽然支付宝的单元化架构容灾基本成型，但还是碰到很多实际问题，花费了数小时完成切换、恢复服务。虽然数据没有出错，但对于这样体量的公司来说，服务不可用的社会舆论影响也是非常大的。

 

所以527这个数字，成为蚂蚁技术人心中悬着的那颗苦胆，5月27日才被定为蚂蚁的技术日，来时刻警醒要敬畏技术，不断打磨技术。

 

再后来，蚂蚁在2018年云栖大会上现场演示了三地五活“剪网线”（如下图所示），达到了中国互联网的顶尖水平。

 

（现场演示的操作界面）

 

到了2017年5月9日，饿了么CTO张雪峰才宣布饿了么多活（Multi-Active IDCs/Regions）取得成功，实现首次多活生产环境全网切换（灰度）。张雪峰还称，据他所知，国内日均（非峰值或大促期间）订单100万笔以上的交易平台，除阿里巴巴真正意义上实现了全网多活（不是双活），截止到当时应该还没有第二家可以完全做到。

在他看来，异地多活的难点在于技术和实施。技术上，最重要的是实时数据强一致性，尤其对于外卖配送这种即时性非常强的业务场景来说。实施上，最大的挑战在于给高速飞行（快速产品迭代）中的飞机换发动机。

 

所以说2018年我们独立自主实现了异地双活，可以秒级按商户、按城市、按省、按机房、按设备随时切换商户流量，商户、用户和收银设备无感知，还真的不算晚。

 

二 有方案，和，敢不敢切换，是两回事

一说到2015年天津港大爆炸危及1.5公里外微信数据中心的数据安危，一说到2015年5月27日支付宝杭州数据中心光缆被挖断导致支付宝花费了数小时才完成切换恢复服务，有人就开心地说银行业二十年前就做到了。我也不知道做到啥了，多数据中心？多活？

 

银行系统虽然很早以前（最早可都是二零零几年）就建立起了完善的灾备系统（注意是“灾备”，不是“多活”），但是由于平常没有做过系统演练，当真正灾难性事件出现的时候，谁都不敢轻易切换系统，生怕切换后再也切不回来。

 

这样的事情屡屡发生屡见不鲜：某股份制商业银行系统宕机业务暂停一天的重大事故与容灾中心没有完全建好、行长不敢下令将业务系统切换到容灾系统有关。十年前，甚至可以说五年前，中国金融机构业务连续性管理的主要工作仍停留在IT系统灾难恢复的技术层面上。

 

下面讲三个案例。

 

第一个，2010年2月3日，从上午十点多到下午15:30，民生银行全行系统瘫痪，故障持续四个多小时。

当时有人在推特上介绍说，这次事故源于IT部门某应用系统数据库（应该是Informix，数据库版本老旧且无正常维护服务），一个应该在夜间处理的长任务，运行到银行开门也未结束，该系统正常时的CPU使用率就已经到达70-80%，长任务从夜里一直跑到上午无法停止，把本来就不堪重负的业务系统拖慢到不能忍受，由于数据库版本EOS（即End of Service），所以没有厂商实验室的工具支持，无奈之下，重启相关系统，结果导致业务停止。所以在这种情况下，多数据中心又有啥用，负载这么高，切哪儿哪儿崩。

 

第二个，2013年6月23日上午，工商银行柜台、ATM、网银业务出现故障，持续近1个小时。作为当时服务2.92亿对私客户及400多万对公客户的全国金融服务巨头，工行此次故障波及北京、上海、广州、武汉、哈尔滨等多个大中型城市，以下简称“6·23事件”。当日，工行将该事故对外模糊描述为：“中国工商银行部分地区因计算机系统升级原因造成柜面和电子渠道业务办理缓慢。”这也是迄今为止工行就6·23事件向用户发布的唯一公开解释。

 

 

如上图所述，工商银行信息科技部就6·23事件正式作出内部通报，这份通报称，工行数据中心（上海）主机系统出现故障，是由于IBM提供的主机DB2V10版本内存清理机制存在缺陷而引发。那么我想问多数据中心呢？

 

原因很简单，2013年的时候工行还没有一键切换能力呢：

2004年，工商银行在国内同业中率先建立起“两地两中心”的数据中心异地灾备架构；

2009年，工行启动“两地三中心”数据中心新架构研究；

2014年，上海嘉定同城数据中心正式投产启用，工行在同业界率先成功实现数据中心同城双中心全业务切换运行，标志着“两地三中心”工程初见成效；

2014 年11 月，工商银行首次采用临时通知的方式，成功实施同城核心系统切换运行，实施过程采用“一键式”切换工具，主机核心系统切换时间控制在分钟级。

 

明白了吗？有灾备，和，敢不敢切换，是两回事。跟异地多活，跟2018年蚂蚁演示的“三地五中心”“剪网线”，更是两回事。

 

第三个，2011年4月12日下午，韩国最大的银行农协银行（NH Bank）的业务全网瘫痪，故障一直持续了3天，直到4月15日才恢复部分服务，而有些服务直到4月18日仍然没有恢复，以至于银行不得不采用传统的手写交易单的方式进行服务。

 

据农协银行工作人员、韩国检察官、金融监督院以及中央银行调查员的初步调查，4月12日下午4:30到5点之间，“某人”通过外包团队中一位雇员的笔记本对银行核心系统的275台服务器下达了 rm.dd 命令，该命令会删除服务器上的所有文件。被删除的服务器包含重启系统用的服务器。结果就是当天下午5:30左右开始，该银行在全国1154个分行的服务中断。

 

rm.dd是最高级别的系统命令，只有拥有最高安全权限的Super Root用户才有权限执行，而且仅限银行内网的特定IP段。

 

在事故过程中，位于良才的中继代理服务器以及位于安城的灾备服务器全都失效了，结果就是只能通过给553台服务器重装系统来恢复服务……&￥%！

 

笔记本的所有者表示删除命令绝非自己所下达。事发当时，该员工的笔记本放置在银行的办公室内。根据当天监控视频，有20个人有机会接触到这台笔记本，这20人当中确有一人拥有Super Root权限。

 

但是，也不排除有黑客从外部互联网连接到这台笔记本，再通过这台笔记本做跳板对服务器下达指令的可能，因为该笔记本在当天的24小时内与外网是连通的。

在这次事件中，灾备起作用了吗？没有。灾备都被人给干掉了。

 

参考：

1，https://www.sohu.com/a/354590436_258957，银行网挂了，会怎样？建行灾备，神操作！

2，https://www.cnbeta.com/articles/tech/140639.htm，从韩国农协银行瘫痪再看安全与灾备的重要性

3，https://www.chiphell.com/forum.php?mod=viewthread&tid=808335，工行内部通报6.23系统故障 系IBM软件缺陷引发

4，https://www.sohu.com/a/78018744_259978，马化腾：去年天津大爆炸，曾让腾讯最大的数据中心

5，https://www.cisco.com/web/CN/partners/industry/pdf/finance_solutions_19.pdf，思科对银行灾备总结的PPT

6，https://zhuanlan.zhihu.com/p/48689251，从“挖光缆”到“剪网线”|蚂蚁金服异地多活单元化架构下的微服务体系