Facebook 如何管理程式碼、專案釋出

Facebook 公司專案如何運作? 程式碼更新是如何控管?

Facebook 如何管理程式碼、專案釋出

原文: How Facebook Ships Code

中文簡體: facebook是如何管理代碼的 (下述文章主要轉載自此篇譯文, 我主要做繁體化後, 再簡單修飾些詞句)

我對facebook的運作著迷。這是一個很獨特的環境，不容易被複製（他們的體系並不適合所有的公司，即使他們努力嘗試過）。

下面是我和facebook的朋友們關於他們如何開發和 Release 的記錄。

現在距離我收集的這些信息又過去6個月了，我相信facebook肯定又對他們的 Release 實踐進行了改進。所以這些記錄可能會有點過時。同時facebook的工程師驅動文化也越來越為大眾所知。非常感謝那些幫助我整理這篇文章的facebook的朋友們。

記錄：

• 截止到2010年6月，facebook有將近2000名員工，10個月前只有1100名，一年之間多了將近一倍的人。
• 兩個最大的部門是工程師和OPS，每個部門大概都是400-500人。這兩個部門人數大約占了公司的一半。
• 產品經理與工程師的比例大約為1-7到1-10。
• 每個工程師入職時，都要接收4-6周的培訓，通過修補bugs和聽資深開發工程師的課程來熟悉facebook。
• 培訓結束後，每個工程師都可以接觸線上的資料庫(更大的權力意味著更大的責任，也有一份"勿做清單"，不然可能會被開除，比如共用用戶的隱私資料)。
• 有非常牢靠的安全體系，以免有人不小心/故意做了些不好的事。
• 每個工程師可以修改facebook的任何程式，隨時可以置入。
• 濃厚的工程師驅動文化。"產品經理基本可以被忽略"，這是facebook一名員工的話。工程師可以修改流程的細節，重新安排工作任務，隨時植入自己的想法。
• 在每月的跨部門會議上，由工程師來匯報工作進度，市場部和產品經理會出席會議，也可以做些簡短的發言，但如果說得太多，很可能就會被打小報告。他們確實想讓工程師來主導產品的開發，對自己的產品負責。
• 專案資源配置都是自願的
  • 一個產品經理把工程師們召集到一起，讓他們對他的想法產生興趣。
  • 工程師們決定開發那些讓他們感興趣的項目。
  • 工程師跟他們的經理說："我這週想開發這5個新功能"。
  • 經理會讓工程師獨立開發，可能有時會讓他優先完成一些功能。
  • 工程師獨立完成所有的功能——前端/後端/資料庫，等等所有相關的部分。如果需要得到設計人員的幫助，需要先讓設計人員對你的想法產生興趣。其他如架構之類的也一樣。但總體來說，工程師要獨立完成所有的任務。
• 對於某個功能是否值得開發的爭論，通常是這麼解決的：花一個星期的時間完成它，並在小部分人群中(如1%)進行測試。
• 工程師常常希望解決難題，這能獲得聲望和尊敬。他們很難對前端項目或UI設計產生太大的興趣。這跟其他公司可能正好相反。在facebook，後端任務，比如新的feed演算法，廣告投放演算法，memcache優化等等，是工程師真正感興趣的。
• 所有的程式碼修改都要進行審核(通過一個或多個工程師)，但News Feed是個例外，因為太重要了，Zuckerberg會親自review。
• 所有的修改至少要被一個人審核，而且這個系統可以讓任何人很方便地審核其他人的程式碼，即使你沒有邀請他
• 工程師負責測試，程式碼修復，和維護自己的項目。
• 每個辦公室或通過VPN連接的員工會使用下一版的facebook，這個版本的facebook會經常更新，通常比公開的早1-12小時。所有的員工被強烈建議提交bugs，而且通常會很快被修復。
• 很奇怪只有很少的QA或自動測試——"大部分工程師都能寫出基本沒有bug的程式碼，只是在其他公司他們不需要這麼做。如果有QA部門，他們只要把程式碼寫完，扔給他們就行了"
• [針對上一條]我們有自動測試，程式碼發佈前必須要通過測試。我們不相信"所有的工程師都能寫出沒有bug的程式碼"，畢竟這是一個商業公司。
• 很奇怪，缺少產品經理的影響和控制——產品經理是很獨立的和自由的。產生影響力的關鍵是與工程師和工程師的領導們搞好關系。需要大致瞭解技術，不要提一些愚蠢的想法。
• 所有提交的程式碼每週二打包一次。
• 只要多一分努力，終於一天會發生改變。
• 星期二的程式碼發佈，需要所有的提交過程式碼的工程師在場。
• 程式碼打包前，工程師必須在一個特殊的IRC channel上。
• OPS執行打包過程
  • facebook有大約60000台服務器
  • 有9個程式碼發佈級別
  • 最小的級別只有6台服務器
  • 星期二的程式碼發佈會先發佈到6台服務器上，OPS組會檢測這6台服務器的反應，保證程式碼正常工作，然後再提交到下一級
  • 如果發佈出現了一些問題（如報錯等等），那麼就停止下一級的部署，提交出錯程式碼的工程師負責修復問題，然後從頭繼續發佈。
  • 所以一次發佈可能會經歷幾次重復：1-2-3-fix. 回到1. 1-2-3-4-5-fix. 回到1. 1-2-3-4-5-6-7-8-9
