昀哥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，從“挖光纜”到“剪網線”|螞蟻金服異地多活單元化架構下的微服務體系