購票案件

最近台灣為了購票事件搞得烏煙瘴氣…真是逗趣，台灣人真是蠻無聊的。

個人覺得更有趣的事情是，很多程式人嘗試用程式設計的角度去剖析，像是lock怎麼設計阿，難度多高阿等等。坦白說，根本不是重點阿。

首先，換個一般人沒有想到的角度，如果今天我們是公關公司的身份，我們會怎麼處理購票系統？

第一次，當然是包案子出去做，花些時間開開會，找找外包，一般網頁開發大約數萬到數十萬不等。這邊其實沒什麼故事可說。

但是，今天一個網頁程式開發好了，演唱會結束了，下一個演唱會的購票系統，難道要重新外包開發嗎？顯然是不可能的，就跟實際上不可能每次演唱會結束，公關公司就把音響砸掉，每位歌手使用的都是全新的音響，這件事情是一樣的。

既然網頁確定會重複使用，根據公司對於技術的知識，就會分出幾種不同的包案方式。技術比較強一點的，可能會要求在哪樣的環境之下，主機可以動態開關（Amazon 的服務就包含此項目，不過我沒有實際執行過），依據系統負擔的參數。比較弱一點的公司，只要知道load balance的概念，可以先預估人數的多寡，最差狀況，即便是完全沒有技術概念，系統一次寫死的公司，只要掌握系統能支撐的人數上限，以及對於人數的預估，你還是可以使用分批購票的方法（先賣搖滾區的500張票，再賣中間的500張票…等等）。

結論就是，無論你有沒有技術的背景，只要你預估的人數不出大錯，基本上網頁是不會有嚴重的當機問題的。這次事件的原因就是，對進來購票的人數預估出現很大的偏差，所以系統無法服務這麼多的人，就是這樣而已。

或許有人會說，只要技術夠強，你不需要預估人數什麼的，只需要直接寫一個動態針對人數開關主機的網頁，這件事情不就結束了嗎？

如果這麼想，那可能忘記一件事情，任何包案都是要優先考慮需求的。如果今天連人數預估都丟不出來的話，那麼光是包案的價格都無法確定。枉論開發出來的網頁應該有什麼功能。除非公關公司使用動態針對人數開關主機的訂票系統，有著夠高的需求，不然這個案子只會在程式人的想像之中成立。

今天許多人無法買到票，公關公司當然有責任，但是很多人以為是技術問題，或者又是過度節省成本的問題，其實都不大正確。真正的核心，其實只是一個單純的人數估計問題而已。