Facebook的工作方式讓我着迷。那是一個非常獨特的工作氛圍，無法複製(也並不適用於其它公司)。下面的是我從很多在Facebook工作的朋友那裏蒐集到的關於這個公司如何開發和發佈軟件的隻言片語。
看起來對Facebook感興趣的大有人在。這個公司以程序員爲主導的企業文化受到人們的極大關注，很多公司都在努力現實這樣的企業文化。儘管Facebook對於其內部的開發過程諱莫如深，但他們的技術團隊還是會對其新功能和一些內部系統做一些公開的說明，可這些說明通常是關於“是什麼”之類的文章，而不是關於“如何做”的 …
所以，作爲一個外人，你很難知道Facebook是如何做到比其他公司更有效的對其產品進行改進和優化。我作爲一個外部人士，嘗試着去了解更多的關於Facebook內部是如何運轉的信息，我把這幾個月的觀察收穫進行了彙編。出於對於信息來源者的隱私保護，我刪除了所有涉及到的人名和特定產品特徵/產品名稱。而且我把這篇文章延遲了6個多月纔對外發布，所以，文章中所涉及的內容都不會太新太敏感。
我希望這篇文章能給那些試圖看清Facebook如何做到決策權“下放”而不引起管理混亂的人增加一些亮光。你很難評論Facebook這種做法的好壞，以及Facebook的產品質量跟這種做法的關係。我想、也希望如此多的互聯網消費型公司都能從Facebook公司的例子中學到有用的知識。
非常感謝那些在Facebook內部工作、幫助我得到這些信息的人，同時也感謝像epriest 和 fryfrog這樣對本文進行校正和修改的人。
語錄：
- 截止到2010年六月，這個公司的員工已經接近2000名，而在此10個月之前只有大概1100名。一年內幾乎翻了一番！
- 公司最大的兩羣人是技術開發人員和實施人員(Ops),各自有400～500人。這兩部分人佔去了公司構成的50%。
- 產品經理跟技術人員的比例大概是1：7到1：10。
- 所有的技術人員都要通過4到6周的“新兵訓練營”培訓，培訓中他們通過修改bug來了解Facebook系統，聽資深/終身司職技術人員做演講。每次訓練營培訓大概會有10%的學員不能通過考覈，會被淘汰出公司。
- 新兵訓練營後，所有的技術人員都要接觸真實現場數據庫(先會有個專門的講座，關於“責任越大，能力越大”，還有一個明確的“違反即開除”的清單，例如泄漏私人信息)。
- [感謝fryfrog的修改]”公司有很多非常有效的防護措施來防止內部擁有這種能力的人做出各種恐怖的事情，”，如果你不幸成爲需要做這種危險操作的人，你需要登記原因，而且會被密切的審查。一點疏忽都不能有，否則你完了。
- 任何技術人員都可以修改Facebook代碼庫裏的任何一段代碼，並按自己的意願提交回代碼庫裏。
- 非常強勢的技術人員爲主導的文化。“產品經理在這裏基本上沒有什麼用處。”—引自一位開發人員的話。程序員人員可以在中途修改產品規格文檔，重新調整要做哪個項目，隨時都可以按自己的想法加入新的功能特徵。[編輯評論]這篇博客的作者是一位產品經理，所以這段文字着實讓我意外。你會在餘下的語錄裏看到，Facebook的企業文化對產品的管理工作是十分重視的。所以，產品管理這個角色並不是可有可無的。並且，這個公司的企業文化是讓“每一個員工”都感到對產品有責任。
- 在每月的跨團隊會議中，進度報告由開發人員提交。產品市場和產品管理部門會出席這些會議，但如果在會上他們說了太多的話，會後領導會收到會議反饋“產品部門在會上說的話太多了。”他們真的希望開發人員能公認的完全控制產品，讓成爲公司開發的產品的主要主導成分。
- 每個項目的人力調配完全是根據自願。
- 產品經理要遊說開發人員，讓他們對自己的想法感興趣。
- 開發人員選擇他們聽起來感興趣的任務。
- 開發人員會對他們的經理說：“本週我打算做這5塊工作。”
- 技術經理會儘可能的由着各程序員的喜好行事，但有時會要求某項工作必須先做。
- 程序員自己把握所有的技術特徵—前端的javascript，後端的數據庫腳本，以及所有這之間的東西。如果他們需要設計人員的幫助(只有少數幾個專職設計人員)，那他需要找到一個對他們的項目感興趣的設計師。找架構師也是如此。但通常，程序員會自己處理所有所需。
- 一個功能特徵是否值得做，通常的判斷方法是用一週快速實現，然後在抽樣用戶裏測試它，例如找1%的內華達州用戶進行測試。
- 開發人員通常喜歡關於基礎架構，系統擴展性，“難題”等的任務—這些都是能產生威望的地方。你很難讓一個程序員對前端項目或用戶界面工作提起興趣。這跟你在一些面向客戶的業務公司裏發現的現象正好相反，那些公司裏所有人都喜歡幹客戶能接觸到的東西，他們會指着某一個界面功能說：“這是我做的”。在Facebook，後端的工作，例如新聞feed算法，廣告定位算法，memcache優化工作等，都是程序員們的搶手工作。
對某項具有高優先級的功能有影響的修改(例如新聞feed)，在代碼提交合並前要經過代碼審查。新聞Feed非常的重要，任何的改動都要經過Zuckerberg(Facebook創始人，總裁)親自審查，但也有例外的時候。- [糾正—感謝epriest]]“任何的代碼的修改都必須進行強制性的代碼審查(由一個或多個技術人員執行)”。我想這篇文章中說的是Zuck 本人並不會親自審查每一處變動。“
- [更正 感謝fryfrog]”所有的代碼的變更都會經過至少一個人的審查，這套系統讓其他人很容易的查看、審查你的代碼—即使你沒有邀請他。想讓未經審查的代碼進入代碼庫屬於一種蓄意的不良行爲。”
沒有QA的事兒，完全沒有。開發人員完全負責代碼的測試，bug修改，後期維護。有一些單元測試和集成測試的框架，但很少人會用它們。- [更正 感謝fryfrog]”我要說的是，我們實際上是有QA的，只是不是一個正式的QA團隊。每一個在辦公室或能連接到VPN的員工都能看到一個包含所有的變更內容的、下次將要對外發布的網站版本。這一版本的網站更新的十分頻繁，你能比世界上其他人提前1～12小時看到這個即將發佈的版本。公司鼓勵所有員工積極的報告發現的任何問題，對於問題會做出快速的應變。”
- 回覆：很吃驚這裏沒有QA和自動單元測試—“大部分的開發人員都有能力寫出沒有bug的代碼。只是在大多數的公司裏他們沒有動機主動去達到這種境界。當有QA部門存在時，你會輕鬆的把代碼拋給他們，讓他們去發現錯誤。“[編輯：請注意，這只是一種主觀論斷，我之所以把這樣的話語收錄到這篇文章裏，是因爲它跟我們其他公司裏標準軟件開發方法形成鮮明的對比。]
- [更正 感謝epriest] ”我們有自動化測試，包括每次軟件發佈前必須通過的“push-blocking“測試。我們根本不相信所謂的”大部分的開發人員都有能力寫出沒有bug的代碼“的說法，更別說一個公司會接受這種觀點了。”
- 回覆：很吃驚產品經理會沒有影響力/控制權—產品經理有很大的獨立性和自由度。影響力的產生關鍵在於和技術經理建立好良好的關係。需要有足夠的技術知識來避免自己提出愚蠢的建議。除此之外，產品經理建立開發路線/Backlog不需要任何的批准或通過任何的審查。產品經理的數量相當較少，但他們都認爲對公司裏非常重要的、自己感興趣的一個區域負有重要的責任。
- 一般情況下，所有提交的代碼會每週一次的打包發佈(週二)
- 如果努力些，本週做的修改也可以在同一天發佈
- 週二程序發佈時，所有在本週有提交過代碼的程序員都要求在現場留守
- 在發佈開始前，所有的開發人員的需要在特定的IRC頻道里等候“點名“，如果沒到的話，將會得到一次公開的批評。
- 實施組發佈程序上線是一個逐步的過程
- Facebook大概有6萬臺服務器
- 程序的發佈有9個
集中操作的規模級別 - [更正 感謝epriest]”有幾個級別的發佈並不是集中式的。有三個階段是集中部署的(階段1 =內部發布，階段2 = 小規模外部發布，階段3 = 完整外部發布 )。其它6個階段是輔助操作，包括內部工具部署，視頻部署等。”
- 最小層級的部署只涉及6臺服務器
- 例如，週二的新版本發佈會從6臺服務器開始(級別1)，實施組觀察這6臺服務器，確保它們都能正常工作，才能推進到下一級別發佈。
- 如果發佈過程中出現問題(例如，拋出錯誤信息等)，發佈會終止。提交這些導致錯誤的程序的程序員會被叫來修正問題。然後發佈會重新從級別1開始。
- 所以，發佈有可能會反覆重複幾個級別： 1-2-3-修復。回退到 1. 1-2-3-4-5-修復。回退到 1. 1-2-3-4-5-6-7-8-9。
- 實施組訓練有素，令人敬佩的，公司很重視。他們的服務器測評是基於常見錯誤日誌、負載&內存使用統計—包括用戶行爲統計。例如，如果新推出的發佈導致了用戶使用Facebook功能特徵的百分比下降，實施組能在他們的統計工具裏看到這種變化，他們會停止這一版的發佈，調查其中的原因。
- 發佈過程中，實施組使用以IRC爲基礎的調度系統，用它可以在需要的時候通過Facebook，email，IRC，IM，以及短信找到相應的人。對實施組的呼叫不響應的會受到公開批評。
- 一旦程序部署到級別9，穩定下來，這周的發佈就是完成了。
- 如果在特定的週期裏沒有足夠的時間把功能開發出來，這個問題不大(除非有硬性的外部依賴)—功能會在完全完成後打包發佈。
- 受到svn相關批評，公開批評，或經常的誤工期會導致開發人員被辭退。“執行力非常的強“。沒有效率或不是非常有才的人會非常的扎眼。經理通常會對低效能的員工觀察6個月，然後說”我們無能爲力，你不能很好的接受公司的文化。“對公司各個級別的人都是如此，即使是C級別和VP級別的人，如果他們不能做到非常的有效率，也會被迅速的辭退。
- [更正 感謝epriest]“員工不會因爲製造了bug而被開除。他們只會因爲當有他們的代碼被髮布，有問題需要他在現場出現，但卻沒有出現來提供支持時被開除(還沒有發現有人遇到這種情況)。“
- [更正 感謝epriest]“被批評不會導致你被開除。對這樣的事情我們受到了極大的寬容，大多數的資深程序員都曾幹過至少一件恐怖的事，包括我。據我所知，沒有人因爲犯這樣自然的錯誤而被開除。“
- [更正 感謝fryfrog]我也沒有聽說過有任何人像本文中提到的那樣因爲犯錯誤而被開除的。我知道有人曾疏忽的把網站給能癱了。他們努力的修復遇到的問題，每個人都從中學到經驗。被公開批評要比被開除恐怖的多，我的感覺。
觀察Facebook的軟件開發文化發展過程是一件非常有趣的事情—特別要注意的是隨着公司的迅猛擴展，這種文化發展能否跟得上步伐。
你有什麼樣的想法？這“以程序員爲主導的企業文化”在你的公司裏也適用嗎？
