【綠色觀點】比未來人預言還準!5 個世界氣候趨勢觀察重點大公開

前陣子網路上流傳未來人的 40 年預言,氣候變遷將帶來巨大代價,不過與其相信陰謀論,不如從幾個觀察點來預測,接下來國際氣候政策與情勢發展。
評論
Shutterstock/達志影像
評論

本文作者黃宗煌,美國明尼蘇達大學應用經濟學博士,臺灣清華大學榮譽退休教授,研究領域專注於環境經濟學、自然資源經濟學、成本效益分析、可計算一般均衡模型等專業研究,曾任臺灣綜合研究院副院長、臺灣環境與資源經濟學會理事長等職。現任臺北大學自然資源與環境管理研究所約聘教授及綠學院綠色帶路人。

原文刊登於綠學院,INSIDE 經授權轉載。

前陣子一位綠學院的綠色帶路人私訊分享《未來人 KFK 對未來 40 年的預言》,據說跟美國滿天飛的陰謀論一樣紅,人人都私下觀看及分享。裡面對於未來地球環境的描述,除了戰爭之外,基本就是說,延宕氣候行動將造成人類社會巨大的成本,包括對生命和生活、商業活動、經濟和社會體系所造成的巨額損害。未來人花這麼大的力氣穿越到當代,就是提醒我們要開始行動,因為最大的成本,就是不做任何事的成本。

這還需要未來人來說?無數人包括我、綠學院、聯合國秘書長 António Guterres,甚至大寶法王、達賴喇嘛都說過類似的話,奇怪的是,效果都沒有 KFK 強,而且這是一個甚至無法驗證是否為真的人。

為什麼?

因為當真相的複雜性超出了我們一般人的理解能力時,我們更期待一個未來人、一個陰謀論,只要按下快捷鍵,簡單的答案就會跑出來。

因此,我這篇文章,將試著用快捷鍵的方式,教你如何從詭譎難測的世界局勢中,找出對你我發展有影響的關鍵問題,光知道什麼是未來還不夠,還要知道未來什麼時候來,我整理出五個觀察重點:

觀察重點一:新冠疫情的衝擊與綠色復甦

英國為炒熱主辦 COP 26 的聲勢,在 2019 年底就宣布 2020 年為「氣候行動年」,承諾修正氣候變遷法,並豪邁地提出「淨零排放」的倡議,因此激發了多起新倡議等待閃亮登場。然 COVID-19 橫掃全球,不僅奪去數十萬生命,而且瞬間對人類發展指數(註一)、實質 GDP 造成石破天驚的巨大衝擊(註二),更激發了地緣政治的利益衝突。能源作為政治博弈的籌碼,最近造成國際能源價格大跌,在此同時,COVID-19 卻使能源需求驟減,如此混沌多元的能源市場衝擊,為全球溫室氣體減排和再生能源發展埋下更大的不確定性。

疫情爆發,市場需求放緩,人們不再無止盡消費,有些人甚至停下來思考人生的意義,這使企業面臨巨大的壓力。現金流趨緊、供應鏈中斷、市場供需普遍下滑,多數企業上半年營收明顯下降,三分之一的企業現金流承受期限不足一個月。(註三)

這波疫情對第三產業的打擊最大,尤其是旅遊業和餐飲業受到的影響最為嚴重,對第一產業(農業)的影響最小;對第二產業(製造業)的主要影響則取決於復工復產的進程問題。可以預期的是,後疫情時代的綠色復甦 (green recovery) 策略,必將成為各國亟待解決的問題,亦將成為 COP 26 的主要議題之一。

面對這樣的變局,經濟社會的各層級決策者,從個別企業到中央政府,應該如何應對?例如,企業在產品研發與設計、員工工作方式與效率、商業模式創新、供應鏈與風險管理、新商機的開發等方面的思維勢必不同往昔。

觀察重點二:2020 美國總統大選

美國現任總統川普在 2017 年宣布退出氣候變化綱要公約 (UNFCCC),但全球性的協定可不適用「七天不滿意退貨」,要等 2020 年 11 月才能生效;而 2020 正好又是美國大選之年,關鍵的問題是,如果川普連任成功,美國可望如願退出協定;如果俄羅斯和沙烏地阿拉伯也表態支持,其結果無非宣告全球減排目標遠不可及。如今川普又宣布退出世界衛生組織(WHO),不管後續的主張與動向為何,不可否認的是,此舉再一次對國際社會應對氣候變遷及其影響人體健康的風險,在「地球村伙伴關係」上多加了一層障礙。

然而,值得關注的問題是,川普的政策主張如果遂願,對於全球所追求的環境衝擊脫鉤、資源脫鉤、以及福祉脫鉤(wellbeing decoupling),究竟是福還是禍,恐怕尚不足以下定論。

觀察重點三:國家自主決定貢獻 NDC 提報頻率由每五年一次縮短為兩年

