科學家為何相信恐龍滅絕,是因為一顆飛向地球的小行星?

科學家為何相信恐龍滅絕,是因為一顆飛向地球的小行星?
Photo Credit:AG2016CC0 Public Domain

我們想讓你知道的是

科學家怎麼知道恐龍的滅亡的原因,可能是來自於一顆小行星?他們當時根本也還沒出生呀?有什麼證據支持這樣的理論?

文:唐納德.普羅泰羅

爬蟲類時代終結是因為時間已經相當久遠,而且從一開始就是個錯誤。中生代結束,更好的日子終於來臨。當時有些體型較小的溫血動物,專門偷吃恐龍蛋,後來牠們慢慢學會偷取其他東西,文明因此逐漸開展。

──威爾.柯皮(Will Cuppy),《滅絕完全指南》(How to Become Extinct)

意外的珍寶

拜無數過度簡化的科學教科書之賜,大多數人都認為科學就是規劃研究工作,以達成某個特定目的、進行簡單預測,再透過實驗找出答案。大多數教科書(或民眾)不知道的是,科學也有運氣成分。科學界許多重大發現不是出自計畫,而是誤打誤撞的結果。這類意料之外的發現通常稱為「偶然力」,出自古波斯「塞倫迪普三王子」的故事。

意外發現的例子在科學史上至少有好幾百個,尤其是化學界。諾貝爾(Alfred Nobel)不小心把硝化甘油和火棉膠混合在一起,發現了膠質炸藥,也就是他後來開發黃色炸藥的主要成分。佩克曼(Hans von Pechmann)於1898年無意中發現聚乙烯。魔術黏土、鐵弗龍、三秒膠、撥水劑和嫘縈纖維,都是意外產物,氦和碘元素則是無意中發現的。

在藥物中,盤尼西林、笑氣、治療脫髮的米諾第爾(minoxidil)、避孕藥和迷幻藥,也都是意外發現。威而鋼原本用途是治療高血壓,不是性無能。物理學和天文學中許多重大發現也在意料之外,包括天王星、紅外線輻射、超導性、電磁學、X射線等等。在實用發明中,噴墨印表機、玉米片、安全玻璃、康寧鍋和硫化橡膠也都是意外。

二次世界大戰結束後,史賓塞(Percy Spencer)為剩餘的磁控管尋找新用途時,意外發現磁控管把他放在實驗衣口袋裡的糖果融化了,因此發現磁控管可用在微波爐裡。1964年,潘奇亞斯(Arno Penzias)和威爾森(Robert W. Wilson)想去除他們剛開發完成的微波天線「雜訊」。在去除尋常的「臭蟲」後,發現有個背景「哼聲」沒辦法消除;更令人驚訝的是,這種雜訊的來源比原先預期強一百倍,甚至遍布整個天空,所以不是地球上或太空中的單一來源。最後他們才知道,他們發現了很早之前就有人預言過的大爆炸宇宙背景輻射。1978年,他們以這項發現獲得諾貝爾獎。

從這些例子和其他許多例子可以得知,科學界純粹為探索和瞭解事物而進行「純研究」有多麼重要。可惜的是,許多短視又受到誤導的人士(尤其是打算刪減國家科學經費的國會成員),把「純研究」視為沒有價值的自我思考,要求每個科學家為自己的研究工作提出實際或有用的理由,否則就不提供經費。這麼做絕對會使科學發展停滯。就連許多以這種方式運作的科學經費分配機構,通常也很重視傳統且「大致相同」的研究,而很少提供經費給有點冒險性的研究。電視主播或政治人物經常嘲笑沒有特定實際目標或用途的「純研究」。目光短淺又知識不足的人,經常干擾完整的科學審查過程,終止他們不欣賞的研究(即使已經取得真正的科學家認可也難逃魔掌)。

這種「科學一定要實用」的錯誤觀念最可悲的矛盾是,科學界的重大發現大多不在預期或計畫中,而是出自意外。大多數狀況下,科學家發現重要新證據不是出於刻意尋找,反而是在尋找其他東西時,重大發現意外出現。在科學界中,偶然力大多出現在研究人員準備觀察某種預期之外的新發現,到底意義何在時。巴斯德(Louis Pasteur)說過:「在觀察這個領域中,機會只留給準備好的人。」著名科學家和科幻作家艾西莫夫(Isaac Asimov)說:「在提出許多新發現的科學界中,最令人激動的一句話不是『我知道了!』而是『這很有趣⋯⋯』。」

