我對Facebook的運作方式一直著迷。這是一個很獨特的環境，不容易被復制(他們的體系并不適合所有的公司，雖然他們努力嘗試過)。下面是我和Facebook的許多朋友們關于他們如何開發和發布軟件所做交流的記錄。
然而，Facebook對自己的內部流程說得很少。他們的工程團隊經常發布筆記介紹各種新的功能和內部系統，但對如何開發卻不怎么講。因此對于外部人員而言，了解Facebook是怎樣遠比其他公司高效地對服務進行創新和優化并不容易。為了更多地了解Facebook的運作，我花費數月時間收集了下面這些文字。為了尊重隱私，刪去了所有人名和具體功能與產品的名字。另外又等過了6個多月才對外公開，所以它們可能會有點過時。我希望發表這些記錄有助于大家了解Facebook是怎樣致力于將決策下放而同時又不至于陷入混亂的。無論Facebook的結果怎樣，產品是否成體系，我認為并希望許多面向消費者的互聯網公司能從中有所裨益。
非常感謝那些幫助我整理這篇文章的Facebook的朋友們。同時也感謝提出指正的Reddit網友。
記錄：
截止到2010年6月，Facebook有將近2000名員工，10個月前只有1100名，一年之間差不多翻了一番。
兩個最大的部門是工程和運維，每個部門大概都是400～500人。這兩個部門人數大約占了公司的一半。
產品經理與工程師的比例大約為1:7到1:10。
每個工程師入職時，都要接收4-6周的培訓，通過修補bug和聽高級開發工程師的課程來熟悉Facebook。約10%的受訓者無法通過，并被請出公司。
培訓結束后，每個工程師都可以接觸線上的數據庫(更大的權力意味著更大的責任，也有一份"勿做清單"，寫明那些行為會導致被開除，比如共享用戶的隱私數據)。
有非常牢靠的防范體系，以免內部人員做惡。如果要應要求替人行事，必須將原因記錄，并接受嚴格審查，此外都絕對禁止。
每個工程師可以修改Facebook的任何代碼，隨時可以簽入(check-in)。
濃厚的工程師驅動文化。"產品經理基本可以被忽略"，這是Facebook一名員工的原話。工程師可以修改流程的細節，重新安排工作任務，隨時植入自己的想法。(作者原注：我就是產品經理，當然對這一點特別關注。其實從下文可以看出，Facebook的文化其實全面吸收了產品管理實踐，他們不是忽視產品管理，而是創造了一種人人對產品負責的文化。)
在每月的跨部門會議上，由工程師來匯報工作進度，市場部和產品經理會出席會議，也可以做些簡短的發言，但如果說得太多，很可能就會被打小報告。他們確實想讓工程師來主導產品的開發，對自己的產品負責。
項目需要的資源都是絕對自愿的
產品經理游說工程師，讓他們對自己的想法產生興趣。
工程師們決定開發那些讓他們感興趣的特性。
工程師跟他們的經理說："我下周想開發這5個新特性"。
經理通常會尊重工程師的選擇，可能有時會讓他優先完成一些特性。
工程師負責所有的特性——前端JavaScript/后端數據庫代碼以及之間所有部分。如果需要得到設計人員(公司內部設計團隊很小)的幫助，需要先讓設計人員對你的想法產生興趣。架構師之類的也是一樣�？傮w來說，工程師要完成所有的任務。
對于某個特性是否值得開發的爭論，通常是這么解決的：花一個星期的時間完成，并在小部分人群中(如1%的內華達用戶)進行測試。(劉江注：蔣長浩介紹，實際操作時通常會選擇某些服務器上的用戶進行測試。)
工程師總是希望解決基礎設施、可擴展性以及其他難題，這能獲得聲望和尊敬。他們很難對前端項目或UI設計產生太大的興趣。這與其他公司工程師喜歡做前端并向用戶吹噓“看，這是我做的”的情況，可能正好相反。在Facebook，后端任務，比如新的feed算法，廣告投放算法，memcache優化等等，是工程師真正感興趣的。
所有的代碼修改必須經過審查(通過一個或多個工程師)，但News Feed是個例外，因為太重要了，Zuckerberg會親自審查所有改動。
所有的修改至少要被一個人審核，而且這個系統可以讓任何人很方便地審查其他人的代碼，即使沒有得到邀請。簽入未經審查的代碼將被視為惡意行為。
工程師負責測試，代碼修復，和維護自己的項目。
每個辦公室或通過VPN連接的員工會使用下一版的Facebook，這個版本的Facebook會經常更新，通常比公開的早1-12小時。所有的員工被強烈建議提交bugs，而且通常會很快被修復。
很奇怪只有很少的QA或自動測試——"大部分工程師都能寫出基本沒有bug的代碼，只是在其他公司他們不需要這么做。如果有QA部門，他們只要把代碼寫完，扔給他們就行了"
[針對上一條]我們有自動測試，代碼發布前必須要通過測試。我們不相信"所有的工程師都能寫出沒有bug的代碼"，畢竟這是一個商業公司。
很奇怪，缺少產品經理的影響和控制——產品經理是很獨立的和自由的。產生影響力的關鍵是與工程師和工程師的領導們們搞好關系。需要大致了解技術，不要提一些愚蠢的想法。
所有提交的代碼每周二打包一次。
只要多一分努力，終于一天會發生改變。
星期二的代碼發布，需要所有的提交過代碼的工程師在場。
代碼打包前，工程師必須在一個特殊的IRC channel上。
運維執行打包過程
Facebook有大約60000臺服務器
有9個代碼發布級別
最小的級別只有6臺服務器
星期二的代碼發布會先發布到6臺服務器上，運維組會檢測這6臺服務器的反應，保證代碼正常工作，然后再提交到下一級
如果發布出現了一些問題(如報錯等等)，那么就停止下一級的部署，提交出錯代碼的工程師負責修復問題，然后從頭繼續發布。
所以一次發布可能會經歷幾次重復：1-2-3-fix. 回到1. 1-2-3-4-5-fix. 回到1. 1-2-3-4-5-6-7-8-9
運維組是受過嚴格訓練，倍受尊敬，而且有商業意識的。他們的工作包括分析錯誤日志，負載和內存狀態等等。還包括用戶行為。
代碼發布期間，運維組使用IRC-based頁面系統，可以通過Facebook/email/irc/im/sms ping每一個工程師，如果需要他們注意的話。對運維組不做回應是一件很羞愧的事。
代碼一旦發布到第9級，并且穩定運行，就算發布成功了。
如果一個特性沒有按時完成，也沒什么大不了的，下次完成時一并發布即可。
如果被svn-blamed,public shamed或工作經常疏忽就很可能被開除。"這是一個高效的文化"。不夠高效或者不夠聰明的員工會被剔除。管理層會在6個月的時間里觀察你表現，如果不合格，只能說再見。每一級都是這個待遇，即使是C級別和VP級別，如果不夠高效，也會被開除。
被責罵不會導致解雇。我們特別尊重別人，原諒別人。大部分高級工程師都或多或少犯過一些嚴重的錯誤，包括我。但沒有人因此被解雇。
我也沒有遇到過因為上面提到過的犯錯誤而被解雇。有些人犯了錯，他們會非常努力地去修復，也讓其他人得到了學習。
文章來源于領測軟件測試網 http://www.k11sc111.com/
