Recca Chao 的 gitHub page

推廣網站開發,包含 Laravel 和 Kotlin 後端撰寫、自動化測試、讀書心得等。Taiwan Kotlin User Group 管理員。

View on GitHub

購票事件

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

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

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

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

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

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

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

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

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

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

(文章存檔 2015-01-21)