據〔iThome 2011-03-01 〕報導:「Google進行儲存軟體更新,卻出現意料外的臭蟲,使得有0.02%(約4萬名)用戶暫時無法存取郵件,故障時間長達30個小時,Google發現此問題後,立即停止部署新軟體,並改回舊版。…受影響的用戶比例Google官方說法數度修正,從一開始的0.29%(約相當於50幾萬用戶),後來又修正為0.08%(相當於十幾萬用戶),最後說法則是0.02%。」…See
More…See
More…See
More。
此次「Google軟體更新導致Gmail用戶無法看信」的事件,證明了雲端運算的風險〔使用Gmail就是使用雲端運算〕,以及有系統地管理雲端運算是如何的重要。
在這裡,我們從「資訊和通訊科技基礎建設管理系統(ICTIMS)」的「上線管理(Release
Management)」和「應用軟體管理(Application
Management)」兩流程來看這次的事件。
從上線管理流程來看,Google在發現軟體更新有問題後,立即停止部署並改回舊版,也就是說Google在「推展(Rollout)」出問題後,立即中斷推展活動,並進行「撤回(Back-out)」行動,把系統還原到其先前的已知狀態。這表示Google在做這件事時,是有「推展計畫(Rollout
Plan)」和「撤回計畫(Back-out Plan)」的,所以才能在僅影響0.02%的用戶時,就發現問題,停止推展,並立即啟動撤回計畫,而將傷害降到最低,沒有影響到大部分的用戶。如果沒有這樣的推展規劃,傷害恐怕將極為慘重。
Google這次比較令人不滿意的,是撤回的速度太慢,使用磁帶備份資料,花了30個小時,資料才回復完成。使用磁帶備份資料,可能是基於成本的考量或其它因素,但由於是免費的服務,因此Google除了感到困窘、商譽稍微受損之外,不需負賠償的責任。但對付費的服務而言,這樣的回復時間是可接受的。
從應用軟體管理流程來看,Google進行軟體更新,卻出現意料外的臭蟲,這表示這個軟體更新的開發管理有問題。在Google的工程師正在判斷是什麼原因導致Gmail出狀況之際,我們也可以幫他們找原因,當作是練習。我認為可能的原因可以從兩個方面來看:
l 工程師為什麼會寫錯軟體?可能的原因,例如:
- 工程師本身能力夠、經驗足或僅僅就只是因為疏失而導致。
- 工程師沒有獲得正確且足夠詳細的關於Google的ICT基礎建設的建構資訊而導致。(提供正確且足夠詳細的建構資訊是建構管理(Configuration
Management)流程的責任。)
l 這個軟體更新應該有經過測試,只是測試活動並沒有找出所有的臭蟲,為什麼?
- 未執行全部的測試腳本(Test Scripts)。
- 未針對軟體更新,設計測試腳本。
- 測試腳本涵蓋範圍不足。
- 測試環境與實況操作環境(Live Environment)或生產環境(Production
Environment)的建構有差異,其測試結果不適用於實況操作生產環境。
從這個案例,我們可以瞭解資訊和通訊科技基礎建設管理系統(ICTIMS)的重要。沒有一個有效的ICTIMS,就算只是一個工程師的小疏忽,都有可能毀掉整個ICT基礎建設、系統和服務。反之,有了一個有效的ICTIMS,可以保證ICT基礎建設、系統和服務的可利用性、可靠性、可維護性以及資訊安全,就算有意料之外的狀況發生,也可以將傷害降到最低。
《《《《《《《《《《《《《《《《》》》》》》》》》》》》》》》》》
龍山顧問是ICT管理專業服務公司,服務項目包含ICT管理的出版、訓練、診斷和輔導,詳情請參考龍山顧問公司網站:http://www.longshine.tw/。
沒有留言:
張貼留言