這是一場震驚技術界的混戰(zhàn)，但傳奇軟件建模專家、容器領域專家、基礎設施技術主管等眾多技術專家都挺身而出，十分一致地站到了馬斯克的對立面，為“叫板馬斯克的 Twitter 工程師們”表達支持態(tài)度。
美國本地時間周一早上，Twitter 工程師被召集參加緊急會議。馬斯克下達了一項新命令：凍結 Twitter 系統(tǒng)上的所有生產(chǎn)變更，立即生效。
這不僅僅是一次普通的代碼凍結，這一次，據(jù)媒體獲得的一封內部電子郵件，工程師被告知他們甚至不能編寫任何代碼 —— “直到另行通知” 。如果存在“解決生產(chǎn)服務問題所需的緊急更改”，則將授予為例外情況，并且員工需要獲得“副總裁級別的批準”，并向馬斯克明確說明需要做出的更改。在 Slack 上，就連參加深夜會議的工程師也一頭霧水?！暗侥壳盀橹?，我們還沒有太多背景信息，”一位員工回應道，“但這是來自 Elon 團隊的指示?！?/p>
與此同時，在過去的一天里，馬斯克就 Twitter 代碼和服務的質量發(fā)表了幾項公開聲明。身為 Twitter 的新掌門人，馬斯克于上周日發(fā)推稱“首先為 Twitter 在很多國家的超慢速度道歉。Twitter App 在渲染主頁時間線時，會執(zhí)行 1000 多個性能低下的批量 RPC?！?/p>
這些聲明很快遭到了現(xiàn)任工程師的指責，Twitter 軟件工程師 Eric Frohnhoefer 站了出來，押上自己的職業(yè)生涯跟馬斯克正面對決。他寫道，“我參與 Android 版 Twitter 的開發(fā)有大概 6 年了，我敢說這種論斷是錯的。”
馬斯克隨后回復，“那請你糾正我，正確的數(shù)字是多少？”
但也許問題壓根就不在于 RPC（遠程過程調用）的數(shù)量上。Frohnhoefer 指出，他的團隊“做了很多工作來提高性能”，也承認“Android 版應用確實還有很大的性能改進空間?！钡a充稱，“我認為請求數(shù)量并不是影響性能的主要原因。”
“在我看來，Twitter 應用運行緩慢有三個原因。首先，其中包含大量極少使用的功能，導致軟件過于臃腫；其次，我們多年以來積累了大量技術債務，所以被迫在速度和功能之間求取平衡；第三，還有很大一部分延遲是網(wǎng)絡響應造成的?！?/p>
“坦率地講，我們可能應該優(yōu)先進行幾輪大規(guī)模重寫，先把 10 多年來積累的技術債務干掉、再考慮刪除那些幾乎沒人用的功能?！?/p>
而當再次被問及 RPC 的“正確數(shù)量”時，F(xiàn)rohnhoefer 果斷回答：“數(shù)量是零。應用程序根本就不調用 RPC?！?/p>
雖然有人認為，在這種公開平臺上跟老板對轟恐怕不是什么好主意，但確實有不少支持者決定站在 Frohnhoefer 這一邊。
軟件工程師 Ben Leib 這樣回復馬斯克的原帖：“作為 Twitter 時間線基礎設施的前技術主管，我可以非常確定地宣布，這家伙根本不知道自己在說什么?！?/p>
Twitter 核心 API 平臺團隊的資深軟件工程師兼聯(lián)合技術負責人 Sasha Solomon 也決定發(fā)聲，而且從技術團隊的大量裁員問題上切入：“你不光裁掉了幾乎所有基礎設施人員，還想對我們的批處理機制大放厥詞？”
她還出言譏諷道，“會用 GraphQL 嗎你？” 所謂 GraphQL，是一種通過 HTTP 請求數(shù)據(jù)的查詢語言。
軟件工程師屆的傳奇人物 Grady Booch 也加入了爭論，其表示從這次的情況來看，“有更多證據(jù)表明，馬斯克沒有能力領導 Twitter 這樣一家運營全球彈性業(yè)務、掌握軟件密集型網(wǎng)絡體系的組織?！?/p>
生于 1955 年的 Grady Booch 是一位資深軟件工程師，以與 Ivar Jacobson 和 James Rumbaugh 一起開發(fā)統(tǒng)一建模語言 （UML） 而聞名，并因其在軟件架構、軟件工程和協(xié)作開發(fā)環(huán)境方面的創(chuàng)新工作而享譽國際。
他補充說，“永遠不要低估復雜軟件密集型系統(tǒng)架構的制度知識（大部分未記錄），這些知識由少數(shù)久經(jīng)沙場的人掌握?！?/p>
根據(jù) Frohnhoefer 的說法，Twitter 應用程序啟動時，會發(fā)出大約 20 個后臺請求。似乎是為了澄清自己最初的推文，馬斯克隨后回應說，“事實上，當有人使用 Twitter 應用程序時，你沒有意識到有多達 1200 個‘微服務’被調用，這并不好?！?/p>
“Twitter 的幾位工程師分別告訴我大約 1200 個 RPC，這與微服務的數(shù)量相匹配。（所以）前雇員（應該指的是 Frohnhoefer）錯了。在美國，同樣的應用程序需要大約 2 秒來刷新（太長），但在印度大約需要 20 秒，因為批處理 / 冗長的通信。實際傳輸?shù)挠杏脭?shù)據(jù)很少。”Frohnhoefer 再次對馬斯克表示不同意此說法，他發(fā)推文說“生成時間線所需的數(shù)量接近 200，而不是 1200?！?/p>
馬斯克認為 Twitter 使用了過多的“微服務”，導致 App 刷新緩慢，而且他們似乎真的在試圖關閉一些“微服務”，以測試哪些“微服務”是運行 Twitter 時所必須的。然后，很多人發(fā)現(xiàn)用于 2FA 身份驗證的微服務也被關閉了......
現(xiàn)在很多大型企業(yè)的技術架構都會有點臃腫，但 Twitter 的基礎架構也不是一個完全的黑匣子，因為已經(jīng)有大量的討論、博客文章和其它材料詮釋過 Twitter 所使用的技術了。而馬斯克似乎是想將 Twitter 縮減為僅保留其核心功能，來驗證性能是否能得到提升，他的方法還是直接進行“拉閘”式測試。
馬斯克和 Frohnhoefer 之間的談話很混亂，雙方用了幾個小時，分散在許多線程之中。具有諷刺意味的是，馬斯克很快就解雇了 Frohnhoefer。而這名 Twitter 工程師也直接曬出了自己被踢出辦公系統(tǒng)之外的圖片。
而且一同回擊馬斯克“不會用 GraphQL”的 Sasha Solomon 也發(fā)表推文稱，自己因為昨天發(fā)布的推文已經(jīng)被解雇。
至于客戶端、服務器、請求數(shù)和微服務的關系，負責 Twitter k8s 基礎設施的工程師向馬斯克提供了一個示意圖，他同時表示，幾年前一個叫車服務都可能需要 4000 個服務。
十年前，當 Twitter 開始解決可擴展性和可靠性問題時，能使用的開源工具并不多。隨后，這群工程師努力創(chuàng)建了世界一流的存儲系統(tǒng)、工作負載調度程序、RPC 框架等，并為世界開源了其中不少的項目。
現(xiàn)在，馬斯克突然就來“指手畫腳”了，也難怪眾多工程師不服氣。而且個別地區(qū) App 性能體驗糟糕，也不僅僅是接口調用問題，手機和數(shù)據(jù)中心之間數(shù)據(jù)傳輸?shù)奈锢項l件也是一大影響因素，特別是在印度這樣存在很多低端手機的環(huán)境下。
至于為什么要代碼凍結？沒有人確切知道，但有人猜測馬斯克已經(jīng)變得偏執(zhí)，擔心一些心懷不滿的工程師可能打算在他們離開時搞些破壞？
根據(jù)匿名職場論壇 Blind 對數(shù)百名 Twitter 員工的調查顯示，89% 的人不認為 Twitter 會在馬斯克的管理下取得成功。而馬斯克面臨的壓力還不只源于 Twitter 公司內部。自從以 440 億美元收購這家頭部社交媒體平臺以來，眾多廣告商和知名用戶開始紛紛退出 Twitter 陣營。
與此同時，Twitter 的工程師們則借此機會心情嘲笑這位新任掌門人，想辦法讓領導班子出丑?！艾F(xiàn)已倒閉的醫(yī)療技術公司 THeranos 也出過類似的狀況，工程師們討論前總裁兼首席運營官 Sunny Balwani，所以大家就會編造一些詞匯，看能不能讓對方誤以為是真的并學著使用。于是他們一直說「crazing」，直到 Balwani 自信地重復了一遍?！?/p>
沒準馬斯克治下的 Twitter 也會在未來成為一座笑話大寶庫。到時候當我們感覺無聊了，就會說“在？來點馬斯克笑話?！?/p>
閩公網(wǎng)安備 35010202001226號
