深刻解析和反思攜程宕機事件

本文做者智錦，資深運維從業者，自動化運維和雲計算倡導者，曾做爲支付寶運維團隊創始人，管理過上萬臺服務器，後做爲建行特聘互聯網技術專家，主導了建設銀行總行數據中心私有云計算平臺建設。智錦目前是杭州雲霽科技有限公司創始人，作運維領域的創業，致力於開發全中國最好的數據中心操做系統。

······················································································

攜程網宕機事件還在持續，截止28號晚上8點，攜程首頁仍是指向一個靜態頁面，全部動態網頁都訪問不了。關於事故根源，網上衆說紛紜。做爲互聯網運維老兵，嘗試分析緣由，談談個人見解

1、 宕機緣由分析

網上有各類說法，有說是數據庫數據和備份數據被物理刪除的。也有說是各個節點的業務代碼被刪除 如今從新在部署。也有說是誤操做，致使業務不可用，還有說是黑客攻擊甚至是內部員工惡意破壞的。

先說一下最先傳出來的「數據庫物理刪除」，其實這個提法就很不專業，應該是第一個傳播者，試圖強調問題之嚴重和恢復之困難，因此用了一個普通電腦用戶比較熟悉的「物理刪除」的概念。實際上，任何一個網站的數據庫，都分爲本地高可用備份、異地熱備、磁帶冷備三道防線，相應的數據庫管理員、操做系統管理員、存儲管理員三者的權限是分離的，磁帶備份的數據甚至是保存在銀行的地下金庫中的。從理論上而言，很難有一我的能把全部的備份數據都刪除，更不用說這個繪聲繪色的物理刪除了。

第二個則是黑客攻擊和內部員工破壞的說法，這個說法能知足一些圍觀者獵奇的心理，所以也傳播的比較快。但理性分析，可能性也不大。黑客講究的是潛伏和隱蔽，作這種事等因而在作自殺性攻擊。而內部員工也不太可能，我仍是相信攜程的運維人員的操守和職業素養，在刑法的威懾下，除非像「法航飛行員撞山」那種極個別案列，正常狀況下不太可能出現人爲惡意的可能性。

從現象上看，確實是攜程的應用程序和數據庫都被刪除。我分析，最大的可能仍是運維人員在正常的批量操做時出現了誤操做。我猜想的版本是：攜程網被「烏雲」曝光了一個安全漏洞，漏洞涉及到了大部分應用服務器和數據庫服務器；運維人員在使用pssh這樣的批量操做執行修復漏洞的腳本時，無心中寫錯了刪除命令的對象，發生了無差異的全局刪除，全部的應用服務器和數據庫服務器都受到了影響。

這個段子在運維圈子中做爲笑話流傳了不少年，沒想到竟然真的有這樣一天。

二 、爲何恢復的如此緩慢？

從上午11點傳出故障，到晚上8點，攜程網站一直沒能恢復。因此不少朋友很疑惑：「爲何網站恢復的如此緩慢？是否是數據庫沒有備份了？」這也是那個「數據庫物理刪除」的說法很流行的一個根源。實際上這個仍是普通用戶，把網站的備份和恢復理解成了相似咱們的筆記本的系統備份和恢復的場景，認爲只有有備份在，很快就能導入和恢復應用。

實際上大型網站，遠不是像把幾臺應用和數據庫服務器那麼簡單。看似好久都沒有變化的一個網站，後臺是一個由SOA（面向服務）架構組成的龐大服務器集羣，看似簡單的一個頁面背後由成百上千個應用子系統組成，每一個子系統又包括若干臺應用和數據庫服務器，你們能夠理解爲每個從首頁跳轉過去的二級域名都是一個獨立的應用子系統。這上千的個應用子系統，平時真正常常發佈和變動的，可能就是不到20%的核心子系統，並且發佈時都是作加法，不多徹底從新部署一個應用。

在平時的運維過程當中，對於常見的故障都會有應急預案。但像攜程此次全部系統包括數據庫都須要從新部署的極端狀況，顯然不可能在應急預案的範疇中。在倉促上陣應急的狀況下，技術方案的評估和選擇問題，不一樣技術崗位之間的管理協調的問題，不一樣應用系統之間的耦合和依賴關係，還有不少平時欠下的技術債都集中爆發了，更不用說不少不經常使用的子系統，可能上線以後就沒人動過，一時半會都找不到能處理的人。更要命的是，網站的核心繫統，可能會寫死依賴了這個平時根本沒人關注的應用，想繞開邊緣應用只恢復核心業務都作到。更別說在這樣的高壓之下，各類噪音和干擾不少，運維工程師的反應也沒有平時靈敏。

簡單的說，就算全部代碼和數據庫的備份都存在，想要快速恢復業務，甚至比從0開始從新搭建一個攜程更困難。攜程的工程師今天確定是一個不眠夜。樂觀的估計，要是能在24小時以內恢復核心業務，就已經很是厲害了。

天下運維是一家。攜程的同行加油，儘快度過難關！

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

攜程的此次事件，無論緣由是什麼，都會成爲IT運維歷史上的一個標誌性事件。相信以後全部的IT企業和技術人員，都會去認真的反思，總結經驗教訓。但我相信，不一樣的人在不一樣的位置上，看到的東西多是截然相反的，甚至可能會有很多企業的管理者受到誤導，開始制定更嚴格的規章制度，嚴犯運維人員再犯事。在此，我想代表一下個人態度：這是一個由運維引起的問題，但真正的根源其實不只僅在運維，預防和治理更應該從整個企業的治理入手。

長久以來，在全部的企業中，運維部門的地位都是很邊緣化的。企業的管理者會以爲運維部門是成本部門，只要能支撐業務就行。業務部門只負責提業務需求，開發部門只管作功能的開發，不少非功能性的問題無人重視，只能靠運維人員肩挑人扛處處救火，能夠認爲是運維部門靠本身的血肉之軀實現了業務部門的信息化。在這樣的場景下，不光企業的管理者不知道該如何評價運維的價值，甚至不少運維從業者都不知道本身除了處處救火外真正應該關注什麼，固然也沒有時間和精力去思考。

在上文的狀況下，傳統的運維人員其實是所謂的「黑盒運維」，不斷的去作重複性的操做，時間長了以後，只知道本身管理的服務器能正常對外服務，可是殊不知道里面應用的依賴關係，哪些配置是有效配置、哪些是無效配置，只敢加配置，不敢刪配置，欠的技術債愈來愈多。在這樣的狀況下，遇到此次攜程的極端案列，須要完整的重建系統時候，就很容易束手無策了。

對於這樣的故障，我認爲真正有效的根源解決作法是從黑盒運維走向白盒運維。和puppet這樣的運維工具理念一致，運維的核心和難點實際上是配置管理，運維人員只有真正的清楚所管理的系統的功能和配置，才能從根源上解決處處救火疲於奔命的狀況，也才能真正的杜絕今天攜程這樣的事件重現，從根本上解決運維的問題。

從黑盒運維走向白盒運維，再進一步實現devops（開發運維銜接）和軟件定義數據中心，就是所謂的運維2.0了。很顯然，這個單靠運維部門自身是作不到的，須要每個企業的管理者、業務部門、開發部門去思考。所以，我但願今天這個事件，不要簡單的讓運維來背黑鍋，而是讓你們真正的從中獲得教訓和啓示。

 

轉自：http://mp.weixin.qq.com/s?__biz=MzA4MDYwMDQ5Mg==&mid=207052274&idx=1&sn=db02845f87053c0c5402e610a0f3b1e7