一 宕機(jī)原因分析

　　網(wǎng)上有各種說(shuō)法，有說(shuō)是數(shù)據(jù)庫(kù)數(shù)據(jù)和備份數(shù)據(jù)被物理刪除的。也有說(shuō)是各個(gè)節(jié)點(diǎn)的業(yè)務(wù)代碼被刪除 現(xiàn)在重新在部署。也有說(shuō)是誤操作，導(dǎo)致業(yè)務(wù)不可用，還有說(shuō)是黑客攻擊甚至是內(nèi)部員工惡意破壞的。

　　先說(shuō)一下最早傳出來(lái)的“數(shù)據(jù)庫(kù)物理刪除”，其實(shí)這個(gè)提法就很不專業(yè)，應(yīng)該是第一個(gè)傳播者，試圖強(qiáng)調(diào)問(wèn)題之嚴(yán)重和恢復(fù)之困難，所以用了一個(gè)普通電腦用戶比較熟悉的“物理刪除”的概念。實(shí)際上，任何一個(gè)網(wǎng)站的數(shù)據(jù)庫(kù)，都分為本地高可用備份、異地?zé)醾洹⒋艓Ю鋫淙婪谰€，相應(yīng)的數(shù)據(jù)庫(kù)管理員、操作系統(tǒng)管理員、存儲(chǔ)管理員三者的權(quán)限是分離的，磁帶備份的數(shù)據(jù)甚至是保存在銀行的地下金庫(kù)中的。從理論上而言，很難有一個(gè)人能把所有的備份數(shù)據(jù)都刪除，更不用說(shuō)這個(gè)繪聲繪色的物理刪除了。

　　第二個(gè)則是黑客攻擊和內(nèi)部員工破壞的說(shuō)法，這個(gè)說(shuō)法能滿足一些圍觀者獵奇的心理，因此也傳播的比較快。但理性分析，可能性也不大。黑客講究的是潛伏和隱蔽，做這種事等于是在做自殺性攻擊。而內(nèi)部員工也不太可能，我還是相信攜程的運(yùn)維人員的操守和職業(yè)素養(yǎng)，在刑法的威懾下，除非像“法航飛行員撞山”那種極個(gè)別案列，正常情況下不太可能出現(xiàn)人為惡意的可能性。

　　從現(xiàn)象上看，確實(shí)是攜程的應(yīng)用程序和數(shù)據(jù)庫(kù)都被刪除。我分析，最大的可能還是運(yùn)維人員在正常的批量操作時(shí)出現(xiàn)了誤操作。我猜測(cè)的版本是：攜程網(wǎng)被“烏云”曝光了一個(gè)安全漏洞，漏洞涉及到了大部分應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器；運(yùn)維人員在使用pssh這樣的批量操作執(zhí)行修復(fù)漏洞的腳本時(shí)，無(wú)意中寫錯(cuò)了刪除命令的對(duì)象，發(fā)生了無(wú)差別的全局刪除，所有的應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器都受到了影響。

　　這個(gè)段子在運(yùn)維圈子中作為笑話流傳了很多年，沒(méi)想到居然真的有這樣一天。

二 為什么恢復(fù)的如此緩慢？

　　從上午11點(diǎn)傳出故障，到晚上8點(diǎn)，攜程網(wǎng)站一直沒(méi)能恢復(fù)。所以很多朋友很疑惑：“為什么網(wǎng)站恢復(fù)的如此緩慢？是不是數(shù)據(jù)庫(kù)沒(méi)有備份了？”這也是那個(gè)“數(shù)據(jù)庫(kù)物理刪除”的說(shuō)法很流行的一個(gè)根源。實(shí)際上這個(gè)還是普通用戶，把網(wǎng)站的備份和恢復(fù)理解成了類似我們的筆記本的系統(tǒng)備份和恢復(fù)的場(chǎng)景，認(rèn)為只有有備份在，很快就能導(dǎo)入和恢復(fù)應(yīng)用。

　　實(shí)際上大型網(wǎng)站，遠(yuǎn)不是像把幾臺(tái)應(yīng)用和數(shù)據(jù)庫(kù)服務(wù)器那么簡(jiǎn)單。看似很久都沒(méi)有變化的一個(gè)網(wǎng)站，后臺(tái)是一個(gè)由SOA（面向服務(wù)）架構(gòu)組成的龐大服務(wù)器集群，看似簡(jiǎn)單的一個(gè)頁(yè)面背后由成百上千個(gè)應(yīng)用子系統(tǒng)組成，每個(gè)子系統(tǒng)又包括若干臺(tái)應(yīng)用和數(shù)據(jù)庫(kù)服務(wù)器，大家可以理解為每一個(gè)從首頁(yè)跳轉(zhuǎn)過(guò)去的二級(jí)域名都是一個(gè)獨(dú)立的應(yīng)用子系統(tǒng)。這上千的個(gè)應(yīng)用子系統(tǒng)，平時(shí)真正經(jīng)常發(fā)布和變更的，可能就是不到20%的核心子系統(tǒng)，而且發(fā)布時(shí)都是做加法，很少完全重新部署一個(gè)應(yīng)用。

