從5月28日中午11:09，攜程旅行網開始無法正常登陸，直到28日23:29分才完全恢復正常。經攜程技術排查，確認此次事件是由于員工錯誤操作，刪除了生產服務器上的執行代碼導致。根據攜程第一季度財報數據，攜程宕機損失為平均每小時106.48萬美元，本次宕機超12小時可謂損失慘重。
一、那么本次攜程宕機事件能縮短到10分鐘內嗎?
為什么攜程宕機持續了超12小時?顯然是沒有啟動任何災備系統。如果及時進行災備切換，宕機時間最短可以縮短到10分鐘內嗎?筆者為此采訪了某資深云計算架構師侯老師，“如果在部署了有效災備的情況下，技術人員可以分秒內啟動災備服務器，從而代替生產服務器正常運行網站。且與生產服務器相比，災備服務器僅缺少最近4個小時的數據，我們可以快速上傳備份數據以保證完整性。”
二、本次數據恢復時間可以縮短嗎?
誠然，類似攜程這樣的大型網站承載著繁多業務，其后臺是一個由SOA(面向服務)架構組成的龐大服務器集群，子系統與子頁面間相互關聯相互依賴，且數據庫龐大，但是12小時的恢復時間是否太長了呢?
候老師表示，“雖然攜程網站系統非常復雜，但我們可以采取復制災備服務器的方式，以應對生產服務器的復原。恢復時間視數據量大小而定，但與備份上傳方式相比，時間會大大縮短。”
三、本次事件有可能避免嗎?
攜程已確認本次宕機是由員工誤刪執行代碼所致，為避免此類事情的發生，只能加強數據訪問權限管理。
那么問題來了，權限管理到底能嚴謹到什么程度?
侯老師表示，無論數據存儲在云端還是物理端，都可以根據數據的重要性及私密程度，進行分級設置。類似本次被誤刪的根目錄代碼，其刪除會引起整個數據庫的丟失，應該僅對最高級別技術人員開放，并且設置刪除詢問及二次審核制度。當然，還是需要各位IT人員工作時多加注意，避免疏忽。
京公網安備 11010502049343號