佔領的日常:再看《亂世備忘》

佔領的日常:再看《亂世備忘》
Photo Credit:Giloo紀實影音提供

我們想讓你知道的是

《亂世備忘》本就志不在此,它要做的是「備忘」,好讓若干年後的人們得以回望、參照,並且省思。就這個角度而言,《亂世備忘》用紮紮實實的79天跟拍,記錄下了相當豐富的「佔領的日常」。

為抗議人大落閘與爭取真普選,三年前香港爆發了大規模群眾佔領街道的雨傘運動,歷時足有79日,震撼世界(但卻震動不了特區政府和中共中央)。運動結束後,失落與無力感籠罩整座城市,參與者們一時之間不忍回顧,導演陳梓桓也曾經如此。雖然他自運動初始便有意識地扛起攝影機做記錄,但這些素材在工作室裡被擱置了一段時日,直至一年後才終於推出紀錄片《亂世備忘》。

或許是因為《十年》帶來的爭議,香港各大院線不願碰觸敏感的政治題材,使得包括《亂世備忘》在內的許多傘運相關作品,始終無法在戲院上映。《亂世備忘》只好出走,遊走海外各大電影節、影展,到過加拿大、捷克,並且入圍2016金馬獎的最佳紀錄片獎項,備受國際注目及肯定。2017年10月第15屆日本山形國際紀錄片影展,將「亞洲新潮」(New Asian Currents)的首獎小川紳介獎頒給《亂世備忘》,為香港紀錄片寫下新的一頁。

《亂世備忘》全片長約129分鐘,內容分為長短不一的20段章節,基本上隨運動時序排列,但各有主題和切入面。導演陳梓桓本身是紀錄者也是運動參與者,他鎖定的焦點不在領導要角或「大台」,而是一群在警民緊張對峙下偶遇的朋友,他們有些是上班族、監工、學生,以及更多不知名的尋常民眾,共同組織物資站、配管線、搭篷架;從旺角轉移到金鐘,開設英語教室,持續佔領、抗爭,也持續在街頭對話、商討,溝通彼此想法和信念。當然,也承接彼此的恐懼與無奈。

雨傘運動的結局大家都知道,而導演在片子的頭尾各剪了長達三分鐘的遠鏡頭、無對話片段,透過「國慶煙花匯演」和「9.28夏慤道催淚煙」的強烈對比/諷刺,揭開全片序幕;並以佔領區從早到夜的清場刷洗,哀悼運動的終結。「結束後,好像甚麼也沒發生過,」導演片尾一句沉重的提問:「我們改變了甚麼呢?」使得無力感成為了紀錄片(至少後半部)的基調。任何參與或關注過雨傘運動的人,在觀賞此片時,望著原本規模浩大、彷彿有些改變可能的運動逐步走下坡、能量耗盡,應該都會有所感傷吧。

亂世備忘 劇照2
Photo Credit:Giloo紀實影音提供

這是我第二次看《亂世備忘》。首次觀賞後確實陷入上述情緒之中,低迴不已;再一次觀賞,才能夠拉出一點冷靜距離,思索其中的段落意義和導演切入手法。

《亂世備忘》的確是一部誠實的紀錄片。不只片中的人物誠實(明白展現擔憂恐懼、對於特定派別的厭惡、喜愛周庭女神……),導演本身透過「提問」的方式,雖不至於與抗爭者的高度激情同步呼吸,但也毫不避諱去顯露自身的喜怒甚至控訴(對於黑警)。不過話說回來,「誠實」固然可親可愛,有時也不免帶來一些缺點。

首先,我同意論者查映嵐的部分觀察,在片中港大優秀學生Rachel和吉利蛋的篇幅比例確實過長,這使得原本志不在「大台」的紀錄片,似乎未能留意到在一般民眾或任何組織中,依然都可能有「小大台」這類主流和邊緣的差距。這涉及斯皮瓦克(Spivak)所謂「從屬者能說話嗎?」(Can the Subaltern Speak?)的問題,相關討論在各大運動場合(包括台灣的太陽花運動)都曾出現。我倒不認為這種「對中產菁英少年的偏愛」,背後是一種「期望知識分子救國救港的僵硬想像」,果真如此,導演便毋須在片中還擺入Rachel和中一便未升學的阿傑之對話橋段了。

我想重點恐怕是在影片的主敘事上,導演無法避免選擇思緒清晰、口齒伶俐者的「誘惑」,只要將他們的片段剪出來、配上字幕,紀錄片的理路和意念便能有效、精準地傳達,那是一種輕省簡便。但過度倚賴便容易忽略那些搭不上話或講不出幾句清楚陳述,但以無聲行動默默支持著運動者的世界。

