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