攜程網(wǎng)宕機事件還在持續，截止28號晚上8點(diǎn)，攜程首頁(yè)還是指向一個(gè)靜態(tài)頁(yè)面，所有動(dòng)態(tài)網(wǎng)頁(yè)都訪(fǎng)問(wèn)不了。關(guān)于事故根源，網(wǎng)上眾說(shuō)紛紜。作為互聯(lián)網(wǎng)運維老兵，嘗試分析原因，談?wù)勎业目捶ā?/p>
宕機原因分析網(wǎng)上有各種說(shuō)法，有說(shuō)是數據庫數據和備份數據被物理刪除的。也有說(shuō)是各個(gè)節點(diǎn)的業(yè)務(wù)代碼被刪除，現在重新在部署。也有說(shuō)是誤操作，導致業(yè)務(wù)不可用，還有說(shuō)是黑客攻擊甚至是內部員工惡意破壞的。
先說(shuō)一下最早傳出來(lái)的“數據庫物理刪除”，其實(shí)這個(gè)提法就很不專(zhuān)業(yè)，應該是第一個(gè)傳播者，試圖強調問(wèn)題之嚴重和恢復之困難，所以用了一個(gè)普通電腦用戶(hù)比較熟悉的“物理刪除”的概念。實(shí)際上，任何一個(gè)網(wǎng)站的數據庫，都分為本地高可用備份、異地熱備、磁帶冷備三道防線(xiàn)，相應的數據庫管理員、操作系統管理員、存儲管理員三者的權限是分離的，磁帶備份的數據甚至是保存在銀行的地下金庫中的。從理論上而言，很難有一個(gè)人能把所有的備份數據都刪除，更不用說(shuō)這個(gè)繪聲繪色的物理刪除了。
第二個(gè)則是黑客攻擊和內部員工破壞的說(shuō)法，這個(gè)說(shuō)法能滿(mǎn)足一些圍觀(guān)者獵奇的心理，因此也傳播的比較快。但理性分析，可能性也不大。黑客講究的是潛伏和隱蔽，做這種事等于是在做自殺性攻擊。而內部員工也不太可能，我還是相信攜程的運維人員的操守和職業(yè)素養，在刑法的威懾下，除非像“法航飛行員撞山”那種極個(gè)別案列，正常情況下不太可能出現人為惡意的可能性。
從現象上看，確實(shí)是攜程的應用程序和數據庫都被刪除。我分析，最大的可能還是運維人員在正常的批量操作時(shí)出現了誤操作。我猜測的版本是：攜程網(wǎng)被“烏云”曝光了一個(gè)安全漏洞，漏洞涉及到了大部分應用服務(wù)器和數據庫服務(wù)器；運維人員在使用pssh這樣的批量操作執行修復漏洞的腳本時(shí)，無(wú)意中寫(xiě)錯了刪除命令的對象，發(fā)生了無(wú)差別的全局刪除，所有的應用服務(wù)器和數據庫服務(wù)器都受到了影響。這個(gè)段子在運維圈子中作為笑話(huà)流傳了很多年，沒(méi)想到居然真的有這樣一天。
為什么恢復的如此緩慢？從上午11點(diǎn)傳出故障，到晚上8點(diǎn)，攜程網(wǎng)站一直沒(méi)能恢復。所以很多朋友很疑惑：“為什么網(wǎng)站恢復的如此緩慢？是不是數據庫沒(méi)有備份了？”這也是那個(gè)“數據庫物理刪除”的說(shuō)法很流行的一個(gè)根源。實(shí)際上這個(gè)還是普通用戶(hù)，把網(wǎng)站的備份和恢復理解成了類(lèi)似我們的筆記本的系統備份和恢復的場(chǎng)景，認為只有有備份在，很快就能導入和恢復應用。
實(shí)際上大型網(wǎng)站，遠不是像把幾臺應用和數據庫服務(wù)器那么簡(jiǎn)單。看似很久都沒(méi)有變化的一個(gè)網(wǎng)站，后臺是一個(gè)由SOA（面向服務(wù)）架構組成的龐大服務(wù)器集群，看似簡(jiǎn)單的一個(gè)頁(yè)面背后由成百上千個(gè)應用子系統組成，每個(gè)子系統又包括若干臺應用和數據庫服務(wù)器，大家可以理解為每一個(gè)從首頁(yè)跳轉過(guò)去的二級域名都是一個(gè)獨立的應用子系統。這上千的個(gè)應用子系統，平時(shí)真正經(jīng)常發(fā)布和變更的，可能就是不到20%的核心子系統，而且發(fā)布時(shí)都是做加法，很少完全重新部署一個(gè)應用。
在平時(shí)的運維過(guò)程中，對于常見(jiàn)的故障都會(huì )有應急預案。但像攜程這次所有系統包括數據庫都需要重新部署的極端情況，顯然不可能在應急預案的范疇中。在倉促上陣應急的情況下，技術(shù)方案的評估和選擇問(wèn)題，不同技術(shù)崗位之間的管理協(xié)調的問(wèn)題，不同應用系統之間的耦合和依賴(lài)關(guān)系，還有很多平時(shí)欠下的技術(shù)債都集中爆發(fā)了，更不用說(shuō)很多不常用的子系統，可能上線(xiàn)之后就沒(méi)人動(dòng)過(guò)，一時(shí)半會(huì )都找不到能處理的人。更要命的是，網(wǎng)站的核心系統，可能會(huì )寫(xiě)死依賴(lài)了這個(gè)平時(shí)根本沒(méi)人關(guān)注的應用，想繞開(kāi)邊緣應用只恢復核心業(yè)務(wù)都做不到。更別說(shuō)在這樣的高壓之下，各種噪音和干擾很多，運維工程師的反應也沒(méi)有平時(shí)靈敏。
簡(jiǎn)單的說(shuō)，就算所有代碼和數據庫的備份都存在，想要快速恢復業(yè)務(wù)，甚至比從0開(kāi)始重新搭建一個(gè)攜程更困難。攜程的工程師今天肯定是一個(gè)不眠夜。樂(lè )觀(guān)的估計，要是能在24小時(shí)之內恢復核心業(yè)務(wù)，就已經(jīng)非常厲害了。
天下運維是一家。攜程的同行加油，盡快度過(guò)難關(guān)！
故障根源反思：黑盒運維之殤攜程的這次事件，不管原因是什么，都會(huì )成為IT運維歷史上的一個(gè)標志性事件。相信之后所有的IT企業(yè)和技術(shù)人員，都會(huì )去認真的反思，總結經(jīng)驗教訓。但我相信，不同的人在不同的位置上，看到的東西可能是截然相反的，甚至可能會(huì )有不少企業(yè)的管理者受到誤導，開(kāi)始制定更嚴格的規章制度，嚴犯運維人員再犯事。在此，我想表明一下我的態(tài)度：這是一個(gè)由運維引發(fā)的問(wèn)題，但真正的根源其實(shí)不僅僅在運維，預防和治理更應該從整個(gè)企業(yè)的治理入手。
長(cháng)久以來(lái)，在所有的企業(yè)中，運維部門(mén)的地位都是很邊緣化的。企業(yè)的管理者會(huì )覺(jué)得運維部門(mén)是成本部門(mén)，只要能支撐業(yè)務(wù)就行。業(yè)務(wù)部門(mén)只負責提業(yè)務(wù)需求，開(kāi)發(fā)部門(mén)只管做功能的開(kāi)發(fā)，很多非功能性的問(wèn)題無(wú)人重視，只能靠運維人員肩挑人扛到處救火，可以認為是運維部門(mén)靠自己的血肉之軀實(shí)現了業(yè)務(wù)部門(mén)的信息化。在這樣的場(chǎng)景下，不光企業(yè)的管理者不知道該如何評價(jià)運維的價(jià)值，甚至很多運維從業(yè)者都不知道自己除了到處救火外真正應該關(guān)注什么，當然也沒(méi)有時(shí)間和精力去思考。
在上文的情況下，傳統的運維人員實(shí)際上是所謂的“黑盒運維”，不斷的去做重復性的操作，時(shí)間長(cháng)了之后，只知道自己管理的服務(wù)器能正常對外服務(wù)，但是卻不知道里面應用的依賴(lài)關(guān)系，哪些配置是有效配置、哪些是無(wú)效配置，只敢加配置，不敢刪配置，欠的技術(shù)債越來(lái)越多。在這樣的情況下，遇到這次攜程的極端案列，需要完整的重建系統時(shí)候，就很容易一籌莫展了。
對于這樣的故障，我認為真正有效的根源解決做法是從黑盒運維走向白盒運維。和Puppet這樣的運維工具理念一致，運維的核心和難點(diǎn)其實(shí)是配置管理，運維人員只有真正的清楚所管理的系統的功能和配置，才能從根源上解決到處救火疲于奔命的情況，也才能真正的杜絕今天攜程這樣的事件重現，從根本上解決運維的問(wèn)題。
從黑盒運維走向白盒運維，再進(jìn)一步實(shí)現DevOps（開(kāi)發(fā)運維銜接）和軟件定義數據中心，就是所謂的運維2.0了。很顯然，這個(gè)單靠運維部門(mén)自身是做不到的，需要每一個(gè)企業(yè)的管理者、業(yè)務(wù)部門(mén)、開(kāi)發(fā)部門(mén)去思考。因此，我希望今天這個(gè)事件，不要簡(jiǎn)單的讓運維來(lái)背黑鍋，而是讓大家真正的從中得到教訓和啟示。
