最近暴雪公司和網(wǎng)易的一則聲明刷爆了朋友圈，大意就是由于『供電意外中斷的原因而產(chǎn)生故障，導(dǎo)致數(shù)據(jù)損壞』，這樣一則公告引發(fā)了一系列的猜想，我們?cè)趪^時(shí)仿佛人人都是諸葛亮，而事實(shí)上設(shè)身處地，我想在一次負(fù)責(zé)任的故障考驗(yàn)下，也許很少有人能夠幸免。

　　如同阿里云會(huì)誤刪文件、京東會(huì)泄露數(shù)據(jù)、支付寶會(huì)被修改密碼、攜程會(huì)大面積癱瘓，在災(zāi)難來(lái)臨之前，誰(shuí)都會(huì)覺(jué)得自己是幸運(yùn)者，而事實(shí)上，只是措手不及那次災(zāi)難還沒(méi)有來(lái)到而已。

　　先回顧一下《爐石傳說(shuō)》長(zhǎng)長(zhǎng)的公告，然后我們?cè)倩谑聦?shí)做一下分析吧：

　　首先，關(guān)于暴雪的核心數(shù)據(jù)庫(kù)架構(gòu)，不是網(wǎng)友猜測(cè)的MySQL(如果是 MySQL 就必然是分布式，不可能全部回檔的)，而是Oracle數(shù)據(jù)庫(kù)。關(guān)鍵的系統(tǒng)架構(gòu)如下(部分屬于推測(cè))：

　　數(shù)據(jù)庫(kù)：Oracle

　　架構(gòu)：RAC + ASM

　　版本：12.1.0.2 (猜測(cè))

　　節(jié)點(diǎn)數(shù)：4 (猜測(cè))

　　系統(tǒng)：Linux

　　同步：GoldenGate

　　基于這樣一些真實(shí)的基礎(chǔ)和前提去討論這次的事故，才更有意義。

　　以下是前一段時(shí)間暴雪招聘DBA Lead的條件要求，系統(tǒng)架構(gòu)由此一目了然：要求深入理解Oracle內(nèi)部原理、Oracle RAC和ASM技術(shù)，熟悉Golden Gate復(fù)制，熟悉Linux腳本編程。

　　這些要求就深刻揭示了暴雪核心數(shù)據(jù)庫(kù)的體系架構(gòu)。在Linux上運(yùn)行的基于ASM存儲(chǔ)的Oracle RAC集群，使用OGG復(fù)制數(shù)據(jù)。

　　在招聘中有一個(gè)特殊的要求，『Evaluate new releases and features of Oracle DBMS』，評(píng)估Oracle新版本和特性的能力，這一獨(dú)特要求可能和當(dāng)時(shí)要升級(jí)核心數(shù)據(jù)庫(kù)有關(guān)，而升級(jí)版本就應(yīng)該是12c，據(jù)此我推測(cè)其數(shù)據(jù)庫(kù)版本應(yīng)該已經(jīng)追到最新版本12.1.0.2，國(guó)外的大公司風(fēng)格基本如此，有了12.1.0.2，肯定不會(huì)有人守在12.1.0.1版本上，而且這套中國(guó)的系統(tǒng)是部署不久的獨(dú)立系統(tǒng)。

　　以下就是暴雪對(duì)于這個(gè)崗位的詳細(xì)需求：

　　之前在互聯(lián)網(wǎng)上已經(jīng)披露了很多信息，包括一次故障的處理流程(來(lái)自搜索引擎)：

　　1.9C在一次服務(wù)器故障中的說(shuō)明，下面只列出關(guān)鍵部分

　　08:29 收到EVA存儲(chǔ)報(bào)警郵件，聯(lián)系數(shù)據(jù)中心工程師，聯(lián)系惠普工程師.

　　08:35 故障應(yīng)急流程啟動(dòng),相關(guān)人員包括THE9/HP/Blizzard US .

　　15:33 Oracle專家加入故障應(yīng)急流程

　　15:50 暴雪數(shù)據(jù)庫(kù)工程師開(kāi)始與Oracle專家繼續(xù)分析故障情況.

