圖片來源: 

iThome

因為硬體問題而造成大當機事件的狀況,常見的原因可以歸納為二:一個是硬體性能預估保留的評估錯誤,無法面對突然來臨的大量處理需求;另一個則是備援機制的維護不確實,導致需要切換到備援機制的時候,無法正確運作,反而引發連鎖錯誤而當機。

當然正如先前所談到,通常會造成嚴重的當機的原因,往往都是因為不同錯誤的連鎖問題造成,但是硬體發生問題,卻常常是很多當機事件之所以之後會一發不可收拾的源頭。

Web應用最常發生性能不足的問題,中介設備常被忽略

硬體的記憶體、處理器或整體設備性能不足,進而造成大當機事件的狀況,最常發生在Web相關的應用上。由於Web應用較難預估使用者的可能數量,當需求大量湧進的時候,往往會造成系統無法負荷,進而導致當機。這種狀況在社群網站、售票、網購的系統上,最常出現。

舉例來說,臺灣高鐵售票系統剛上線時,就曾發生過這種狀況。2007年1月,當高鐵正式開始售票的時候,就發生了多次自動售票機當機的事件,當時交通部路政司司長尹承蓬表示,1月17日當天16餘萬張車票的交易,已經是高鐵公司當時售票系統的上限。之後交通部高鐵局局長龐家驊才進一步指出,高鐵公司將再增加4 臺伺服器,由原本的4臺擴充至8臺,用來解決當時系統當機的問題。

這就是很典型的性能空間預留不足所造成的問題,一般直接的思考就會想到透過增加後端伺服器、頻寬來解決這樣的問題。但其實事情往往不是這麼簡單,有的時候,系統效能和前端整合設備的介面,以及中間負載平衡設備或是閘道器設備,也有很大的關係,許多因為硬體能力不足而造成大當機的事件,這些設備往往才是主因。

舉例來說,日本某間網路購物廠商,也曾有過類似的問題。該廠商的購物終端設備,除了Web直接訂購之外,也能夠透過便利商店的Kiosk和部分連鎖書局的專用購物Kiosk設備進行連線。某次當一個熱賣商品正式開賣沒多久,便利商店Kiosk連線購物的功能很快就當機無法使用了。事後發現,由於便利商店的Kiosk購物介面與Web不同,所以在系統設計時,使用者購物資訊傳回該購物廠商後端系統前,必須透過中介轉換的伺服器,將資訊轉換為適當格式後才能輸入該廠商的Web應用伺服器。書店專用的Kiosk上也採用相同做法,但是由於事前的評估低估了便利商店的使用量,所以當熱賣的商品上線開賣時,便利商店Kiosk專用的中介伺服器無法承受同時湧入的大量需求而當機,導致整個系統無法完成交易,使得商品銷售的業務上遭受了一定的損失。

當時臺灣高鐵的售票系統也有類似的需求,當需要整合不同介面的終端時,中介設備往往是設計與規畫上的瓶頸,容易因為低估需求而出錯,導致當機。其實很多網站的當機事件,也常常不是因為Web應用的伺服器被擊潰,而是前面的負載平衡設備無法承受突然湧進的流量而導致當機。舉例來說,2008年,知名遊戲網站巴哈姆特遭受DDoS攻擊事件,雖然是攻擊事件,但最先倒下也是負載平衡設備,而不是後端的應用伺服器。

其實準備伺服器來面對突如其來的流量,很多企業已經都有了這樣的常識,當流量暴增或是伺服器停止運作時,至少確保75%的運算效能,已經是很多企業設計系統的標準。不過如果每臺伺服器的運作使用率比較低,也可以多準備伺服器來預防這樣的問題。例如準備4臺伺服器,3臺運作、1臺預備,在這樣的架構下,理論上只要每臺伺服器的運算負荷沒有超過33%,任1臺伺服器無法運作的時候,預備的伺服器隨時都可以接手。加上現在伺服器虛擬化的應用也比較成熟,這一類的準備已經是多數企業IT人員都已經做到,或是已經擁有的常識。

但是從歷次幾場相關原因的大當機事件來看,反而網路中介設備、中介伺服器的需求評估,常常會是被忽略的一環。例如先前談到日本的例子。而雖然沒有被證實,當時臺灣高鐵數次售票系統當機的原因,也有不少人直指是資料傳輸到後端核心售票系統前,中介伺服器的準備數量不足造成。

