客委會旅遊券 遇急變則大亂

這幾天客委會提供旅遊券登記和發送一事,網路服務時好時壞,網路服務的使用者旅程 (user journey) 也再三更佚(站點一站點二站點三),堪為台灣政府在疫情後數位發展的經典案例之一。

此案有幾個特徵,造成在服務規劃、系統分析、程式開發、專案執行、客服除錯、公眾溝通等面向非常難以「順全緩平」:

  • 急:準備時間少,可能低於一般作業時程,前後起心動念,我估算差不多一個月到一個半月(更正:接近三個月)。這時間期程對客委會而言已是急如星火。
  • 變:在三天之內,服務的提供型態一再變更,國民也必須從「紛亂」的各種媒體管道得知不完整的服務訊息。
  • 大:客委會的服務對象並不是一般國民,主要所服務的客家族群也不若本次對所有國民開放登記。為這個數量級國民提供網路即時服務,本來就是客委會沒有經驗的領域。從選擇 LINE 平台竟然由單位自陳沒有想到峰值人潮的估算背景知識,更證實了很多在數位時代不堪的決策品質。
  • 亂:這是此案的上述條件因素在執行後三天給國民的體驗。

縱整一句就是:遇急變則大亂

為什麼客委會所提供的網路服務會淪落至此?我想還是有兩個長期未解的難題:

  1. 政務官體系缺乏基本的相關背景知識:期待政務官在各領域都有專業專才是不切實際的期許,但有些屬於基線 (baseline) 的背景知識是有必要知道的。例如服務在短時間內會湧入多少人,所以我們要如何估算、預留多少的運算資源等。這些運算資源是否符合採購程序?如果採購程序不允許,如何控制在可負擔的成本之內?如果服務藉由它方的資訊系統來支持必要的服務流程(本案為 LINE),那麼在對公眾宣傳大量發放旅遊券之前,是否在系統介接和責任歸屬等合作條件上已經談妥,甚至有基本服務限制的認識?網路服務「人潮」湧入的估算方式和實體服務據點的差異頗大。我們這次看到客委會單方表示由於 LINE 基於系統安全,在短時間內若有「超過1700個帳戶加入」,則會自動啟動防護的措施。這在任何超大型資訊系統都是屬於正規的做法,客委會難道在討論階段沒有這樣的警覺?峰值同時湧入「20萬人」和「1700人」的差距是超過一百倍。一個數值的估算如果超過一百倍,那已經不是單純的錯誤,而是根本不知道該怎麼估算的後果。
  2. 單位本身缺乏能判斷風險的幕僚和作業文化:在數位時代,自己的單位不用甚麼都做,但至少要有足夠的幕僚人力在決策過程扮演關鍵的角色。目前台灣政府各部會的主官(如部長、主委等)和副主官(如政次),多半和數位世界離的很遠,因此主官本身必然要有培養相關幕僚的決心和體悟。但「網路資訊服務」的提供又不是「善用社群媒體」等時下興盛的潮流族群能有所貢獻,傳統單位內的 IT 幕僚在處理 “web scale” 的經驗也多半不足(原因不一而足)。客委會推出「旅遊券」的服務流程若內部會議有幕僚,很多問題並不是這麼難遇見和預留解決的路徑(技術、合作、採購等)。總不能每次都要外部派「消防隊」來支援,這畢竟是自己單位的事。

時間都2020年了,很多人最不樂意見到的就是每次「網站卡卡」,問題的根源就歸咎於「駭客入侵」「流量太大」,解決的手法就是「加大頻寬」「增加機器」。 從規劃、分析端就預留了各種出包的風險,更遑論更精細的指揮調度 (command & control) 檢討與優化。這些疫後的案例,很誠實的暴露出台灣政府在提供數位服務大致是什麼樣的光景,而這些「遇急變則大亂」的癥結點又是在哪裡。

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.