大學生看公投:「只因不了解而不去投,形同支持不同意」,這只是再次陷入選舉的萬年泥濘

大學生看公投:「只因不了解而不去投,形同支持不同意」,這只是再次陷入選舉的萬年泥濘
Photo Credit: 中央社

我們想讓你知道的是

公投結果並不代表人民絕對的同意或否決,也不是立即的亡國或走向國際。對人民來說,不論公投通過與否,生活還是照平常那樣子過,現在討論該投同意或不同意已無意義,但切勿忘記,這些議題還沒有正式結案。

文:蔡博元

作為大學生,我和大多數年輕族群一樣不喜歡政治惡鬥,但因其充滿各種奇妙的人類行為,所以我覺得政治很有趣。

比如我的觀察是,在這場公投中,有許多人並不清楚公投內容,只是依政治立場重覆著辯論會中所宣傳的口號。這在任何選舉早已見怪不怪,也許過陣子就沒人討論公投議題,畢竟接下來還有縣市首長、縣市議員、總統等各種選舉等著台灣人民。

如今公投結束,爭辯該投「四個同意」或「四個不同意」已無意義,但我們應該靜下心來反思此次公投。為了探討公投結果,我蒐集了來自五個不同平台的民調或投票統計,並以一個年輕族群的視角提出幾點反思。

公投前,我們真的瞭解公投案嗎?

根據LINE TODAY投票統計(如下圖),經過說明會或辯論會後,約56-62%的人自認瞭解公投內容,約26-28%是還沒看過說明會,僅有11-15%的人承認不瞭解。若問最關心的公投案,有46.19%的人自認四項都很關心,14.89%是四項都不太關心,其餘則是只選一項,分別是核四20.68%,萊豬12.49%,藻礁2.98%及公投綁大選2.77%。

a
作者提供

似乎多數人自認關心並清楚公投案,可是,我們這陣子在各社群平台看到的留言,幾乎都是「四個不同意,台灣更有力」或「四個同意,就是民意」,還充斥著仇恨與恐懼的言論,而深度討論並不多。這表示,雖然多數人自認關心、瞭解公投,但可能只知道其所傾向的政黨是主張四個O還是四個X,並免費幫忙宣傳而已。

我們應當反思,該如何理性、科學地掌握公投案的背景知識?該如何避免接收錯誤的假消息?進一步說,如何促成不同立場的正反方互相溝通、瞭解?

畢竟,公投的意義是全體國民共同解決國家問題、決定國家方向,而不是製造更多社會問題,更不應該淪為政治惡鬥的工具。

公投時,為何多數人不願出來投票?

不論是公投民調,還是公投結果,約六成的投票權人表態或實際不參與投票。

根據TVBS民調中心在公投前三天的調查,有49%的人表態一定會去投票,27%選擇不會,剩餘23%尚未確定。實際結果是,只有約41.1%的投票權人出來投票,58.9%沒投,對比2018年「九合一大選綁公投」的55%投票率(如下圖),少了整整270萬人。

a
作者提供

根據中選會的資料,上一次公投的正反方共有約1000萬票;而近五次總統大選最低也有1200多萬有效票,而其半數的5-600萬票可輕鬆跨過公投門檻。

不難想見,這是第19案公投綁大選會出現的主要原因,雖然即便公投通過,政府也不見得會完全採納。

民眾不願意出來投票的原因百百種,有的人寧願加班,有的人厭倦選舉,而對學生族群來說,也許是時間與花費過高,但我認為「並非真正瞭解」才是此次公投不踴躍的主要原因。這從許多社群網站上的貼文和留言便可看出,那些雜亂的討論,並不能讓大家更瞭解公投案,只能對口號更有印象。

作為一個大學生,我必須承認,即便我看過公投辯論會,還上網查證資料,但我對每個議題的瞭解程度遠不及專業人士,也不確定通過與否對政策執行有多少影響力。如果連知識份子都沒有把握,甚至公投案的正反方也不那麼瞭解公投案,那公投的意義為何呢?

有的人說:「只因不了解而不去投,形同支持不同意。」但我認為,這只是再次陷入選舉的萬年泥濘——在兩個都不喜歡的選項裡選擇一個比較不討厭的。這樣的思維並不能促進良好的溝通,反而加深對立。

公投後,我們願不願意一起走向更好的台灣?

根據TVBS、台灣制憲基金會、Share Party及Yahoo的民調統計(如下圖),18案反萊豬進口、19案公投綁大選及20案珍愛藻礁都是同意勝過不同意,而實際公投結果是四大案皆為不同意略勝且同意票未達門檻,因而無一通過。

a
作者提供
a
作者提供

但我並不認為公投結果表示人民絕對的同意或否決,也不是立即的亡國或走向國際。

對人民來說,不論公投通過與否,生活還是照平常那樣子過,現在討論該投同意或不同意已無意義,但切勿忘記,這些議題還沒有正式結案。

我們應當反思的是,在公投結束後,這些尚未解決的問題該如何有效處理。同時,為了一起走向更好的台灣,我們應當藉此機會多瞭解社會上未解決的難題,增加理性科學的深度討論,而不是隨政治立場選邊站,才不會形成其實不懂公投案,只是跟著喊喊口號的狀況。

延伸閱讀

【加入關鍵評論網會員】每天精彩好文直送你的信箱,每週獨享編輯精選、時事精選、藝文週報等特製電子報。還可留言與作者、記者、編輯討論文章內容。立刻點擊免費加入會員!

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


猜你喜歡


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

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


猜你喜歡