作者簡介

蓋國強

中國地區首位Oracle ACE和ACE總監，中國地區最著名的Oracle技術推廣者之一，他的專著《深入解析Oracle》、《循序漸進Oracle》等書籍受到Oracle技術愛好者的廣泛好評。

2010年，與Oracle ACE總監張樂奕先生共同創立ACOUG(中國Oracle使用者組)，持續推動Oracle技術圈的地面活動和技術交流。

正文

最近暴雪公司和網易的一則宣告刷爆了朋友圈，大意就是由於『供電意外中斷的原因而產生故障，導致資料損壞』，這樣一則公告引發了一系列的猜想。

我們在圍觀時彷彿人人都是諸葛亮，而事實上設身處地的想，在一次複雜的故障考驗下，也許很少有人能夠倖免。

如同阿里雲會誤刪檔案、京東會洩露資料、支付寶會被修改密碼、攜程會大面積癱瘓，在災難來臨之前，誰都會覺得自己是幸運者，而事實上，只是因為令你措手不及的那個災難還沒有來到而已。

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

首先，關於暴雪的核心資料庫架構，不是網友猜測的MySQL（如果是 MySQL 就必然是分散式，不可能全部回檔的），而是Oracle資料庫。關鍵的系統架構如下（部分屬於推測）：

資料庫：Oracle

架構：RAC + ASM

版本：12.1.0.2 （猜測）

節點數：4 （猜測）

系統：Linux

同步：GoldenGate

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

以下是前一段時間暴雪招聘DBA Lead的條件要求，系統架構由此一目瞭然：要求深入理解Oracle內部原理、Oracle RAC和ASM技術，熟悉Golden Gate複製，熟悉Linux指令碼程式設計

這些要求就深刻揭示了暴雪核心資料庫的體系架構。在Linux上執行的基於ASM儲存的Oracle RAC叢集，使用OGG複製資料。

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

以下就是暴雪對於這個崗位的詳細需求：

之前在網際網路上已經披露了很多資訊，包括一次故障的處理流程（來自搜尋引擎）：

1.9C在一次伺服器故障中的說明，下面只列出關鍵部分

08:29 收到EVA儲存報警郵件，聯絡資料中心工程師，聯絡惠普工程師.

08:35 故障應急流程啟動,相關人員包括THE9/HP/Blizzard US .

15:33 Oracle專家加入故障應急流程

15:50 暴雪資料庫工程師開始與Oracle專家繼續分析故障情況.

17:15 暴雪表示暫時還未從他們的admin以及DBA處獲得任何有新的訊息，他們仍然在研究此故障。

當時的資料庫執行在HP伺服器上（大約2013年），現在已經遷移到Linux伺服器上。

此外，暴雪的資料量很大，多年前Oracle 9i 時就是TB級別的資料庫了，當然現在中國大陸地區肯定是獨立的伺服器，但是資料量也絕對會是TB級別的，再加上免費開放的熱門程度，我推測兩節點的RAC對中國玩家不夠尊重，至少應該是4節點的Oracle RAC叢集。

所以大家可能想到了2016年的另外一則故障，大約在2016年3月22日，全日航空的故障導致了120個航班取消，據傳是4節點RAC叢集，由於網路問題導致故障：

【導致全日空(ANA)120個航班被取消的票務系統故障是交換機引起的】造成Oracle Cache Fusion的UDP通訊異常，4節點的Oracle RAC無法重組叢集。本來交換機是有主備設計的，但是主交換機並未徹底壞掉，而是處於不穩定狀態，備用交換機不知道主交換機出了故障所以沒有接管。

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

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

• 1月14日 15：20 （據說）因為供電問題，導致資料庫損壞；
• DBA開始修復，但是發現備份資料庫也損壞了；
• 資料庫帶病堅持工作，DBA同時開始線上修復；
• 1月17日1點開始停機修復，修復預計8小時，未能按照預期時間完成；
• 1月18日18：00釋出公告，資料回檔到1月14日 15：20，業務恢復；

外行看熱鬧，內行看門道

在瞭解了系統架構之後，從官方的資訊裡我們能夠看到很多事實：

第一：故障出現在14日，應當早於15：20，公佈時間推移，這是慣例；

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

第三：資料庫損壞應該是壞塊，Oracle資料庫在出現損壞故障時，仍然能夠堅持工作的，應該是出現了壞塊，壞塊通常被大家疏忽，以為可解，所以拖延成了極慢長的次生故障；

第四：暴雪沒有ADG的災備，不可切換，請注意宣告中明確說“備份資料庫”而不是“備用資料庫”；

第五：資料庫依賴OGG進行復制，這個複製因為某種原因不能用於恢復，極可能因為Redo日誌或 Undo 也有損壞，丟失了某些事務；

