近日，香港考評局的「監考易」及「報到易」系統發生大規模故障，引起社會關注。儘管任何系統都可能出現問題，但此次事件涉及900萬公帑，且有充裕的資源與時間準備，卻仍不堪一擊，實在令人費解。
本公司雖未參與該系統開發，但基於豐富的大流量系統開發及第三方壓力測試經驗，我們認為此次故障很可能源於壓力測試不足。壓力測試的目的是找出系統瓶頸，並在無法達到預期流量時，及早採取應對措施，如虛擬排隊系統等，以控制用戶體驗，避免問題擴大。
「監考易」及「報到易」的流量完全可預測，壓力測試指標亦易於制定。若指標設定正確且通過測試，本不應出現如此大規模的故障。因此，我們推測可能是測試指標過低，或未充分模擬實際使用情境。
此外，從公開資料可見，系統錯誤訊息竟將資料庫請求代碼顯示於用戶端。這引發了我們的疑問：用戶端是否直接連接資料庫？若是如此，資料庫可能需同時連接上萬用戶端，極易超載，並可能存在安全隱患。若非直接連接，則後台將此訊息返回用戶端亦屬異常，為何要將用戶無法理解的資料顯示出來？是否開發時的除錯代碼未妥善處理？
由於並非系統開發商，我們無法確切得知瓶頸所在，亦難以提出精準的解決方案。但若由我司設計此系統，我們會提出以下建議：
1 避免單點故障： 將系統設計為多個後台，每個考試試場或數個市場指派到特定後台，避免全港考生及監考員集中於同一後台，降低全港性故障風險。必要時，可透過後台批次作業或異步處理方式，減輕中央系統壓力。
2 減少用戶端請求： 減少用戶端與後台的互動次數，可降低後台壓力及故障機率。例如，將用戶端設計為可獨立或離線運作，僅在必要時與後台溝通；或僅少數用戶端需連接系統。事實上，「安心出行」已採用類似方式，市民端無需時刻連線，僅更新資料或餐廳端需即時連線檢查。
⠀此次事件中，虛擬排隊系統雖未必能完全解決問題，但我們擁有豐富的大流量系統開發經驗，即使無法參與系統設計，也願在壓力測試方面提供協助，為政府和市民帶來更滿意的體驗。