基於「宿命型直覺」,我們很難接受非洲有可能趕上西方

基於「宿命型直覺」,我們很難接受非洲有可能趕上西方
Photo Credit: Depositphotos

我們想讓你知道的是

在過去60年間,撒哈拉以南的非洲國家大多告別殖民,獲得獨立,也穩定提升教育、供電、供水與衛生基礎建設,就像當年歐洲國家展現奇蹟那般。撒哈拉以南的50個非洲國家統統降低了兒童死亡率,比當年的瑞典速度更快。這怎麼不能稱為驚人進步?

文:漢斯.羅斯林(Hans Rosling)、奧拉.羅斯林(Ola Rosling)、安娜.羅朗德(Anna Rosling Rönnlund)

宿命型直覺

宿命型直覺認為固有特質決定了個人、國家、宗教或文化的命運。事情會是現在這樣,背後有無從擺脫的命定理由:事情向來如此,永遠不會改變。由於這種直覺,我們把第六章的錯誤概括或把第一章的二分化視為真實無誤,而且命中註定:不會改變,也無從改變。

宿命型直覺的演化來由顯而易見。在古代,人類所生存的環境絕少變動,明智的生存策略大概不是反覆重估事物,而是在了解事物的運作之後就假定不會再有變動。

另外一點也很容易理解。宣稱自己所屬族群有某個特定命運是一種很好用的做法,有助讓大家團結於一個大概永不改變的目標,還激發對其他群族的優越感。這對部落、國家和帝國取得力量十分重要。然而現在宿命型直覺會讓我們沒有妥善更新知識,看不見周遭社會的巨大變革。

社會與文化不是石頭一塊,不會改變也無從改變。社會與文化是會動的。西方社會與文化會動,非西方社會與文化也會動——通常動得遠遠更快。只是除了網路、智慧型手機與社群媒體等最快速的文化轉變之外,其他變動往往不夠快,所以未獲注意或報導。

宿命型直覺的一個常見例子就像愛丁堡那位男士,他認為非洲永遠無望,不可能趕上歐洲。另一個例子是認為「伊斯蘭世界」與「基督教世界」有根深柢固的差異。出於宿命型直覺,我們可能認為某個大洲、宗教、文化或國家將會(或必定)永不改變,原因出在他們抱持不變的傳統「價值觀」:這類說法一而再出現,如新瓶換舊酒。乍看似有分析依據,細究卻往往是出於直覺的偏誤。這類高傲說法經常只是出於讓感覺掩蓋事實。

真確問題十:

全球30歲的男性平均接受過十年的學校教育,而同齡的女性平均接受過幾年學校教育?

  • (A)九年
  • (B)六年
  • (C)三年

這本書讀到現在,我希望你已經發現最保險的做法就是選最正面的答案。全球30歲的女性平均在學校待過九年,只比男性少一年。

我的許多歐洲同胞抱持傲慢自信,自以為歐洲文化最為卓越,不僅高過非洲和亞洲文化,也高過美國的消費者文化。然而談到誤解,真不知誰消費得最多。26%的美國人選對答案,比利時和西班牙僅13%,芬蘭為10%,挪威為8%。

195
Photo Credit: 先覺出版

這問題是有關性別不平等,是現在斯堪地那維亞媒體成天在談的議題。我們不斷看到女性被殘酷施暴,暴行通常發生在世上的其他地方,至於阿富汗等國則有許許多多女孩失學,結果我們更加相信一個在斯堪地那維亞很流行的觀點,那就是全球其他地方在性別平等上並無進步——多數其他文化卡住了。

非洲能迎頭趕上

非常多人認為非洲註定永遠貧窮,但這似乎往往只是基於一種感覺。如果你想實事求是,就得知道下面這些事。

沒錯,平均來說,非洲落後其他各洲。現今非洲新生兒的平均壽命是65歲,遠比西歐少13歲。

然而,首先你知道平均值很容易造成誤導,非洲各國之間有巨大差異。並非所有非洲國家都落後其他國家。突尼西亞、阿爾及利亞、摩洛哥、利比亞和埃及等五個非洲大國的平均壽命高於全球平均的72歲,等於瑞典在1970年的水準。

這例子也許還無法說服那些認為非洲無望的人。他們可能會說這些都是位於北非海岸的阿拉伯國家,不是他們腦中的非洲。其實在我年輕的時候,外人無疑認為這些國家也逃不過非洲的宿命,等他們有了進步才當作例外。不過為了驗證,我們先把北非擺在一邊,把目光放在撒哈拉以南的非洲。

在過去60年間,撒哈拉以南的非洲國家大多告別殖民,獲得獨立,也穩定提升教育、供電、供水與衛生基礎建設,就像當年歐洲國家展現奇蹟那般。撒哈拉以南的50個非洲國家統統降低了兒童死亡率,比當年的瑞典速度更快。這怎麼不能稱為驚人進步?

原因也許在於情況雖然好上許多,但仍屬糟糕。如果你想看非洲的窮人,當然看得到。

然而瑞典在90年前也處於赤貧。在我年輕的時候,只不過50年前,中國、印度和南韓在大多數方面遠不如現今的撒哈拉以南非洲國家,而當時亞洲的命運似乎該像現在非洲的命運:「他們永遠無法餵飽40億人。」

如今非洲將近五億人過著赤貧的生活。如果他們註定赤貧,那麼他們必然有某種特質,不同於全球其他數十億人,包括非洲其他已經脫離赤貧的人。可是我不認為有這種特質。

我認為最晚才脫離赤貧的會是困於貧瘠土地與周遭衝突的極窮農人,現在約有兩億人,約為非洲赤貧人口的一半。他們無疑得面對異常艱困的未來,但不是因為有何根深柢固的文化,而是因為土壤與衝突。

然而我仍對這些世上最窮困無望的人抱持希望,因為無望的赤貧向來看似如此。在可怕的飢荒與衝突期間,中國、孟加拉和越南似乎永不可能脫離水深火熱,但如今你家衣櫃裡的多數衣服大概生產於這些國家。35年前的印度,如同現在的莫三比克。30年內,莫三比克非常可能改頭換面,像印度那樣晉升第二級國家,成為可靠的貿易夥伴。莫三比克在印度洋旁擁有長長的美麗海岸線,而印度洋將是全球貿易的中心,為什麼莫三比克不該繁榮興盛?

沒人能百分之百預測未來。我不是認為這註定發生,但我是可能性主義者,現有的事實讓我相信:這是可能的。

基於宿命型直覺,我們很難接受非洲有可能趕上西方。我們也許完全沒注意到非洲的進步,但就算注意到了,也只當作短暫好運的曇花一現,轉眼又會陷入命定的窮困與烽火。


猜你喜歡


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

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


猜你喜歡