為何9/22臺北市熊好券無法登記？ 台北市政府還原當時情況，說明應變做法

臺北市政府配合政府振興方案推出熊好券，9月22日開放民眾登記，吸引民眾大量登錄，卻出現系統異常，導致民眾無法登入台北通，也無法登記熊好券，系統異常長達6小時，直到晚間6點之後才逐漸恢復正常，臺北市政府資訊局近期檢討並公布原因，包括未做好整合性壓力測試，以及熊好券與台北通採單一服務驗證，短時間內系統高度交互作用下，導致高負載效能失衡。

臺北市長柯文哲在9月22日上午召開記者會，正式宣布臺北市加碼振興方案熊好券開放登記，吸引大批民眾湧入登記，由於熊好券登記，需透過台北通線上登記，從中午開始系統慢慢出現異常，不少人無法登入台北通，連帶無法登記熊好券，市府遭受不小的批評，資訊局緊急成立應變小組，系統異常直到當天下午6點才慢慢恢復正常。

市府也在10月4日召開專家學者會議，探討原因及改善之道，經過盤點所有問題點後，本周四臺北市資訊局公布檢討報告。

北市資訊局長呂新科表示，當天早上公布熊好券系統上線，上午皆維持正常，但在中午開始出現系統服務回應緩慢的異常狀態，主要是系統資源負載使得效能失衡，隨即啟動改善工程，下午6點漸漸恢復正常，針對這次事件也會檢討SOP流程，避免相同事件再發生。

熊好券是在台北通既有的身分認證基礎上推出，而台北通的系統架構源於過去的台北卡系統。臺北市政府是在2014年推出多卡合一的台北卡，後續因應實體卡走向虛擬卡的趨勢，2016年推出了台北卡App，去年10月再進一步推出台北通App，以實現卡證整合及市政服務，的台北通App去年10月推出至今，歷經北市防疫實聯，更在今年9月振興券帶動下，台北通App會員數已增至162萬。

配合政府在疫情下振興經濟政策，北市今年8月開始規劃熊好券，先進行局處及商家的需求訪談，以及局處、商家與銀行的清分設計，並進行系統規畫與設計，其中包括系統架構與上線評估，9月進入系統開發、測試與上線，在上線前進行壓力測試。根據資訊局的說明，熊好券系統在上線前通過壓力測試，78分鐘可完成490萬組交易，每組包含2個transactions，等於0.24秒完成一組交易。

但是在9月22日還是發生問題，問題點在哪？

但是，既然熊好券經過完整的需求訪談、規畫評估、測試上線，也通過壓力測試，為何還會發生問題？

呂新科表示，熊好券嫁接在台北通的認證基礎上，台北通系統承襲自台北卡3.0架構，因此台北通與熊好券系統間交互較為繁複，包括身分驗證、資料交換在內共有6道程序。

呂新科指出，熊好券和台北通之間，身分核實、資料交換的架構，這導致一個簡單的呼叫，系統間就有6個交互確認的過程，負載急速放大的結果。當9月22日因高流量導致系統負載失衡時，系統還是有緩慢的登記成功，但系統回應緩慢，許多民眾無法登記完成，出現系統回應異常的情形。從系統的CPU負載及成功交易量等監控數據來看，熊好券主機因等待台北通主機，因台北通高度負載，影響到熊好券主機的交易完成。

資訊局補充說明，資料庫CPU快速滿載，64核心CPU滿載，而從監控平臺來看每個API指標，台北通串接熊好券系統，大量等待服務呼叫、延時、中斷、阻塞的情形。

從監控數據來看，熊好券與台北通的系統交互程序，在系統異常的6小時，台北通與熊好券的主機CPU使用率提高，但台北通登入成功次數減少，熊好券的交易數也降低：

資訊局成立的應變小組，發現台北通與熊好券系統間的交互程序過於繁複，因此採取應變措施。首先，在台北通上，如果不涉及敏感資料的交換，可簡化資料驗證的程序，因此他們採取分級分流，依不同的應用系統分為三級，根據不同的分級設計差異化的驗證程序，立即改寫程式，熊好券被分為B級，只做身分查核，將程序從6個簡化為4個。

資訊局解釋，原本，熊好券與台北通的設計是，透過token交換取得授權，再由系統產生一組有時效的亂數token給其他系統，其他系統透過這個token與台北通會員中心取得該使用者的個人識別UUID或其他資料。分級分流制度下，分為ABC三級，熊好券被畫為B級，台北通App直接將個人UUID提供給熊好券系統，讓熊好券以UUID紀錄個人的登記意願，將6步驟簡化為4個。

其次，他們也將資料庫系統進行分割，分為即時與非即時兩個區塊，原本集中式的資料庫作區分，將前端、中端系統存取資料庫路徑分散，降低資源產生瓶頸的風險。

資訊局表示，新的應變措施上線後，效能恢復正常，每分鐘可處理數百筆登記，到10月14為止，熊好券登記已達466萬分，未來將抽出113萬派送至民眾手中。

資訊團隊事後檢討這次事件發生的原因。歸納幾個因素，其中一個情境因素是，因台北通會員增加，原本計畫採購設備擴充系統，但在全球晶片短缺下，設備尚未到貨。潛在因素則是，台北通、熊好券雖各自有進行壓力測試，卻沒有做整合性壓力測試，因此未能及早發現問題。台北通單一且繁複的身分驗證、資料交換程序，沒有依應用需求作分級分流，導致頻繁的系統交互程序造成高負載。

北市資訊局事後檢討，針對全球晶片短缺，調整採購策略，未來採購先詢問廠商現貨或符合規格的設備，同時針對這次沒有進行整合性壓力測試、集中式資料庫與交互頻繁，納入驗收及上線階段SOP考量。未來對於大型活動也會採取分流制度，例如依身分證單、雙號分流。