這幾天客委會提供旅遊券登記和發送一事，網路服務時好時壞，網路服務的使用者旅程 (user journey) 也再三更佚（站點一、站點二、站點三），堪為台灣政府在疫情後數位發展的經典案例之一。
此案有幾個特徵，造成在服務規劃、系統分析、程式開發、專案執行、客服除錯、公眾溝通等面向非常難以「順全緩平」：
- 急：準備時間少，可能低於一般作業時程，前後起心動念，我估算差不多一個月到一個半月（更正：接近三個月）。這時間期程對客委會而言已是急如星火。
- 變：在三天之內，服務的提供型態一再變更，國民也必須從「紛亂」的各種媒體管道得知不完整的服務訊息。
- 大：客委會的服務對象並不是一般國民，主要所服務的客家族群也不若本次對所有國民開放登記。為這個數量級國民提供網路即時服務，本來就是客委會沒有經驗的領域。從選擇 LINE 平台竟然由單位自陳沒有想到峰值人潮的估算背景知識，更證實了很多在數位時代不堪的決策品質。
- 亂：這是此案的上述條件因素在執行後三天給國民的體驗。
縱整一句就是：遇急變則大亂。
為什麼客委會所提供的網路服務會淪落至此？我想還是有兩個長期未解的難題：
- 政務官體系缺乏基本的相關背景知識：期待政務官在各領域都有專業專才是不切實際的期許，但有些屬於基線 (baseline) 的背景知識是有必要知道的。例如服務在短時間內會湧入多少人，所以我們要如何估算、預留多少的運算資源等。這些運算資源是否符合採購程序？如果採購程序不允許，如何控制在可負擔的成本之內？如果服務藉由它方的資訊系統來支持必要的服務流程（本案為 LINE），那麼在對公眾宣傳大量發放旅遊券之前，是否在系統介接和責任歸屬等合作條件上已經談妥，甚至有基本服務限制的認識？網路服務「人潮」湧入的估算方式和實體服務據點的差異頗大。我們這次看到客委會單方表示由於 LINE 基於系統安全，在短時間內若有「超過1700個帳戶加入」，則會自動啟動防護的措施。這在任何超大型資訊系統都是屬於正規的做法，客委會難道在討論階段沒有這樣的警覺？峰值同時湧入「20萬人」和「1700人」的差距是超過一百倍。一個數值的估算如果超過一百倍，那已經不是單純的錯誤，而是根本不知道該怎麼估算的後果。
- 單位本身缺乏能判斷風險的幕僚和作業文化：在數位時代，自己的單位不用甚麼都做，但至少要有足夠的幕僚人力在決策過程扮演關鍵的角色。目前台灣政府各部會的主官（如部長、主委等）和副主官（如政次），多半和數位世界離的很遠，因此主官本身必然要有培養相關幕僚的決心和體悟。但「網路資訊服務」的提供又不是「善用社群媒體」等時下興盛的潮流族群能有所貢獻，傳統單位內的 IT 幕僚在處理 “web scale” 的經驗也多半不足（原因不一而足）。客委會推出「旅遊券」的服務流程若內部會議有幕僚，很多問題並不是這麼難遇見和預留解決的路徑（技術、合作、採購等）。總不能每次都要外部派「消防隊」來支援，這畢竟是自己單位的事。
時間都2020年了，很多人最不樂意見到的就是每次「網站卡卡」，問題的根源就歸咎於「駭客入侵」「流量太大」，解決的手法就是「加大頻寬」「增加機器」。 從規劃、分析端就預留了各種出包的風險，更遑論更精細的指揮調度 (command & control) 檢討與優化。這些疫後的案例，很誠實的暴露出台灣政府在提供數位服務大致是什麼樣的光景，而這些「遇急變則大亂」的癥結點又是在哪裡。
T.H. Schee 