昨晚 TVB 選港姐，特設用手機一人一票形式作最後加分衝刺，並送出名車吸引用家參與。可惜事與願違，當晚系統掛掉被逼取消，官方解釋是人流過多。隨即觀眾作出不同的指控，例如 Microsoft Azure 伺服器太差、TVB 不願購買額外的雲端資源、黑箱作業做假、系統設計不當等等的傳言。我們 unwire.hk 訪問了兩位專家，嘗試由 IT 角度分析當中的指控是否合理。
IT 資深 Blogger – 亞當
“系統設計公司低估困難度”
亞當認為，做手機 APP 無論是前台或後台都要非常小心，尤其是流量大的 Case。他個人認為今次出事，有可能是幫 TVB 設計 APP 的公司低估了困難度，因為手機網絡的 App 跟一般使用 Wifi 或 BoardBand 的 Web 架構設計很不同，在家中上網，回應都是即時性的，但手機網絡有延遲 (Latency) 的問題，嚴重時伺服器可能要等幾秒才收到手機APP 所發出的指令，因此系統在「處理容錯」部份要設計得很好。
他指出要編寫一套高流量的手機投票系統是很因難，行內編寫一般的 Web 系統時，會執行一些壓力測試模擬多人使用的情況，以確保系統的穩定性，偏偏這些壓力測試是不能模擬手機網絡的環境，所以非要把系統搬到真實環境下去使用用才能真正測試到穩定性，風險較高。
事發後，網民紛紛找出在 Microsoft 的 Case Studies 中，看到 TVB 使用了 Microsoft 的 Windows Azure 雲端伺服器，聲稱每秒能處理 4,000 個投票。但事後TVB 解釋流量大令系統不勝負荷，令人間接聯想到是 Microsoft Azure 的問題。他指出行內人都知道根本不是 Microsoft 的問題，Windows Azure 的可靠度並沒有那麼差，而且他覺得在伺服器方面，應付 50 萬人及 100 萬人的伺服器資源不會有甚麼大區別，所以因 100 萬人同時投票令 Windows Azure Down 機實在很難令人相信
由於 Microsoft 是雲端伺服器的關係，資源可以因流量大小作出即時調整，有網民指控 TVB 因為 Budget 問題沒有即時增加 Compute Instances 才能系統處理不到。亞當卻認為是系統設計的問題居多，因為就算增加到二千台同時運算，系統設計有缺憾的話問題也會出現，全因樽頸並不在伺器服資源不夠，是中間的 API 阻塞，散不到大量 JOB 給後台紀錄。
亞當最後補充，一個好的系統必需要前台(APP)及後台(Server)一手一腳經由同一人設計，但在香港很難找到熟悉兩邊的人材，因此往往都是「各有各做」，最後合併作測試，才發現很多的問題。
手機及網頁程式開發商 IGPSD 負責人 Chris Chan
“伺服器沒有問題，是系統問題”
他指出現時高用量手機及網頁程式，大部分做法亦跟 TVB 一樣，背後用雲端服務去進行運算及擔當數據庫的角色。他估計昨日的「Down 機」事故有幾個可能性：
首先，他指出雲伺服器的其中一個優勢是可以隨時因應流量去加多減少伺服器資源。過程雖自動化。但如果太依賴自動調整功能，有機會因為監測功能出現 Delay 而趕不及加大資源。
另一可能性是網上程式碼不夠完善，因為要保證一人一票，所以程式每次都要先停止寫入，檢查數據庫沒有重覆資料才進行存取，這個過程或會因為太高流量令程式碼出錯。「尋晚網站出左 Error Code，即係個 Server 仲上到，係程式冇回應。」因此推斷是系統設計未夠完善，而不是伺服器能力不足。
EXTRA : 城巿傳聞 ……
只有兩個半月時間
有內行人透露，官方要求由 APP 設計到上架，只有兩個半月的時間，對於如此困難的投票系統根本是不可能的，大如 AWS 也放棄當初的合作，可想而知系統根本沒有足夠的時間作測試及設計，不過這個是傳聞而已。