• OPS組是受過嚴格訓練，倍受尊敬，而且有商業意識的。他們的工作包括分析錯誤日誌，負載和記憶體狀態等等。還包括用戶行為。
• 程式碼發佈期間，OPS組使用IRC-based頁面系統，可以通過facebook/email/irc/im/sms ping每一個工程師，如果需要他們註意的話。對OPS組不做回應是一件很羞愧的事。
• 程式碼一旦發佈到第9級，並且穩定運行，就算發佈成功了。
• 如果一個功能沒有按時完成，也沒什麼大不了的，下次完成時一並發佈即可。
• 如果被svn-blamed,public shamed或工作經常疏忽就很可能被開除。"這是一個高效率的文化"。效率不夠高或者不夠聰明的員工會被剔除。管理層會在6個月的時間裡觀察你表現，如果不合格，只能說再見。每一級都是這個待遇，即使是C級別和VP級別，如果效率不夠高，也會被開除。
• 被責罵不會導致解雇。我們特別尊重別人，原諒別人。大部分高級工程師都或多或少犯過一些嚴重的錯誤，包括我。但沒有人因此被解雇。
• 我也沒有遇到過因為上面提到過的犯錯誤而被解雇。有些人犯了錯，他們會非常努力地去修復，也讓其他人得到了學習。

相關網頁

• 一窺Facebook的管理秘密
• Facebook Engineering's Notes
• Product Management: You Get What You Pay For | Forrester Blogs
• 平常心看「Facebook如何管理程式碼」
• Exclusive: a behind-the-scenes look at Facebook release engineering
• 下述摘錄自此篇: Facebook 產品發佈內幕
  

  Facebook的源代碼大部分用PHP開發，PHP便於快捷開發，但性能上弱於其它現代語言。為改進基於PHP的架構的伸縮性，Facebook開發了將PHP代碼動態翻譯成原生機器碼的虛擬機HipHop，平均減少了50%的CPU消耗。由於Facebook的整個代碼被編譯成單一的二進制可執行文件，因此它的部署流程與常見的PHP環境不同。二進制文件有1.5GB大小，當工程師更新代碼生成新的版本，它需要被部署到所有服務器上。向無數服務器遷移1.5GB文件並非易事，在研究了多個方案之後，Facebook決定使用BitTorrent點對點文件共用協議。它創造了一個定製的BitTorrent tracker，允許一臺服務器能從同節點的其它服務器上獲取文件片段。滾動更新產品耗時30分鐘，其中15分鐘編譯出新的可執行文件，另外15分鐘通過BitTorrent部署到大部分服務器。可執行文件只是應用程式棧的一部分，其它資源如JavaScript、CSS和圖形庫則托管在CDN上。

作者: Tsung

對新奇的事物都很有興趣, 喜歡簡單的東西, 過簡單的生活. 檢視「Tsung」的全部文章