狂熱而無知的烏合之眾們(八):為什麼烏合之眾只喜歡聽政客說話?

狂熱而無知的烏合之眾們(八):為什麼烏合之眾只喜歡聽政客說話?
Photo Credit: 子迂的蠹酸齋

我們想讓你知道的是

「人生如戲,戲如人生」,我們都被賦予了一些角色上的定義。像是做老爸的要有老爸的樣子、做兒子就要有兒子該說的話,那當然做為一個政客也又屬於他們自己的角色設定和侷限。

在公開場合與他人吵架是一門學問中的學問。

吵架這門學問一直以來在學校教育就沒有討論,並且老師的教育經常就是要求就事論事,然後要求同學要針對對方說話,但這些竅門是討論,並不是吵架。所謂吵架中所說的話,從來就不是說給對方聽的,而是說給在場的其他人聽,只要這些話是其他人聽得懂的,自然形勢就會把對方給壓下去。至於討論跟吵架的分野其實認真說起來也是不知道到底該怎樣區分的。

在教室、交通工具或是餐廳這種公共場合跟別人吵架,當然除了罵對方之外也會用在場所有人都能了解的價值觀對對方施壓。如果轉而使用只有對方聽得懂的事情,就算最後在兩人的價值觀中贏了也不見得能夠獲得其他大眾的支持。這個道理應該就很好懂。所以想像自己變成政治人物的時,在公眾媒體平台上面吵架時所說的話,從來也不是講給對方聽的,而是講給烏合之眾去腦補的。這就是媒體語言,或者說是「政客語言」。

RTSWN29
Photo Credit: Reuters/達志影像

這種政客語言有幾種特性

  • 常識先於知識

對於烏合之眾來說,所有的資訊都是放在手邊的電腦前面,問題是要怎樣吸引他們的注意?最簡單的方式就是讓所有人都擁有對這個標題的認同感,這種認同感可能是來自於自己或是朋友的經歷。

這也是為什麼情歌的市場永遠比其他類型的歌曲來的大。因為並不是每個人都有什麼特殊的經驗,但講到談戀愛或許大家都或多或少有一點經驗,這就是為什麼要把常識放在知識前面。把自己的知識水平降到只剩下國民基本教育,甚至更甚者,把自己變成一個只剩下道德價值觀的人,很多時候反而會引起大量的民眾爭相歡迎。

  • 感性先於理性

不是所有人都擁有理性思維的能力,至少烏合之眾只懂得用感情來思考事情的始末。與其使用理性真正的提供事情的解決方案,不如提供一個情緒的宣洩出口,讓烏合之眾認為自己有盡一份心力。至於最後的結果,他們也從未真正在乎過,烏合之眾只在乎自我感覺有沒有良好而已。

  • 二元善惡思維

烏合之眾所使用的方法就是利用二元善惡戲劇中的形象去思考事情的對與錯,例如政府必定整天黑箱、大企業就是反派、政治人物都是黑道、正妹都是婊子等等的相關刻板形象思維方式。利用這些人們因為不理性而產生的感性標籤思維方式,只要將對方貼上幾個正派或是反派標籤,就能夠引起大多數烏合之眾自動腦補。而後他們心中會無形中認定對方是正氣的好人或是邪惡的壞人。

  • 高抽象語言先於低抽象語言

雖然指著對方罵的時候要用大眾聽得懂的常識甚至是道德,拿這些為基礎點來罵人是正確的。但是當我們要描述自己遠大的目標時則是要盡可能的使用高抽象名詞,講得越是模糊、越是不清楚就越好。例如:

讓美國再次偉大、九二共識、自由和平、性別平權、均富的社會等等這種沒有辦法有時直定義的目標。

烏合之眾的思維沒有能力,也沒有企圖去想清楚這些口號背後的詳細定義是什麼。最多就是利用自己對於未來的想像力,在腦中自己幻化出一個美好世界,然後自我感覺良好的認為對方說的就是自己說的。

RTS7YMY
Photo Credit: Reuters/達志影像

萬一政客公開的發言講得太過鉅細靡遺就會遭受他人的質疑。像是馬英九的競選承諾說過的「六三三」、朱立倫的「三環三線」等等以及未來蔡英文要面對的「非核家園」,都是把目標講得太過明確也太清楚,極為容易就成為敵方說自己跳票的標靶。

而這些東西之所以總是無法在任期內實現,也跟希望跟選民繼續支持有關。但是聰明的政客就會使用「清廉」「夢想」「效率」「幸福」或是「平等」這種根本沒有辦法定義的詞彙來作為公開發言的內容。就算這些名詞所有選民已經聽膩了,也還是有「性別平權」「居住正義」永遠也不會跳票,也永遠無法真正的在意義上實現。

「人生如戲,戲如人生」,我們都被賦予了一些角色上的定義。像是做老爸的要有老爸的樣子、做兒子就要有兒子該說的話,那當然做為一個政客也又屬於他們自己的角色設定和侷限。

