一封給家園的《情書》:悼不斷上演的迫遷鬧劇

一封給家園的《情書》:悼不斷上演的迫遷鬧劇
Photo Credit:吳昀慶

我們想讓你知道的是

學習空間設計、規劃專業的人都知道,人對於空間是具備記憶的。空間給予人們的,不僅僅是遮風避雨的處所,更是支撐生活、情感的重要條件,更何況是家園呢?政府若對土地、城市規劃想望仍停留在舊思維,人民有實現進步生活便遙不可及。

文:吳昀慶(台灣大學研究生協會會長、南鐵青年、台大建城所碩士生)

電影《情書》中有關於家園的線索

《情書》這部日本電影,在20年後的今天,重新在台灣的電影院復刻上映。除了在劇情、角色設定、運鏡手法、電影配樂上都令人再次驚嘆之外,最重要的是,能夠在視聽娛樂產業蓬勃發展的今天,持續以其優雅清麗的風格,再次感動影廳中的人們,這恐怕也是這部電影成為所謂「經典」的必要條件吧。 關於《情書》的好,20年來已經有太多的影評者進行深刻的分析,在此不再多做贅述。今天希望跟讀者分享的是,在影片中提及有關於「家」的這個線索。事實上,在本部電影的各種線索之中,最明顯的就是「家」了,一封投遞到遠方,本以為消失的地址,竟是開啟這一連串綺麗故事的源頭。男主角藤井樹的家,在小樽市國道五號的開發案中,遭到徵收拆除。這也使得男主角藤井必須被迫離開自己青春期所眷戀的求學環境,也同時離開了他所暗暗喜愛的同名女孩。
即便是遷居到了遠方的大城市神戶,那樣的眷戀依舊存在。岩井俊二導演並未明說,卻在電影中所透露的訊息,我們幾乎可知,男主角藤井樹持續在追尋的是青春期意外被剝奪的生活。那樣深深地失落感,恐怕是主角一輩子難以忘懷的吧。 對於「徵收」,一般的人可能會認為這不過就是一種「倒楣」,或者無關痛癢的偶發事件。然而,學習空間設計、規劃專業的人,幾乎都知道,人對於空間是具備記憶的。這在文學、電影中,我們都可察覺:無論是《新天堂樂園》裡的廣場及舊戲院;《情書》、《海街日記》中的老房子。更不用說,在執行空間設計的同時,我們不可忽略之歷史脈絡的認知。事實上,空間給予人們的,不僅僅是遮風避雨的處所,更是支撐生活的重要條件,更何況是家園呢? 家園的重要性如此不證自明。正如女藤井樹爺爺所守護的老家,即便頻臨傾頹,又距離鬧區有一段路程(每當遇見北海道酷寒的冬季時,沿路的積雪又相當不便)。但是這樣的記憶或生活模式,是可以被輕易取代的嗎?生活的不便是搬到新的電梯公寓就可以解決的嗎?爺爺將家園庭院外的樹木細緻養護,如同自身的骨肉一般。每一個在這片土地上居住的人,都享有憲法保障的基本權力,中華民國憲法第十條:「人民有居住及遷徙之自由。」即便是任何一個庸庸碌碌的人,都不只是在統計表上的一個數字而已。
螢幕快照_2016-10-03_下午4_14_10

「我決定固守這個老家」

