壯闊台灣 iCanHelp 災情回報系統
類似的系統大約在網路普及之後就有人陸續提出，在不同的國家也有人基於自願者協作，或是由媒合團體介接相關資服業者和志願者。我們就來看看這樣系統的優勢和劣勢在哪裡。
首先是類似的系統我們在八八風災曾經大規模試行過，當時也在消防署的災害應變中心內部用外掛的方式派上用場。到了2012年之後，NCDR 的相關計畫也陸續上線，經過十幾年來的佈署，我相信也有很多經驗的累積。
什麼樣的災情需要回報？
光這件事情就是大災問。目前和2009年八八風災不同的是，大部分的災防里鄰系統都是用 LINE 在回報，回報後再根據現場資害應變中心開設的狀況，決定哪些要進入不同的資訊系統「列管」「列為追蹤」。這件事連每年的國家防災日演習都是這樣做的。（以上流程有所簡化）
八八風災的時候沒有這種工具，而且政府端在「資訊公關」和公共需要的災情資訊幅散部分剛好遇到一個交叉點。現在的政府資訊公關體系手法多也比以前精熟，所以當時那一套到處爬資訊，交由專業的編輯人員來核實，進一步與公部門的資訊作比對，再決定是否要進入搶救系統，這整串現在不需要這樣做。
外商當時對於這些政府資訊也掌握度比較低，因此例如 Google、微軟等，因為本地沒有這方面的業務和產品線，所以只能接我們餵給他們的資料源。
但如今壯闊台灣推出 iCanHelp，有些挑戰一樣在15年後還是要克服的。
一則回報的資訊有生命週期
資訊是有時效性的，例如在地震場景下，回報的範疇是道路通阻、道路淹水，還是人員受困淹水區。針對這三種資訊所要做出的應變時間是不同的，意思就是一則回報訊息進來系統的當下，你要有人能核實，接下來要能判斷下一段要送給什麼單位，這些單位收不收訊息，會不會分配資源處理。這整串的資訊鏈比想像中的冗長很多，所以什麼樣的訊息進來是這個平台能處理的，這點我們目前還看不出來。
演訓是一回事，真實派上用場是另外一回事。一個 issue 進來要 track，issue 可能還要跟其他 issue 做 merge 然後派公給誰去做 resolve。這些在軟工的領域很簡單，但在災難發生時就不是那麼回事。在災害發生的時候還要應付很多時效過的資訊在網路上流傳，這些若進到回報系統，要很多人工去排除。
整個資訊系統的 locality
我們可以看到新聞稿說資料都放在台灣的機房，問題是一個網路服務的各個 stack 可能會是在境外。在比較極端的狀況之下，資料在本地但路由還是要跑到境外，那整個服務就很難使用。這點或許壯闊台灣和微軟台灣的團隊還沒有要想處理這問題。
誰會用這個系統？
以我的經驗觀察，這就是壯闊台灣自己的志工系統。消防、警政、災防都有成年的習慣和作業的慣性（或是 protocoll）。我沒有說現在的方式比較好，但 iCanHelp 的效用有待發掘實證。目前已經 embed 到災害管理作業的各種作法非常龐雜，要改變會需要很大的誘因。iCanHelp 這系統可能很 light 很 agile，但目前面對民眾的災害顯示和回報系統，其實並不在少數。
一個比較有規模的組織和志工網絡確實需要這樣的系統，所以若這個是給壯闊台灣自己用的，這件事是高度值得推進的。若是其他小型但專精的團體要使用，我認為在災害現場搶救的 feasibility 會有不少人力上的需求才能達成。
微軟台灣的角色
在烏克蘭戰爭發生之前（你沒聽錯），微軟烏克蘭的人就開始 relocate 到周圍國家。微軟是美商，其內部針對區域衝突的 contingency 和 continuity plan 是有的。但台灣有沒有就不得而知，因此，若他們作為提供這種 backbone 服務的 sponsor 業者，其人員被允許在災難時能支援多少大大小小的資訊系統問題，這件事也是儘早得知會比較好。