從德州心跳法案到優生保健法,探討胎兒生命權和生育自主權(下)

從德州心跳法案到優生保健法,探討胎兒生命權和生育自主權(下)
Photo Credit: iStock

我們想讓你知道的是

生育只是藉由生養下一代作為個人的生活選擇,婦女並無義務上繳身體自主權,只為成為報效國家的生產工具,或延續他人生命。

文:Betty Chen

捍衛生育自主權的全面反擊

反墮胎人士以心跳作為生命跡象的共識遍及全球。然而,德州「心跳」法案的名稱卻不甚貼切。任教於美國婦產科學院(American College of Obstetricians and Gynecologists)的墮胎醫師維爾瑪(Nisha Verma)指出,超音波顯現的胎兒心臟活動其實只是電脈衝(electrical impulses),並非真正的心跳。「心跳聲來自心臟瓣膜的開合,而妊娠六個星期的胎兒尚未發展瓣膜。」

任教於加州大學(University of California)的婦產科醫生科恩斯(Jennifer Kerns)表示,「六個禮拜的孕期無法偵測明顯的心跳活動,而這也只是確認懷孕狀況的其中一項指標而已。」而生育權倡導組織Avow Texas執行長阿拉姆比德(Aimee Arrambide)認為,此法案的名稱「刻意煽動大眾的情緒,但實際只是嚴重違憲的墮胎禁令。」專家認為該法案不精確的醫療用詞,包含使用胚胎(fetus)而非受精卵(embryo),皆有誤導嫌疑。