在體認到那座空曠、不起眼的舊房子,是為家族成員相濡以沫的空間之時,原本主張放棄山丘上老屋的女藤井樹母親,最終如此宣告:「我決定固守這個老家」。令人不禁想起,現代諸多土地開發案,政府號稱具備「安置」方案,似乎一切迫遷就合理。基本上,只要沒有達成全體的共識,我們就應當謹慎去處理,任何有關於對他人家園的任何處置。 迫遷的爭論,不只在於補的多寡(財產權)。它牽涉到居住權、工作權,甚至是受教權(如男藤井樹被迫轉學)的剝奪。這絕非目前所有地方政府向外的宣稱:「為了『公共利益』,這些『釘子戶』正在阻礙城市的發展。」 迄今,我們不斷地發現政府操弄著都市急求發展的意識形態,透過不同的土地取得的方法,在進行大肆的開發。因為,進行土地的炒作,不僅能塑造一種海市蜃樓的都市樣貌,更對地方政府的稅收、政客的名聲多有助力。號稱拆除一座又一座的老舊社區,是為了解決城市的「違建」問題。但事實上,鐵皮屋跟違建不必然扯得上關係,真正的「違建」,常常反而是被迅速營建完成、外表看似富麗堂皇的新建大樓,透過找尋建築法規漏洞取巧設計,盡量灌滿容積的「地產商品」。在被金權遊戲所操控下的城市,市民的「公共利益」只剩下愈來愈高的房價、愈來愈單調的城市景觀。
14585678_1505227892827508_1361538884_o
Photo Credit:吳昀慶
蟾蜍山聚落/許多城市裡看似窳陋而不起眼的聚落,事實上反而是城市不可或缺的元素。同時具備著生產、生活的功能,聚落的形成更是有其發展的歷史脈絡。都市的再生,不應再以剷除式的規劃、僵化且不合時宜的法規來看待。
歷經林口A7合宜宅徵收的徐玉紅女士曾說:「人民在自己的土地上逃難。」是的,迫遷不只是拆除建築物,更幾乎是毀滅了一個人、一個家庭、一個社區、甚至是一個村莊裡的生命。國家輕易執行土地徵收、進行開發,比起企業剝削勞工更加殘忍的是,由於土地的稀缺性Scarcity),因此諸多當下遇到迫遷困境的民眾,那座要被「徵收」的房子,幾乎都是他們一輩子積蓄的血淚。勞工被剝削,尚有另謀他途的可能;但當僅有的房子受人掠奪,也就僅能在自己的土地上逃難了,但該往哪逃呢?

在昨天剛舉辦完的反迫遷論壇中,政大地政系戴秀雄老師就表示:

德國從1970年代開始,就警覺到若德國每年GDP成長一直維持在2%以上的狀態下,對於他們全國土地資源環境的保護上,就會出現『危機』。
我們可能很難想像,GDP的穩定成長,竟也會成為先進國家煩惱的事情?先進民主國家所希望促成的,是國家、城市、社區、鄉村的永續發展,而非殺雞取卵式的破壞性開發。台灣若要躋身已開發國家的行列,想要和國外有同等的生活水準、水平的話,不該僅僅只追求GDP的上升與(表象上)經濟的繁榮,更應當在法制上、公民的價值觀上,開始著手進行變革。當然,對於尾大不掉的政府機關,要達成這樣的調整,仍需要很長的時間,甚至需要更多的社會運動發生才有可能扭轉這樣的困境。 歷經了前不久的925反迫遷團體上凱道陳情之後,超過60多個相關的迫遷案例血淋淋地擺在眼前。一再地讓我們看到各個地方政府,不分藍綠政客,為了每次選舉能夠再次取得政權,不惜用盡各種手段與地方派系結盟,透過都市計畫的手段為財閥開路。反迫遷的各個公民團體,在歷經了幾乎令人絕望的9月高雄果菜市場拆除後,完全感受到被當下民進黨政府給出賣的氣氛。因此,我們應當了解,政權不管怎麼輪替,當他們緊握權力魔戒之時,就極可能失去初衷。公民需要有決心和共識,去重新奪回對於城市發展的決策權,而非任憑鄰舍輕易受人宰割。

整個世界都在提倡惜物環保、減少開發,怎麼政府到了居住與都市規劃時候,就大小眼供奉「開發至上」為神主牌? 在憤怒與感傷之餘,我希望透過溫柔的書寫,甚至是寫一封哀婉的情書給在這片土地上承受苦難的人們,甚而是已經離去的他們:

「你好嗎?」

「我很好。」

責任編輯:黃郁齡
核稿編輯:楊之瑜


猜你喜歡


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

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


猜你喜歡