原文：How Facebook Ships Code

Facebook是如何管理程式碼的



　　記錄：

    * 截止到2010年6月，facebook有將近2000名員工，10個月前只有1100名，一年之間差不多翻了一番。
    * 兩個最大的部門是工程師和營運，每個部門大概都是400-500人。這兩個部門人數大約占了公司的一半。
    * 產品經理與工程師的比例大約為1-7到1-10。
    * 每個工程師入職時，都要接收4-6周的培訓，通過修補bugs和聽高級開發工程師的課程來熟悉facebook。
    * 有非常牢靠的安全體系，以免有人不小心/故意做了些不好的事。
    * 每個工程師可以修改facebook的任何程式碼，隨時可以簽入。
    * 項目需要的資源都是自願的
          o 一個產品經理把工程師們召集到一起，讓他們對他的想法產生興趣。
          o 工程師們決定開發那些讓他們感興趣的特性。
          o 工程師跟他們的經理說："我下周想開發這5個新特性"。
          o 經理會讓工程師獨立開發，可能有時會讓他優先完成一些特性。
    * 對於某個特性是否值得開發的爭論，通常是這麼解決的：花一個星期的時間完成他，並在小部分人群中(如1%)進行測試。
    * 所有的程式碼修改都要進行審核(通過一個或多個工程師)，但News Feed是個例外，因為太重要了，Zuckerberg會親自review。
    * 所有的修改至少要被一個人審核，而且這個系統可以讓任何人很方便地審核其他人的程式碼，即使你沒有邀請他
    * 工程師負責測試，程式碼修複，和維護自己的項目。
    * 所有提交的程式碼每周二打包一次。
    * 只要多一分努力，總有一天會發生改變。
    * 星期二的程式碼發布，需要所有的提交過程式碼的工程師在場。
    * 程式碼打包前，工程師必須在一個特殊的IRC channel上。
    * 營運執行打包過程
          o facebook有大約60000台服務器。
          o 有9個程式碼發布級別。
          o 最小的級別只有6台服務器。
          o 星期二的程式碼發布會先發布到6台服務器上，營運組會檢測這6台服務器的反應，保證程式碼正常工作，然後再提交到下一級。
          o 如果發布出現了一些問題（如報錯等等），那麼就停止下一級的部署，提交出錯程式碼的工程師負責修複問題，然後從頭繼續發布。
          o 所以一次發布可能會經曆幾次重複：1-2-3-fix. 回到1. 1-2-3-4-5-fix. 回到1. 1-2-3-4-5-6-7-8-9。
    * 營運組是受過嚴格訓練，倍受尊敬，而且有商業意識的。他們的工作包括分析錯誤日志，負載和內存狀態等等，還包括用戶行為。
    * 程式碼一旦發布到第9級，並且穩定運行，就算發布成功了。
    * 如果一個特性沒有按時完成，也沒什麼大不了的，下次完成時一並發布即可。
    * 被責罵不會導致解雇。我們特別尊重別人，原諒別人。大部分高級工程師都或多或少犯過一些嚴重的錯誤，包括我。但沒有人因此被解雇。
    * 我也沒有遇到過因為上面提到過的犯錯誤而被解雇。有些人犯了錯，他們會非常努力地去修複，也讓其他人得到了學習。