數字會說話:放颱風假真能討好小確幸選民嗎?

數字會說話:放颱風假真能討好小確幸選民嗎?
Photo Credit: AP/達志影像

我們想讓你知道的是

颱風假跟其他政策最不一樣的地方,就在於全縣市的選民都可以立即切身體會到縣市長的決策是正確還錯誤的,就算是不太關心政治的選民,也會關心要不要上班、會不會被淋濕,因此特別可以用來觀察民眾是怎麼對於執政者來課責的。

文:王宏恩(杜克大學政治所博士候選人),原文發表於2016年10月11日

在近日颱風假的爭議中,除了預測準確率的爭議以及半天假的辯論外,對於坐鎮在防災中心的縣市長們來說,最擔心的大概就是決定放不放颱風假是否會影響到自己、或同黨同伴連任了。然而,到底該不該放假呢?台北市長柯文哲說放錯假會對不起國家民族,而謝金河則大力抨擊台灣民眾只愛放假小確幸。真的是如此嗎?台灣民眾是怎麼回應縣市長們的颱風假決策表現呢?

在政治科學的學術論文中,對於天災、政策與選舉的研究不算少數,而且都十分有趣。舉例來說,縣市長無力控制的鯊魚攻擊會造成下次選舉得票減少。其中最有名的是Healy與Malhotra(2009)對於災害支出的研究:他們分析1985-2004年全美3,141個縣的防災支出與災後重建支出,發現只有災後重建支出可以增加得票,防災支出選民無感;更慘的是,防災支出的成本約等價於災後重建的十五分之一而已。

回到台灣的例子,我國對於颱風假的規定,是假如十二小時前預測平均或最大陣風到一個標準即可決定宣布放假,但礙於科技限制,預測準確率最高只有八成,但這樣已經是世界頂尖水準(可見科學人雜誌的這篇討論) 。然而,很多時候縣市長對於是否放假是舉棋不定的。在颱風假決策時,縣市長可能會遇到三種狀況:

第一,準確放假,先宣布放假,然後隔天風雨真的超大。第二,白放一天,宣布放假後隔天大晴天。第三,該放未放,硬要大家去上班,然後才知道風雨過大(為了簡化討論與資料限制,本文在這裡暫不討論放半天假的狀況)。筆者本人不是氣象專家、也不是地質系,但作為一個政治行為研究者,我能做的就是:到底台灣民眾會不會因為放假而更支持做決策的縣市長連任?台灣選民喜歡哪一種假?

本文感謝聯合報系新媒體部楊棋宇等人耐心整理了2005年至2015年每一次颱風過境的資料,結合了縣市長宣布放假與否、氣象局預報結果、以及當天風雨大小,非常詳細的討論了哪些縣市放了哪幾種假;也感謝數感實驗室提供的研究靈感與指引,以及知了新聞對於資料收集進一步的追蹤。

筆者把這筆難得的資料,結合這段時間內的縣市長以及直轄市長選舉結果(中選會資料庫),就可以看出2005年以及2009年當選的縣市長們,在任期內決定放或不放的各種颱風假,是如何影響到接下來的選舉結果。然而,考量到選舉結果可能受到地方治理表現的影響,我再加入中華民國統計網中各縣市的失業率、犯罪率、教育程度、以及人口組成等變數來進行控制,希望可以單獨釐清颱風假對縣市長連任選舉帶來的影響(有些縣市沒有天氣觀測站只好刪除,例如桃園與彰化。另外也刪去難以判斷誰在連任的地方選舉,例如05花蓮縣,最後剩35/44個樣本)。

透過簡單的迴歸模型統計發現,當縣市長做出「正確」的決策時,台灣民眾會顯著地以選票作為回報。換言之,當縣市長宣布隔天放假,結果隔天真的風雨超大後,選民會記住這樣的正確神算,然後在之後的選舉中回報給該縣市長或同黨候選人:平均而言,每多放對一天,連任時得票率會增加2%!但在同時,錯誤決策對得票沒有顯著的影響,無論是宣布放假後隔天大晴天、或是沒有放假結果大風大雨,就這筆資料來看,台灣民眾並不會因此以選票懲罰現任者。

這樣的統計結果,即使在納入各縣市的執政表現之後也依然是統計上顯著的(在統計模型上,選舉年的控制變數與失業率高度共線性,而老年人口也與青壯年高度共線性,因此這兩個變數並沒有被放進模型中)。

螢幕快照-2016-10-04-17_12_51
螢幕快照-2016-10-04-17_12_43

為什麼台灣選民會獎勵放對的、卻不懲罰放錯的呢?雖然沒有進一步的資料,但本文猜測可能選民也預期到判斷錯誤的機率確實存在。另一方面,就算是放颱風假結果是大晴天,選民額外獲得一個大白天可以出去玩,但部分選民可能寧可工作賺錢、部分產業因多放一天而造成損失,而且對所有選民來說也會記住這個縣市長的判斷失誤,因此不一定有動機因額外多一天假就更支持這縣市長。

颱風假跟其他政策最不一樣的地方,就在於全縣市的選民都可以立即切身體會到縣市長的決策是正確還錯誤的,就算是不太關心政治的選民,也會關心要不要上班、會不會被淋濕,因此特別可以用來觀察民眾是怎麼對於執政者來課責的。受限於資料,所以這筆實證資料的樣本數並不多,也構成許多推論與統計上的限制。但至少就統計結果來看,並沒有證據顯示亂放颱風假就可以討好台灣選民,雖然同時台灣選民也不會因此透過選票懲罰現任者。

本文發現,只有當縣市長做出「正確」的決策時,民眾才會顯著地以選票作為回報。相較於文章一開始的美國研究,本文關於台灣颱風假的初步研究顯示民眾不只在意現任者在災後的投入,也在意決策的品質。有放假當然好,但台灣選民要的放假並不是小確幸,而是風雨肆虐前後,為了安全與為了重建的必要時間及體力支出。

本文經菜市場政治學授權刊登,原文發表於此

責任編輯:翁世航
核稿編輯:楊之瑜


猜你喜歡


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

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


猜你喜歡