另外,據了解,某知名售票系統常常發生無法訂票的原因,很多時候是使用者使用習慣的關係。使用者為了買到熱門的票券,常常打開多個網頁視窗占用連線數量,長達幾個鐘頭,並且反覆地以重新整理的方式試圖搶購。使得系統維護者無論如何增加頻寬和伺服器的數量,就是無法解決問題。其實這也意味著考量到不同消費族群的使用習慣,在硬體設計的評估上也需要事先準備,其實要解決這種問題也不是不可能,只是投資是否合乎企業的利益,還需要再考慮清楚。

備援機制也需要注意維護,否則會造成更大的災難

還記得2009年初的桃園機場大當機事件嗎?這次長達36小時左右的大當機,主要問題是第一航廈的護照查驗系統,因為硬碟損害影響機場正常運作,雖然桃園機場第一航廈與第二航廈的系統有交互備援機制,但是由於備援的第二航廈系統,竟然同時也因為硬碟受損而無法運作,才導致護照查驗系統完全無法使用。當時影響範圍包括桃園機場、松山機場、臺中機場、高雄機場、金門水頭碼頭以及馬祖福澳港等。

雖然當時內政部移民署副署長黃碧霞對外發表聲明指出,依據初步判斷,已經排除人為因素的可能。但事實上這整個大當機事件的真相如果真是因為硬碟損壞,那就非常令人匪夷所思,而且很明顯的有人為維護、操作的錯誤因素在其中。不過由於相關人士都無法出面證實,所以事件的全貌也就如此埋沒。

不過,事後追查發現,當時,由於護照查驗系統的維護廠商,才剛從大同公司轉由神通電腦負責不到幾天,雙方竟然沒有完成交接,導致神通電腦是在完全不了解系統架構與概況的情況下,搶修護照查驗系統,最終雖然也完成搶修,這可能是造成搶修時間拉長的原因之一。

此外,也有不少人猜測,是否因為不熟悉系統,以致於第一線維修人員動手維修時,沒有依照標準作業程序,造成磁碟連鎖當機,導致更嚴重的問題,否則,一般情況下,由於有RAID架構的保護,不太會因為單一硬碟出問題,且在有備援系統的狀況下,還陸續引發連鎖當機的情況。有趣的是,護照查驗系統已經有10多年的歷史,那一次大當機也不是第一次當機,據了解2008年就先後有過4次當機事件,只是當機時間短,所以並沒有引起太多關注。據了解,之前的當機都是在幾十分鐘內就完成,由於沒有人可以證實,所以不確定這些小規模的當機,是否和之後這次停擺36小時的事件有關,但很有可能已經有一些問題徵兆顯現。

這個例子除了顯示出日常維護的鬆散,以及行政流程完全不考慮交接過程的嚴重過失之外,也揭露了一個重要的問題,那就是平常養兵千日,用在一時的備援機制,其實也需要花心思去維護,否則在真正需要的時候,反而可能是另一場災難的開始。這其中還有許多值得探討的問題,例如公營單位的委外制度,讓第一線的IT人員都沒有能力處理任何問題,只能極度仰賴廠商,這樣的做法是否正確?不過那已經是制度面的問題,在這裡我們暫且打住。

此外,今年農曆年前,中國信託商業銀行的當機事件也是一個血淋淋的例子。2月5日晚上6點20分,中國信託商業銀行的機房發生大當機,導致包括銀行端信用卡、網路銀行、自動櫃員機、客服中心與臺灣彩券電腦型彩券交易系統等業務服務皆中斷。中國信託緊急搶修後,才在7點20分機房恢復營運,終於讓民眾趕在開獎前買到彩券。事後中國信託商銀對外發布新聞稿表示,當機原因是不斷電系統(UPS)故障異常。

會發生這個事件,是因為2月5日中國信託商銀的機房正在進行停電演練,模擬臺電供電異常時,機房的備援措施能否發揮功效,以確保機房的運作不受臺電跳電或斷電等問題的影響。但是當切斷臺電供電來測試發電機是否正常時,中間會有30秒的空窗期,必須仰賴UPS供電。巧合的是,當時UPS的電池電量不足,導致這短短30秒電力中止,讓整個系統因為無電可用而停擺。據了解,主因是因為UPS的電池已經使用了7年,老化後電量不足。

詳細的內容報導過去iThome電腦報周刊已經著墨過,這裡就不再重複,不過這個例子也點出了很多時候企業IT人員會疏忽的盲點,那就是備援機制的維護。

 

中國信託即使UPS使用並聯式架構,電池沒電也無力回天

 


相關報導請參考「為什麼會大當機?」


熱門新聞

Advertisement