多重角力下的觀光面貌:看到蘭嶼人喝CITY CAFE,好像怪怪的?

多重角力下的觀光面貌:看到蘭嶼人喝CITY CAFE,好像怪怪的?
Photo credit: AP / 達志影像

我們想讓你知道的是

我們可以從照片獲得對一個地方的印象,蘭嶼的拼板舟、曬飛魚、各種美麗景色,遊客們前往一地,就是為了看看他的面貌,並且應證那些印象,但這些印象與面貌的產生,背後可能是許多複雜的想法角力之後出現的結果。

文:曾令懷

四月底在貳拾號公民會所分享了去年我去蘭嶼打工換宿的經驗,以觀光的角度切入蘭嶼的當代面貌,從7-11的進駐、拼板舟、炸飛魚等方面,去討論文化變動、主客體想法之間的衝突。我將當天的討論整理出來,對於理解「觀光與地方之間的關係」,會有許多激發。

我之前也寫過一篇蘭嶼的文章,不過是從「照片帶給我們的地方意象」這個角度去談論的,而這一篇則是以我個人的觀察,針對「不同角色(遊客、政府、當地社群等)與蘭嶼觀光之間的關係」撰寫,同時結合《觀光人類學》這本書的一些論點,討論當代觀光下的蘭嶼究竟面臨著什麼。

0b9b4655-4962-4639-8e09-089773772896
Photo Credit: 曾令懷

蘭嶼作為台灣靠南的海島,又擁有達悟族文化,再加上吵得不可開交的核廢議題,似乎結合了各種旅遊必備的元素。我們知道觀光可能帶來經濟收益、也可能刺激地方的文化保存;相反地,我們也知道觀光可能帶來環境衝擊、社會衝突等等。蘭嶼當然也出現了上述的許多現象,但是我們不能簡化那些現象出現的原因、也難以預測這些現象未來的走勢,因為當代已經是一個複雜錯綜又龐大的系統,這也是社會科學的困境之一。

蘭嶼的歷史脈絡、達悟族文化世界觀、國民政府來台後的政經結構、當地環境資源變化、對外交通、在地社群不同的年齡層與社經背景、性別、過去接待觀光客的經驗、是否從觀光獲得直接好處,這些因素都會影響到蘭嶼如何回應觀光,或是反過來——觀光對蘭嶼的影響,就算同為蘭嶼人,青年與鄉長因為社會角色差異,對觀光的想法也可能截然不同,甚至是相衝突的。

你會帶餐具去東清夜市嗎?

在蘭嶼,入住民宿時或多或少會被提醒隨時攜帶環保餐具,因為蘭嶼的自然資源與景觀也是被觀光客凝視的對象,如果環境被污染了,那觀光客也會少很多的——儘管事實上,觀光客們幾乎會自動視垃圾不見。

位在東清部落的東清夜市,熱鬧非凡。根據網路資料,東清夜市從2010年開始,由當地居民自發性組成,為的是服務前來的觀光客們。有意思的是,東清夜市的攤販提供各式各樣的一次性餐具,這就與在民宿經歷的經驗大不相同了。

同樣身為當地居民,卻發展出截然不同的餐具政策,這就是一次明顯的內部衝突的例子。不過,當地居民並不代表一定是島上土生土長的人,有可能是從島外移居的人。從「移動」的角度去思考,也許可以解釋這樣的衝突。

保存傳統——但何謂「傳統」?

拼板舟是所有遊客去蘭嶼都嚮往一睹的景色,也被視為是達悟族的文化代表。一般常見的拼板舟都是紅、黑、白三種顏色,那大家有沒有看過「綠色的」拼板舟呢?

使用紅、黑、白三種顏色為拼板舟上色,是因為過去沒有塗料,只能用紅土、鍋底焦灰以及貝殼灰來塗色,而這三種顏色對於達悟族而言具有不同的意義。如今因為經濟貿易興盛以及資本主義的到來,塗料隨手可得,還有各種顏色。

蘭嶼出現偷竊(1)
Photo Credit: 中央社

對於不同顏色的拼板舟,達悟族能否接受似乎與年齡層相關,老一輩的較偏好維持傳統的紅黑白三色,年輕一點的也許可以接受更鮮艷的綠色、橘色、藍色等配色。不過,年齡層這個變因並不是絕對的,把「族群」想像成一個均質的團體,也是不切實際的。當時我們討論到一個例子,如果世界各國元首來台灣開個G20會議,我們要請他們穿上台灣的傳統服飾,那會是什麼?原住民族服飾嗎?但台灣也不是只有原住民族存在。

遊客希望看到當地人的「傳統」生活,是一件非常有趣的事情。達悟族人平常穿的服飾,跟你在台北街頭看到的差不多,但有人就是會想看到他們穿上丁字褲,因為是他們的「傳統」服飾,好像不穿上就不是達悟族似的。或許達悟族可以藉此機會獲得一筆可觀的觀光收益,還可以展示自己的文化、甚至保存自己的傳統,但這或多或少帶有一些表演性質。

