前幾天驚聞我們在松山機場寫的程式發生意外，排班要播放的訊息卡住不動，系統沒當機，只是以為某則廣播一直未播完而停頓下來。在此之前系統已經正常運作好幾天了，表示程式應該是正確的，卡住是因為某個無法預期的意外狀況，而不是程式流程寫錯。據說之前已發生過一次，重新啟動程式之後就正常了！當然我們還是必須處理，讓系統以後即使發生意外時也不致中斷。

這種事情多數施工單位大概會刻意不講，或者飾詞狡辯，但這不是我的作風，所以還是在此就事論事分享經驗。其實系統卡住時，機場那邊沒有技術夠好的人能適時診斷留下紀錄，也因為程式並沒有當掉，我們也沒有錯誤訊息可以分析，確實很難在事後確定發生障礙的原因，只能用猜的！

基本上電腦是很穩定的機器，一個程式反覆執行一個動作連續很多年都不會有不同的結果，那怎麼會有「不穩定」的狀況呢？依據我的經驗，一個程式內部確實不會有意外，除非是停電啦！但是如果一個複雜的系統內部有多個程式，甚至多台電腦之間作行程通訊或網路通訊，那就可能會有「意外」了！

譬如大家都有過開網頁時內容不完整的經驗，如果真的是網頁寫錯，那再試一百次都是一樣的結果，但通常我們稍候幾秒，再按一次「重新整理」就會出現完整的畫面，這就是通訊的意外了！當電子訊號離開電腦在網路線上傳播，還經過很多網路節點轉傳，任何電波干擾、訊號過度衰減、封包碰撞或有人踢到電線都會產生通訊失敗。多數網路通訊協定與設備都會努力以各種機制避免發生這些意外，或偵測出意外後進行重新傳送等補救措施，讓使用者「以為」網路很穩定！

但是從網頁偶爾會殘缺不全的經驗，我們知道這些網路的自動補救機制未必總是管用，所以必須手動更新才能解決問題。甚至不必上到網路，一部電腦內部不同程式之間的溝通(行程通訊)可能都會有「意外」！譬如我們已經多次證實，用自製的程式「監看」某個目錄內的檔案是否有增減的機制常常會出錯，所謂「監看」其實是經過Windows作業系統的通知來觸發我的程式內部的事件。但三不五時，就會有沒收到通知的狀況，好像國稅局沒通知到你要去報稅。

這個廣播系統確實很複雜，光是伺服端就牽涉到至少三台不同電腦之間的網路通訊，其中的兩台電腦內部還有兩個以上的獨立程式或網站資料庫必須互相通訊協同運作。還要加上十多個客戶端(登機門)也都與伺服器主機系統有網路通訊，任何一次通訊出了意外就有可能讓系統卡住的！

我們當然不能抱怨完之後就推諉責任，即使不是我的程式寫錯，我也必須想辦法處理。其實解決方式很有趣，很人性化！就是分析所有流程中可能出現通訊失敗的斷點，在這些通訊動作上附加一個計時機制，逾時之後就做必要的自動處理，最糟狀況只是忽略這個有問題的播音訊息，通常就是再做一次通訊，有如用程式去按F5重新整理的按鍵；或者約會等女友，最多等個一小時就該放棄了！不必永遠等下去的。

現在加上計時偵測機制的新程式已經上線繼續運轉了！我相信應該不會再有嚴重的問題了。天佑台灣！如果我做得好，表示以後機場不必再找歐美或大陸人士來寫這種軟體了！國家省很多錢，我和協力廠商的眾多台灣員工還可以一起賺錢。