把「逆時中」當成預警危機的金絲雀,而非唱衰台灣的烏鴉嘴

把「逆時中」當成預警危機的金絲雀,而非唱衰台灣的烏鴉嘴
Photo Credit: 多維TW

我們想讓你知道的是

儘管要戰勝病毒,人們有賴於政府的領導,以團結社會力量共同抗疫,但這絕非等同領導者或政府,就此便獲得免於監督、糾錯的「免疫力」,集體抗疫的內涵也不該輕率被簡化為「順時中」或「聽政府的就對了」。

文:陳炯廷

面對全球新冠肺炎疫情肆虐,台灣迄今交出亮眼的抗疫成績單,這也讓防疫期間高度曝光、主持防疫大局的流行疫情中心指揮官陳時中人氣和聲望與日倶增。起初柯文哲那帶有嘲諷的一句「現在都要順時中,不要逆時中」,轉眼已成為朝野之間的共識,也佔據民意和輿論主流的意向,甚至形成某種不容被輕易冒犯的言論界線:一旦發言「逆時中」,或對政府的防疫決策有所質疑或異議,就會淪為眾矢之的。假如社會不能對「逆時中者亡」的輿論氣氛加以省思,恐怕會讓社會失去監督的力量,錯失某些警示性的哨音。

當風向開始「順時中」

在新冠肺炎疫情擴及台灣之前,民眾恐怕並不清楚掌管醫療、社福、公衛、食安等重大民生事務的衛福部長是誰?但疫情以來,民眾也許仍搞不清楚衛福部的職能有哪些,但恐怕已無人不識陳時中。

自農曆新年迄今這三個多月來,由防疫指揮官陳時中每日親自主持的疫情記者會,不但成為台灣最受注目的「直播節目」,不但被解讀為台灣抗疫成功的原因之一,也是以陳時中為首的防疫團隊贏得民心的重要媒介。

「當災難時期,社會越是混亂,公眾越是想透過媒體,了解發生什麼事」,中正大學傳播系副教授管中祥向本刊表示,由政府主動說明疫情、澄清或釐清謠言,有助降低人們對疫情的恐慌。而陳時中在這段時間的媒體曝光,加上整體台灣的抗疫表現,無疑已讓他成為扮演穩定民心的代表性人物。

管中祥認為,即便陳時中不願意成為那個被「造神」的對象,但外界還是會把所有目光放在他身上。這不見得是官方有意為之的結果,可能是某些人的人格特質或能力,自然容易被凸顯。但當防疫的焦點過於集中在個人身上時,值得社會和官方有所反思的是,我們是否忽視了整個集體的運作和努力,例如那些在公務體系中一個個默默的無名英雄。

有關「順時中」的社會氣氛是如何形成,管中祥認為,這是社會處於緊急、危難狀態下,很容易發生的事情。因為防疫是個集體抗疫的過程,需要人民與政府間的互信配合。當政府防疫表現好的時候,人們會產生對政府的信任及認同。在這種情況下,若有「逆時中」的異議或質疑出現,人們就會以為這是在否定他們對政府的信任感。

3度連6天零確診 陳時中:全民防疫很努力
Photo Credit: 中央社

「防疫做得好,相信他不是天經地義的嗎?」管中祥表示,民眾的信任也不是沒來由的。他指出,在這份信任與支持的背後,也存在某種選舉的心態,既然「這個人做得好,我就支持他,沒有什麼不對的?」從這個角度來看,不能說民眾都是盲目的支持。然而,「對政府的效忠或過度信任,長遠來看,當然不是件好事」,管中祥強調,身為傳媒和公民,仍是必須對執政者保持某種批判性的距離,不能只是期待政府的防疫不會出問題。

此外,管中祥認為,媒體和民眾習慣用個人,而非集體的角度來看待事情的發展,也造就了「順時中」社會氣氛。從敘事的角度而言,相較於個人,集體的故事確實比較難寫。這是不論台灣媒體或國外媒體都有的通病。例如在探討台灣防疫成績時,美國有線電視新聞網(CNN)和《富比士》雜誌聚焦於蔡英文,日本《每日新聞》則是陳時中。這些外媒對台灣防疫成績的報導,更進一步會讓人們對台灣官員防疫表現的好感,產生某種加乘效果。

「逆時中」就沒有發言權?

管中祥坦言,在「順時中」的社會氣氛下,對於異議空間的限縮,不僅會發生在疫情記者會的媒體發言上,可能會讓有的記者,因此不太敢問某些「逆時中」問題,類似的情況,也存在於其他領域。他舉例,立法院在審查「紓困條例預算」時,國民黨一開始提出「凍結」80%的預算提案,就引發非常大的反彈,最後也讓國民黨不再堅持凍結。

事實上,國民黨的凍結提案,並非是在反對紓困的預算,只是想藉「凍結」的手段,要求政府把具體紓困怎麼做講清楚,這是過去在立法院內常見的監督預算手段。管中祥認為,即便國民黨給人的觀感「很廢」,但在這件事情上,它就是在扮演在野黨的監督角色,不該被輕易撻伐。

有關媒體在疫情時期的角色,管中祥指出,協助政府傳達資訊本身並沒有問題,但媒體的職責不只是負責當傳聲筒。假如只是傳聲筒,在網路時代,政府部門的「小編」就能做好這份工作。他強調記者的工作更在於檢視、監督政府的言行,唯有記者將自己與官員視為對等的關係,才可能避免淪為傳聲筒的角色。

模擬疫情記者會 小學生記者踴躍發問不怕生
Photo Credit: 中央社

「逆時中」不等於唱衰台灣

對於當前高度限縮異議的社會氣氛,管中祥認為,不論是官員或社會大眾,在涉及公共議題的討論上,還是得就事論事。面對質疑與異議,首先應有的態度就是,不要假定這是「來亂的」,應先聆聽再下判斷。媒體的質疑可能是為釐清問題,或有助於政府發現問題,而不同意見,也可能只是從不同的角度,要讓事情能做得更好。

儘管要戰勝病毒,人們有賴於政府的領導,以團結社會力量共同抗疫,但這絕非等同領導者或政府,就此便獲得免於監督、糾錯的「免疫力」,集體抗疫的內涵也不該輕率被簡化為「順時中」或「聽政府的就對了」。

總結來說,任何有道理和依據的發問都應被正視,納入防疫思考。退一步言,就算毫無道理的發問或質疑,不也是給了政府發揮影響力,可藉機正視聽,紓解恐慌嗎?不論是官員或心繫疫情的民眾,都應該把防疫的質疑和異議,視為礦坑裏預警危機的金絲雀,而非唱衰台灣的烏鴉嘴。相信任何身為生命、健康共同體的同船成員,其不論是肯定或質疑防疫團隊,其初心本意都是希望台灣不要翻覆或淹沒於疫情洪流中。

本文獲多維新聞授權轉載,原文發表於《多維TW》月刊054期。

延伸閱讀

責任編輯:丁肇九
核稿編輯:翁世航


猜你喜歡


挖掘雲端開放架構優勢!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。

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


猜你喜歡