再者,墮胎產業資本化的擔憂與實際情形正好相反。根據女性政策研究院(Institute of Women's Policy Research)統計,人工流產有效減少青少女懷孕,並提供非裔女性等弱勢族群完成學業的機會。現任華盛頓公平增長中心(Washington Center for Equitable Growth)的代理經濟總監(interim chief economist)巴恩(Kate Bahn)指出,如果沒有人工流產的自由,「將影響勞動市場的動態平衡。自主權是人們參與經濟的重要因素。」

墮胎限制尤其影響已深陷財務狀況的少數族群,任教於明德大學(Middlebury College)的經濟學教授邁爾斯(Caitlin Myers)表示,尋求流產需求的女性「四分之三為低收入戶,一半已有養育重擔,超過一半面臨失業或分居困境。」而離開研究(Turnaway Study)數據也顯示,無法終止孕期的女性,其逾期還債的機率高達78%,信用不良紀錄的案例則為81%。

事實上,經濟狀況更弱勢的女性連人工流產、防止懷孕的措施都無法觸及。反墮胎團體對胎兒生命的關注似乎只停留在子宮中,並不重視出生後其母親是否有足夠資源養育一個小孩。然而,選擇中止懷孕的女性則在深思熟慮後,評估自己不適合撫養小孩,才決定人工流產。因此,女性主義團體並不認為優生保健法規定的強制諮商制度及三日思考期有所助益,反而以繁雜手續徒增門檻。

台灣目前將聯合國的《消除對婦女一切形式歧視公約》(以下簡稱CEDAW)國法化,CEDAW委員會第21號一般性建議提到,由於女性為懷胎哺乳的直接對象,就算男性為精子提供者,是否生養子女也只需與伴侶協商,不應受到配偶、父母、政府等限制。相較之下,優生保健法要求「施行人工流產,應得配偶之同意」,忽視受暴婦女為取得同意再次面對施暴配偶的風險。另外,公約規定「妨礙婦女獲得適當保健的障礙」都該消除,然而國內《刑法》第288條仍未將墮胎除罪化:「懷胎婦女服藥或以他法墮胎者,處六月以下有期徒刑、拘役或一百元以下罰金。」

由此可證,自稱「生命派」(pro-life)的擁護者並未對所有生命一視同仁,不但未能考量胎兒出生後其個人法益將受母親身心、經濟狀況影響,也阻礙婦女掌控生育自主的身體權利,部分人士甚至支持死刑或反對兒童福利制度。其次,墮胎是特殊情況下的必要措施,婦女並非樂意尋求人工流產。將生育自主視為道德汙點並假設性氾濫的結論,與現實情況天差地別。

最後,低生育率的罪魁禍首並非生育自主權,而是建立在性別歧視之上的人口政策。過往女性無法輕易拒絕婚事或終止孕期,因此政府得以完全控制生育率。身體自主權與國家政策本不該衝突,如今婦女的身體和角色逐漸脫離父權社會的附屬,社會公民不應藉由限縮個人權利提高生育率,而應從改變與父權體制的相處模式,以提高女性的生育意願。

保障生育權、提高生育率的最佳解方

總體來看,大多美國民眾都支持生育自主。據美國智庫皮尤研究中心(Pew Research Center)民調,59%受試者認為多數情況下,婦女擁有墮胎權。路透社(Reuter)數據亦顯示,52%受訪者同意大多數人工流產都應合法化,僅有36%視之非法。而此次德州心跳法不但悖於大部分民眾意願,其禁止婦女妊娠六周後墮胎的規範更強人所難。根據美國民權聯盟數據,德州約85%到90%的墮胎女性至少懷孕6週。察覺自己懷孕不如想像中容易,女性需謹慎記錄經期、經期固定、洽詢醫生,才能確認有孕在身,更別提忙於工作的勞工婦女。

因此,人工流產的權利不應受法律阻礙。生育只是藉由生養下一代作為個人的生活選擇,婦女並無義務上繳身體自主權,只為成為報效國家的生產工具,或延續他人生命。筆者認為,若無法取得異性戀婚姻中的雙方共識,沒有做好養育小孩的準備,即可尋求人工流產,也可避免小孩出生後無妥善照顧的窘境。

若男方想要小孩卻被女方拒絕,可尋求代理孕母作為替代。美國疾病管制暨預防中心(CDC)統計,2015年有5,521位嬰兒來自代理孕母,成長速度倍增。就連謹慎的紐約州也在今年2月15日通過代孕法,以完善制度劃分代孕雙方的權利和義務。推動台灣代孕解禁的陳昭姿,也終於等到《人工生殖法》於2020年5月一讀通過。雖然該法以妻子無法分娩作為代孕前提,卻已是跨越科學、倫理議題的一大里程碑。

代孕爭議確實存在,諸如孕母遭公司剝削、非人待遇的問題,以及生父母與小孩的基因、女性尊嚴或工作權選擇等,但代理孕母的身分確實能夠解決無法懷胎的男性生育權,包含同性戀男性;而孕母也能藉由生育翻轉經濟困境。若未有其他方案供上述對象選擇,則不該完全禁止代孕。

若女方想要小孩卻被男方拒絕,則女方依然有權利生下嬰兒。先前提及CEDAW公約認為,由於女性是懷胎哺乳的直接對象,因此可自行選擇是否生養小孩。然而,若該女性需經濟補助,讓其懷胎的男性應負責前者在懷孕期間的金錢損失,才能彌補女性在生育期間及往後的身體負擔。

可以生育的生理構造不應成為女性的劣勢,反而是傳承經驗與文化的珍貴寶藏。孕育生命的子宮不該受社會掌控,相反地,後者應建立性別平等、友善育兒的環境。舉例來說,台灣產假只有八周,遠低於國際勞工組織建議的14周;有喜後必須犧牲事業的照顧歧視、雇主和執政單位的「母職懲罰」更令人壓力倍增;私領域中女性仍肩負照顧家務和情緒勞動,「喪偶式育兒」才是生育率低落的主要原因。

生命派和選擇派(pro-choice)把人一分為二,但個人對於墮胎的意見取決於信仰、道德、政治、現實情況等各個因素。捍衛胎兒生命的擁護者也應該尊重懷孕女性的生命,而保障自由的法律更不該侵犯個人隱私權及生育自主權。

延伸閱讀

責任編輯:蕭汎如
核稿編輯:翁世航


猜你喜歡


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

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


猜你喜歡