攜程數據庫事件網上有各種說法。有說是數據庫數據和備份數據被物理刪除的。也有說是各個節點的業務代碼被刪除 現在重新在部署。也有說是誤操作,導致業務不可用。盡管眾說紛蕓,做為一個技術人員,我們還是需要透過現象看本質。
網站崩潰的表象
我們先觀察一下ctrip這次問題的表現。從我觀察視角來看,在下午2點左右,攜程PC版的首頁上的酒店、機票這兩個最核心的應用還是無法使用的,而且個人用戶也是無法登錄的,同時攜程手機端的酒店、機票無法使用,以及個人訂單是無法查詢的。
而網上的新聞報道上午11點服務就不可用了:攜程方面稱,今天上午11時09分,攜程的部分服務器遭到不明攻擊,導致官方網站及APP暫時無法正常使用,目前正在緊急恢復。從攜程內部人士處獲悉,此次不明攻擊是攜程未攔截成功的第一次數據庫攻擊,目前技術部正在搶救。
數據庫整體被攻擊的可能性極大
從這些信息來判斷,應該不是業務流程上線中出BUG,或者上線流程過程有些誤操作。為什么這么講,我們要進行粗略分析。對于用戶的角度來講,好像攜程的首頁是只有一個,好像攜程只有首頁這么一個,各個業務的入口是統一的,但是從程序以及項目管理的角度來看,單單只是從攜程的首頁來看,至少有14以上個業務部門以及項目,而且這些項目之間關聯耦合度不大,平時上線肯定也是獨立上線的,如果一個項目掛了,短暫不可用又很快恢復了,那還可以理解,畢竟誰上線沒有回滾過。但是大面積絕大部分業務都不可用,必然不是正常的上線流程中出問題。基本上我們可以判斷,攜程內部系統肯定是受到大規模的攻擊,大部分的業務節點受到嚴重的攻擊或者數據庫受到嚴重的攻擊,至于是內部員工或者是黑客那就不好說了。
我們再來分析下是不是業務節點受攻擊,從表象來看,業務節點或者負載均衡應該是被攻擊了,不然不會點擊酒店和機票搜索都會跳出Http/1.1 Service Unavailable,而應該會出現搜索遲遲不出結果,但是網頁大部分的界面還是可以展現的。如果僅僅是業務節點受攻擊,比如:所有的業務節點上的部署的代碼、程序被刪除了,或者是關機了,受到這種攻擊恢復的手法還是可以非常迅猛的,畢竟機器還在,攜程做為一個十幾年的老牌公司,上線部署流程應該是建設的比較完善的,可以在比較短的時間內進行恢復。
我們再看是不是某個數據庫掛了,從前面我們也講到,攜程的業務多,項目多,這些項目與業務線是不太可能使用同一臺數據庫的物理機的,攜程的數據庫機器數量肯定是比較龐大的,而且我相信攜程的數據庫肯定是做好高可用的,同時日常備份是定期進行的。如果只是個別數據庫掛了,恢復起來的時間是非常快的。但是從這次攻擊的事件來看,數據庫整體被攻擊的可能性非常大。
可能攤上大事了
如果這是一次黑客攻擊,那黑客對攜程內部的系統了解程度那是相當的深,而且滲透、潛伏的時間非常長。如果這是一次非常惡意的攻擊,而且黑客對攜程苦大仇深,想一擊致命的話,數據庫就會是核心攻擊目標。業務節點丟點程序代碼不會緊,最多就像人走在大街上衣服被搶光了而已,雖然丟人,但是還是可以很快再搞幾件衣服回來穿上就是了,要是數據庫被刪除,而且不僅僅是邏輯刪除,而且是物理刪除,同時把所有備份也進行非常徹底的物理刪除的話,那基本上心臟中槍,沒得救了,不過好在這種情況出現的可能性不大。如果黑客把數據庫所在的主、從機器上的數據全部進行邏輯刪除,同時運行類似于dd的命令進行數據覆蓋,那么主、從機器上的數據是沒法救的。
從網上的新聞來看,上午11點09服務就不可用了,我們做一個最壞情況的猜測:黑客應該是攻擊了大部分的數據,同時估計也備份到存儲上的數據也給刪除了。所以到現在,攜程的服務還沒有恢復。
那么現在的問題關鍵點來了:攜程是用什么方式進行數據庫的備份的(如果沒有日常備份,那整個攜程就可悲劇了)。如果采用內部私有云存儲的方式進行備份,那么此事還有的救。雖然黑客有可能把這些數據從云存儲的應用端刪除,但是服務端這些數據可能還存在。數據是否可以恢復要取決于私有云存儲的架構。攜程從公開的報道來看,內部私有云用的是openstack,那么很有可能是使用swift的存儲,除非黑客也是非常熟悉swift的架構,把swift上的三個備份的機器找到,進行物理刪除。否則,數據還是有可能恢復的。如果到備份到存儲一體機,我相信數據還是有可能找的回來的。簡而言之:如果有正常的備份,我相信數據還是可以恢復,如果沒有做數據庫日志的實時備份的話,最多丟個一備份周期的數據(一般是一天)。
上面講的都是針對性的攻擊,但是最壞的情況是:黑客掌握了攜程大部分機器的root權限,同時進行無差別的毀滅性的攻擊的話(業務節點、數據庫節點、存儲節點),那后果反正我是不敢想了。
晉城龍鼎 - 晉城網站建設為您解答!