系統襲擊易攻，難守。
科技
攜程資料庫事件網上有各種說法。有說是資料庫資料以及備份資料被物理移除的。也有說是各個節點的業務代碼被移除 現在從新在部署。也有說是誤動作，致使業務不可用。儘管眾說紛芸，作為一個技術人員，咱們仍然需要透過現象看實質。
網站崩潰的表象
咱們先察看一下ctrip這次問題的表現。從我察看視角來看，在下晝2點周圍，攜程PC版的首頁上的酒店、機票這兩個最核心的運用仍然無法使用的，而且個人使用者也是無法登入的，同時攜程手機端的酒店、機票無法使用，以及個人定單是無法查詢的。
而網上的新聞報導上午11點服務就不可用了：攜程方面稱，今天上午11時09分，攜程的部份伺服器受到不明襲擊，致使官方網站及APP暫時無法標準使用，目前正在緊迫恢復。從攜程內定人士處獲悉，此次不明襲擊是攜程未攔截勝利的第一次資料庫襲擊，目前技術部正在搶救。
資料庫總體被襲擊的可能性極大
從這些訊息來判斷，應該不是業務流程上線中出BUG，或是上線流程過程有些誤動作。為何這麼講，咱們要進行粗略分析。對于使用者的角度來說，攜程的首頁是只有一個，各個業務的入口是統一的，然而從程式以及項目管理的角度來看，單單隻是從攜程的首頁來看，至少有14以上個業務部門以及項目，而且這些項目之間關聯耦合度不大，平時上線確定也是獨立上線的，假設一個項目掛了，短暫不可用又很快恢復了，那還可以理解，畢竟誰上線沒有返回過。然而大面積絕大部份業務都不可用，必然不是標準的上線流程中出問題。基本上咱們可以判斷，攜程內定系統確定是受到大規模的襲擊，大部份的業務節點受到嚴重的襲擊或是資料庫受到嚴重的襲擊，至於是內定員工或是是黑客那就不好說了。
咱們再來分析下是否業務節點受襲擊，從表象來看，業務節點或是負載均衡應該是被襲擊了，不然不會點擊酒店以及機票搜尋都會跳出Http/1.1 Service Unavailable，而應該會呈現搜尋遲遲不出結果，然而網頁大部份的介面仍然可以展示的。假設僅僅是業務節點受襲擊，譬如：所有的業務節點上的部署的代碼、程式被移除了，或是是關機了，受到這種襲擊恢復的手法仍然可以非常迅猛的，畢竟機器還在，攜程作為一個十幾年的老牌公司，上線部署流程應該是建設的對比完美的，可以在對比短的時間內進行恢復。
咱們再看是否某個資料庫掛了，從前面咱們也講到，攜程的業務多，項目多，這些項目與業務線是不太可能使用同一台資料庫的物理機的，攜程的資料庫機器數量確定是對比龐大的，而且我相信攜程的資料庫確定是做好高可用的，同時日常備份是按期進行的。假設只是個別資料庫掛了，恢復起來的時間是非常快的。然而從這次襲擊的事件來看，資料庫總體被襲擊的可能性非常大。
可能攤上大事了
假設這是一次黑客襲擊，那黑客對攜程內定的系統瞭解程度那是至關的深，而且滲入、潛在的時間非常長。假設這是一次非常歹意的襲擊，而且黑客對攜程苦大仇深，想一擊致命的話，資料庫就會是核心襲擊目的。業務節點丟點程式代碼不要緊，至多就像人走在大街上衣服被搶光了而已，儘管丟人，然而仍然可以很快再搞幾件衣服回來穿上就是了，要是資料庫被移除，而且不僅僅是邏輯移除，而且是物理移除，同時把所有備份也進行非常徹底的物理移除的話，那基本上心臟中槍，沒得救了，無非好在這種情況呈現的可能性不大。假設黑客把資料庫所在的主、從機器上的資料整個進行邏輯移除，同時運行相似於dd的指令進行資料籠蓋，那麼主、從機器上的資料是無法救的。
從網上的新聞來看，上午11點09服務就不可用了，咱們做一個最壞情況的猜測：黑客應該是襲擊了大部份的資料，同時估量也移除了備份到存儲上的資料。所以到現在，攜程的服務尚未恢復。
那麼現在的問題重要點來了：攜程是用甚麼模式進行資料庫的備份的（假設沒有日常備份，那整個攜程就可慘劇了）。假設採納內定私有雲存儲的模式進行備份，那麼此事還有的救。儘管黑客有可能把這些資料從雲存儲的運用端移除，然而服務端這些資料可能還存在。資料是否可以恢復要取決於私有雲存儲的架構。攜程從公開的報導來看，內定私有雲用的是openstack，那麼頗有可能是使用swift的存儲，除非黑客也是非常熟識swift的架構，把swift上的三個備份的機器找到，進行物理移除。否則，資料仍然有可能恢復的。假設到備份到存儲一體機，我相信資料仍然有可能找的回來的。簡而言之：假設有標準的備份，我相信資料仍然可以恢復，假設沒有做資料庫日誌的實時備份的話，至多丟個一備份週期的資料（一般是一天）。
上面講的都是針對性的襲擊，然而最壞的情況是：黑客掌握了攜程大部份機器的root許可權，同時進行無差別的毀滅性的襲擊的話（業務節點、資料庫節點、存儲節點），那後果反正我是不敢想了。
系統襲擊易攻，難守。
科技
攜程資料庫事件網上有各種說法。有說是資料庫資料以及備份資料被物理移除的。也有說是各個節點的業務代碼被移除 現在從新在部署。也有說是誤動作，致使業務不可用。儘管眾說紛芸，作為一個技術人員，咱們仍然需要透過現象看實質。
網站崩潰的表象
咱們先察看一下ctrip這次問題的表現。從我察看視角來看，在下晝2點周圍，攜程PC版的首頁上的酒店、機票這兩個最核心的運用仍然無法使用的，而且個人使用者也是無法登入的，同時攜程手機端的酒店、機票無法使用，以及個人定單是無法查詢的。
而網上的新聞報導上午11點服務就不可用了：攜程方面稱，今天上午11時09分，攜程的部份伺服器受到不明襲擊，致使官方網站及APP暫時無法標準使用，目前正在緊迫恢復。從攜程內定人士處獲悉，此次不明襲擊是攜程未攔截勝利的第一次資料庫襲擊，目前技術部正在搶救。
資料庫總體被襲擊的可能性極大
從這些訊息來判斷，應該不是業務流程上線中出BUG，或是上線流程過程有些誤動作。為何這麼講，咱們要進行粗略分析。對于使用者的角度來說，攜程的首頁是只有一個，各個業務的入口是統一的，然而從程式以及項目管理的角度來看，單單隻是從攜程的首頁來看，至少有14以上個業務部門以及項目，而且這些項目之間關聯耦合度不大，平時上線確定也是獨立上線的，假設一個項目掛了，短暫不可用又很快恢復了，那還可以理解，畢竟誰上線沒有返回過。然而大面積絕大部份業務都不可用，必然不是標準的上線流程中出問題。基本上咱們可以判斷，攜程內定系統確定是受到大規模的襲擊，大部份的業務節點受到嚴重的襲擊或是資料庫受到嚴重的襲擊，至於是內定員工或是是黑客那就不好說了。
咱們再來分析下是否業務節點受襲擊，從表象來看，業務節點或是負載均衡應該是被襲擊了，不然不會點擊酒店以及機票搜尋都會跳出Http/1.1 Service Unavailable，而應該會呈現搜尋遲遲不出結果，然而網頁大部份的介面仍然可以展示的。假設僅僅是業務節點受襲擊，譬如：所有的業務節點上的部署的代碼、程式被移除了，或是是關機了，受到這種襲擊恢復的手法仍然可以非常迅猛的，畢竟機器還在，攜程作為一個十幾年的老牌公司，上線部署流程應該是建設的對比完美的，可以在對比短的時間內進行恢復。
咱們再看是否某個資料庫掛了，從前面咱們也講到，攜程的業務多，項目多，這些項目與業務線是不太可能使用同一台資料庫的物理機的，攜程的資料庫機器數量確定是對比龐大的，而且我相信攜程的資料庫確定是做好高可用的，同時日常備份是按期進行的。假設只是個別資料庫掛了，恢復起來的時間是非常快的。然而從這次襲擊的事件來看，資料庫總體被襲擊的可能性非常大。
可能攤上大事了
假設這是一次黑客襲擊，那黑客對攜程內定的系統瞭解程度那是至關的深，而且滲入、潛在的時間非常長。假設這是一次非常歹意的襲擊，而且黑客對攜程苦大仇深，想一擊致命的話，資料庫就會是核心襲擊目的。業務節點丟點程式代碼不要緊，至多就像人走在大街上衣服被搶光了而已，儘管丟人，然而仍然可以很快再搞幾件衣服回來穿上就是了，要是資料庫被移除，而且不僅僅是邏輯移除，而且是物理移除，同時把所有備份也進行非常徹底的物理移除的話，那基本上心臟中槍，沒得救了，無非好在這種情況呈現的可能性不大。假設黑客把資料庫所在的主、從機器上的資料整個進行邏輯移除，同時運行相似於dd的指令進行資料籠蓋，那麼主、從機器上的資料是無法救的。
從網上的新聞來看，上午11點09服務就不可用了，咱們做一個最壞情況的猜測：黑客應該是襲擊了大部份的資料，同時估量也移除了備份到存儲上的資料。所以到現在，攜程的服務尚未恢復。
那麼現在的問題重要點來了：攜程是用甚麼模式進行資料庫的備份的（假設沒有日常備份，那整個攜程就可慘劇了）。假設採納內定私有雲存儲的模式進行備份，那麼此事還有的救。儘管黑客有可能把這些資料從雲存儲的運用端移除，然而服務端這些資料可能還存在。資料是否可以恢復要取決於私有雲存儲的架構。攜程從公開的報導來看，內定私有雲用的是openstack，那麼頗有可能是使用swift的存儲，除非黑客也是非常熟識swift的架構，把swift上的三個備份的機器找到，進行物理移除。否則，資料仍然有可能恢復的。假設到備份到存儲一體機，我相信資料仍然有可能找的回來的。簡而言之：假設有標準的備份，我相信資料仍然可以恢復，假設沒有做資料庫日誌的實時備份的話，至多丟個一備份週期的資料（一般是一天）。兩岸商貿,在家工作,網路創業,創業賺錢思惟,微商平台,賺新台幣
上面講的都是針對性的襲擊，然而最壞的情況是：黑客掌握了攜程大部份機器的root許可權，同時進行無差別的毀滅性的襲擊的話（業務節點、資料庫節點、存儲節點），那後果反正我是不敢想了。
留言列表
