論人與動物:應如何思考對待動物的標準?

論人與動物:應如何思考對待動物的標準?
Photo Credit: Vasily Fedosenko / Reuters / 達志影像

我們想讓你知道的是

多年來人類如何對待動物爭論不休,每逢出現爭議,大眾乃至公共知識分子取態較為極端,然而,難道人類對待動物的標準和界線,中間沒有更妥當的分寸嗎?

動物天堂or地獄?對待動物的標準真要如此極端嗎?

人類如何對待動物是個爭論不休的問題,由公共議論乃至學術研究數十年來不絕,可以這樣說:只要人類一天仍與動物「相處」,一天也會有諸如此類的價值爭論。

每年6月桂林狗肉節、9月日本太地町「 海豚屠殺」如常,2016年有簡稚澄醫生為貓狗議題服毒自殺,辛辛提那動物園槍殺大猩猩救四歲男童事件,還有包括香港一再熱議葉劉淑儀「穿皮草」,全球各地的虐待動物事件,爭取動物權益的呼聲。可見,從生活似是小事的「食肉」反思,乃至社會文化和法律如何看待人類與動物的關係,不僅是哲學和科學糾纏不清的價值討論,都可以是日常很「貼身」的課題(葉劉強調若同意吃乳鴿,不能反對她穿皮草)。

筆者早於2014年8月撰寫〈我們就愛吃豬吃魚不吃狗?〉(下稱〈我〉)一文,提出坊間較少考慮「有等差善待動物」的觀念,隨時代演進,人類應一步步、合情理地擴展善待動物的範圍,猶如人類討論相處上「等差愛」和「平等愛」的不同方向。可是大部分對動物議題的評論,都偏向兩極化,認為按等差地對待動物就是錯誤,就是「物種主義」(speciesism),就是偽善。慶幸,筆者在2015年11月碰巧遇見〈開放吃狗肉,並不會保護我們的毛小孩。〉一文,作者以社會學和國際視野主張可有「等差」地對待動物,儘管那篇文章主要討論「吃狗肉」的爭議,以反駁台灣哲學作家與哲媒搞手—朱家安刻意引起爭議的文章—〈要保護我們的毛小孩,就開放吃狗肉吧!〉,但分析的方向筆者頗為贊同。

就所謂「平等 / 一致」的思考方向,以食肉為例,不少人主張:要麼就所有動物通通都「可吃」,要麼就所有動物通通都「不可吃」;或是,要麼所有動物都「具有」道德地位,要麼所有動物都「不具有」道德地位。好像一旦賦予動物道德地位和權利,就須「等同」人類所擁有的一樣,否則就不一致,就有問題。又好像只要在善待動物上不夠「平等」,就相當於人類正在殘害動物。

然而,你會否這樣說:

由於你沒有像愛親人一般去愛你的朋友,所以你正在傷害那些朋友?

不錯,這想法很古怪,一看就知不妥,有等差其實不表示有問題,正如你成不了耶穌愛世人,並不表示你是惡魔要遺禍人間。可是不論香港、台灣,我們社會很多討論動物議題時,大致上在這種思維框架之下進行,年復一年地爭論著。(筆者並不排除人類社會在N年以後,「有可能」實現美好的平等世界,凡事「有可能」)

過往愛護動物的哲學「聖經」屢遭挑戰

我們身處的時代,一切問題不在於簡化談論動物「有 / 無」道德地位和權利,也不在於「每一種」動物都要有平等對待,卻是即使承認「有」必要賦予動物道德價值,箇中的程度與分寸在那裡?另外,真是要「每一種」動物都平等對待嗎?還是按不同種類的動物有「妥善的」差別對待呢?就這樣的思考,筆者認為德國思想家普列希特(Richard David Precht)在著作《我是誰?》(Wer Bin Ich?und wenn ja, wie viele?)之中,寫關於動物的討論,非常值得我們好好深思,以下反思也可視為〈我〉文的延續。

首先,站在極端愛護動物的一派,大都援引彼得.辛格(Peter Singer)和湯姆.雷根(Tom Regan)的理論,以人類某派哲學思想「賦予」平等對待動物的利益(interests) / 權利(rights)。筆者傾向詳述辛格的思考,而不是雷根,主要是雷根的思考在於要人們「相信」動物存在「本有價值」(inherent value)、「生命主體」(the-subject-of-a-life),可以是比較漫長的概念糾纏。而辛格就《動物解放》(Animal Liberation)的思考相對明確一點,是對是錯則屬後話了。