再者,在運動第一線中激烈衝突、近身肉搏的絕非高官,而是警察人員和抗爭者,因此抗爭者會對警察滿懷怨言和忿恨,乃是人之常情,但紀錄片卻不必過度停留在此一面向上。警察做為國家機器權力末梢的執行工具,紀錄片將焦點放在追問「警察不也都是香港人嗎?」、「當了警察便丟了良心?」等,意義其實不大。究竟是甚麼使得香港市民和警察必須在街頭對立?或許才是更值得尋索、展現的結構性課題。

我個人非常欣賞本片傳達「公民抗命」理念的手法,透過一位在旺角遇見的16歲中學女孩之口,短短幾句:「會有這樣(被捕)的心理準備,因為佔街是違法的,我知道自己違法,不過我不覺得自己有錯。」便讓觀眾對於抗爭者的心態及其「準備」,能夠有總體性的把握。

亂世備忘 劇照3
Photo Credit:Giloo紀實影音提供
2014年,中國全國人大常委會通過香港行政長官選舉、立法會選舉的「8‧31決議」,引發香港市民高度不滿。為求真普選,香港市民自9月26日起,發動佔領中環運動,遭到香港警方大規模鎮壓,使得運動得到更多市民響應,佔領了主要街道長達79日(一說達81天)。

說完了瑕不掩瑜的缺點,可以來說說《亂世備忘》的優秀之處。在過往的一些評論中,曾提及本片有著敘事散漫、冗長之病;我在第一次觀賞時,確實也對部分片段頗感乏味冗贅。但此次重看,卻有所改觀,問題恐不在紀錄片而在觀影者本身,當我們被劇情片養慣口味時,心底暗暗期待明晰的主敘事線、沒有高潮迭起至少要不時精彩的情節,或者抗爭的英雄(主義)。《亂世備忘》本就志不在此,它要做的是「備忘」,好讓若干年後的人們得以回望、參照,並且省思。就這個角度而言,《亂世備忘》用紮紮實實的79天跟拍,記錄下了相當豐富的「佔領的日常」。

縱使不舒服,但人生究竟有幾多機會,能在車來車往的夏慤道、彌敦道上躺著睡覺?導演在不少段落的結束,都將鏡頭拉遠拍攝佔領區,不時可見人們在大馬路上開會、讀書,或躺臥在高架橋匯入道的「奇特」景象,這是佔領的日常。導演還跟拍到長洲、葵盛,去捕捉抗爭者家人們的反應,有些嘴上說不反對,但表示「即使熱血,也要餬口啊,大佬!學民思潮能養活他嗎?」又或者抗爭者察覺到遠離佔領區,各地其實依舊如常、彷彿沒事發生的現實,這亦是佔領的日常。

片中人物主要在運動中協助處理物資,那些搬箱堆疊、載運分配、不時擔憂物資在雨中淋濕,他們必須搭棚架、處理導水問題等等,在觀影者看來也許覺得枯燥細微,但正正是這些沒有掌聲鼓勵的枝微末節,撐起了長達兩個月餘的抗爭運作,這也是佔領的日常。當然,開會商討、爭論表決、高呼口號、流動抗爭,甚至衝突流血,以及不斷襲來的難過失落-活動升級、包圍政總失敗後,一位抗爭者面容哀戚說:「是啊,我甚麼也做不到。我只是可以逃跑。」這都是佔領的日常。

片中還有一幕是眾人圍聚著閒聊,其中的曱甴哥表示他自第一天出來,就不認為可以爭取到「真普選」;另一位抗爭者則認為直到現在,他都覺得還有百分之一的機會能爭取到退而求其次的方案。無論是毫無希望或渺茫的1%,這些人不都上街抗爭、來到了這裡?世上便是會有如此多明知不可為而為之的「傻子」。《亂世備忘》用心記錄了三年前雨傘運動中許多佔領的日常,紀錄下香港的理想主義火焰還在熊熊悶燒的時刻。

三年過去了,顯而易見的是,雨傘運動並非香港民主自由下坡路的停損點、轉折點,而只是個稍稍停留的中途站。寫作此文時,香港立法會建制派議員乘DQ6之危修改議事規則的消息傳來,令人感到黑暗布幕的籠罩無以復加,香港已快喘不過氣來。

能怎麼辦呢?《亂世備忘》的片尾字幕,導演除了特別鳴謝所有被拍攝者外,還感謝了所有香港人(Hong Konger)。這或許是一個小小「彩蛋」,能夠在一個地方共同生活、為理想奮鬥,本就是值得感激的緣分。失望之餘,回首一下三年前的熱情與初衷,或許能夠為冷酷的現實注入些許暖流。

責任編輯:曾傑
核稿編輯:翁世航


猜你喜歡


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

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


猜你喜歡