最近暴雪公司和網(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ù)分享,與講師在線討論。
- QQ:61149512