《資訊圖表看懂氣候變遷》:天氣變熱不只危害人類健康,農業、經濟也已經付出代價

《資訊圖表看懂氣候變遷》:天氣變熱不只危害人類健康,農業、經濟也已經付出代價
Photo Credit: 商周出版 / Lisa Schwegler、Stefan Kraiss與Janna Geisse製作

我們想讓你知道的是

氣候變遷如今已經直接或間接影響了地球上75億人的生活,並且造成許多代價。本文以數據與資訊圖表方式,帶我們一一了解氣候變遷的實際影響。

文:戴維・內勒斯(David Nelles)、克里斯堤安・塞爾勒(Christian Serrer)

氣候變遷如今已經直接或間接影響了地球上75億人的生活。不過全球暖化對各地帶來的影響不盡相同,這意味著不同地區的人、人與人之間的共同生活,也會受到不同程度的影響。

無論如何,可以確定的是:氣候持續暖化將不斷為人類帶來各種不良影響。

氣候變遷對人類健康的危害

氣候變遷會對人體健康造成許多方面的影響,比如高溫引起的熱壓力〔譯注:指逾量生理代謝熱能、作業環境因素(包括空氣溫度、濕度、風速和輻射熱)及衣著情形等作用,對人體造成的熱負荷影響〕與高溫事件,可能使心臟、血液循環系統和呼吸道相關疾病惡化,提升這些疾病的致死率。

另一方面,高溫有利接近地面的臭氧形成,而這些臭氧對人體健康有不良影響,例如可能導致肺功能下降。水災或暴風雨等極端氣候現象更頻繁出現時,也會對人體健康帶來更多隱憂,比如人可能因此受傷,嚴重時甚至導致死亡等。此外,原本已經受到汙染的水域,可能因為強降雨和水災而提升傳染病爆發的風險。

在德國,氣候變遷帶來的另一個影響就是花粉季時間延長,使氣喘或過敏性鼻炎等呼吸道疾病的症狀更加惡化。而且這樣的氣候條件更有利引起過敏植物的生長與繁衍,如豬草(Ambrosia)就是一個很好的例子。

氣候變遷對人類健康的影響
Photo Credit: 商周出版 / Lisa Schwegler、Stefan Kraiss與Janna Geisse製作
2010年全球因氣候變遷增加的死亡人數

氣候變遷導致病媒傳染病的擴散

病媒指的是可以將病原體從被感染的動物或人類身上傳染到其他動物或人類的生物,如俗稱壁蝨的蜱,或是蚊子。

氣候變遷正在改變現今經由病媒散布病原體的環境條件。近幾十年來,因全球化和氣候上的有利條件,使得原生於亞洲的白線斑蚊(又稱「亞洲虎蚊」)活動範圍已經抵達南歐部分地區。

接下來的不久,歐洲緯度較高的其他地區應該也會因為氣候變遷而成為適合蚊子活動的環境。值得注意的是,白線斑蚊會散播登革熱與屈公病毒(Chikungunya virus)。

另一方面,高溫必須維持一段時間,病毒才有機會經由被感染的蚊子散布出去,這是因為溫暖的溫度才能讓病毒在蚊子體內成功繁殖,然後在蚊子叮咬人類時將病毒傳染給人類。氣溫上升為白線斑蚊的擴散創造了有利條件,同時縮短了病毒在白線斑蚊體內的繁殖時間。

要是再結合全球化,以及隨之而來的風險,如外國商品進口可能夾帶白線斑蚊,或是被病毒感染的歸國旅人,都會提高疾病傳播的風險。

氣候變遷對白線斑蚊在歐洲分部的影響
Photo Credit: 商周出版 / Lisa Schwegler、Stefan Kraiss與Janna Geisse製作

氣候變遷對農業的影響

高溫、空氣中二氧化碳濃度過高、降雨型態的改變,以及連帶發生變化的天氣參數都會影響到植物的生長。當溫度上升到最適當的生長溫度時,可以提升特定作物的產量,但一旦溫度超過這個最適值,作物產量就會開始減少。

以玉米和大豆為例,生長期間只要有一天超過30°C就不利這些作物的發育。另外還有極端天氣,尤其是乾旱和高溫,以及暴雨,都會對產量造成負面影響。僅2000至2007年間,全球榖類作物就已經因為乾旱及高溫減少約6.2% 的收成。

當空氣中的二氧化碳濃度增加時,許多植物會快速以減少水分從葉面發散出去,同時增加光合作用的方式來加以因應。如此一來,就有足夠的水分和養分可以促進植物生長,這就是所謂的「二氧化碳施肥效應」(CO2-Düngungseffekt)。

至於這樣的施肥效應可以抵消多少某些地區因為溫度與降雨型態改變造成的減產,目前仍存在爭議。此外,空氣中二氧化碳濃度增加雖然可以促進植物生長,但同時也意味著會相對降低植物中的養分濃度。

倘若因為平均氣溫上升,因此有較長的耕作期、較少寒害進而提升農作物的產量,那麼氣候變遷對地球緯度較高的區域,如北歐就有正面意義。相對地,對於熱帶和副熱帶地區的作物產量,氣候變遷就不見得是好事了。

因應氣候變遷的經濟代價

氣候變遷帶來三類不同的成本:首先是損害成本,比如極端天氣事件對不動產或是公共建設造成的直接損害。其次是適應成本,例如修築堤防或為防洪建造滯洪池。第三是所謂的迴避成本,這類成本比如為限制未來全球暖化的發展,從化石能源轉換到再生能源所衍生的成本。

因為無法明確而全面地掌握所有產生的成本,所以實際上想要為氣候變遷所產生的經濟代價計算出精確數字非常困難。因此計算出的成本只能取決於做出的假設,而且比如融化的永凍土,要準確掌握諸如此類所產生的成本也非常困難,因此解析下方圖表要格外謹慎。

氣候變遷帶來的年度損失佔全球國內生產毛額的比重
Photo Credit: 商周出版 / Lisa Schwegler、Stefan Kraiss與Janna Geisse製作

由於這些高度不確定性,因此純就經濟學角度而言,非常難拿捏到底應該採取哪些氣候保護措施,又要干涉到怎樣的程度。

如果人們想將暖化範圍限制在升溫1.5°C以內,勢必要付出極高的投資成本。相對於把升溫範圍設定在最高3.5°C,投資成本雖然顯著下降,卻會導致更高的損害成本。

整體而言,比起毫無限制地讓全球氣溫上升所產生的損害成本,限定全球暖化的成本應該少很多。值得注意的是,隨著氣溫上升,也會增加不可逆損害的風險。

2010氣候變遷對全球產業造成的損失與節約估算
Photo Credit: 商周出版 / Lisa Schwegler、Stefan Kraiss與Janna Geisse製作

結論

氣候變遷並非遙不可及的未來景象,而且它所代表的意義也不僅止於冰山融化和海平面上升而已,現今已經有許多人以及他們的生計受到氣候變遷的威脅。

此外,也顯示進入工業化時代以來觀測到的氣溫上升情形,主要原因還是人為溫室氣體排放。幸好還有個頗帶諷刺意味的好消息:我們有機會影響未來氣候的發展,而且對氣候變遷並非完全無能為力!


猜你喜歡


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

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


猜你喜歡