為甚麼要「哲學普及」?

為甚麼要「哲學普及」?
Photo Credit: Ted, CC BY-SA 2.0

我們想讓你知道的是

哲學普及不應僅是哲學入門或講述思考方法,更重要的是令人作出種種反省。

作者︰白水

哲學談何普及?

談到哲學普及,我們當先問的是︰為甚麼哲學要被普及?學問有很多,但不是每一種學問都需要普及,很多專業而且複雜的學問其實只需要社會上少數的人認識就可以了,大眾根本不用了解。比方說考據學就不一定人人都要學會了,因為一來不是每一個人都有興趣,二來大家也不一定要懂得考查不同文本的真偽或者懂得整理書籍的時序。如果說大家應該培養一種求真精神,例如會考究報章或者雜誌上的資料來源和準確程度,那亦不必大費周章普及考據學,推廣應有的閱讀態度和求真精神便可。

香港不同於法國或者意大利等國家,哲學在中學不是一個必修科,更不像是德國把哲學視為選修科,哲學在香港僅僅是個在大學教授的科目,社會對哲學的認識普遍地低。那到底它為甚麼值得被推而廣之呢?這問題其實換句說法,即是在問到底哲學之於社會,又或者之於每一個人,到底有何意義。

這樣問的時侯,其實我們彷彿預設了哲學對大眾而言有意義有價值,只不過我們還未清楚它的意義和價值何在。相反,假如一早就知道哲學是一無是處,便不會有此一問了。當然,可能經過思考之後,我們便會發現也許哲學對大眾真的是得物無所用,但相信它之於大眾是有意義可言的,而其意義可以從了解哲學普及到底是甚麼中得到一點啟示。

哲學普及與哲學入門

有不少人認為,哲學普及即是哲學入門。哲學是一種很繁複而且高深的學問,大眾不是維根斯坦這種哲學天才,往往須花很多心力才可以進入哲學的大門,所以哲普便是一個踏腳石,為大家介紹一些基本的哲學問題和學說,好讓大家可以慢慢了解它的大千世界。

其實此類論者混淆了很重要的東西︰哲學入門可以是哲學普及的其中一種(這一點將在下文提到),但倒轉過來哲學普及並不直接等於哲學入門。假如不是每個人都要認識考據學,那同樣地每個人也不一定要認識哲學中很繁複的部分。一個平常人不懂得「實在論」與「唯名論」的仔細論爭他也可以過得很好,反過來說,即使他認識這場討論也不會令得他過得更好,更何況大眾亦不會對這些光聽名目已經不明所以的複雜討論有興趣。

所以,假如哲學普及要對社會普遍人有意義,那它首先便不應該被當成哲學入門,否則其價值就會局限於引導大家進入繁瑣深嚴但又得物未必有所用的哲學世界,根本無法觸及大眾普遍的需要,亦未必適用於大部分人。

當然,這些高深的討論其實亦適合一些有興趣的人,所以哲學入門為一種繁複的哲學問題簡介,也可以算是哲學普及的一種,能夠滿足社會上部分可能有興趣的人,為他們帶來智性滿足,只是這不應該是哲學普及最主要的工作。

哲學普及與思考方法

亦有人從哲學作為一種思考方法去理解哲學普及的工作。哲學給大眾的不僅僅只是學術內容,更重要的是一種思考方法。哲學思考的基本訓練包括了邏輯分析,可以協助大眾看出一些論者是否犯了邏輯謬誤等等,亦讓大家學習怎樣去論證和反駁某些論點,訓練大家的批判思考。

也許哲學的學術內容對很多人可能得之無益,而且學習了也難免早晚會忘記,可是哲學的思考方法一旦內化了成觀察事物的觸角,便可以應用到生活的不同層面,幫助我們判斷日常生活很多值得探討的議題,例如民主、社會公義和兩性平權等等。

