攜程網官方微博聲明,該公司網站與App當機超過12小時,是因為內部員工操作錯誤造成的。

圖片來源: 

攜程網官方微博

中國最大旅遊業者攜程網(Ctrip)官方網站及App於5月28日上午11點9分出現當機,官網及App無法提供服務,一直到當天晚上11點29分全面恢復正常。這期間,對於當機的原因多所臆測,攜程網官方微博最早在上午11點9分宣布,攜程網部分伺服器遭到不明攻擊,導致官方網站和App暫時無法正常使用;之後陸續恢復部分服務功能,直到5月29日凌晨1點半發布官方聲明,表示攜程網的當機事件是因為員工錯誤操作導致,因為相關業務與服務範圍較為繁多,所以花了比較長的時間,驗證服務能否順利進行。

攜程網會員就多達2.5億人,員工人數超過3萬人,而根據攜程網2015年第一季財報,其淨營收為3.73億美元(約為新臺幣115.6億元)來估算,平均小時營收新臺幣535萬元,而當機12小時,相當於損失了新臺幣6420萬元。受當機事件影響,攜程網在美國的股價也從原本81.52美元,小跌到每股78.81美元,但中間一度跌幅超過10%。

攜程網服務當機12小時後,官方宣稱問題出在員工操作錯誤

由於攜程網提供各種機票、酒店和旅遊行程的預定,包括官方網站以及App服務出現當機時,引發中國使用者的恐慌。第一時間,網路上便有人傳出攜程網的資料庫遭到物理性刪除,引發使用者一陣恐慌;爾後,攜程網則在官方微博表示,當機源自於遭到駭客不明攻擊,才導致服務中斷。攜程網服務從上午11點9分出現當機,一直到當天晚上11點29分全面恢復正常服務,中斷服務時間超過12小時。直到5月29凌晨一點半,攜程網才對外宣稱,因為攜程網提供許多旅遊相關的網路服務,攜程網官方聲明指出,該公司技術人員要復原上線服務時,必須確認每個Web Services和系統之間的驗證與串接無誤後,才能服務恢復上線。也因此,此次的服務從當機到重新上線,技術人員花了超過12小時才復原。

果核數位營運長許武先表示,連這種規模的企業都會發生人為操作錯誤,更提醒了,高度依賴網路的服務業者,應該要重視特權管理和備援機制;臺灣線上古典音樂網站Muzik Online總工程師曾義峰則認為,為了降低人為操作出錯的風險,不論多麼複雜的網站服務,對於DevOps(開發銜接維運)中的Operation(維運)都應該預先規畫服務當機時的應對方案,有SOP(標準作業程序)照表操課,可以降低不必要的損失。

落實權限管理與災難備援機制,減少人為錯誤

對於攜程網將服務中斷原因歸咎於員工的操作錯誤,負責線上遊戲業者遊戲橘子所有IT服務與安全的許武先表示,從官方表示資料沒有遺失,訂單資料也保留完整,但服務卻中斷12小時,問題就可能發生在應用程式或者是儲存系統出問題。一般而言,應用程式出錯極有可能某些應用程式的程式碼被不當刪除或修正,改善的方式便與權限控管息息相關;若是儲存系統出問題造成的服務中斷,則會和系統資料的備份、備援機制完整度相關。

他以遊戲橘子為例,正常來說,員工在上線(Production)環境中的權限都是受到高度控管與限制的,像是刪除資料庫(Drop DB)或是欄位(Table)時,或者是修改資料庫或欄位時,都有明顯的警告機制,都必須經過授權後,才能夠執行相關的指令。為了避免類似服務中斷的可能性,遊戲橘子還引進特權管理機制,並要求所有的指令的執行,都必須先在測試環境中確認無誤後,才能在上線環境執行;而所有的服務上線,也都必須依照排程逐步進行。

早一天,中國支付寶才發生因為光纖被挖斷導致服務中斷,但支付寶在2小時內,就恢復正常服務。許武先認為,相較於支付寶的快速復原,可以推測攜程網平時的災難備援機制的演練或許不夠完善,以致於,一旦發生服務中斷的意外時,攜程網缺乏一套完善的災難應變流程。

從DevOps角度重新關注網路服務上線與部署流程

曾義峰則認為,這麼大型的網站服務公司要重新恢復線上服務時,開發與維運團隊勢必要攜手合作,這正是近期為了降低應用程式部署風險的IT顯學DevOps所要解決的難題。

他進一步指出,像攜程網這類當機事件,姑且不論是外部惡意攻擊或者是內部疏失造成的,DevOps 中的 Ops(Operations,維運) 都應該事先設想到,服務一旦當機時的備援機制,而這個方式也應該同時包含Online(線上)及Offline(離線)兩種方式。

Online的備援表示平時要有多臺伺服器做熱備援,資料庫就必須有2臺以上,1臺出錯,還有1臺可以即時接手備援。不過,Online線上熱備援的問題在於,很難處理大量刪除資料的問題。也就是說,這批同時上線運轉的機器為了隨時提供服務,也會即時同步彼此的資料和數據,一旦外部駭客入侵或內部員工下指令要刪除整個資料庫時,這些同時線上提供服務的資料庫,就會同時被刪除。

所以,曾義峰說,Online線上的備援有風險,所以也必須同時落實Offline離線的備援機制,就是備份,包括資料與系統在內。但他則提醒,Offline離線備援機制仍有層級之分,企業可以忍受多久的服務中斷時間?資料還原後,驗證服務的階段時,判斷有哪些資料遺失,有哪些資料毀損,又需要多久的時間,都必須事先做好規畫才行。此外,採用離線備援機制時,企業可以忍受多少的資料損失,有賴設定備份的頻率,上述都與企業投資在備援方案的成本多寡,息息相關。

從攜程網服務當機超過12小時,曾義峰更特別意識到,DevOps中的災難備援機制都應該同時包含Online線上與Offline離線方案, 若企業無法忍受任何資料遺失或毀損時,如何做到快速同步又能避免同時面臨資料毀滅,是很大的挑戰;但無論如何,好的Offline離線備援機制,是所有線上備援機制失效後,最後的保命符。

 


Advertisement

更多 iThome相關內容