台日韓射箭男團的自拍合影,完美體現了「君子無所爭,必也射乎!」

台日韓射箭男團的自拍合影,完美體現了「君子無所爭,必也射乎!」
東京奧運26日射箭男子團體對抗賽,金銀銅牌分別由韓國(白衣)、台灣(藍衣)及日本(橘衣)拿下。頒獎典禮後,韓國隊提議3隊選手一起自拍留念。|Photo Credit: 中央社

我們想讓你知道的是

在這次的東京奧運競賽中,除了選手們的表現之外,多數台灣人民對於選手的正向回饋也很值得一提,在台灣社會的民情與風氣下,國人普遍對於選手們賽後失利並不苛責,更多的是鼓勵與打氣;台灣選手們也因為這些正能量而激勵自我,期盼自我能夠再提升。

台灣自五月疫情大爆發以來,不論工作與生活,社會上似乎瀰漫著滿滿的負能量,好似人生漸漸陷入絕望,快樂距離人們好遠。然而隨著東京奧運賽事的開打,台灣健兒們紛紛傳來捷報,獎牌數已突破歷年新高,甚至大大超出以往表現,這些好消息也讓國人一掃陰霾,為選手加油喝采的同時,生活也慢慢多了些期待與積極。

賽事中,有一張照片引起許多國人關注與討論,如此令人讚嘆的人性美麗,那便是男子團體射箭項目頒獎結束後,韓國選手邀請台灣與日本選手自拍合影,前一刻他們還是競爭激烈的對手,後續他們卻是相互欣賞彼此的朋友。

然而這三個國家的選手合影,會引起這麼大到討論,難免和以往的既定印象有衝突。台灣與日本的關係向來友好,其中互動看起來便覺得自然;但是日本與韓國之間,不論在歷史情結、政治外交或經濟產業競爭上,日韓之間一直有著難以解開的心結;台灣與韓國更不用說,經濟產業相互競爭之餘,運動賽事諸多項目更是競爭激烈,舉凡跆拳道、棒球等,國人印象中偶有的小動作更讓人不悅,台韓運動的競爭關係要說是世仇也不為過。諸多概念衝突下的友好合影,讓我想到《論語.八佾》有說過這段非常貼切的話:

「子曰:『君子無所爭,必也射乎!揖讓而升,下而飲,其爭也君子。』」
(翻譯:孔子說,君子之間沒有可爭的事,如果有的話,那就射箭吧!賽前行揖禮相讓,賽後彼此飲酒致敬,這樣的競爭才是君子的表現。)

韓國、台灣及日本這三個國家,包辦射箭項目的前三名,賽後韓國主動邀請自拍合影,大家又能盡釋前嫌的開心互動,其實就很符合孔子所說的這段話。可以說,孔子所處的春秋時代,正是各方諸候相互爭逐及競爭的時期,天下為公的大道時代已經距離愈來愈遠,身處在一個無法迴避競爭的環境,彼此之間又非得如此而為的話,射箭就是一個非常好的方式,因為射箭也是當時士大夫及貴族普遍學習的才能。能以箭術分出高下後,彼此又能發自內心地為對方肯定、祝福,這才是君子之間的良性競爭。

當然孔子的說法是立基於「仁」的表現,仁的基本概念不脫離「成全他人」與「利益他人」,重點在於「摒除私心」,如果存有自我私心,凡事作為都以「利益自我」為先,這就違背了「仁」的基本價值了。然而存在於這世間,成全或利益他人的極限能有多大?舉例孔子在《論語・衛靈公》曾說:

「子曰:『志士仁人,無求生以害仁,有殺身以成仁。』」
(翻譯:志士仁人之中,沒有人會為了自我生存而殘害「仁」,只會有犧牲自我性命來成全「仁」的人。)

上述這段話簡單說,就是站在「成全他人」與「利益他人」的角度下,哪怕我可能會失去性命,也不能存有一點圖利自我的私心。看似如此大愛的一段話,但要讓每個人都能具體實踐,其實還是有它的難度存在,因為要犧牲生命才能成仁,對普羅大眾太過遙遠。而「利他」其實沒有那麼難,只要不做出只顧及自我生存而傷害他人的事,至少也可以算是最基本限度的利他了。

然而在這次的東京奧運競賽中,除了選手們的表現之外,多數台灣人民對於選手的正向回饋也很值得一提,在台灣社會的民情與風氣下,國人普遍對於選手們賽後失利並不苛責,更多的是鼓勵與打氣;台灣選手們也因為這些正能量而激勵自我,期盼自我能夠再提升。不論是選手雙方之間的真心祝福,抑或是選手與國人雙方之間的正向回饋,都是一種美麗的「人」性與「仁」性的體現,因為那都是發自內心的希望對方好,即便要讓我付出才能成全你們,我願意。