亞平寧山脈中的意外

發現恐龍時代終結事件的證據,就是偶然和意外的經典範例。幾10年來,許多人都在爭論,白堊紀結束時恐龍滅絕的原因究竟是什麼,但卻不得要領而沒有結論。有人說是氣候變得太熱,也有人說是太冷。有人歸因於開花植物出現,但開花植物出現在白堊紀早期,比恐龍滅絕早了8000萬年,而且開花植物或許還有助於鴨嘴恐龍和有角恐龍等草食性恐龍出現。有人說是哺乳類吃掉了恐龍蛋,但哺乳類和恐龍同樣出現在三疊紀晚期(約2億年前),而且並存了1億3500萬年,哺乳類並沒有突然變得特別愛吃恐龍蛋。此外,甚至還有更誇張、更不合科學的說法,包括傳染病和疾病、憂鬱症和心理問題,甚至還有小報宣稱,是外星人綁架了全部的恐龍,甚至把牠們全都殺掉!

古生物學家傑普森(Glenn Jepsen)曾在1964年寫道:

恐龍為什麼滅絕?擁有各類專長的作者提出,恐龍消失的原因是氣候惡化(突然或緩緩變得太熱、太冷、太乾燥或太潮濕),或是飲食惡化(食物中的羊齒油等物質太多或不足,水、植物或攝取的礦物中含有毒素、嚴重缺乏鈣或其他必需元素等)。有些作者歸因於疾病、寄生蟲、戰爭、器質或新陳代謝疾病(椎間盤移位、荷爾蒙和內分泌系統失調或不平衡、使大腦縮小及智力減退、熱絕育、溫血動物在中生代時所受的影響)、種族老化、演化漸趨過度特化、大氣壓力或成分改變、毒氣、火山灰、植物釋出氧過多、隕石、彗星、小型哺乳類動物吃掉恐龍蛋導致基因庫流失、精神性自殺因素、熵、宇宙輻射、地球自轉軸移動、洪水、大陸漂移、月球由太平洋盆地脫離、沼澤和湖泊乾涸、太陽黑子、上帝的旨意、造山運動、乘飛碟而來的綠色小獵人、諾亞方舟裡沒有恐龍位子,以及古厭世主義等。

如果沒有獨立證據加以檢視,這些說法都只是猜測,而非科學。此外,這些說法只著重在恐龍本身,忽略了更重要的部分:白堊紀末大滅絕是全球性事件,影響了海洋食物鏈(尤其是某幾種浮游生物和許多種海洋動物)和陸地植物。範圍如此廣泛的滅絕事件需要更全面性的解釋,而不只是針對恐龍。事實上,如果它的影響如此深遠,食物鏈各階層有這麼多生物死亡,那麼恐龍滅絕應該只是最後結果,而非事件中最重要的部分。

年輕地質學家艾爾瓦瑞茲(Walter Alvarez),在義大利中部的亞平寧山脈進行地質調查時,白堊紀大滅絕的研究狀況就是如此(1976年,我在拉蒙─多爾蒂地質觀測所認識艾爾瓦瑞茲,當時他是沒沒無名的獨立研究者,而我是研究生)。他的研究主題跟恐龍完全無關,而是一直對這些岩石的結構地質以及它們如何傾斜與褶皺很有興趣。

他繪製義大利古比奧附近的白堊紀末期與新生代早期(古新世)石灰岩層分布圖及說明,結果發現有些不尋常。在白堊紀和新生代的分界處有一層特別的深色黏土,而非石灰岩(圖20.1)。白堊紀的標準地質縮寫是K(源自德文的Kreide﹝白堊﹞),第三紀(新生代中6600萬年前到240萬年前)的縮寫是T,所以當時把這層黏土稱為KT界線。後來地質學家廢除「第三紀」,改用古近紀(Paleogene)來稱呼6600萬年前到2300萬年前的這段時間。因此不再稱為KT界線,而是KPg界線。

20_1
Photo Credit:八旗文化
圖20.1 義大利古比奧的KPg界線特寫。硬幣處為高銥濃度的邊界黏土層。下方是白色的白堊紀石灰岩,上方是古近紀的滅絕後岩層。(圖片授權:Wikimedia Commons)

猜你喜歡


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

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


猜你喜歡