第六：最終壞塊問題無法修復，只能選擇基於時間點的不完全恢復，放棄了部分事務，也就是資料回檔了，這是最無可奈何但是也是保證資料一致性的殘酷選擇；

第七：資料庫的壞塊，沒有影響資料庫執行，證明是小範圍的損壞，不是檔案級別的損失，這應當和儲存的相關性更大，寫丟失導致了資料塊損壞；

第八：最初的8小時，是計劃恢復部分表空間，但是沒有解決問題，最終進行了全庫恢復，根據這個停機時間預估資料庫整體容量應當在10TB左右；

所以我們大膽推測：是因為儲存故障導致了RAC叢集寫資料丟失，最終選擇不完全恢復，放棄了部分資料。

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

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

既然備份這麼重要，國內資料庫的備份情況如何呢？雲和恩墨白求恩平臺最近釋出的《中國2016年Oracle資料庫執行現狀報告》顯示，有完整RMAN備份的資料庫不到20%，24%的資料庫甚至處於非歸檔模式下。

下圖來自報告資料，可以看到其實國內的資料庫的DG的使用率其實並不高，僅有21%：

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

關鍵節點是什麼？

回顧一下，資料庫帶病堅持工作，這是整個案例最核心的一個決策，也就是說，通過線上執行，同時修復問題（壞塊），向前走。

這也是一個艱難的決策，如此可以減少業務的中斷，但是面臨的風險就是可能最終資料不一致，需要回退或者承受複雜的校驗工作。

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

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

我覺得得按照業務特性，事先約定優先保A（可用性）還是保C（一致性），如果沒約定的話，如果我指揮，我會臨機進行決斷。

我非常贊同這一觀點，有了事先約定，應急處置時才能有準則，不出現重大偏頗。

要一致性還是連續性？

如前所述，每一個DBA團隊都應該有一個準繩，那就是在關鍵時刻，要保障一致性（準確性）還是連續性？

對於金融機構，毫無疑問，要保證資料庫的一致性，在遇到故障時，可以果斷中斷業務提供，進行資料恢復或者修復；

而對於網際網路業務等，可能連續性就更為重要，類似攜程的業務，中斷幾天的服務是不可想象的；王曉徵就此總結說：

在運營商系統建設的過程中，最初覺得業務連續性最為重要，但是當這些問題已經被較好的解決之後，現在覺得資料的一致性變得更重要起來，所以不同系統在不同階段，就會有不同的取捨。

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

為何不切災備？

關於這樣嚴重的事故，為何不切災備？

如前所述，從備份資料庫的一字之別，我猜測這個系統根本就沒有災備，所以無從切換，畢竟這只是一款免費的遊戲，在官網首頁的顯示『《爐石傳說》官方網站_暴雪首款免費休閒卡牌網遊』。

對於災備的部署和切換，王曉徵表示浙江移動內部是這樣的：

按業務重要度，實現不同保障級別。

• 一般系統：只做資料備份，無高可用，無容災；
• 重要系統：資料備份，高可用，無容災；
• 核心系統：備份，高可用（部分含柔性可用），容災。

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

如果出現數據損壞，核心系統肯定切容災了，這種情況如果是硬體損壞或者刪除資料檔案引起的問題，基本就搞定了；當然，最怕的就是誤操作或程式碼bug搞出來的資料丟失，可能把容災端資料同時破壞，那就只能通過備份來恢復啦。

由此可以看出，即便有了完備的災備環境，也很難防範所有問題，尤其是人為的誤操作，所謂『功夫再高，也怕菜刀』，一個誤刪除可能就級聯到所有的系統，再加上軟體BUG不可避免，除了災備，必然還要有可靠的備份來託底。

運維團隊怎麼配置？

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

如何倖存於類似事故？

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

首先，要有完善、有效的備份和容災機制。誠然很多企業都有了一整套的備份、容災機制，但是這套備份機制能否真實奏效是需要檢驗的。我接觸過某大型企業，投入巨資興建的災備中心，從未正式切換過，這樣的災備在故障來臨時也很難有人拍板去進行切換，所以備份的有效、容災手段的有效是必須確保的。

注意：備份的恢復速度必須足夠的考慮到，磁帶的低效備份關鍵時刻會害死人。

其次，要有完善的故障處理策略和流程。對於不同系統，在關鍵時刻要優先確保什麼，是要訂立規則的，有了規則才能照章辦事，不走錯方向，不無辜背鍋。幾年前某國內金融系統出現數據壞塊，同樣選擇了帶病修復，最終沒能解決問題，同樣選擇了回檔承擔了資料損失。

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

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

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

感謝王曉徵提供觀點，歡迎大家留言回覆您的觀點，以上內容純屬猜測！！