攜程可能攤上大事了——崩潰原因分析之「高能技術貼」

攜程數據庫事件網上有各種說法。有說是數據庫數據和備份數據被物理刪除的。也有說是各個節點的業務代碼被刪除現在重新在部署。也有說是誤操作，導致業務不可用。儘管眾說紛芸，做為一個技術人員，我們還是需要透過現象看本質。

網站崩潰的表像

我們先觀察一下ctrip這次問題的表現。從我觀察視角來看，在下午2點左右，攜程PC版的首頁上的酒店、機票這兩個最核心的應用還是無法使用的，而且個人用戶也是無法登錄的，同時攜程手機端的酒店、機票無法使用，以及個人訂單是無法查詢的。

而網上的新聞報道上午11點服務就不可用了：攜程方面稱，今天上午11時09分，攜程的部分服務器遭到不明攻擊，導致官方網站及APP暫時無法正常使用，目前正在緊急恢復。從攜程內部人士處獲悉，此次不明攻擊是攜程未攔截成功的第一次數據庫攻擊，目前技術部正在搶救。

數據庫整體被攻擊的可能性極大

從這些資訊來判斷，應該不是業務流程上線中出BUG，或者上線流程過程有些誤操作。為什麼這麼講，我們要進行粗略分析。對於用戶的角度來講，好像攜程的首頁是只有一個，好像攜程只有首頁這麼一個，各個業務的入口是統一的，但是從程式以及項目管理的角度來看，單單隻是從攜程的首頁來看，至少有14以上個業務部門以及項目，而且這些項目之間關聯耦合度不大，平時上線肯定也是獨立上線的，如果一個項目掛了，短暫不可用又很快恢復了，那還可以理解，畢竟誰上線沒有回滾過。但是大面積絕大部分業務都不可用，必然不是正常的上線流程中出問題。基本上我們可以判斷，攜程內部系統肯定是受到大規模的攻擊，大部分的業務節點受到嚴重的攻擊或者數據庫受到嚴重的攻擊，至於是內部員工或者是駭客那就不好說了。

我們再來分析下是不是業務節點受攻擊，從表像來看，業務節點或者負載均衡應該是被攻擊了，不然不會點擊酒店和機票搜索都會跳出Http/1.1 Service Unavailable，而應該會出現搜索遲遲不出結果，但是網頁大部分的介面還是可以展現的。如果僅僅是業務節點受攻擊，比如：所有的業務節點上的部署的代碼、程式被刪除了，或者是關機了，受到這種攻擊恢復的手法還是可以非常迅猛的，畢竟機器還在，攜程做為一個十幾年的老牌公司，上線部署流程應該是建設的比較完善的，可以在比較短的時間內進行恢復。

我們再看是不是某個數據庫掛了，從前面我們也講到，攜程的業務多，項目多，這些項目與業務線是不太可能使用同一台數據庫的物理機的，攜程的數據庫機器數量肯定是比較龐大的，而且我相信攜程的數據庫肯定是做好高可用的，同時日常備份是定期進行的。如果只是個別數據庫掛了，恢復起來的時間是非常快的。但是從這次攻擊的事件來看，數據庫整體被攻擊的可能性非常大。

可能攤上大事了

如果這是一次駭客攻擊，那駭客對攜程內部的系統瞭解程度那是相當的深，而且滲透、潛伏的時間非常長。如果這是一次非常惡意的攻擊，而且駭客對攜程苦大仇深，想一擊致命的話，數據庫就會是核心攻擊目標。業務節點丟點程式代碼不會緊，最多就像人走在大街上衣服被搶光了而已，雖然丟人，但是還是可以很快再搞幾件衣服回來穿上就是了，要是數據庫被刪除，而且不僅僅是邏輯刪除，而且是物理刪除，同時把所有備份也進行非常徹底的物理刪除的話，那基本上心臟中槍，沒得救了，不過好在這種情況出現的可能性不大。如果駭客把數據庫所在的主、從機器上的數據全部進行邏輯刪除，同時運行類似於dd的命令進行數據覆蓋，那麼主、從機器上的數據是沒法救的。

從網上的新聞來看，上午11點09服務就不可用了，我們做一個最壞情況的猜測：駭客應該是攻擊了大部分的數據，同時估計也備份到存儲上的數據也給刪除了。所以到現在，攜程的服務還沒有恢復。

那麼現在的問題關鍵點來了：攜程是用什麼方式進行數據庫的備份的（如果沒有日常備份，那整個攜程就可悲劇了）。如果採用內部私有雲存儲的方式進行備份，那麼此事還有的救。雖然駭客有可能把這些數據從雲存儲的應用端刪除，但是服務端這些數據可能還存在。數據是否可以恢復要取決於私有雲存儲的架構。攜程從公開的報道來看，內部私有雲用的是openstack，那麼很有可能是使用swift的存儲，除非駭客也是非常熟悉swift的架構，把swift上的三個備份的機器找到，進行物理刪除。否則，數據還是有可能恢復的。如果到備份到存儲一體機，我相信數據還是有可能找的回來的。簡而言之：如果有正常的備份，我相信數據還是可以恢復，如果沒有做數據庫日誌的實時備份的話，最多丟個一備份週期的數據（一般是一天）。

上面講的都是針對性的攻擊，但是最壞的情況是：駭客掌握了攜程大部分機器的root權限,同時進行無差別的毀滅性的攻擊的話（業務節點、數據庫節點、存儲節點），那後果反正我是不敢想了。

From 郭理靖