为何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考量。未来对于大型活动也会采取分流制度，例如依身份证单、双号分流。