談起辛格,我們先看他一段浪漫的故事,那一次經歷啟發他不再吃肉,而且寫下《動物解放》的經典著述 。1970年,辛格正在牛津大學食堂享用那美味的牛排餐,那時他仍未嚴肅思考吃肉乃至人與動物的價值問題。辛格滿心歡喜進食牛排之際,看見同枱的學生把肉撥開,向來熱衷討論是非對錯,甚麼都納入思考的辛格對這動作萬般好奇,這學生為何好像很討厭肉類呢?這位學生叫理查.科申(Richard Keshen),後來當上加拿大布列頓角大學(Cape Breton University)的哲學教授。當辛格詢問他吃肉問題時,科申斬釘截鐵地強調自己永不吃肉,因為吃動物在道德上站不住腳,並歡迎辛格提出他不同意見。

怎料,這次以後,辛格認真地反思人類吃動物的問題,他認為動物的外觀形態和理性思考能力,並不是人類可以吃動物的理由,因為他認同邊泌(Jeremy Bentham)的說法:

「有一天人們將會明白,腿的數目、體毛的多寡都不足以構成如此對待一個有感受的生物的原因。但是,什麼會是不能逾越的界限呢?是說話的能力嗎?可是一匹長成的馬,或一隻成年的狗比一個剛出生一天、一個星期或甚至一個月的嬰兒,都要來得聰明,社會能力也更好;而且就算不是如此,那又能改變什麼呢?

『問題並不是他們是否會思考或說話,而是他們會不會感到痛苦。』("The question is not, can they reason? nor, can they talk? but, can they suffer?")」

由此,辛格得出一種強烈的價值判斷:人類無論外形乃至有思考能力,這些條件也不成為可以吃動物的道德優越性,即使剛出生嬰兒知性低於一頭豬,還是不能吃他,至基本他「有感受快樂和痛苦的能力」。

如果講求最極端嚴格的善待動物,難道要禁絕吃昆蟲?

筆者絕對明白,且別論世界每一處地方,要生存下來是否都「能夠」不吃肉,至少在先進的文明城市應該可以,只要做好素食的教育、文化、制度配套,吃肉不是人類生存必須的,實踐只是時間問題,是「應然」。可是,我們討論的是「現在、此刻」,在未能完全實踐的時候,我們事實上是在有等差地對待動物,尤其更好地對待貓狗和瀕臨絕種動物,甚至,上星期在慘劇中遭槍殺的大猩猩,人們為牠設置悼念活動,這根本不值得批評。且別論我們基於甚麼原因不吃貓、狗、豬、牛、馬、羊、大猩猩、黑猩猩、倭黑猩猩⋯⋯大概,吃掉上述動物,部分人的反感相當強烈。可是若說吃雞,大家還是會有點掙扎,吃老鼠掙扎可能又再少一點,吃田雞的掙扎就更少了;但是,魚是否一定不能吃呢?好了,那昆蟲又如何?最近《立場新聞》報導澳洲認知科學家Andrew B. Barron和哲學家Colin Klein的研究指:「昆蟲既然擁有處理資訊的能力,而類似的能力又和脊椎動物的中腦結構相似。由此或可推論出昆蟲也可能擁有一定程度知覺。」假如保守起見,是否「應該」立法禁止捕捉和進食昆蟲?

一旦以痛感或知覺的基礎推論,又要「當下」對不同動物作出價值判斷,要堅持賦予「平等」的道德地位,即使暫時撇開法律處理,要自圓其說也絕不容易,也牽涉不少科學證據。

學者駁Peter Singer,動物「利益」不等於「權利」

台灣國立中央大學哲學研究所副教授李凱恩寫的〈Singer動物解放倫理學批判研究〉,就辛格以動物痛感和利益,藉此賦予動物平等權利的推論提出明確的反駁,節錄如下:

「在面對『動物對待』的議題時,Singer 基本上是以『the having interests argument for animals’ rights』來予以回應:

  1. 由於動物具有感受痛苦的能力,因此牠們具有避開(非必要)痛苦的利益(interests)。
  2. 由於動物具有避開(非必要)痛苦的利益,因而牠們具有相應的權利(rights)。 ⋯⋯⋯

然而,『the having interests argument for animals’ rights』有以下的缺失。首先,在此論證中,『having interests』與『having rights』之間似乎存在著一個鴻溝(或似乎缺少必然連結)換言之,『having interests』無由必然得出『having rights』。 ⋯⋯