除了男子團體射箭選手們的友好互動,其他選手們的賽後故事也紛紛傳為佳話。例如戴資穎與印度選手辛度(Pusarla Venkata Sindhu)、泰國選手依瑟儂(Ratchanok Intanon)的相知相惜;林昀儒與德國選手奧恰洛夫(Dimitrij Ovtcharov)二度競爭後的相互肯定。還有好多好多場上選手們既競爭又美麗的故事,一一都在這次東京奧運上顯見,然而更多的是選手在場上奮力拚搏的專注精神。例如奧運五朝元老莊智淵的堅持不懈;李智凱幼時許願到今日的奪牌實現;郭婞淳貧困出身卻翻轉人生的屢創佳績。好多好多選手故事與國人之間的相互激勵,散發滿滿正能量的人性美麗,彼此間相得益彰。

這次東京奧運的台灣選手表現,即便競賽失利也讓國人為他們喝采,在這滿是正能量充溢的情境中,有時候會讓我們認為這般發自內心的作為,其實是很自然的人性表現,但是這類狀況在其他國家未必理所當然,例如中國。舉例來說,早在東京奧運競賽之前,中國游泳選手孫楊(東奧被禁賽)算是最典型的例子,不論參賽的禁藥使用或爭議風波,最讓人印象深刻便是2019年的世界游泳錦標賽,孫楊獲得金牌之後,他逕自跑到第三名的英國選手史考特(Duncan Scott)面前說:「You're a loser, I'm a winner.」(你是輸家,我是贏家。)

上述例子是特例嗎?其實在這次東京奧運中,更讓人印象深刻的是女子雙人羽球競賽項目,中國選手陳清晨對戰韓國多次說出「我操」等疑似髒話,能聽懂中文的觀眾亦紛紛表示驚訝。雖然賽後陳清晨解釋是以「watch out」或「ciao」來作為激勵用語,但仍令部分人覺得此舉有爭議。其實最讓人訝異的並非陳清晨,反而是中國人民對於她的「疑似羞辱髒話」大表肯定,不少中國人民對於陳清晨亦更為激賞,認為她為中國出一口氣,甚至中國人民亦會到他國選手的粉絲頁面戰狼出征。

換個角度來看,如果台灣選手也仿效陳清晨的舉動,相信在台灣社會風氣的主流聲音定不會認同此舉,更明白說這絕對不會是台灣人民觀賽的多數反應,因為當我們看到受人肯定的對手,即便我方落敗亦會給予對方肯定,我們也只會在對手的粉絲頁面用「讚賞來替代出征」。

然而並非所有中國選手都如同孫楊或陳清晨那般,也並非所有中國人民觀賽的表現都是如此,重點在於這「令他人反感」的言行似乎成為了中國主流聲量,很難想像這是怎麼樣的社會風氣。從孔子談「仁」的觀點來看,似乎中國社會的「利己」風氣已遠大於「利他」價值,既鮮少「揖讓」作為更難見「君子」表現。

換個角度說,當中國選手揹負如此負面又強大的「國族情懷」壓力時,有時看到他們競賽失利卻被自己人批判時,身為台灣人也難免為其心生憐憫,最明顯的就是中國射箭選手王大鵬,只因競賽失利便被自己人辱罵「死胖子」、「人醜活差」等字句,雖然中國亦有不少人為其平反打氣,只是如此負面批判的風氣卻也頗為突顯,這在台灣社會都是難以想像的事。

這次東京奧運有個現象特別吸引我的注意,就是不少歐美國家的競賽選手是東方面孔,有些人可能是華裔在當地出生成長,但有些原為中國籍卻歸化他國來參賽,為數亦不少。我開始反思為何這些中國籍選手要歸化他國?若是單一特例便罷,但當這些例子已不再是單一現象時,他們選擇歸化的原因又是為何?對照上述例子,再反觀台灣的狀況,印象中也不太看到台灣選手歸化他國參賽,即便在台灣社會批判體育協會作為聲浪頗高的風氣下,東京奧運卻也看到許多台灣選手,先後紛紛表態來自台灣的驕傲。

上述所談論的,簡單說即是一個國家所呈現的社會風氣與人性表現,究竟是風氣影響人性?抑或是人性帶動了風氣?這其實也沒有答案,但我想用「仁」的角度來看,其實就是「利己」與「利他」的差別,如此而已。從正面角度來看待這些競賽,只能說謝謝這些選手為我們帶來的美好。

延伸閱讀

責任編輯:潘柏翰
核稿編輯:翁世航


猜你喜歡


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

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


猜你喜歡