　　17:15 暴雪表示暫時(shí)還未從他們的admin以及DBA處獲得任何有新的消息，他們?nèi)匀辉谘芯看斯收稀?/p>

　　當(dāng)時(shí)的數(shù)據(jù)庫(kù)運(yùn)行在HP服務(wù)器上(大約2013年)，現(xiàn)在已經(jīng)遷移到Linux服務(wù)器上。

　　此外，暴雪的數(shù)據(jù)量很大，多年前Oracle 9i 時(shí)就是TB級(jí)別的數(shù)據(jù)庫(kù)了，當(dāng)然現(xiàn)在中國(guó)大陸地區(qū)肯定是獨(dú)立的服務(wù)器，但是數(shù)據(jù)量也絕對(duì)會(huì)是TB級(jí)別的，再加上免費(fèi)開(kāi)放的熱門程度，我推測(cè)兩節(jié)點(diǎn)的RAC對(duì)中國(guó)玩家不夠尊重，至少應(yīng)該是4節(jié)點(diǎn)的Oracle RAC集群。

　　所以大家可能聯(lián)想到了2016年年初的另外一則故障，在2016年3月22日，全日航空的故障導(dǎo)致了120個(gè)航班取消，據(jù)傳是4節(jié)點(diǎn)RAC集群，由于網(wǎng)絡(luò)問(wèn)題導(dǎo)致故障：

　　【導(dǎo)致全日空(ANA)120個(gè)航班被取消的票務(wù)系統(tǒng)故障是交換機(jī)引起的】造成Oracle Cache Fusion的UDP通訊異常，4節(jié)點(diǎn)的Oracle RAC無(wú)法重組集群。本來(lái)交換機(jī)是有主備設(shè)計(jì)的，但是主交換機(jī)并未徹底壞掉，而是處于不穩(wěn)定狀態(tài)，備用交換機(jī)不知道主交換機(jī)出了故障所以沒(méi)有接管。

　　我們?cè)倩剡^(guò)頭來(lái)看暴雪的運(yùn)維，最終看起來(lái)似乎沒(méi)有找到合適的DBA Leader，所以內(nèi)部晉升了一位，在LinkedIn上，這些信息是公開(kāi)的：

　　好了，有了這些事實(shí)之后，我們?cè)倏垂婢蜁?huì)清晰很多了。我們理一下時(shí)間軸：

　　1月14日 15：20 (據(jù)說(shuō))因?yàn)楣╇妴?wèn)題，導(dǎo)致數(shù)據(jù)庫(kù)損壞;

　　DBA開(kāi)始修復(fù)，但是發(fā)現(xiàn)備份數(shù)據(jù)庫(kù)也損壞了;

　　數(shù)據(jù)庫(kù)帶病堅(jiān)持工作，DBA同時(shí)開(kāi)始在線修復(fù);

　　1月17日1點(diǎn)開(kāi)始停機(jī)修復(fù)，修復(fù)預(yù)計(jì)8小時(shí)，未能按照預(yù)期時(shí)間完成;

　　1月18日18：00發(fā)布公告，數(shù)據(jù)回檔到1月14日 15：20，業(yè)務(wù)恢復(fù);

　　外行看熱鬧，內(nèi)行看門道

　　在了解了系統(tǒng)架構(gòu)之后，從官方的信息里我們能夠看到很多事實(shí)：

　　第一：故障出現(xiàn)在14日，應(yīng)當(dāng)早于15：20，公布時(shí)間推移，這是慣例;

　　第二：供電問(wèn)題可能性不大，如果說(shuō)成熟運(yùn)營(yíng)的IT，還存在單電單點(diǎn)是說(shuō)不過(guò)去的，網(wǎng)易也不允許;

　　第三：數(shù)據(jù)庫(kù)損壞應(yīng)該是壞塊，Oracle數(shù)據(jù)庫(kù)在出現(xiàn)損壞故障時(shí)，仍然能夠堅(jiān)持工作的，應(yīng)該是出現(xiàn)了壞塊，壞塊通常被大家疏忽，以為可解，所以拖延成了極慢長(zhǎng)的次生故障;

