攜程今日上演了“天地大沖撞”的災難劇情。來自攜程官方的最新消息是：“攜程app已經恢復，官網產品正在逐步恢復中。”
今天（5月28日）上午11點左右，攜程旅行網官方網站突然陷入癱瘓，登陸顯示404錯誤。
稍后，攜程官微發消息稱“今天上午11時09分，攜程的部分服務器遭到不明攻擊，導致官方網站及APP暫時無法正常使用，目前正在緊急恢復。”
根據筆者獲得的信息：攜程系統昨日便已出現問題，技術部門未能及時解決，今清晨5時許，客戶訂票無法正常出票。在中午到來前，內網、外網 、App陸續癱瘓。
微博用戶 @尜尜DJ ，實際身份為華住酒店集團的產品經理在微博上發布了“還原攜程網宕掉事情原委”的信息：
烏云網發布了攜程服務器的一個漏洞，估計攜程技術人員就開始各種修復。然后在中午部署上線的時候，某技術人員由于人為操作失誤不知道刪了一個什么根目錄文件于是乎導致靈異事件發生，線上數據全部被刪，再次發布依舊被刪。。。。現在我好想知道這個技術人員是誰啊～會火
雖然該用戶稱此微博僅為小道消息和腦補，但是她聯系過攜程上班的朋友，對方表示線上發布一直有問題，一發布就被刪。
這一消息中，“靈異事件”說明其信息不夠充分，“發布依舊被刪”則與筆者從各渠道獲得的信息近似。
其實自今年1月起，烏云平臺就已經曝光了超過十次攜程的漏洞，包括撞庫、官方郵件劫持、內部員工郵箱歷史信息泄露、信息泄露，但攜程的回應大多是“無影響廠商忽略”。
烏云網官微對上述微博的回復，基本匯總了下午輿論場中對該事件的推測與傳言：
“攜程業務故障引發了各版本的‘真相’在互聯網瘋傳，什么物理刪庫、離職員工報復、管理員感情糾葛甚至連烏云君也被拉下水了……從11點到目前仍未解決問題也說明這是其自身甚至國內互聯網都沒遭遇過的重大事故。”
與最先傳聞數據庫被物理刪除的消息不同，根據筆者接觸到的匿名信源透露：數據庫并未丟失。問題可能發生在代碼上，所有節點上業務代碼均被刪除，并且發布日志消失，備份也被清除。
機制和災難應對反思
根據筆者的從業經驗來看，大型互聯網公司保護數據安全的機制健全，技術也非常成熟。此次攜程問題嚴重，需要從整個機制和災難應對過程中反思：
1、企業為了信息安全，數據庫均會異地備份
首先采用動態備份記錄最新形態，還要做靜態的異地備份。出錯時可以進行恢復，另外還要做至少2個“死備份”，防止備份丟失、損壞或者被篡改。關鍵數據一般都會進行同城和異地的實時備份，可以保證業務實時切換。一般公司還會制定災難恢復計劃并定期進行測試，確保各個恢復程序。
此次攜程恢復時間之長，就說明問題不只出現在數據庫方面。攜程技術部門的初始工作是在每個節點重新部署業務代碼，結果發現無法部署，推斷原因可能是服務器被攻擊，導致發布通道關閉，甚至會有人員層面的嚴重問題。
2、對員工的安全審查：
為了信息安全，員工在入職時進行背景調查，在離職時第一時間關閉權限賬戶。數據庫權限對大公司來說會有負責權限級別管理，分為管理員、大管理員、超級管理員，會設置層級限制。涉及到刪除操作，會有操作日志，記錄是哪個賬戶執行的。而重要數據的刪除會有嚴格的審核制度。
由于較長的一段時間內無法部署代碼，從業者普遍推測：可能是掌握root權限的（現在或者以前的）運維人員寫了刪除腳本。有未經證實的傳聞說，攜程的內部檢查中發現已離職的具有7級權限的開發總監留下了后門。
3、數據存儲采用加密而非明文。
加密的方式主要是MD5，加密之后就算黑客侵犯隱私信息也沒什么用，因為只能得到亂碼。
雖然上次攜程的隱私信息泄漏的安全事故中，人們發現攜程使用明文儲存。但這一次攜程遭遇完全刪除，則顯然是完全惡意的。
4、web程序和DB服務器分開，服務器群組有防火墻隔離，界面和數據庫相互隔離
此次攜程的安全問題已超過這個范疇。
至于知乎上的這個問答，只能當作段子來消遣一下：
宕機會損失多少？
先看組歷史上互聯網公司發生過的宕機，導致損失的數據：
5分鐘，谷歌，損失55萬美元
30分鐘，亞馬遜，損失近200萬美元
9小時，網易，損失估算超1500萬元
近12小時，蘋果，損失2640萬美元
按照攜程一季度財報公布的數據，攜程宕機的損失為平均每小時106.48萬美元，損失的用戶數和品牌形象......就難以用貨幣單位來統計了。
京公網安備 11010502049343號