硬體當機2大主因：性能預留不足與備援維護不確實

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

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

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使用並聯式架構，電池沒電也無力回天

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