　　第四：暴雪沒(méi)有ADG的災(zāi)備，不可切換，請(qǐng)注意聲明中明確說(shuō)“備份數(shù)據(jù)庫(kù)”而不是“備用數(shù)據(jù)庫(kù)”;

　　第五：數(shù)據(jù)庫(kù)依賴OGG進(jìn)行復(fù)制，這個(gè)復(fù)制因?yàn)槟撤N原因不能用于恢復(fù)，極可能因?yàn)镽edo日志或 Undo 也有損壞，丟失了某些事務(wù);

　　第六：最終壞塊問(wèn)題無(wú)法修復(fù)，只能選擇基于時(shí)間點(diǎn)的不完全恢復(fù)，放棄了部分事務(wù)，也就是數(shù)據(jù)回檔了，這是最無(wú)可奈何但是也是保證數(shù)據(jù)一致性的殘酷選擇;

　　第七：數(shù)據(jù)庫(kù)的壞塊，沒(méi)有影響數(shù)據(jù)庫(kù)運(yùn)行，證明是小范圍的損壞，不是文件級(jí)別的損失，這應(yīng)當(dāng)和存儲(chǔ)的相關(guān)性更大，寫丟失導(dǎo)致了數(shù)據(jù)塊損壞;

　　第八：最初的8小時(shí)，是計(jì)劃恢復(fù)部分表空間，但是沒(méi)有解決問(wèn)題，最終進(jìn)行了全庫(kù)恢復(fù)，根據(jù)這個(gè)停機(jī)時(shí)間預(yù)估數(shù)據(jù)庫(kù)整體容量應(yīng)當(dāng)在10TB左右;

　　所以我們大膽推測(cè)：是因?yàn)榇鎯?chǔ)故障導(dǎo)致了RAC集群寫數(shù)據(jù)丟失，最終選擇不完全恢復(fù)，放棄了部分?jǐn)?shù)據(jù)。

　　DBA第一守則：備份重于一切

　　如果大家還記得我曾經(jīng)寫下的DBA守則，沒(méi)有備份對(duì)于DBA來(lái)說(shuō)將會(huì)是致命的，而如果沒(méi)有有效備份，那么備份也只能是心靈安慰。不論如何，備份至少可以給我們重來(lái)一次的機(jī)會(huì)，暴雪這一次最終救命的就是備份。雖然是回退到了14日。

　　既然備份這么重要，國(guó)內(nèi)數(shù)據(jù)庫(kù)的備份情況如何呢？云和恩墨白求恩平臺(tái)最近發(fā)布的《中國(guó)2016年Oracle數(shù)據(jù)庫(kù)運(yùn)行現(xiàn)狀報(bào)告》顯示，有完整RMAN備份的數(shù)據(jù)庫(kù)不到20%，24%的數(shù)據(jù)庫(kù)甚至處于非歸檔模式下。

　　下圖來(lái)自報(bào)告數(shù)據(jù)，可以看到其實(shí)國(guó)內(nèi)的數(shù)據(jù)庫(kù)的DG的使用率其實(shí)并不高，僅有21%：

　　Bethune 平臺(tái)可以幫助大家檢查RMAN備份完整性，Dataguard同步及時(shí)性，假期來(lái)臨之前強(qiáng)烈推薦大家為數(shù)據(jù)庫(kù)做一次健康檢查。

　　關(guān)鍵節(jié)點(diǎn)是什么？

　　回顧一下，數(shù)據(jù)庫(kù)帶病堅(jiān)持工作，這是整個(gè)案例最核心的一個(gè)決策，也就是說(shuō)，通過(guò)在線運(yùn)行，同時(shí)修復(fù)問(wèn)題(壞塊)，向前走。

　　這也是一個(gè)艱難的決策，如此可以減少業(yè)務(wù)的中斷，但是面臨的風(fēng)險(xiǎn)就是可能最終數(shù)據(jù)不一致，需要回退或者承受復(fù)雜的校驗(yàn)工作。

　　大家可以想想我們面臨這樣的工作會(huì)如何處置？

