http://taiwan.cnet.com/enterprise/co...0115201,00.htm
杜奕鋒 2007/02/15
高鐵車售票系統的問題在網路上引發熱烈討論（例如：JavaWorld），其中又以批評多過讚美。其中最讓人詬病的是，高鐵竟出現一個位子被賣三次的事，讓排了一二個小時買到票的乘客氣得冒煙。
對我們這一些稍有經驗的工程黑手而言，真的是不太能接受，這也令我想到在學校教書教到設計或撰寫多人同時線上使用的系統的時候，常碰到一些即使耳提面命，沒經驗的學生還是會犯的錯。所以看到「高鐵車票連三買」的新聞時，第一個反應就是：「呵，這是一個很好的Case Study…」特別是對於學校的那一群學生們，他們總是喜歡用「一人使用系統的程式撰寫習慣」來撰寫「多人同時使用系統的程式」，高鐵的例子，剛好提醒他們這樣搞的下場。
就像任何IT專案一樣，要追究高鐵訂票系統的責任，也可以從三方面來追究：程式設計／開發人員、測試人員、以及專案經理。
系統設計人員與技術人員的責任？
首先，就資料庫層面而言，通常在做資料庫的規劃與分析的時候，對於某些形成「惟一值」的欄位，資料庫的schema 設計者就應該利用資料庫的機制(Unique Key)將之限制，這是從資料庫層面所做的保護機制，可以避免程式人員的疏失而造成資料混亂的現像。
以車票的劃位為例，理論上，每一天的同一班列車上相同的一個位子只會買一次，因此，「日期」加「車次」再加「位子」應該是那個惟一值，在高鐵售票系統的資料庫中，這樣一個組合就應該把資料庫中的Unique Key設起來。當然，高鐵售票系統中的表格情況會是更加複雜，但如果沒有找到一個規範，從資料庫的來進行資料的保護，就很容易造成目前這樣一位三賣的情況。
再來，就是程式開發的部份，寫過多人同時使用的系統都會知道，這樣的系統經常要去處理資源所有權的問題。以高鐵的座位為例，在座位還沒有賣出去的時候，這個座位是不隸屬任何人的。當有買家出現時，通常會先做系統做一次查詢的動作，把所有的未銷售的動作列出來，此時列表當下所有被列出來的車位應該都是沒有隸屬者的。不過由於列表與買家下單購買的時間是有時間差的，所以買家決定購買的同時，該車位有可能已經被其家的買家買走了。
所以程式人員在設計或撰寫這段程式的時候，理論上，程式行為應該在買家下單的同時先立即檢查該車位的是否已經被賣走了，如果沒有被買走，程式才可以下單；如果已經被買走了，程式就應該反應給買家一個錯誤訊息：「對不起，所選擇的座位已經在您猶豫不決、拖拖拉拉的過程中被買走了…」。
因此，高鐵車票會一個位子賣到三次，如果猜測沒有錯的話，問題應該是就出在最後買家下單的那一支程式上面，當買家下單時，那隻程式並沒有去檢查（或檢查的邏輯有問題）車位是不是已經被賣走了。所以在購買人潮多的時候，同一個時間點，有多個人進行車位的列表（列表的時候，反正那一個位子還沒有被買走，所以都統統列出來了），後來這些人又選買了同一個位子（加上這個程式在下單的時候沒有去檢查），所以這些人就在高鐵售票系統的搓和下，修得了百年才有機會同位的因緣。
當然售票系統是有可能還有其它的問題。不過如果上述兩個問題在系統設計與開發的時候有注意到，理論上，不論採用什麼架構、技術或介面（Web、人工售票機、自動售票機…），甚至銷售作業流程被改變了，一個座位被買了三次以上的情況應不致發生，因為不論是那個購買者透過任何的UI介面來下單，檢查位子是否有已經被賣出的程式都會是最後防線。
當然還有一種情況，就是在資訊流程上，下單的資料還沒有透過這支檢查的程式塞到資料庫中時，系統就已經把票列印給客戶。但是這種情況不太常見，因為如果這樣子設計，已經列印給客戶的車票是有可能發生沒有被塞到資料庫內的情形。如此，最慘的情況就是高鐵系統售票系統的帳務資料可能會有問題。
高鐵車位連三賣的問題，第一個要去面對責任的就是這一些資料庫系統、系統設計、以及程式撰寫等技術人員。
修改範本不適合？
有小道消息指出，售票系統是機票系統改的。我並不太確這樣這的消息來源是否正確，不過，基本上我對這點抱持質疑，因為兩者商業行為的作業流程是大不相同的。首先，一班飛機的座位有限，也不像高鐵可能會有站票的情況產生，再加上購票的流程中，機票並不是在購買的當下就將座位劃位給旅客，而是在登機的時候才進行劃位。因此在銷售機票過程中，系統只需要掌握所銷售的機票數量不要超過有限座位的數量即可（而且據我所知，大部份的飛機在機票銷售的時候都還是會預留一些座位，以便不時之需）。同時，由於登機櫃檯人員並不會太多，因此負責同一班機劃位的人員作業上較容易協商（幾個劃位櫃台橋一下就好了），比較不容易有重複劃位的情況產生，即使真的重複劃了位，由於旅客的總量是不可能多於座位的數量，所以比較容易立即幫旅客找到座位。
高鐵的情況不同，高鐵的載客量大（每台波音七四七的載量也大概才400個人），售票的方式也比較多元，例如自動售票機（呵，我們大概不可能買機票還用自動售票機買票吧？），並且停駛的車站也多（大概很難找到一架飛機在飛往目的地的途中有六個停駛站的，更不用說，這一些站都會有乘客上下），所以如果高鐵的售票系統是採用機票的售票系統來改的，那這一個售票系統勢必會需要做大幅度—而且很大--調整、重新分析，並逐一改寫。寫過程式的人，或多或少都會知道，與其要Programer改別人寫的程式，說不定自己重寫一個還比較快。
當然，還是有可能有一些因素（商業、政冶因素……）造成這個售票系統是用飛機的售票系統來改的，但即使是這個樣子，在修改系統範本的過程中，稍有經驗的系統分析師或程式撰寫者應該都很容易發現這些系統需求上的差異。重新分析需求、修改架構，適時地給客戶建議，並調整系統到可用，避免這種一位賣到三次的情況。(請繼續閱讀下一頁)