Meta 尋奇：工程師的內部觀察 (0.5) - 聽說 Meta 服務大當機了
聽說前幾天 Meta 的服務又再一次的大當機，除了導致怨聲載道外，也間接影響了其它服務的穩定性，像是最常見的 OAuth 登入，以及各家通訊軟體的流量激增。
咦，我怎麼說「又」呢？如果大家還記得的話，在 2021 年 10 月，當時同樣也有一次大當機 ，那次除了對外全面斷線外，內部系統同樣也無法連上，包含了事故管理系統，甚至連門禁系統也無法倖免 ，還記得那時正好是倫敦接近下班時間，在家工作的我就直接下班開吃爆米花看戲。
目前這次出包的原因還沒有公佈細節，如果大家對上次因為 DNS 問題而發生的大當機有興趣，可以參考 Meta 自己發佈的部落格文章，這裡我主要想把我回應臉友的留言內文稍作改寫，不談技術細節，來蹭蹭熱度。
我想大家可能會問： Meta 作為一間近乎壟斷中國市場以外社交媒體平臺的公司（ Facebook, Instagram, WhatsApp, Threads ），怎麼服務好像這麼不穩定？難道他們沒打算要招聘更多人專門來負責系統的穩定嗎？
首先我覺得第二個問題，我自己的看法是：沒有。當然不是代表說 Meta 現在沒有持續在招募，而是認為單純以穩定性為目標，是件很不 Meta 的事。從比較外部的因素來說，在祖克柏去年宣佈要將 2023 年作為 Meta 的效率元年 後，不管是公司的產出或是投資人的信心，都非常地正面，相信公司在這樣的前提下，肯定會維持相對高壓的精兵策略。
所以之前的 Meta 就不是如此嗎？跟我 2020 年加入時相比，我覺得在第二次裁員之後，公司內部的氣氛確實有更為高壓，在那之前 20-21 甚至 22 我覺得並沒有特別比其它地方壓力大到哪裡去（以我在的 Oculus 和 Messenger org 來看），精兵的部份我沒有什麼特別的觀察，但確實聽過一些比較資深的同事在說公司在疫情大舉徵才時 hiring bar 降低了一些。
其實 Meta 也養了一群專門到處調查潛在性能、穩定性問題的 Production Engineers ，如果有機會跟他們聊聊的話，就會聽到很多很有趣的問題與解法，比方說資料庫層面的 bug 、 Data centre 裡 load balancer 效能衰退還會不定時掛掉的原因等等，只是畢竟在公司裡還是少數，況且就如同前面所說，穩定與否就是生存者偏差：就算你再怎麼疊層架屋抄捷徑，只要系統沒有出事，就很難從客觀數據的角度去推動說需要重視穩定性、效能之類的改進。
這也可以回到第一個問題，因為不容易有好的立論點去說服公司專注在穩定性是有助於公司商業表現與成長的，在 Meta 的 Impact-driven 文化下，就很難得到該有的認同。
如果有認真寫過 PSC （績效自評）就知道，很多時候需要思考的，便是將自己所作的事情轉化成數字，再由數字去 frame 這件事對公司的 impact 何在，這也是為什麼 Meta 在某個時間點導入了 Engineering Excellence axis ，希望讓大家能夠更加重視 code quality 、design scalibility 等更加虛無飄渺的層面。（但同樣也是有人在 game EE ，像是我就聽過有人一個一個檔案把 Java 轉成 Kotlin ，然後拿 diff/PR 數目說嘴）
以我自己待過的 Messenger 底層 infra 的 PRE (Performance, Reliability, and Efficiency) 為例，每當你提出一個新專案，就會被要求思考「哪些 metrics 看來不樂觀」、「你這個專案想移動的是哪些 metrics 」、「這些技術類 metrics 的變動對產品類 metrics 會有什麼 impact」。
像我當初想推開發者體驗改善的專案時，就一直在思考該如何 frame 這件事，例如說縮短工具啟動時間乘上每日多少使用者、降低每件事故找出原因的時間云云，然後再由這些數據去延伸出這樣的改善最終反應到哪些使用者體驗上，比方說降低使用者 crash 的機率、降低傳送訊息的延遲等等。
…… 不知道你怎麼想，反正我打完是突然覺得，果然還是快速產出新功能最好了，不用想那麼多有的沒有的間接數據來佐證自己的成果。
至於這樣公司文化還有影響到什麼層面呢？就留待下一篇來說詳細一點吧。
