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

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

　　先回顧一下《爐石傳說》長長的公告，然后我們再基于事實做一下分析吧：

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

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

　　架構(gòu)：RAC + ASM

　　版本：12.1.0.2 (猜測)

　　節(jié)點數(shù)：4 (猜測)

　　系統(tǒng)：Linux

　　同步：GoldenGate

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　我們再回過頭來看暴雪的運維，最終看起來似乎沒有找到合適的DBA Leader，所以內(nèi)部晉升了一位，在LinkedIn上，這些信息是公開的：

　　好了，有了這些事實之后，我們再看公告就會清晰很多了。我們理一下時間軸：

　　1月14日 15：20 (據(jù)說)因為供電問題，導(dǎo)致數(shù)據(jù)庫損壞;

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

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

　　1月17日1點開始停機修復(fù)，修復(fù)預(yù)計8小時，未能按照預(yù)期時間完成;

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

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

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

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

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

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

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

　　第五：數(shù)據(jù)庫依賴OGG進行復(fù)制，這個復(fù)制因為某種原因不能用于恢復(fù)，極可能因為Redo日志或 Undo 也有損壞，丟失了某些事務(wù);

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

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

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

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

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

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

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

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

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

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

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

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

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

　　我就此訪問了浙江移動王曉征王總，他表達了他的觀點：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　運維團隊怎么配置？

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

　　如何幸存于類似事故？

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

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

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

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

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

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

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

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

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