面對 Singer 的上述說法,我們不禁要質疑:有什麼理由得以支持我們將『感受痛苦的能力』作為『給予某一生物之利益平等考量』 之充分必要條件?為何我們不(像康德一樣)擇定『理性』(reason)以作為『給予某一生物之利益平等考量』的判準?或者,為何我們不(像Paul W. Taylor一樣)擇定『生命』(life)以作為「給予某一生物之利益 平等考量」的根據?就實質而言,Singer僅僅提出上述的說法,並沒有進一步提出任何可接受的理由來支持此一說法,這是其理論構作上的缺失。⋯⋯

『感受痛苦的能力』只是一項輔助性的工具,其目的是要保全生命,故其本身並非我們的真正考量對象。就理論而言,進化是有可能產生某種動物,其得以不靠『感受痛苦的能力』而能夠保全生命。J. Baird Callicott則更直截地表明,有許多種類的動物是不具感覺能力。若果如此,則Singer將『感受痛苦的能力』視作『給予某一生物之利益平等考量』的判準,其作法並不圓足,因為,這樣做將會把某些動物給排除在道德考量的範圍之外,這有違Singer自己的基本主張──『All Animals Are Equal!』。 」

善待動物不能「單憑」直覺,但完全不顧直覺又不妥,科學有啟示?

說到這裡,如果我們可以不同意、不相信辛格甚至雷根的「理論 / 說法」,我們還是每天跟這些動物共存,喜談價值和反思的人,能夠不作判斷嗎?有人不小心弄傷、弄死街鼠時,會像弄傷、弄死流浪貓狗一樣「嚴陣以待」的處理、討論和反思嗎?難道由於批駁哲學家以往的說法難以成立,我們將對待動物的判斷,保留至100年後有更佳的答案再說?若極端的二分思考無助我們這個時代「恰當」地對待動物,那還有甚麼標準呢?不就是變相支持任意對待動物,要吃便吃,要虐便虐,要殺便殺嗎?

當然不是,儘管,人們「僅僅」以道德直覺判斷吃甚麼動物直覺較難受(嘔心),並不是一個對確的理由,因為對不同動物的主觀感受人人不同,你認為吃掉不傷心的,別人可以很傷心,甚至各種文化與宗教信仰也有一定影響,平等對待眾生似乎是一種非常遙遠,甚至含糊不清的理想(究竟那時會是怎樣的世界?)。

但無論依據痛感,抑或憑人類與動物互動的經驗,在人類未能實現對待動物、眾生平等的理想之前,參考基因研究、神經科學,可以姑且在當下有較確當的做法,也更有利推進我們擴大把動物列入關懷善待行列。

在此提示一下,當我們說「動物」時,回到生物學的分類,大致分為:界 (Kingdom)、門(Phylum / Division)、綱(Class)、目(Order)、科(Family)、屬(Genus)、種(Species)加以分類。單就「動物門」(Phylum)的生物就有45門,並有「綱、目、科、屬、種」等分支,假如你要善待動物,你要善待「那些」動物的「主體」?如何判斷牠們的「痛感 / 知覺 / 意識」?

還是,你平日所說的「愛護動物」,只不過是說一般親近你的哺乳類動物?

有等差也是善待也是愛,只是層次不同

不錯,基因、演化、神經科學各有其參考性,雖然基因研究顯示,人類與黑猩猩很可能有共同演化祖先(人類與黑猩猩基因遠比獮猴接近),可是,若以演化史塑造的親切感來說,我們對貓狗更感親切。但自詡身處文明世代,我們可以根據不同的科學證據,有各種善待的做法,從盡可能減少動物痛苦,以及「隨時代」逐漸擴大愛護動物範圍,不必每種動物完全一致。

松澤哲郎是「比較認知科學」(Comparative Cognitive Science)的學者,他在著作《想像的力量》提及:

「『人科,人屬,現代人種』這種說法,給人一種『人類是一種獨一無二的特別生物』這種感覺。很多人誤以為人類這種生物,在生物分類學上是一種單科單屬單種的存在,但這卻是個錯誤的觀念。在生物分類學上,目前通用的觀念是認為人科底下共有四屬—換句話說,人科底下不是只有人屬(Homo)還有黑猩猩屬(Pan)、大猩猩屬(Gorilla)以及紅毛猩猩屬(Pongo),總共四屬。

還有,黑猩猩不是只有在學術領域被列在人科底下,在法律上也是日本的法律,已經把黑猩猩分類在人科裡面了。比方說,為了呼籲大家『這個物種已經瀕臨滅絕了,請大家一起來保護他們吧﹗』而訂定的〈物種保存法〉或〈動物愛護法〉等法令裡,列有著瀕臨絕種動植物的物種清單。裡面,就以明文寫下了『人科黑猩猩』。因此,黑猩猩不是只有在學術領域上被分類為人科,在法律面也是列在人科之下。請各位千萬要記住,『人科一共有四屬』。」

