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