COP 24 (2018) 在波蘭達成一項新的共識,據此,每個國家應提交的「國家自主貢獻」(NDC)報告,自 2024 年起將從巴黎協定的每五年一次,改為每兩年一次,而且必須呈現所採取的具體減排舉措。這種頻率只對於特定國家(如排放大國、或減緩策略有彈性及其操作空間大的國家)才有意義,對於臺灣來說,在短短兩年內能有的新作為與績效,應該不會有太大變動,即便推動了減緩與調適策略,效果也不見得在兩年內顯著呈現,充其量只是徒增一些撰寫報告的準備庶務。

問題是,一旦「淨零排放」成為 COP 26 的結論,國內所必要的減排目標與應對策略在未來的 NDC 應該如何呈現?《溫室氣體減量及管理法》的 2050 減排目標或階段性減量目標是否需要隨之加嚴,執行進程是否需要加速?凡此問題,都需要兼顧多層面向,進行更審慎的評估和長遠的規劃,切忌一再偏執一方思維。

觀察重點四:公司、銀行、保險業者、及投資人是否願意調整他們的商業模式和投資期待,ESG 是否有機會成為主流

英格蘭銀行在 2020 年 2 月宣布啟動「COP 26 民營金融議程」,協助民營金融機構支持全球經濟轉型,邁向溫室氣體「淨零排放」的經濟社會。專業融資決策必須考慮氣候變遷的問題,包括氣候風險揭露、風險管理及投資回報等,都得納入考量,以協助開發中國家融資經濟社會的轉型,實現淨零排放的境界。因此,每一個公司、銀行、保險業者、及投資人都需要調整他們的商業模式和投資期待,為低碳世界盡一份心力。

雖然目前已有綠色氣候基金 (Green Climate Fund) 及調適基金 (Adaptation Fund),但 COVID-19 大幅地擴大了氣候變遷的脆弱度 (vulnerability),提高了氣候行動的成本,因此幫助開發中國家走上永續及氣候友善的發展路徑,提供必要的氣候金融是他們最需要的支持。這也代表全球在後疫情時代實現綠色復甦的關鍵性驅動力,將帶給下一代安全,並在這過程中發展新且清潔的綠色產業,創造工作機會。

觀察重點五:「淨零排放」的成本技術與經濟可行性

首先,我們要瞭解為何是「淨零排放」而不是「零排放」?簡單的說,淨零排放就是考慮到一個國家需要而且擁有足夠的機會和空間操作「挖東牆補西牆」的策略性政策,或者境內有足夠的潛力以再生能源替代化石能源。

淨零排放並不是每一個國家都能做到的命題。以臺灣為例,在彈性機制及國際減量合作受限、能源供應系統孤立無援、再生能源占比有限的情況下,要實現淨零排放,幾乎形同緣木求魚,除非相關的限制有解脫的機會。

其次,常言道:「顧佛祖,也要顧腹肚」,因此,即便淨零排放在技術面可行,但我們不得不問:需要付出的代價究竟有幾何?已有許多評估報告指出,為在 2050 年達到「淨零排放」的目標,碳價在 2020 為 £40〜100 /tCO2,2050 年則漲至 £125〜300(平均為 £160)(註四)。這樣龐大的支出,我們負擔得起嗎?

再者,《溫室氣體減量及管理法》通過後所運用的經費均來自空污費的挹注,然而適用期限即將到來,未來的財源目前還是充滿不確定性。目前環保署正在研擬開徵「碳費」的可行性,再加上對用電大戶的再生能源管制,是否必然確保企業綠色競爭力的提升?

此外,臺灣在地方自治條例下,垂直溝通及政策調和與執行的問題日益嚴重,再加上《原住民族基本法》,無不為資源整合利用和政策調和增添不少「國中之國」的困擾。因此,對於後巴黎協定與後疫情時代的挑戰,我們必須考慮自身的條件和能量,在事前創新獨立自主的倡議,但凡國際的新倡議,我們可以聞雞起舞,但不必總在事後以追隨者的身份與狼共舞。

下一篇,將帶你從個別企業的角度來看,如何評估並參與可能的綠色復甦振興策略。

(註一)見聯合國開發計劃署 (UNDP) 的評估報告:《UNDP (2020b), COVID-19 and Human Development: Assessing the Crisis, Envisioning the Recovery》

(註二)見國際貨幣基金會 (IMF) 的評估報告:《World Economic Outlook: Chapter 1, The Great Lockdown》

(註三)2020 年聯合國開發計劃署 (UNDP) 針對中國大陸企業進行的新冠疫情影響問卷調查分析

(註四)請參考 Ackerman and Stanton (2012)、Moore and Diaz (2015)、Burke at al. (2019) 等

責任編輯:Mia
核稿編輯:Chris


開發者享受 CI/CD 價值!運用 Amazon EKS 整合 GitLab 創建自動化部署

企業如何在 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 部可以獲得以下三大好處。

透過 AWS 增加雲端技能 在組織發揮影響力

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。

了解 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。

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