《蓋國強：《爐石傳說》大故障，不要以為你也可以幸免》要點：
本文介紹了蓋國強：《爐石傳說》大故障，不要以為你也可以幸免，希望對您有用。如果有疑問，可以聯系我們。

作者簡介

蓋國強

中國地區首位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卡牌包等值的補償”,越來越覺得,這次“營銷”是很成功的.

感謝王曉征提供觀點,歡迎大家留言回復您的觀點,以上內容純屬猜測!!

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4371.html