《被誤讀的哲學家》:霍布斯真的崇尚專制獨裁嗎?

《被誤讀的哲學家》:霍布斯真的崇尚專制獨裁嗎?
Photo Credit: Wikimedia Commons Public Domain

我們想讓你知道的是

霍布斯經歷了英國內戰和歐洲的宗教戰爭。是不是這些可怕的事件促使霍布斯提出一種比疾病更糟的治療方式呢?狄德羅寫道,霍布斯把當時危險的情況誤認為世界的普遍現象,對人性產生太灰暗的看法,而提出過於激烈的解決之道。但事實不僅止於此。

對這個問題,霍布斯做出另一個更好的回應。他說,即使統治者的力量僅足以完成任務,而不具備絕對權力,統治者還是有可能濫用這種力量,因為「只要他的力量足以保護所有人,就足以壓迫所有人」。換句話說,任何一個有效率的政府都有可能做出專制的行為,即使沒有獨裁領袖也依然如是。霍布斯發現世界上沒有完美的政治系統:「處理人類事務的方式一定會產生某些缺點。」這句話本身很公道,但霍布斯的系統缺點未免也太大了。它允許權力無限大的獨裁者進行壓迫,永無止盡地揮舞王權。只要是聰明的工程師,在設計政治系統的時候,一定會想辦法降低這種悲劇的發生風險。其中一種有效的方法,就是將權力劃分給好幾個不同的機構,牽制彼此的作為。正如孟德斯鳩(Montesquieu, 1689-1755)在影響力卓著的《論法的精神》(Spirit of the Laws)中表示,「我們不斷看到人們一旦擁有權力,就會濫用權力⋯⋯因此要讓人無法濫用權力,就必須透過某些機制來制衡。」霍布斯反對權力分立,認為這就是內戰的起源。然而事實上,即使在當時的英國,分權似乎也沒有引發內戰,自一六八九年新王上任之後,就一直享有和平。[註]

某些二十世紀的作家說,早在極權主義 (totalitarianism)這個詞於一九三○年正式誕生之前,霍布斯就主張了這種思想。「極權主義」的定義源自義大利法西斯領袖墨索里尼(Mussolini),他認為這種國家「不像自由主義的教條那樣⋯⋯只能依照法律與規定來做事」,這種國家是「無所不能的」(all-embracing),可以插手介入「人民的一切道德生活與心智生活」。自一九四○年代以來,人們就將這種妄自尊大的國家體制,視為法西斯主義與共產主義都具有的獨裁形式。但霍布斯支持的似乎並不是這種體制,而是墨索里尼口中的「自由主義教條」。霍布斯允許人民的自由被侵犯的理由,大部分都是為了讓國家維持和平。他認為,優秀的統治者必須保護臣民幸福生活時所需的自由,制定法律時必須謹慎,不能用法律綁死人民。霍布斯從來沒有像真正的極權主義者那樣認為國家應該控制人民的藝術與娛樂。而且雖然他希望由執政者來監督教會,但並不是為了支持任何一種意識形態,只是為了削減狂熱教派與煩人神職人員的政治權力。

霍布斯認為,統治者的任務就是在凡間施行上帝的律法,並促進「人類的福祉」。因此,國家的職權範圍不僅限於守衛國土,還需要管理其他事務。例如禁止酗酒、重婚、亂倫、同性戀、「對女性的淫亂利用方式」,以及「過度消費食物與服飾」──霍布斯似乎認為最後這件事也會以某種方式傷害國家的財富。然而,如果每個管制性行為、成癮性物質、危險經濟思想的國家都會被當成極權政體,那麼每個國家都是極權政體了。雖然霍布斯這種放任統治者自行其是的做法,一定會讓我們更難阻止希特勒或史達林這種人的崛起,但是極權主義想要的那種全能政府,卻與霍布斯的思想完全不同。要在他的政治思想貼上現代的標籤很簡單,但這些標籤通常很難持久。

AP_215214211668
Photo Credit: AP/達志影像

例如霍布斯對於平等的看法就與極權主義不同。霍布斯算是某種平等主義者。亞里斯多德說,「某人的血比其他人更優良」,「某些人天生就是統治者,其他人天生就是僕人」,但霍布斯反對這套說法。他指出,即使人們存在先天差異,也會對於彼此之間的差異程度抱持歧見。用先天差異來為不平等辯護,只會導致爭吵:

只要人們給自己的敬重比給其他人的更多,就很難想像人們要如何和平共處。如果要擁有和平,就得遵守這條大自然訂下的法則:每個人都必須平等對待他人,一如對待他自己

很多人心中的大自然規則都與這條相距甚遠。舉例來說,一百年後的法國大革命前夕,巴黎議會用來保護貴族特權的說法是這樣的:「宇宙有著永恆不變的智慧,讓人們之間的力量、秉性各有差別,並不均等。因此社會中人們擁有的條件,自然也不能均等。」

霍布斯絕大部分的工作都是擔任貴族們的導師、祕書、夥伴,大多數的雇主都來自地位尊貴的卡文迪許家族(Cavendish),因此有些人認為他主張平等主義實在有點忘恩負義。身為政治家、有兩個外孫女當上女王的第一代克拉倫登伯爵(Earl of Clarendon)就批評霍布斯「對皇室抱持極度惡意,完全不管他的麵包是誰給的」(譯注:首代克拉倫登伯爵海德(Edward Hyde)是保皇派重臣,也是瑪麗二世與安妮女王的外祖父)。克拉倫登伯爵覺得霍布斯就和當時的「平等派」(Levellers)一樣,要廢除所有人出生時的統治特權,而「只要傑出受尊敬的父母其繼承者及後嗣的品行並未敗壞,每一個制度完善的政府⋯⋯都會讓他們在朝為官,承擔榮譽與信任」。

不過,霍布斯並沒有要消除所有財富與地位差異的意思。他反對的是將祖先的差異讓子孫繼承。他似乎認為,只要是自己爭取來的,並且以公平的方式分配,地位的差異就可以接受。至於經濟不平等的議題,既然財產權以及「利用個人產業並獲益」的能力都是統治者保障的範圍,那麼霍布斯應該會認為一個人富有並不是罪惡。但他也同情赤貧者的處境,堅持政府應該幫助無法工作的人,不應該把這種事都推給私人慈善機構處理。

而儘管霍布斯提倡立法禁止放蕩行為,他的名聲卻反而讓人以為他支持這些行為。許多在教堂悔過的罪人都把霍布斯當成自己墮落的藉口。一個年輕的劍橋大學教師丹尼爾・斯卡吉爾(Daniel Scargill)在一六六九年被解僱之後,就在學校教堂朗誦了一段悔罪文:「我曾以身為霍布斯信徒與無神論者為榮⋯⋯在我同意那些原理,接納那些立場之後,就開始了極為放蕩的生活。我輕率地辱罵他人、毫無節制地喝酒、傲慢地誇耀自己,腐化別人⋯⋯哦,我當時是多麼地卑劣啊!」


猜你喜歡


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

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


猜你喜歡