【公投意見發表會】藻礁贊成方批三接有如生態版「服貿」,王美花稱壯大產業一定要蓋

【公投意見發表會】藻礁贊成方批三接有如生態版「服貿」,王美花稱壯大產業一定要蓋

我們想讓你知道的是

台灣雖然是海洋立國,但我們對周遭海域沒有完整調查,以至於每次有開發案件,正反方都會有不同的論述,因為資訊欠缺、沒有充分公開,我們無從得知三接興建,對生態的影響是什麼?我們不知道桃園大潭是不是最適合的場址?

年底四大公投案將於12月18日登場,中選會從今(13)日開始一連舉辦5場的公投電視說明會,其中「珍愛藻礁」公投案意見發表會,正方代表人為律師陳憲政,反方代表人為經濟部長王美花。

此案主文為「您是否同意中油第三天然氣接收站遷離桃園大潭藻礁海岸及海域?(即北起觀音溪出海口,南至新屋溪出海口之海岸,及由上述海岸最低潮線往外平行延伸5公里之海域)」,是4個公投案中內容最長、議題也最複雜的一案。

支持「珍愛藻礁」公投的陳憲政表示,第三天然接收站到底適不適合蓋在大潭?最近大家應該充滿疑惑,因為同一個科學事實,正、反雙方說法卻有很大差距,意見兩極。

陳憲政指出,這個公投的辯論重點,包括了大潭藻礁生態好不好?贊成開發的學者認為,大潭生態不好、生物多樣性低、沒有保育價值;但反對開發的學者認為這裡生態非常好,獲國際保育組織Mission Blue列為東亞第一個生態希望熱點。

另外到底有沒有替代方案?開發方說大潭非常安全是三接唯一場址,沒有其他替代方案,但反對方說觀塘風浪並不適合蓋天然接收站,北部有現成的地方可以作為替代。對於藻礁、當地生態影響,政府認為,不會造成任何藻礁生態影響,甚至有利於生態保育,到底這裡誰講得對?

陳憲政指出,這些資訊落差的問題,就是因為台灣雖然是海洋立國,但我們對周遭海域沒有完整調查,以至於每次有開發案件,正反方都會有不同的論述,因為資訊欠缺、沒有充分公開,我們無從得知三接興建,對生態的影響是什麼?我們不知道桃園大潭是不是最適合的場址?

陳憲政說,中油三接案遭到反對,開發單位提出接收站興建往北移20公尺、行政院提出北移455公尺的再外推方案,但評估的依據是什麼都沒有講清楚,環評程序至今也還未完成審查,目前是未定案的狀況。

jrwjv3j4fwcrcc0xdrvwwv9mc1rl8c
Photo Credit: 行政院提供
行政院今年5月公布三接再外推方案,第三天然氣接收站觀塘港外推455公尺。

陳憲政要求政府召開聽證程序,公開所有替代方案、建港前後的評估資料,找出最好的方案,但政府對於聽證程序還是猶豫了。

陳憲政表示,我們記得多年前服貿爭議,當年我們感到憤怒,因為立法院聯席審查的召委花不到30秒的時間,就讓服貿協議一字未審送出委員會,民眾當年的訴求就是希望回歸法律規定逐條審查,我們可以發現程序沒有落實,不僅侵犯個人權益,也會影響公共利益,三接也有同樣的問題,因為評估報告沒有公開,大潭藻礁就判死刑,這是不是另一個誤判?

wmzmgbflh5q4ad31d7fcylj5fp0b25
Photo Credit: 關鍵評論網 李秉芳攝
2018年10月,環保署環評大會最終審查「中油觀塘第三天然氣接收站環境影響差異分析案」,最後以7:2表決結果正式通過,被稱為是環評史上最黑暗的一天。

陳憲政說,大潭藻礁當年因為政府過多期待、在媒體上的發言,已經實質影響官派環評委員,導致環評大會變成投票大會,7票同意票有6票來自官派委員,凸顯政治介入專業審查。政府還提出用觀塘三接來換深澳電廠停建,沒想到專業審查,變成政治交換的籌碼。

陳憲政說,珍愛藻礁公投要彰顯的不只是生態保育的問題,希望藉由這個案子,突顯程序沒有被落實的問題,三接在最後的環評大會,沒有回應三接興建對生態造成影響,最後用表決強行通過,讓專業審查會議崩潰。

他表示,台灣未來還會有許多開發案,如果不遵守法定程序,無法凝聚全民共識,只會增加更多衝突,更多內耗,「由衷的希望不管是台灣的自然環境還是民主法治,都希望能完完整整的交給下一代。」

台灣「例外開發」變成原則,陳憲政憂物種正在消失

陳憲政表示,任何一個物種消失,都可能對生態系造成影響、影響人類的生活,像是蜜蜂消失影響授粉,引發糧食問題。

大潭藻礁有7600年的歷史,養育許多生命,小燕鷗、白海豚都是藻礁常客,不過中油過去在此施工曾造成工作船擱淺,導致0.58公頃(14個籃球場面積)的裸露藻礁的毀損,也包括柴山多杯孔的熱區。

陳憲政也提到,過去因為不當開發,台灣西海岸有八成已經水泥化,很多閒置港口和消坡塊,就是過度開發帶來的海岸淤積、侵蝕,是破壞環境的惡性循環。至今大潭電廠南邊,可以看到泥沙覆蓋自然海堤和消波塊,就是因為要抵擋大潭電廠入水口突堤侵蝕,但已經嚴重影響附近居民的安全。

陳憲政認為,經濟部推出的再方案,只是把突堤再外延伸,侵蝕只會更嚴重,這也是為什麼他們主張三接應該考慮現成的港口,比如台北港、林口港、麥寮港、甚至考慮浮動式平台,彌補能源轉型對三接的短期需求,也保存海岸。

陳憲政說,從立法價值來看,原則都是我們可以保護自然環境,少數原則才能開發,現在我們看到例外變成原則,雖然我們都有法規、環評,可是在面臨開發選擇,我們卻往往選擇犧牲生態。

他說,或許有人認為現階段經濟開發比較重要,但從新聞來看,環境破壞帶來的氣候變遷都是得不償失,立法院已2050年作為淨零碳排,國際大廠也要求碳中和,減少碳排也是國際趨勢,政府常以缺電為裡有,還要開發更多天然氣接收站,現在除了三接,一接、二接正在擴建,四接、五接正在環評,六接也在規劃,「我們左手淨零碳排,右手拼命蓋石化設備,不是右手打左手嗎?」他說天然氣不是越多越好,而是剛好就好,應該逐年降低。

台商回流、台積電擴廠,王美花稱製造業為「國安」三接一定要蓋

擔任反方代表的經濟部長王美花則說,過往很多廠商到中國投資,在美中科技貿易戰後,國際局勢有很大的改變,廠商在這兩、三年大量回台投資,帶動有史以來最大的投資潮,已經有超過1兆3000億在台投資。

加上今年全球車用晶片短缺,國外發現台灣有一個這麼重要的產業,這些都影響台灣的用電需求,過往十幾年每年用電成長1.3%,從去年到今年,未來每年用電要成長2.5%。


猜你喜歡


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

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


猜你喜歡