厄文・高夫曼(Erving Goffman)是個社會學家,他將人生中的每個情境都給了一個舞台,並且說明我們日常生活就習慣於「見人說人話,見鬼說鬼話」。就像是父母總是會囑咐我們要做哪些事情,但我們在口頭上應付了父母之後,會跟朋友抱怨個幾句關於父母愛嘮叨的事實,並且盡可能的不要按照父母的想法卻又盡量不希望讓他們知道自己其實只是不想聽話而已。這就是分別處於家庭生活和友誼的兩個戲台,有興趣的人請閱讀《日常生活的自我表演》。

政治正是個最好的戲台,上面有許多的角色,像是總統、行政院長、立法委員、地方首長、地方民代、黨秘書長……等等,每個人都有機會公開在媒體發言,這些發言的內容必須符合當時的角色和身分。

例如當一個國民黨的立法委員知道軍公教的年金將會造成未來國家的負擔時,即便知道這些年金的問題,也不能公開說有問題。反而要依照自己國民黨的身分,以及自己選票的基礎來決定自己的發言風向。所以到了最後這名立委也只能依照著自己能上位的因素來決定自己發言的內容。這就是政治的戲台。

有趣的事情是當這位國民黨的立法委員這樣做的時候,他的對手也就是民進黨的行政官員即便知道對手選擇不理性的發言時,他還只能按照對方公開發言的內容做為回應。因為講出對方背後考量的因素並沒有辦法公開回應,大型媒體的受眾,也就是烏合之眾並不了解那麼多政治後台的細節。

photos_21908_1492051603
Netflix頻道《紙牌屋》

這造就了所有的政客即便知道彼此的後台、婚外情、貪汙以及所幹過的壞事和好事,還是必須按照當前烏合之眾所知道的事情和價值觀來發言。並且依照本文先前所提到的「政客語言」來做為發言時的依據和標準。

任意揭露政客後台的樣貌一點用也沒有,因為在烏合之眾的心中,這些政客是依照他所塑造的形象而生存著。例如一個整天喊著支持軍公教年金的政客,即便他心中知道這東西是壞的,但他成天的行動和發言足以說服他的支持者他就是個這樣的人。

因此就算有政客嘗試用那些隱藏於政治後台的細節和發言來攻擊對手,由於這些資訊並不是烏合之眾已知或是簡單到足以理解的。一個良好的政客在新聞上如果沒有花30秒就能攻擊對手的語言能力,就沒有辦法成為一個好的政客,簡短的故事和低俗的發言標準就是他們所必備的能力。

我們現在看中國的歷史劇,經常會講就個什麼「師出有名」、「大義為重」,或是西方歷史上即便要打個小戰爭經常都要請示教宗,這兩種無非就是圖個讓自己擁有正當性的做法。這種正當性對於戰爭或是宮鬥沒有甚麼幫助,但為什麼還是要這樣做?

目標是讓自己的政治勢力在大局上擁有道德制高點,這個道德制高點是為了讓烏合之眾可以了解己方勢力是正義之師,而自己即將侵略的地方則是邪惡的淵藪。不只讓大眾理解,更是為了讓自己的軍隊充滿信心,一隻有士氣的軍隊才有獲勝的可能性。

這就是烏合之眾閱讀政治新聞時的盲點,因為了解政治新聞需要先有「政客語言」的知識基礎才能順利解讀政治新聞背後的涵義和對話。有時候看著兩個政治人物在辯論台上用著「政客語言」在彼此打高空的時候,才能真正意識到原來這就是歷史。我們所認識的歷史絕大多數都是運用「政客語言」而譜成的歷史觀,只是我們有沒有辦法發覺那些隱藏在許多名義之下的真正含意。

烏合之眾系列文主要參考書目

  • 《烏合之眾》古斯塔夫・勒龐Gustave Le Bon
  • 《群眾運動聖經》艾瑞克・賀佛爾Eric Hoffer
  • 《君主論》馬基維利Niccolo Machiavelli
  • 《異常流行幻象與群眾瘋狂》查爾斯.麥凱Charles Mackay
  • 《日常生活中的自我表演》高夫曼Erving Goffman
  • 《語言與人生》S.I.早川、艾倫.R.早川
  • 《神話的力量》坎伯Joseph Campbell
  • 《千面英雄》坎伯Joseph Campbell
  • 《人及其象徵:榮格思想精華》卡爾.榮格Carl G. Jung
  • 《自私的基因 》理查・道金斯Richard Dawkins
  • 《英雄與英雄崇拜》卡萊爾Thomas Carlyle
  • 《我的奮鬥》阿道夫・希特拉Adolf Hitler

本文由子迂的蠹酸齋授權轉載,原文發表於此

責任編輯:彭振宣
核稿編輯:翁世航


猜你喜歡


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

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


猜你喜歡