　　我就此訪問(wèn)了浙江移動(dòng)王曉征王總，他表達(dá)了他的觀點(diǎn)：

　　我覺(jué)得得按照業(yè)務(wù)特性，事先約定優(yōu)先保A(可用性)還是保C(一致性)，如果沒(méi)約定的話，如果我指揮，我會(huì)臨機(jī)進(jìn)行決斷。

　　我非常贊同這一觀點(diǎn)，有了事先約定，應(yīng)急處置時(shí)才能有準(zhǔn)則，不出現(xiàn)重大偏頗。

　　要一致性還是連續(xù)性？

　　如前所述，每一個(gè)DBA團(tuán)隊(duì)都應(yīng)該有一個(gè)準(zhǔn)繩，那就是在關(guān)鍵時(shí)刻，要保障一致性(準(zhǔn)確性)還是連續(xù)性？

　　對(duì)于金融機(jī)構(gòu)，毫無(wú)疑問(wèn)，要保證數(shù)據(jù)庫(kù)的一致性，在遇到故障時(shí)，可以果斷中斷業(yè)務(wù)提供，進(jìn)行數(shù)據(jù)恢復(fù)或者修復(fù);

　　而對(duì)于互聯(lián)網(wǎng)業(yè)務(wù)等，可能連續(xù)性就更為重要，類似攜程的業(yè)務(wù)，中斷幾天的服務(wù)是不可想象的;

　　王曉征就此總結(jié)說(shuō)，在運(yùn)營(yíng)商系統(tǒng)建設(shè)的過(guò)程中，最初覺(jué)得業(yè)務(wù)連續(xù)性最為重要，但是當(dāng)這些問(wèn)題已經(jīng)被較好的解決之后，現(xiàn)在覺(jué)得數(shù)據(jù)的一致性變得更重要起來(lái)，所以不同系統(tǒng)在不同階段，就會(huì)有不同的取舍。

　　這是一個(gè)辯證的思考，也是運(yùn)維發(fā)展到一定高度之后才能有的判斷。

　　為何不切災(zāi)備？

　　關(guān)于這樣嚴(yán)重的事故，為何不切災(zāi)備？

　　如前所述，從備份數(shù)據(jù)庫(kù)的一字之別，我猜測(cè)這個(gè)系統(tǒng)根本就沒(méi)有災(zāi)備，所以無(wú)從切換，畢竟這只是一款免費(fèi)的游戲，在官網(wǎng)首頁(yè)的顯示『《爐石傳說(shuō)》官方網(wǎng)站_暴雪首款免費(fèi)休閑卡牌網(wǎng)游』。

　　對(duì)于災(zāi)備的部署和切換，王曉征表示浙江移動(dòng)內(nèi)部是這樣的：

　　按業(yè)務(wù)重要度，實(shí)現(xiàn)不同保障級(jí)別。

　　一般系統(tǒng)：只做數(shù)據(jù)備份，無(wú)高可用，無(wú)容災(zāi);

　　重要系統(tǒng)：數(shù)據(jù)備份，高可用，無(wú)容災(zāi);

　　核心系統(tǒng)：備份，高可用(部分含柔性可用)，容災(zāi)。

　　在實(shí)操層面，一般系統(tǒng)基本絕跡，目前以核心和重要系統(tǒng)為主。

　　如果出現(xiàn)數(shù)據(jù)損壞，核心系統(tǒng)肯定切容災(zāi)了，這種情況如果是硬件損壞或者刪除數(shù)據(jù)文件引起的問(wèn)題，基本就搞定了;當(dāng)然，最怕的就是誤操作或代碼bug搞出來(lái)的數(shù)據(jù)丟失，可能把容災(zāi)端數(shù)據(jù)同時(shí)破壞，那就只能通過(guò)備份來(lái)恢復(fù)啦。

　　由此可以看出，即便有了完備的災(zāi)備環(huán)境，也很難防范所有問(wèn)題，尤其是人為的誤操作，所謂『功夫再高，也怕菜刀』，一個(gè)誤刪除可能就級(jí)聯(lián)到所有的系統(tǒng)，再加上軟件BUG不可避免，除了災(zāi)備，必然還要有可靠的備份來(lái)托底。