的確,過往我們在討論人類與動物的關係,很少建立在確切認識動物本身,很少把思考「也」投放在科學發現之上。事實上,當部分大眾仍對「猩猩」的印象停留在遠比人類低等的動物,對牠們的關心甚至及不上貓狗。現在我們知道,不但學術研究以至法律將三種猩猩屬歸入「人科」之中,而以往實驗結果顯示倭黑星星坎奇(Kanzi)學會使用265個符號的鍵盤,大猩猩可可(Koko)在二十多年訓練後,可掌握上千個美國手語辭語,亦能理解2,000個英文辭。那麼,比一般有更高理解能力、意識能力的動物,乃至整個物種,我們應如何對待?要提升到甚麼層次?

普列希特雖然認同要好好善待猩猩,同時對贊同大加愛護猩猩的「大猿計劃」,也整理出一些反對意見:

「單單談論保障人猿身體不受傷害、自由發展其位格等權利,卻不同時思考他們該如何盡『義務』,是否真的有意義呢?例如,這些被視為人類群體一員的人猿們,未來該如怎麼繳稅和服兵役呢?就算不用這種語帶諷刺的論調好了,我們還是要問,若是有一隻猿猴違反了那些不是他們自己接受、而是由我們賦與的『人權』的話,該怎麼辦呢?我們如何評價黑猩猩之間的『戰爭』,以及發生在人猿世界中『殘暴謀殺』和『同類相食』的行為呢?⋯⋯

為大型人猿的人權請命只是第一而已;而這個嘗試已經獲得了初步的成功。1999年10月,紐西蘭政府正式賦與了在國內生活的約30隻人猿不可侵犯的生命權;英國也自1997年開始禁止對大型人猿的任何動物實驗。這是個重大思想改變的開始嗎?動物和人類之間古老的界線是否不再存在了呢?與其關注傳統的道德(哲學),認知科學難道不應該探討這類現象嗎?如同我們所看到的,腦部研究在脈衝與反射、反應和處理之間的關係上劃分了全新的等級制度。」

人類與動物的關係不像「數學公式」,我們應思考標準的「分寸」在那裡

總體來說,普列希特在書中許多篇章,並不是在妄下判斷,而是在傳統哲學與新近科學認知之間,對待林林總總的動物,探討有沒有更寬濶的眼界,在「殘忍任意」與「愛護關懷」之間,當下有沒有一些界線或尺度可以「首先」妥善實踐,再看日後文明的進程?(例如:增加愛護動物的範圍,自此列不再殺害 / 未受保護的動物,阻止殘忍的屠宰方式)

既然人類與動物之間,似乎「一時」難有絕對明確的道德標準,當法律乃至道德討論時,具體認識再訴諸按等差的做法,大概仍是妥當的價值取態。

例如吃肉問題,一方面,筆者贊成選擇性讓貓狗得到更好的善待,甚至高度重視海豚的保育,當然停止屠殺進食牠們,此外,一些商人販賣高級衣飾殺害貂等動物作「皮草」,也應該禁止;另一方面,筆者亦認同以教育制度和配套努力推進素食文化,嘗試兼及不吃牛、豬甚至雞,同時,在「人造肉」方面,政府也應大力投資相關科技,以盡快取得成果,舒緩全球社會吃肉的心理困難。(緊記:道德應然,可以是長遠理想,不表示實踐價值毋須考慮技術困難)

而在人與動物的生命取捨上,一般情況大可以人類作為優先考慮,暫時親疏有別還是合乎情理的。但是,假如我們碰上的是毫無情理的屠夫,用變態的方式濫殺象、殺狗、殺犀牛,是否應該因為他是人類,智力或意識能力比較高等,便要善待他呢?當然不是,對此必須交由司法制度嚴厲判刑。

是故,與其逐年無休止地辯論動物「有 / 無」權利,「要」保護動物,倒不如除了哲學思辨以外,多就科學發現,價值實踐的技術問題考慮,留意程度、分寸、層次在那裡,何必不弄清如何「平等」,便氾濫地口誅筆伐呢?善待動物的方式不一,但善意如一:不平等也可善待動物。(本文就專題化作出修訂)

參考資料:

核稿編輯:周雪君


猜你喜歡


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

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


猜你喜歡