利用資訊視覺化動員全民防疫:政府可引入「每日新增案例曲線圖」強化溝通

利用資訊視覺化動員全民防疫:政府可引入「每日新增案例曲線圖」強化溝通
Photo Credit: 中央社

我們想讓你知道的是

在「有或沒有社區感染」的爭吵中,若能以資訊視覺化提供共同、可信賴的事實基礎,同步全民對疫情發展的理解,台灣社會對防疫政策的討論或許能跳脫「順時鐘 vs. 逆時鐘」這種政治性二分法。

文:梁志鳴(台北醫學大學醫療暨生物科技法律研究所副教授)

筆者在日前的投書中提到,隨著COVID-19(2019年新型冠狀病毒疾病,以下簡稱武漢肺炎)正式成為歷史教科書級別的傳染病大流行,我國政府應該超前部署,預先思考如何對全國民眾進行「防疫破口如果產生時全民應該如何因應」的心理動員。

但這樣的心理動員如何執行呢?最直接、速效的方式,是在指揮中心的記者會以外,由在防疫上具有公信力的專家(例如陳建仁副總統),密集上平面、電視、網路、甚至社群媒體宣導相關防疫觀念。

不過,不管是記者會或密集媒體曝光,全民防疫的心理動員要能奏效,關鍵還是在政府傳遞的疫情訊息和行動指引必須清楚明確。否則溝通的再多,都很容易重蹈清明連假民眾到底該不該出門的亂局。

而追根究底,清明連假的進退失據,相當程度反映指揮中心及各級政府這段時間在「防疫」與「保持日常生活」兩個戰略目標間擺盪的困局。而這一場混亂,又進一步加深民眾自從3月中海歸潮造成確診數大增以來持續累積的焦慮感。許多民眾都想更清楚地知道「我們現在疫情到底發展到哪裡」、「我們具體又應該如何配合防疫」。

筆者認為,防疫到了現下的時間點,已逐漸脫離正規軍(指揮中心)決戰的階段,而逐漸走入全民心理動員的總體戰,此時領導者能否給出清晰、可有效依從的號令,將會實質影響這場戰爭後半段的勝敗。而要能夠在未來不再給出矛盾的防疫訊息,政府整體除了必須在「防疫」與「保持日常生活」兩個戰略目標間做出明確的優先排序外,防疫資訊的視覺化,也可能會是另外一個可能有助全民心理動員的工具。

防疫資訊的視覺化,在現實上存在無限種可能,但受限於篇幅,筆者在本文預計僅討論其中一種可能性,亦即每日新增案例曲線圖的使用。而筆者之所以認為此一曲線的擴大視覺化應用將有助政府與人民的風險溝通,其實又是基於一個非常簡單的理由,那就是相當比例的防疫決策,其實都是圍繞著此一曲線而做成。

例如大家熟知的「Flattening the curve」圖示,其實就是將此一曲線結合醫療體系量能,來呈現不積極防疫可能產生的醫療崩潰結果。

而一旦大流行不可避免,政府進一步需要透過對曲線的可能高峰進行模型估算,以得知醫療體系或甚至社會整體需要進行怎麼樣的動員,來緩和(flatten)此一曲線或提升醫療體系的量能(raise the capacity)。

  • 紐約州長古莫3/25防疫記者會〔0:00~16:45〕,說明紐約州如何利用模型推估曲線高峰時的醫療需求,並據此加以部署

而在一般情況下,每日新增案例曲線進一步又有兩項特性。

首先,因為疾病有潛伏期,因此此一曲線通常並不反映當下的疫情,而是反映上一個或兩個傳染週期前的疫情;其次,若外力不介入或介入失敗,疫情會先經過幾個傳染週期的緩步成長,之後才突然拉高斜率,進入不可逆轉的指數成長(exponential growth)。

每日新增案例曲線的上述特數,有助我們瞭解為什麼超前部署、「stay ahead of the curve」是防疫的重中之重,這是因為當下的曲線發展,永遠反映過去而不是今日的疫情,因此若僅針對今日的曲線來制訂防疫政策,很容易就會出現台大公衛詹長權教授所說追著疫情跑、「stay behind the curve」的狀況。

而若疫情進入指數成長,減災(mitigation)就會成為唯一選項。而由於武漢肺炎歷史級別的傳染力與死亡率,一旦進入減災,往往就不可避免需要採取各種會造成社會大規模停滯的強制措施(只有南韓暫時成為例外)。因此,防疫前期(即台灣)的主要戰略目標,就在於竭力(甚至過度防疫)以避免疫情進入指數發展的爆炸階段。

民眾停等紅綠燈  保持社交距離
Photo Credit: 中央社

防疫政策與每日新增案例曲線之間緊密不可分割的連結,於是使得此一曲線成為與民眾溝通十分具潛力的視覺工具。

目前指揮中心的溝通方式是以文字型態的新聞稿為主,輔以指揮中心人員的口頭說明。這種溝通方式的自然結果,就是說明與媒體提問很容易聚焦在新聞稿中對個案染疫前後過程細節的釐清與確認,但對於民眾普遍最關心的「我們現在疫情到底發展到哪裡」,「我們又應該如何配合防疫」等問題,則無法快速傳達簡潔明確的訊息。

此時試想,若指揮中心改變以文字為主的溝通方式,而在每日記者會開場的疫情簡報,使用每日新增案例曲線作為說明媒介,向民眾報告「加入今日新增案例後,我國疫情成長的曲線為何」、「依據現況評估,對未來一週內曲線變化可能範圍的預測」、以及「政府與民眾面對不同疫情可能發展,已經或需要採取的因應措施」等等事項,這樣的溝通方式,將很快有助民眾理解以下的重要資訊:

  • 疫情目前發展到哪裡(Where are we)?
  • 疫情接下來發展的可能趨勢為何(What is the trend)?
  • 疫情若進入下一階段會先有哪些跡象(What should we watch)?
  • 疫情從出現跡象到進入下一階段中間有多少時間(How long do we have)?
  • 疫情如果進入下一階段最壞的可能性為何(How bad can it be)?
  • 為避免疫情進入下一階段,政府做了哪些準備(How are we preparing)?
  • 疫情若進入下一階段,政府民間應如何因應(How we should respond)?

筆者認為,相較個案間的相互關係,指揮中心若能將溝通重點,轉向傳遞上述對人民具體安排日常生活來說極為重要的核心資訊,將直接有助全體國民的防疫心理動員。

  • 視覺化簡報的範例,可參考紐約州長古莫防疫記者會

溝通重點的上述轉向,進一步有助指揮中心跳脫「零星社區感染 vs. 社區傳播」的詞彙爭議泥淖。事實上,若放在每日新增案例曲線的脈絡下來看,指揮中心對「零星社區感染」的定調其實一直都是相當一貫且符合專業的,也就是認為「已有零星個案滲入社區,但離曲線進入指數爆發成長仍有距離,重點在現階段全力防堵」。但這樣的專業判斷若缺乏適當溝通媒介,將很難讓一般民眾理解,甚至成為爭議的來源。


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