Meta 尋奇：工程師的內部觀察[0]->技術宅的你會好奇的事
自從 2020 年 9 月，我為了 Facebook （現改名為 Meta）的工作從荷蘭搬來英國也已經超過三年，而且前陣子 2023 年十月換工作後也差不多過了三個月，這段時間不管是與 Meta 前同事們間閒聊，或是回荷蘭時與朋友們之間談論近況，總是會聊到一個主題： Meta 的文化與其它公司有什麼不一樣，越聊越覺得想把自己的一些經驗與觀察寫下來：不管是我懷念的也好，討厭的也罷。
所以，你誰？
我於 2014 年從中正大學資工所畢業後，在臺灣工作了三年左右，主要在新創工作，一開始以後端為主，但後來不可避免地開始碰到了前端、資料工程，乃至於 DevOps 等不同的面向，對於我後續職涯的發展有著不小的正面影響。
在 2017 年時，運氣不錯的我拿到了荷蘭 Booking.com 的 offer ，並於年底搬到阿姆斯特丹，在約莫一年後又加入了當時剛在荷蘭設辦公室的英國公司 DAZN ，成為該分部的前 8 名員工之一。
而在 2020 年全球因為疫情封城之際，我幸運地拿到了英國倫敦 Facebook 的工程師 offer ，並於該年 9 月搬到了英國。一開始是在 Oculus (爾後整併改名為 Reality Labs) 負責 VR 裝置上測試相關的底層架構，之後又輾轉加入過 Messenger Desktop 以及 Messenger 客戶端底層系統的團隊。
在這篇文章裡，我想先從最表面的觀察開始：以我一名小小工程師的視角來看，在 Meta 裡工作，技術層面與工作環境上，與我待過的其它公司有什麼不一樣的地方呢？
自己的系統自己寫
對於工程師來說，對於 Meta 的印象，除了很多 bug 的服務外 (?) ，可能就是其所開發並發佈的各種開源工具與框架：假如你是前端工程師，那你可能會想到 React ；假如你是後端工程師，那你可能會想到 GraphQL (呃，會有人想到 Hack 嗎？)；假如你是行動端開發者，那你可能會想到 React Native；假如你是資料工程師，那你可能會想到 Presto ；假如你是 AI 從業人員，那你可能會想到 PyTorch 或是最近很紅的 llama LLM 等等。
但真正進來 Meta 工作之後，會發現上面所列的不過只是冰山的一角罷了，因為內部系統絕大部份都是為了因應公司的需求，而完全由公司員工所開發的。不管是專案管理、 A/B 測試、效能量測、資料視覺化、版本控制、持續測試、雲端開發平臺等等，都是由公司內不同的團隊開發出不同的工具，來滿足我們自身的需求。這些內部系統的完善程度以及多樣性之高，高到有一些 Meta 前員工在離開公司之後，創業時直接把公司內部的系統當作題目來作。
而身為一個工程師，令人興奮的是，這些系統的原始碼都是你有權限看得到、有權限去修改的！（大多數時候啦，有些比較特殊的系統不一定是每個人都看得到，或者像是先前公司改名那樣只有極少數人知道的事）
事實上，在剛進公司的一段時間，大家都會需要參加所謂的 bootcamp 來熟悉公司內部的運作，而軟體工程師前幾個禮拜的工作，便是上課以及完成由各自的 bootcamp mentor 所選擇，公司內部各個不同的 team 所提供的 bootcamp tasks ，像我一開始除了一些簡單的 refactor 之外，還修過公司內部 oncall 系統的 bug 。
當你正式加入 team 之後，也還是可以利用自己的時間去改其它系統的 code ，很多時候負責該系統的 team 可能還會很歡迎你幫他們解決他們沒時間作的功能、沒空修的 bug 呢。
另一方面來說，這樣的自由有好有壞：有時你會發現本來想修的 bug 已經有人修好了，讓我印象最深的是有一次 Messenger app 發生無法使用輸入法的情況，正想跳下去自己修的時候，就有臺灣同事找到了對的 team 對的人幫忙修好了；有時你會發現自己負責的功能莫名其妙出包了，最後發現是有主管不明究理地請底下的工程師 approve 他的改變，導致全球上百萬不該看到這個 Proof of Concept 的使用者開始使用了這個功能（然後就被我默默寫進履歷裡）。
裡面的開發環境同樣也是獨樹一幟，就如同前述，有著自己的版本控制系統，同時為了實現 monorepo ，還特地用 Rust 寫了個 on-demand 的虛擬檔案系統 ，另外像是需要與資料庫連接的系統，為了效能同時也為了防止資料外洩，只能從 VSCode 裡隨選隨開一台 server 來作為你的開發環境，搭配上公司內部只有一個主 branch 的版本控制流程，要多工同時作不同的功能只要新開一個 VSCode 視窗即可，甚是方便（能不能作完就是另外一回事了），而在我離開前，也有幾個著重在將 mobile app 開發搬到遠端開發環境的專案在進行。加入新工作後，什麼都要自己設定，難免還是有些懷念 Meta 的開發環境。
牽一髮動 20 億人（其實不會啦）
提到前一段那個百萬使用者的故事，就不得不提到對我而言 Meta 最大的吸引力：龐大的使用者群體。我先前在臺灣的工作經驗主要都在比較前期的新創公司，會接觸到使用者的數量級，當然無法跟 Facebook 、 Messenger 、Instagram 、 WhatsApp 這些服務相比。
不過實際上，真正會碰到純技術 scaling 問題的專案與其他的專案相比，數量上簡直是滄海一粟，理由也不難想像，因為這些問題大多數都在 infra 端就被幾個精兵團隊解決掉了，多數的工作主要則是如何在這些基礎系統的地基上，建構出商業問題的解決方案。當然，就如同前一段所說，你真的感興趣的話，也是可以投入不少時間去閱讀文件、原始碼、 Workplace （基於 Facebook 的工作協作平台）上的各種貼文，去研究特定的系統怎麼運作，只是大部分時候你應該都會忙得不可開交，更遑論有空閒可以去做深入研究了。就我觀察，大多數人在公司文化的驅駛之下，通常在實作時會更著重在產出的速度上，因此也讓我見識到了不少世界奇觀（這我會留待下一篇文章專門來討論）。
撇開技術層面不談，即使是釋出新功能時也鮮少會一口氣開放給全球的使用者，幾乎所有的功能在規劃階段，都需要考慮到我們該怎麼評估功能的成效、該先開放給哪些使用者、該如何蒐集資料等等。
為了因應這樣的需求，公司內部同樣有相對應的 feature flag 系統，可以基於各種不同的條件去決定是否執行特定部份的程式碼（毫不意外地，這同樣有前員工拿來作為自己新創的題目）。在長年的開發下，這個系統已經累積了不少可以用來判斷的條件，除了可以判斷帳號是否為內部員工這類讓人又愛又恨 [1] 的條件外，幾乎你想得到的使用者資料都可以被作為判斷的條件。
「 燒等幾勒臺羅：sió-tán chi̍t-ē [2]，這樣你們員工不就把大家的資料看光光了？」
在公司內部，你在釋出會用到使用者個資的新功能前，都會經過法務等部門的審查，平時工作在存取任何有使用者資料的系統時，都有權限的管控，當然不乏有人試圖用其它的方式偷看使用者的資料，但這些案例最終的下場都是當天直接被開除。
主委加碼：至於「上海總部在作針對臺灣使用者的言論審查」這種跟疫苖裡有 5G 晶片同等級的幻想文，可以就只留在 PTT 和臉書 (??) 上就好嗎？
除了面向一般外部使用者的系統，我在 Ｍeta 的期間其實更多的是負責內部系統的開發，如果你問我的話，我會跟你說這要比寫任何會影響到我爸媽 (?) 的功能還要有壓力得多，畢竟你所服務的客戶，就是坐在你左右，每天工作都忙得焦頭爛額，還要忍受你上的新功能，跟你一樣挑剔的工程師們。而且即便是內部系統，在全球有數萬名員工（雖然裁了不少……）的 Meta 裡，使用者基數也是相當地可觀，比方說我之前在 RL 時負責了一個 infra 專案，掐指一數，大概也影響了近 30 個不同的 teams 、上百名工程師（好吧這數目似乎不是掐指就數得出來的），更是影響到了每天上萬次的 builds 。
然而，這些特點，對我來說，僅止是在 Meta 工作最表象的體驗，對我來說，真正讓我感覺 Meta 與其它我先前工作過的環境不同的，是它的文化，而這正是我想在下一篇細談的主題。
[1] 又愛又恨的原因在於任何功能幾乎都會先開給員工內部使用，雖然可以搶先玩到像 Meta AI 等有趣的功能，但同時也會有很多充滿 bug 的功能，所以不少同事還會特別申請一個新的臉書帳號，以免影響平常的使用體驗。
[2] 感謝 Iàp Sîng Gān 網友提供臺羅拼音