靜止的傳統/動態的文化

面對新出現的變化,許多人的第一反應該都是先抱怨一番(可以回想自己面對公司丟出新政策時的反應),「傳統」也不例外;定義傳統並不容易,傳統的保存則更顯爭議。為什麼一定要保持原來的形式跟意義呢?像是貨幣,也經歷了好記次的變化,從貝殼、銅銀金幣、紙幣,現在更是只有一串數字了,這些都是順應時代演變的正常狀況。

除了上述拼板舟塗色的變化之外,飛魚相關的改變則更為極端,因為飛魚對達悟族而言是非常神聖的,當飛魚的意涵面臨需要隨著時代作出轉變的時候,那陣痛可能非常劇烈。

如果去過蘭嶼,相信一定看過(甚至吃過)「炸飛魚」這樣的料理。達悟族認為這種烹煮飛魚的方式並不恰當——怎麼能把神拿去油炸呢?但終究還是出現了。是因為遊客喜歡炸物當地人才開始炸飛魚的,還是非達悟族人開的餐廳率先這樣料理飛魚的,我們不得而知,不過很顯然,這也是一種對外關係產生後帶來的變化。

讓遊客體驗捕飛魚是另一個例子。過去達悟族的社會,男女有別,並不讓女性接觸漁船,更何況出海捕魚;不過現在不只有划拼板舟出海的體驗,還有夜捕飛魚的活動,都在在地打破了過往的禁忌界線。儘管島上似乎會區分族人自己用的拼板舟以及給觀光客用的拼板舟,這也可以視為是應變觀光的一種策略。

我們可以發現,其實所謂「傳統」、「文化」是會不斷變動的,隨著時間演進,只要出現新的技術、產生新的對外聯繫與關係等等,都會影響到原來的生活方式,全球化在當代的影響可以說是無微不至了,就算是在小小一個台灣,「魯肉飯」這個詞也是南北有別。

蘭嶼 飛魚 Drying fish under the sun during Flying Fish Festival, Lanyu(Orchid Island)
Photo Credit: Shutterstock / 達志影像

看到蘭嶼人喝CITY CAFE,好像怪怪的?

2014年9月19日,蘭嶼島上第一間7-11開始營業,至今(2020年)總共有兩間7-11在蘭嶼營業,一個是蘭嶼門戶椰油港,一個是有日出有夜市好不熱鬧的東清部落。

去網路上查,當時關於7-11是否該進駐蘭嶼吵得沸沸揚揚,有人認為那會破壞蘭嶼,也有人認為那可以帶來便利性。就我在島上那一個半月左右的觀察,出現在7-11以遊客居多,當地人購物首選似乎還是超市、雜貨店等等,一來可能是距離關係(如果住在紅頭,還要騎個十分鐘的車才能到),二來是需求可以在超市或雜貨店被滿足。

究竟7-11進駐是好是壞,其實還是應該由當地人自己決定,也許他們覺得多了些選擇,也許椰油跟東清的人也覺得更便利了(還可以吹冷氣?),但更重要的是我們應該反思一下:為什麼是由我們去斷定7-11是否該進駐呢。

在討論時,我們提到馬祖曬衣的趣事。觀光尚未活絡之前,當地人因為是否要把衣服收起來而有過討論,有人認為遊客來就是要看這個,也有人認為這個很醜,不要讓遊客看到。

其實這些都是關於「主體/客體」的思考,當地人以觀光客為主去構思該呈現什麼樣的觀光(炸飛魚)、遊客決定島上該呈現什麼樣子(7-11不夠「原住民族」所以不能進駐)、當地社群內部對於傳統的看法(拼板舟該不該有別的顏色)等等,上面的討論都是在看不同的角色對於蘭嶼和觀光的想法之間的碰撞。

7-11, 小七 ,便利商店
Photo Credit: dabing626 @ Flickr CC BY 2.0

多重角力下的觀光面貌

我們可以從照片獲得對一個地方的印象,蘭嶼的拼板舟、曬飛魚、各種美麗景色,遊客們前往一地,就是為了看看他的面貌,並且應證那些印象,但這些印象與面貌的產生,背後可能是許多複雜的想法角力之後出現的結果。

有時候是當地社群為了自己而改變、或拒絕改變,有時候是當地社群為了遊客而改變,有時候是當地社群被迫改變,例如政府政策、或是社群內部少數的菁英。有時候我們會希望一個地方保持原樣(「傳統」),而盡量讓他們避免資本與商業化,但當地人不見得希望保持原樣(傳統);有時候地方的文化意涵的轉變,就連當地人自己也需要很多時間來適應;甚至傳統的獨特性也不是因為不與人接觸才產生,反而是接觸後為了強調差異而出現的。

但Chambers在《觀光人類學》中提醒:也許很多更大的傷害,早在觀光開始之前就已經來到了。

本文經《方格子》授權轉載,原文發表於此

延伸閱讀

責任編輯:王祖鵬
核稿編輯:翁世航


猜你喜歡


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

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


猜你喜歡