在我正式完成工程教育的幾年前(編按:1990年代),我在一艘負責西非附近區域的地震勘測船上擔任儀器技師;這些勘測船透過調查海床下的地質,做為探勘海底原油的第一階段。在產能全開時,單一艘勘測船一天可產生數十萬美元的營收,因此當紀錄系統發生故障、導致調查範圍內出現空白時,會需要一個很充分的理由,特別是當你有個作風與眾所周知的維京人如出一轍、從軍隊退役的挪威裔主管。

有一天紀錄系統就是掛了,沒有錯誤警告、也沒有冒煙或是燒起來…就是停止紀錄,而且重複發生;於是調查結果看起來就像是卡通裡面那種被飢餓老鼠啃了很多口的起司。到底發生了什麼變化?為了省錢,公司開發了自己的紀錄系統,用「新不可靠」取代了「老忠實」。在原型系統與「老忠實」平行測試時,我是持保留意見,導致我是在一條生產線啟動前不到一分鐘,才斷開兩個系統間的連結。反正當時的我比較年輕,可以承受得了刺激。

無論如何該專案是有截止期限的,不管有沒有準備好,「老忠實」系統都得被移除;我預想該次調查可能損失50萬美元的產量,系統至少會順利運作一天以上的時間再掛點。而因為我有幾年都是使用以Unix為基礎之系統的板載處理器,具備Unix系統管理的基礎知識,於是設定了一個簡單程序監視運作。

果然,當我舒適地安頓下來,紀錄系統掛了;但是系統監視持續運作,我可以看到在紀錄系統上有單一個程序佔用處理器99%資源,所以我殺了它…我不記得是用溫柔還是粗暴的手段,不過奇怪的是,像我這樣的操作員居然可以用命令列存取系統,不需要管理權限就可以殺掉程序;安全性大概不是該系統設計時的考量因素之一。

接著紀錄系統又開始運作了!我記下我殺掉的那個程序的名字,是以x字母開頭,沒有看到資料顯示發生任何變化。我們順利完成了那個航程的資料採集,沒有再發生任何意外;但在下一個航程又發生同樣的事情,我再次殺掉那個吃資源的程序,並在換班的時候交接了我看到的細節以及如何暫時修復系統的過程。

第二天,我同事根據我的報告,發現有兩個即時資料顯示疊在一起。那個x開頭的程序是一個x-windows顯示(x-windows是該軟體使用的繪圖工具套件),因為某種理由,這會偶爾造成一種競爭條件讓系統掛點;這解釋了為何在我殺掉錯誤的顯示時沒有看到任何改變,因為它是隱藏在另外一個下面。我們忠實地往上呈報這個問題,岸上的支援團隊很快提供了一個軟體修補程式;我的維京人老闆很滿意。

回顧那段時間,上述事件可以說是我任職那家公司期間最大的一樁功勞,但我不敢專美於前,因為這是團隊合作的成果──我發現了第一個線索,我的同事們根據該線索繼續找到了解答。我也想不起來我們是不是有因為這件事受到公司總部表揚,當時我只是個菜鳥技師,連撰寫事故報告的資格都沒有哩!

編譯:Judith Cheng

(參考原文:Newer isn't always better when performance is critical ,by Matthew Oppenheim;本文作者目前仍從事海洋地震資料採集工作,在Polarcus擔任首席現場地球物理學家,此外他也是英國蘭卡斯特大學Lancaster University的InfoLab21研究中心榮譽研究員,其研究成果細節可以在seismicmatt.com查閱)