無可否認,這的確是哲學對於大眾一大功用,可是一來這種想法忽略了哲學也可以於其他方面對大眾有意義,二來思考方法其實並非哲學獨有,許多學科例如通識亦會教導學生思考,如果將思考方法直接等同哲學普及的首要任務,那便無法突顯哲學普及的獨到之處。所以,同樣地,思考訓練可以是哲學普及的其中一個工作,為大眾在不同學科中提供其中一種途徑,但哲學普及不能直接就完全等同思考訓練。

哲學普及與認識自己

在古希臘德爾菲(Delphi)的阿波羅神殿有一句很著名的箴言,就是「認識你自己」(Σεαυτον ισθι,英文即know thyself)。我們生而在世,並非手空空無一物地過活,人總有很多一直在運用、自以為理所當然的人生觀、價值觀和世界觀。認識你自己不僅僅要了解自己對事物的種種判斷和理解,更重要的是思考這些未經反省的見解是否合理或者恰當,這樣有助我們更深刻地認識事物,而且在種種抉擇上有更正確的決定。

哲學就是一門合適的學科以介入日常生活中種種未經反省的判斷。哲學是甚麼其實很難一時三刻說得清楚,但可以確定的是,它往往都是一種後設反省,要求追問反省對象的本質、意義或者是理由何在。愛情哲學要反省的就是甚麼是愛情,而人生哲學要問的就是人生的意義。

哲學普及要普及的就不能只是哲學入門──如果入門的意思是一種預備,讓我們慢慢地深入了解一些與自身未必有直接關連的課題。正如哲學家海德格(Heidegger)所言︰「若把哲學只了解為一些和生命分離了的純智構作的話,則這一意義的哲學是無力的……」海德格說的「無力」跟「無意義」可以分開來理解。哲學作為一種高深的學問當然有其智性上的樂趣,這當然可以算是一種意義,因本身追求真理這個活動亦可以是一種意義,但這樣的哲學成為了一種抽離的學術研究,則它對我們而言是無力的,因為根本無法直接指導我們去思考一些切身的問題。(當然,有時哲學入門可以是一種很好的預備以反省與自己更有關的哲學問題,在這意義下,哲學入門亦可以算是一種哲學普及。)

哲學要普及的亦不會僅僅是一種思考方法。思考方法當然有用,但方法除了本來值得學習之外,它亦可以是一種輔助,好讓我們可以更好地了解值得探討的課題,而且更要緊的是可以讓我們「四通八達」,有能力思考不同問題。

哲學要普及的就是種種與自身關切的反省,讓大家可以有一種途徑去理解相關問題,而這些問題可以是包羅萬有,例如思考政權的正當性、社會對同性戀的看法合理與否、人存生有否意義。探討這些課題不只帶來一種思考的樂趣,更重要的是,通過對這些課題的反省,可以讓我們更深入和更好的了解這個世界,並且有更好的理由和能力去應對生活,例如怎樣看待身邊的人如同性戀者,甚至是怎樣看待自己的人生乃至整個世界。

無知乃有知

蘇格拉底乃哲學之父,理應是最有知識的人,可是他卻自認無知。然而,這樣的無知才是有知,因為他知道自己所知的其實不多,而他亦沒有人像其他人一般自以為是,把未經反省的見解當成道理。如是無知比起更多自以為有知的人其實懂得更多。

亦因為無知,蘇格拉底才會終其一生無休無止發問。如果說一個人沒有感受等於沒有活過,那一個人沒有反省過,他也沒有活過。沒有活過不是說他從未存在過,只不過用蘇格拉底的話語來說,他的人生是不值得活的,因為他的一生根本活得毫不深刻。

哲學的希臘文為「φιλοσοφία」,「φιλο」可以解成愛,「σοφία」就是智慧。哲學就是一種愛智的活動。哲學之於大眾,其意義也莫過於此,更愛智慧,其實亦即是更愛深刻而且有洞見的人生。

本文獲授權轉載,原文見好青年荼毒室(哲學部)

相關文章︰

責任編輯:tnlhk
核稿編輯︰周雪君


猜你喜歡


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

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


猜你喜歡