看到各網對於高鐵停擺四小時一事的評論,多數人是偏向支持工程師那方的,而認為新聞稿 中的文字過於搧情嘩眾。雖說能上網發言的人多半也對電腦系統較有認識,未必能與全民劃 上等號,但術業專攻不同者,倒也不一定對此插得上話。

軟體工程師、或程式設計師,從事這門行業久了,漸漸地會對複雜系統較了解、較有興趣。 就算是架個網站服務,也會愈來愈複雜,拆出愈來愈多部件,各自分工,又自合作。

分工多半是為讓各部件有足夠的計算資源,能更快速地完成特定事項,並且不影響其他部件。 但分工過細、部件過多,也會讓系統的中的臭蟲更難被發現、更難被解決。

仔細想想,如果重開機能解決問題,那麼可不可以每次有問題,只要重開機就好?

如果在討論中的系統是「手機」,那麼以重開機作為解決特定臭蟲的手段,也許是可以的。 手機的重開機過程很單純,所需時間也不多,普通手機幾秒就夠,雖然智慧性手機重開 機要比較久,但多半也不會超過一分鐘。如過有個手機系統的臭蟲在開發階段很難被解決, 而一般使用者會碰到此臭蟲的機率極低,那麼,為了不延遲手機上市時間,決定忽略不解決, 或是以「直接強制重開機」做為解決方案的可能性也是存在的。

雖然可能會讓使用者少了一分鐘可能使用手機的時間,但實際發生狀況的使用者比例可能不 到萬分之一,因此評估,不必再花時間去徹底解決臭蟲。而像這樣的決策過程,多半不為外 人道。

如果要討論較複雜的鐵路系統,那就會跟手機系統有很不一樣的討論過程,畢竟關聯的 部件較多,多半比手機更加複雜。

複雜系統的重開機,也不會手機重開機一樣,只要按一個鍵,等幾十秒,所有事就會自動完 成。事後還會有很多檢查性的工作要執行,確保重開完成的系統,一樣能運作無誤。

「幾分鐘可解決的故障 高鐵竟停擺4小時」這樣的新聞標題雖然正確無誤,但同時,也僅 是片面的事實,在新聞稿內文中,除了傳達部份民眾的抱怨,也未提到高鐵公司的說明。 倒是後來高鐵網站也有公佈了一則說明:

2013-04-25 今日台中站區域號誌異常暫停營運,高鐵公司說明

相較起來,花四小時或四十小時去仔細檢查,是否值得,外人不知道,也沒有出現在新聞報 導中。新聞稿的文字,只有傳達民眾的發言,沒有傳達高鐵公司方面的發言。說起來,如果 只有單方面的發言,那麼,新聞倒底發揮了什麼角色呢。

關於複雜系統的失敗與「重開機」,Paul Fenwick 曾經給過幾場很有意思的 演講,主題是 "An Illustrated History of Failure",以經典的工程錯誤 為例,旨在讓人從前人的錯誤中學習經驗。影片網址: http://blip.tv/tucs-tech-talks/an-illustrated-history-of-failure-2729174

在影片中約 8:50 秒處提到了 AT&T 替他們的交換機機房設計出了一套以「自動重開機」來 自我修復的機制。每台交換機會記住鄰居的健康狀態,並且在發現自己出問題時,把自身的健康 狀態通知鄰居,然後主動重開機,作為自我修復的手段。

實際運作了許多年後,發生了一場大災難。某一台交換機在重新起動後回報的頻率快了一些, 鄰近的交換機在連續收到同樣的回報後,卻認定是自己的記憶內容有誤,應該是自己的問題, 因此自動重開機,並且回報狀態給鄰居。鄰居收到回報後,也認定是自已的記憶有誤,自動 重開機,然後回報。整個過程就這樣慢慢而不斷的反覆擴散出去。

最後,所有機房中交換機以每六秒一次的頻率,不停地自動重開機。

說倒底重開機算不算是個解決問題的方法?當然是,但是更重要的一點,是大家從這次經驗 裡學到了些什麼事情。這次花了四小時,那麼下次類似情況是否能只花二小時?或者下次能 早點判斷需要重開機?或者能加速重開機的時間?

大型而複雜的系統失誤,代價都很昂貴。3.5 萬人次的影響也許不真的算高額,但也不是可 以隨便浪費掉的數目。如果有學到些經驗,那麼這 3.5 萬人次的賠償費用,也許就算值得的學費, 如果沒有學到任何事,那才是真正地浪費了。