　　在平時(shí)的運(yùn)維過(guò)程中，對(duì)于常見(jiàn)的故障都會(huì)有應(yīng)急預(yù)案。但像攜程這次所有系統(tǒng)包括數(shù)據(jù)庫(kù)都需要重新部署的極端情況，顯然不可能在應(yīng)急預(yù)案的范疇中。在倉(cāng)促上陣應(yīng)急的情況下，技術(shù)方案的評(píng)估和選擇問(wèn)題，不同技術(shù)崗位之間的管理協(xié)調(diào)的問(wèn)題，不同應(yīng)用系統(tǒng)之間的耦合和依賴關(guān)系，還有很多平時(shí)欠下的技術(shù)債都集中爆發(fā)了，更不用說(shuō)很多不常用的子系統(tǒng)，可能上線之后就沒(méi)人動(dòng)過(guò)，一時(shí)半會(huì)都找不到能處理的人。更要命的是，網(wǎng)站的核心系統(tǒng)，可能會(huì)寫死依賴了這個(gè)平時(shí)根本沒(méi)人關(guān)注的應(yīng)用，想繞開(kāi)邊緣應(yīng)用只恢復(fù)核心業(yè)務(wù)都做到。更別說(shuō)在這樣的高壓之下，各種噪音和干擾很多，運(yùn)維工程師的反應(yīng)也沒(méi)有平時(shí)靈敏。

　　簡(jiǎn)單的說(shuō)，就算所有代碼和數(shù)據(jù)庫(kù)的備份都存在，想要快速恢復(fù)業(yè)務(wù)，甚至比從0開(kāi)始重新搭建一個(gè)攜程更困難。攜程的工程師今天肯定是一個(gè)不眠夜。樂(lè)觀的估計(jì)，要是能在24小時(shí)之內(nèi)恢復(fù)核心業(yè)務(wù)，就已經(jīng)非常厲害了。

　　天下運(yùn)維是一家。攜程的同行加油，盡快度過(guò)難關(guān)！

三 故障根源反思：黑盒運(yùn)維之殤。

　　攜程的這次事件，不管原因是什么，都會(huì)成為IT運(yùn)維歷史上的一個(gè)標(biāo)志性事件。相信之后所有的IT企業(yè)和技術(shù)人員，都會(huì)去認(rèn)真的反思，總結(jié)經(jīng)驗(yàn)教訓(xùn)。但我相信，不同的人在不同的位置上，看到的東西可能是截然相反的，甚至可能會(huì)有不少企業(yè)的管理者受到誤導(dǎo)，開(kāi)始制定更嚴(yán)格的規(guī)章制度，嚴(yán)犯運(yùn)維人員再犯事。在此，我想表明一下我的態(tài)度：這是一個(gè)由運(yùn)維引發(fā)的問(wèn)題，但真正的根源其實(shí)不僅僅在運(yùn)維，預(yù)防和治理更應(yīng)該從整個(gè)企業(yè)的治理入手。

　　長(zhǎng)久以來(lái)，在所有的企業(yè)中，運(yùn)維部門的地位都是很邊緣化的。企業(yè)的管理者會(huì)覺(jué)得運(yùn)維部門是成本部門，只要能支撐業(yè)務(wù)就行。業(yè)務(wù)部門只負(fù)責(zé)提業(yè)務(wù)需求，開(kāi)發(fā)部門只管做功能的開(kāi)發(fā)，很多非功能性的問(wèn)題無(wú)人重視，只能靠運(yùn)維人員肩挑人扛到處救火，可以認(rèn)為是運(yùn)維部門靠自己的血肉之軀實(shí)現(xiàn)了業(yè)務(wù)部門的信息化。在這樣的場(chǎng)景下，不光企業(yè)的管理者不知道該如何評(píng)價(jià)運(yùn)維的價(jià)值，甚至很多運(yùn)維從業(yè)者都不知道自己除了到處救火外真正應(yīng)該關(guān)注什么，當(dāng)然也沒(méi)有時(shí)間和精力去思考。

　　在上文的情況下，傳統(tǒng)的運(yùn)維人員實(shí)際上是所謂的“黑盒運(yùn)維”，不斷的去做重復(fù)性的操作，時(shí)間長(zhǎng)了之后，只知道自己管理的服務(wù)器能正常對(duì)外服務(wù)，但是卻不知道里面應(yīng)用的依賴關(guān)系，哪些配置是有效配置、哪些是無(wú)效配置，只敢加配置，不敢刪配置，欠的技術(shù)債越來(lái)越多。在這樣的情況下，遇到這次攜程的極端案列，需要完整的重建系統(tǒng)時(shí)候，就很容易一籌莫展了。

　　對(duì)于這樣的故障，我認(rèn)為真正有效的根源解決做法是從黑盒運(yùn)維走向白盒運(yùn)維。和puppet這樣的運(yùn)維工具理念一致，運(yùn)維的核心和難點(diǎn)其實(shí)是配置管理，運(yùn)維人員只有真正的清楚所管理的系統(tǒng)的功能和配置，才能從根源上解決到處救火疲于奔命的情況，也才能真正的杜絕今天攜程這樣的事件重現(xiàn)，從根本上解決運(yùn)維的問(wèn)題。

　　從黑盒運(yùn)維走向白盒運(yùn)維，再進(jìn)一步實(shí)現(xiàn)devops（開(kāi)發(fā)運(yùn)維銜接）和軟件定義數(shù)據(jù)中心，就是所謂的運(yùn)維2.0了。很顯然，這個(gè)單靠運(yùn)維部門自身是做不到的，需要每一個(gè)企業(yè)的管理者、業(yè)務(wù)部門、開(kāi)發(fā)部門去思考。因此，我希望今天這個(gè)事件，不要簡(jiǎn)單的讓運(yùn)維來(lái)背黑鍋，而是讓大家真正的從中得到教訓(xùn)和啟示。

　　本文為那些默默無(wú)聞的運(yùn)維兄弟而轉(zhuǎn)