Facebook是如何開發軟件的

來源: 外刊IT評論發布時間: 2011-11-14 22:12 閱讀: 5312 次推薦: 2 原文鏈接 [收藏]

　　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批評(svn-blamed)，公開批評，或經常的誤工期會導致開發人員被辭退。執行力非常的強。沒有效率或不是非常有才的人會非常的扎眼。經理通常會對低效能的員工觀察6個月，然后說我們無能為力，你不能很好的接受公司的文化。對公司各個級別的人都是如此，即使是C級別和VP級別的人，如果他們不能做到非常的有效率，也會被迅速的辭退。
[更正感謝epriest]員工不會因為制造了bug而被開除。他們只會因為當有他們的代碼被發布，有問題需要他在現場出現，但卻沒有出現來提供支持時被開除(還沒有發現有人遇到這種情況)。
[更正感謝epriest]被批評不會導致你被開除。對這樣的事情我們受到了極大的寬容，大多數的資深程序員都曾干過至少一件恐怖的事，包括我。據我所知，沒有人因為犯這樣自然的錯誤而被開除。
[更正感謝fryfrog]我也沒有聽說過有任何人像本文中提到的那樣因為犯錯誤而被開除的。我知道有人曾疏忽的把網站給能癱了。他們努力的修復遇到的問題，每個人都從中學到經驗。被公開批評要比被開除恐怖的多，我的感覺。