　　運(yùn)維團(tuán)隊(duì)怎么配置？

　　大家還要思考一個(gè)問(wèn)題，在處理復(fù)雜故障的時(shí)候，工作不能中斷，但是人不能持續(xù)運(yùn)轉(zhuǎn)，在暴雪的這次事故中，從14日至18日，將近5天的時(shí)間，處理人員可能已經(jīng)更替了幾輪，如何延續(xù)處理思路、執(zhí)行正確決策、保持核心戰(zhàn)斗力，這也是運(yùn)維要思考的重要因素。

　　如何幸存于類似事故？

　　好吧，我們談一談如何避免陷入這樣的困境？以下是我們的一些思路，與大家商榷。

　　首先，要有完善、有效的備份和容災(zāi)機(jī)制。誠(chéng)然很多企業(yè)都有了一整套的備份、容災(zāi)機(jī)制，但是這套備份機(jī)制能否真實(shí)奏效是需要檢驗(yàn)的。我接觸過(guò)某大型企業(yè)，投入巨資興建的災(zāi)備中心，從未正式切換過(guò)，這樣的災(zāi)備在故障來(lái)臨時(shí)也很難有人拍板去進(jìn)行切換，所以備份的有效、容災(zāi)手段的有效是必須確保的。注意，備份的恢復(fù)速度必須足夠的考慮到，磁帶的低效備份關(guān)鍵時(shí)刻會(huì)害死人。

　　其次，要有完善的故障處理策略和流程。對(duì)于不同系統(tǒng)，在關(guān)鍵時(shí)刻要優(yōu)先確保什么，是要訂立規(guī)則的，有了規(guī)則才能照章辦事，不走錯(cuò)方向，不無(wú)辜背鍋。幾年前某國(guó)內(nèi)金融系統(tǒng)出現(xiàn)數(shù)據(jù)壞塊，同樣選擇了帶病修復(fù)，最終沒(méi)能解決問(wèn)題，同樣選擇了回檔承擔(dān)了數(shù)據(jù)損失。

　　再次，要有端到端融會(huì)貫通的應(yīng)急機(jī)制。也就是說(shuō)不僅僅技術(shù)上具備容災(zāi)應(yīng)急的響應(yīng)方案，從業(yè)務(wù)端同樣要有對(duì)應(yīng)的預(yù)案，以便應(yīng)急時(shí)同步處理，區(qū)別對(duì)待。很多時(shí)候，有了業(yè)務(wù)上的應(yīng)急、降級(jí)服務(wù)方案，技術(shù)層面的處理就能夠從容許多。

　　最后，要有能夠快速協(xié)同的團(tuán)隊(duì)資源。很多時(shí)候嚴(yán)重的故障，需要較大規(guī)模的專業(yè)團(tuán)隊(duì)協(xié)作處理，原廠商和第三方在其中都承載著重要的角色，所以關(guān)鍵時(shí)刻，要能夠獲得內(nèi)外部快速及時(shí)的支持，尤其是在綿延數(shù)天的高強(qiáng)度工作中。

　　對(duì)于事后的補(bǔ)償，19日暴雪已經(jīng)給出了反饋，第一條就是“只要曾經(jīng)在2017年1月18日18點(diǎn)之前登錄過(guò)國(guó)服玩家，均可獲得與25卡牌包等值的補(bǔ)償”，越來(lái)越覺(jué)得，這次“營(yíng)銷”是很成功的。

　　感謝王曉征提供觀點(diǎn)，歡迎大家留言回復(fù)您的觀點(diǎn)，以上內(nèi)容純屬猜測(cè)，猜對(duì)了也別告訴我。

　　如何加入"云和恩墨大講堂"微信群

　　搜索 蓋國(guó)強(qiáng)(Eygle)微信號(hào)：eyygle，或者掃描下面二維碼，備注：云和恩墨大講堂，即可入群。每周與千人共享免費(fèi)技術(shù)分享，與講師在線討論。