被炒Google員工錯了嗎?關於男女差異的一些迷思

被炒Google員工錯了嗎?關於男女差異的一些迷思
Photo Credit: Mike Blake / REUTERS / 達志影像

我們想讓你知道的是

從Google外洩的一份備忘錄引起爭議,被開除的員工指兩性在公司內的差距,有部份源自男女的生理差異,這說法有根據嗎?

Google軟件工程師James Damore撰寫一份內部傳閱的備忘,題為〈Google的意識形態迴音室〉。備忘批評該公司的兩性平權政策,認為其做法忽略了男女之間的生理差異,亦認為不應盲目追求多元化。備忘傳出後引起軒然大波,有人批評Damore「反多元」,同時亦有人支持其說法。

昨日Google行政總裁Sundar Pichai指該份備忘暗示,女同事生理上有令她們較不適合其工作的特徵,並不符合Google的基本價值和行為守則,因此將Damore開除。Damore則認為Google開除他的決定不合理,正研究採取法律行動。

先說明一點,我不同意Damore的備忘當中不少內容(下文詳述),但如果Google單憑這份外洩的備忘而開除他,這決定同樣有問題,而且無論Pichai如何宣稱尊重言論自由,也難以令人信服。言論自由的確不應包括歧視言論,然而要減少歧視,特別是植根深處的偏見,首先需要更多對話及接觸,我認為Google今次的做法只會招來反彈。

另一方面,Google須考慮到女性員工面對歧視時的感受,應重申支持平等,以及會解決公司內男女比例不均的問題——據統計,Google內女性分別佔技術和領導職位20%和25%。不過我並非想寫企業管理的文章,這一點就此打住。本文主要想討論的,是男女之間的差異,是否足以說明科技公司在員工數量以至薪酬上的差距,以至社會上各種的性別差距。

兩性有差異不代表沒有歧視

在Damore的備忘中,他強調自己是在討論兩性整體上的差異,認為這個差異可以解釋兩性在工作數據上的差距,但他同時反對以偏概全地把一個組別的整體優勢,視為「整個組別都較優秀」。舉個例說,即使整體而言男性氣力較大,也不代表所有男性都會比所有女性更大力(合理到幾乎不必說明)。下圖出自他的備忘︰

Selection_182

Damore最主要的論點是,不應把所有差異都視作歧視結果,男女之間的生理差異可能是女性未能佔據各種職位50%的部分原因。他提倡把人視作個體而非群組的一部份(例如男性/女性)來看待。

先假設男女之間有他所提到的差異(這一點稍後處理),這個說法仍有其問題。就算兩性生理差異是科技界性別差距的部分原因,餘下「有待修補」的差距應該是多少?在差距如此明顯的情況下,宣稱「我們不必硬性規定男女比例各半」,就有轉移視線之嫌,至少忽略了女性在投身科技產業以至整體在職場上要面對的困難,可謂搔不着癢處。

此外,不把所有差距都視作歧視的所致,不代表社會上沒有歧視。除非Damore認為兩性差異完全沒有性別歧視成份,否則我們仍須比較各群組之間的差異,才可知道歧視造成的影響。「把人視作個體看待」說來好聽,但假如社會文化、制度本身並不公平,以致有些人「贏在起跑線」的話,單看比賽過程的「公平」無法消彌不平等。

兩性有甚麼差異?

兩性之間的差異真的有那麼明顯嗎?毫無疑問,兩性生理差異可以影響工作選擇,例如消防員對體力有一定要求,而女性能符合條件者較少,就未必是性別歧視所致,差異可能合理(也不能排除社會文化有部份影響)。不過對於體力以外的技能要求,性別差異又有多少影響?

Damore引用心理學中性格特質的研究指,女性平均而言對感受、美感較有興趣,男性的興趣則較多在意念、想法,又指女性對人的興趣較對物件為大。他認為這差異解釋了為何女性較傾向社交、藝術範疇的工作,而男性更喜歡寫程式,是因為這工作要求系統化思考,即使在軟件工程中,女性較多成為需要處理人和美感前端工程師。

他又認為女性的外向表現為合群,而非肯定斷言,而且女性較為友善,這令女性較難商討要求加薪、提出意見及領導公司。然而他強調這只是平均的差異,不代表男性不會面對同樣問題,所以一些針對上述問題的計劃只讓女性參與,就會排除有需要的男性。

最後,Damore指研究顯示女性較為神經質(neuroticism),較容易焦慮,承受壓力較低,可能導致Google內部調查中女性焦慮程度較高,以及更少女性就職高壓工作。

這些差異真的「純粹」?

雖然心理學研究要面對可重複性問題,不過在此我不打算探討個別研究的樣本、研究方法等限制(Damore引述的是《維基百科》,條目內文有提到若干研究)。我想指出的是,這類研究的最大限制,在於只能夠描述現有狀況,無法排除父權社會、文化的影響。除非不相信性別歧視存在(Damore亦表示不認為現時Google或社會「100%公平」),否則的話,以這些研究結果來「證明」兩性差異,有可能只是在複製原有的性別不平等和偏見。

例如,就算有調查顯示女學生對寫程式較少興趣,所以較少人選擇在大學修讀電腦,我們仍要追問,那是否因為社會上普遍認為寫程式(以致普遍理工科)是「男性」的喜好?且別忘記,女性在歷史上有很長時間被視為次等、不擅長思考、從屬於男性,與之相比,女性可謂「剛剛」才擁有相同的教育權利、投票權等,亦遠遠未達平等。

「天才」的偏見和性別定型

2015年在《科學》的一項研究,訪問了1820名來自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。

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


猜你喜歡