2015年6月1日

放「乖乖」還不夠的服務維運管理

軟體系統服務的維運管理,在台灣最常見的,就是請到「乖乖大神」出面,因為一般伺服器都是透過燈號,來辨識主機的運作情形,綠燈代表正常,紅燈則是故障燈號,這是軟體系統維運人員某個不成文的信仰。

當線上的服務不正常地離線後,我們最常見到的答案就是「駭客攻擊」,因為類似的服務競爭對手很多,如果官方承認是內部管理不周,沒有忠誠度的客戶,或許就可能鳥獸散,或發生使用者集體位移的狀況,都可能會影響到公司的營運。

大概是被駭客攻擊的新聞太多了,使用者很習慣接受這樣的理由,甚至有可能連開發的工程師,在系統上線一段時間之後,再遇到自己系統當機的情況時,第一時間,也會認為自己的服務被攻擊了。

大家猜測,責任在駭客身上,這是再直接不過的事情了。就系統開發者來說,不管任何時候發生問題,絕對不能一開始就下定論,首先要檢查的是系統的 log,要想的是有沒有任何造成當機的原因。

還記得遠通 ETC 的事件嗎?回想一下這個新聞 政院踢爆 全因APP設計不良 eTag遭駭 攏係假 當時因為 ETC APP 上線後,瞬間過多 APP 向 Server 查詢餘額,造成系統的當機,而這瞬間過多的 server request,是 APP 設計不良造成的,而且由於 APP 還得經過兩週的審核程序才能更新,當時立委每天都得質詢修正的進度,相信不管是每一個承辦單位,都承擔了很多壓力。不過幸好 ETC 是個獨占事業,不管如何,他們都撐過了系統上線那一段混亂時期,現在已經進入了穩定的營運期。

5/28 發生了 中國最大的線上旅遊網站攜程網當機,疑遭駭客攻擊 的事件,而且到了晚上八點,系統都還沒有恢復正常。

系統掛點,第一時間收到的解釋,就是駭客攻擊。針對這個問題,由於沒有正式的官方說明,各方的臆測很多,可以看一下這些連結。

服務中斷、瘋傳數據庫遭刪除 攜程網堅稱數據庫安好

ezTravel 最大股東中國攜程網,系統疑似遭到內部物理刪除

攜程癱瘓續:藝龍旅行網也沒法訪問了

從攜程網的故障中我們應該反思什麼?

攜程網癱瘓超8小時,可能故障原因分析

深入解析和反思攜程宕機事件

看著這樣的事件,我們可以知道什麼,學到什麼?

  1. 線上服務最重要的是資料的完整性
    客戶最在意的,就是自己的權益,不管發生什麼事情,都必須要讓客戶的資料完整地復原回來,這或許不是賠錢就能解決的問題。

    實務上資料備份有三道防線,第一個是 HA,再來是異地備援,第三是磁帶備份,這三個部份都是分開管理的,基本上很難同時被刪除,但比較難達到的是系統還原的程序。

  2. 系統還原需要有演練的程序
    一般系統常常會因為成本的考量,而放棄了備援的機制,甚至有了備援,卻沒有測試環境可以進行系統還原的驗證,這一切都是機器與人力成本的問題,而同時又是很難合理說明的必要花費。

    磁帶備份只要有磁帶機就能作,但是誰能保證備分出來的資料,可以還原回去?用什麼方法還原回去?這是個謎!

  3. 維運人員要如何避免人為疏失
    要說駭客攻擊造成資料遺失很容易,但真正比較有可能發生的,是內部員工疏忽,造成系統資料被刪除。

    這是推動 DevOps 的最佳理由,讓維運作業,加上系統工程的管理,可以降低發生錯誤的機會。

  4. 線上服務的架構複雜
    現在的系統設計時,常會考慮到混搭的作法,最基本的資料庫選擇,就有 NoSQL 跟關聯式資料庫兩大派別。而且最麻煩的是,不同的系統有不同的優缺點,也因此在系統發展的過程中,各式各樣的程式語言,作業環境,常會出現混搭的狀況。

  5. 重構時,要勇敢去刪除不必要的東西 -> 這只是口號
    軟體系統的進入發展與維護期,會增加一些新的小功能,當開發人員、管理人員、維護人員異動之後,新的人員會調整與修改系統,真正熟悉這個系統實作的人就消失了,整個作業環境,就只會逐漸地疊床架屋,系統之間的依賴關係,只會越來越混亂。

    重構時,要勇敢去刪除不必要的東西,這是最好的方式,但也是一種不負責任的說法,因為這樣的說法,並沒有完全考慮到現場實作人員的狀況。

    假設我們是開發人員,接收了一個既有產品或服務的更新或維護的工作,首先我們能得到的既有的文件,再來是前一個負責人員的幫助,要知道更深入一點的問題,就只能去查看程式碼,或實際發布看看。

    有時候,即使是出自自己開發與設計的產品,在經過半年或一年的維運期之後,如果突然要改什麼新功能,也不能保證會不會影響就的功能,這時候,也只有唯一一個選擇,就是避開舊的程式碼,把新功能疊加上去。

    很抱歉,在這裡只能提出一個理想化的口號,完全沒有實際上可行的作法。

  6. 我們缺少的維運管理工具
    DevOps將顛覆未來IT人角色 文章中提到,DevOps其實是針對雲端運算環境,提出來的一個概念,我們需要一個快速且穩定的開發、測試以及釋出軟體服務的方法。【知識庫】Github上推薦的12款DevOps開發工具 列舉出來的也都是針對雲端運算的維運工具。

    在這裡,有個想法,就是我們需要一種工具,可以將維運的文件與維護的script整合在一起,在管理時,可直接點擊 script 然後就遠端執行並取得結果。文件與 script本身要有版本管理的功能,才能在維護團隊之間共享維運知識。

    如果是修改設定檔,可以即時將設定檔取回,修改並存檔後,即時同步到遠端,重點是要有新舊設定檔的備份。

    另外,我們還需要知道,透過這個工具,每一個維護人員在這個機器上做過什麼事情,改過什麼設定,每一台機器的執行結果都能記錄下來。

    在有多台機器的服務環境上,一個產品會部屬在多個雲端機器上,這時候可能要面對版本同步的問題,或許一個指令同時在多個 server 執行會有幫助。

    puppet 的用途,看起來是要用 DSL 程式設計的方式,快速地將每一台機器的安裝設定做好。對於一般企業內部的服務管理來說,看起來有點大材小用。

    這個工具的想法與概念還沒有一個比較確切的藍圖,還只在紙上談兵而已。

最終官方在微博發布了正確的資訊:5月29日1:30分,經攜程技術排查,確認此次事件是由於員工錯誤操作導致。由於攜程涉及的業務、應用及服務繁多,驗證應用與服務之間的功能是否正常運行,花了較長時間。攜程官方網站及APP已於28日23:29全面恢復正常。對用戶造成的不便,攜程再次深表歉意。

攜程網 微博
攜程網 404 事件:員工錯誤操作,刪除伺服器原始碼