一 宕機原因分析

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

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

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

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

　　這個段子在運維圈子中作為笑話流傳了很多年，沒想到居然真的有這樣一天。

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

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

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

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

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

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

三 故障根源反思：黑盒運維之殤。

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

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

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

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

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

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