「路跑」的資本主義:台灣的馬拉松狂潮是因為22K崩世代需要建立自信?

「路跑」的資本主義:台灣的馬拉松狂潮是因為22K崩世代需要建立自信?
Photo Credit: Josiah Mackenzie @ Flickr CC BY 2.0

我們想讓你知道的是

台灣急速風起雲湧路跑熱,青年大量注入路跑運動,成為主力成員,必須有特定的社會條件,政治力與商業力才得以動員起來,那其社會脈絡為何?

文:張烽益(勞動與社會政策研究協會)

跑步與路跑,是不同的。跑步有可能會是在封閉的田徑場當中,以正式競技規則的方式進行,也有可能只是個人隨意慢跑,跑步是一種強調個人肢體物理性動作的活動。但是路跑,通常意味著在開放的道路或山野,以各種不同任意性的自訂規則,所進行的一種集體性社會參與行為。

台灣的路跑活動,逐漸走向資本主義化

台灣全年路跑場次的爆增,網路報名的瘋狂秒殺,路跑商機的無限,這都是路跑資本主義化的結果。基本上,跑步這件事情,被商業化、市場化與資本主義化,雖然有部分學者認為,商業主義剝奪了運動的本質,削弱原本注重的社區與休閒性質,但是也有學者認為商業化是運動發展成一個產業的重要驅動力,會促進國家經濟發展 [2]。

從個人身體物理動作到集體性社會行為

筆者認為,路跑的資本主義或許會被銅臭味汙染其單純的運動本質,但如果控制得宜,卻也可能是萌生路跑運動普及化的新契機。商業競爭機制的引進,也可能導入運動管理專業化,強調顧客需求導向可能會吸引更多人投入運動,讓運動更加普及化,而這些正是過去長期以來,台灣路跑運動發展所欠缺的要素。

路跑資本主義化,改變了路跑的刻板印象,透過商業逐利模式的驅動,豐富了其面貌,吸引了新的潛在年青跑者,達到前所未有的參與人潮,使得「跑」不再僅僅是個人身體的物理性動作,而是資本主義商業邏輯的市場焦點,一個價格與利潤的計算標的。

路跑如何從一個單純個人身體的鍛鍊,逐步推向一個產業、一種生意、一種從中賺錢的資本主義化過程,嚴格來說是在最近這5年才突然大爆發的。筆者有幸親身參與並見證了這段發展史,本文將以第一手的觀察與統計資料,來初步探知這段歷程,並嘗試挖掘出其發展的社會脈絡。

民間慢跑俱樂部的聯誼健身時期

筆者在2003年開始,為了與中年危機對抗,開始了以一雙跑鞋就能進行的最省錢運動-路跑。為了督促自己的可能怠惰,因此就報名參加了大台北地區的各式路跑賽,透過報名來砥礪外控自己平日可能疏於練習的惰性,後陸續在2004年完成首場半馬、2005完成全馬。

筆者為了對抗中年危機,開始透過參加路跑來督促自己

當時的路跑環境,比較起今日報名網路秒殺盛況,只能說處於一種高度單純跑步、非商業性的質樸狀態,大規模全馬賽事一年只有兩三場,其餘就是一些由各地長跑俱樂部自行辦理的中小型路跑賽,甚至也有少數的全馬賽事。

這些散落在台灣各地的長跑俱樂部,有些是架構在當地體育會之下,有些則是自發性組成,例如早在1963年就成立的北大長跑協會、1990年代左右陸續成立的永和、艋舺、土城等慢跑俱樂部、1992年成立的鳳山慢跑協會以及1995年的台中大腳丫長跑協會等等。

這些俱樂部性質的團體,每日清晨或假日都有跑友在固定的場所團練,參與者大多以中高齡為主,其運作類似早覺會或山友隊的休閒、志工聯誼性質,以個人健身為目的。不過在最近台灣興起路跑熱之後,某些組織有轉型為專業路跑承辦單位的趨勢。

以本人居住的台北市為例,當時大多是台北市政府與路跑協會在各行政區舉行,大抵是數百人規模的路跑賽。參加者就自行到圓山中山足球場的路跑協會報名並現場繳費兩百元,然後賽前再來一次去領取號碼牌,整個過程沒有擁擠的人潮,一切以手工作業,沒有網路這回事。

到了路跑賽現場,俱樂部的成員都齊聚一角熱身寒喧,起跑點旁還可以看到一些賣跑鞋等相關跑步用品的小攤,主辦單位也不會驅趕,大家都相安無事,相互尊重,跑者也都會親切前往交談選購。而路跑賽現場,沒有晶片計時,而是以抵達終點領取名次卡,然後現場以點陣列表機列印成績,將長條的紙捲,張貼於公布欄,由跑者自行依照名次卡上的號碼,去對照成績。這是一個沒有宣傳花招、單純,甚至有點簡陋的路跑時期,那是一個單純跑步的時代。

國家政治力動員的開始

國家為何要涉入運動,運動政治學者Barrie Houlihan認為有六種可能面向:一、早期為了維繫特定階級特權(例如狩獵)或基於宗教因素禁止某些殘暴運動。二、對國民健康與公共衛生有益。三、運動做為社會整合的工具,防止階級衝突擴大。四、做為軍事準備的工具。五、運動員的表現與國家在國際間聲望逐漸相關。六、促進經濟發展,使衰敗中的都市區域復活起來 [3]。

那台灣呢?筆者認為與台灣民主化所帶來的激烈選舉競爭有關。過去的馬市長,現在的馬總統,就是一個最成功的案例。長期喜愛跑步的馬英九,在僅有行政經歷,毫無選舉經驗之下,靠著小馬哥的清新健康形象於1999年一舉當選台北市長,之後更於2008年當選總統。運動所帶來的選民良好印象與政治邊際效益,馬英九發揮到了極致。

台北市在馬英九擔任市長之後,為了推動市民的運動風氣,開始大力推動了一區一運動中心計畫。2003年,台灣第一座由政府興建的運動中心在中山區完工營運,台北市各區持續興建,2010年台北市第12座文山運動中心完工,平均每座造價5億元,民眾使用費單次100元,比起私人健身中心相對平價。

根據北市府的統計,每中心每天平均有2600人次使用。一河之隔的新北市,也起而效法,將規劃興建14座運動中心,2012年底首座新莊運動中心開始營運,截至2014年底為止,已經有6座開始營運。


猜你喜歡


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

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


猜你喜歡