臺北市資訊局長呂新科親自開記者會,說明9月22日當天熊好券登記系統異常長達6小時的原因。

圖片來源: 

臺北市政府資訊局

臺北市政府配合政府振興方案推出熊好券,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考量。未來對於大型活動也會採取分流制度,例如依身分證單、雙號分流。


熱門新聞

Advertisement