我對Facebook的運作方式一直著迷。這是一個很獨特的環(huán)境，不容易復(fù)制（他們的體系并不適合所有的公司）。我和Facebook工作的許多朋友們交流過他們開發(fā)和發(fā)布軟件的方式，下面是交流筆記。

似乎還有其他人對Facebook有興趣……比如這里以及其他公司的相關(guān)討論。 然而，F(xiàn)acebook對自己的內(nèi)部流程諱莫如深。他們的工程團隊經(jīng)常發(fā)布筆記介紹各種新的功能和內(nèi)部系統(tǒng)，但都是一些“是什么”類型的文章，對如何開發(fā)卻不怎么講。因此對于外部人員而言，了解Facebook是怎樣遠比其他公司高效地創(chuàng)新和優(yōu)化其服務(wù)，并非易事。為了更多地了解Facebook的運作，我花費數(shù)月時間收集了下面這些筆記。為了尊重來源的隱私，我刪去了所有人名和具體功能與產(chǎn)品的名字。另外又等過了6個多月才對外公開，所以它們肯定會有些已經(jīng)過時。我希望發(fā)表這些筆記有助于大家了解Facebook是怎樣致力于將決策下放而同時又不至于陷入混亂的。Facebook這樣做的結(jié)果以及其產(chǎn)品是否成體系很難評判，我認(rèn)為并希望許多面向消費者的互聯(lián)網(wǎng)公司能從中有所裨益。

非常感謝那些幫助我整理這篇文章的Facebook的朋友們。同時也感謝提出指正的Reddit網(wǎng)友epriest 和 fryfrog 。

筆記

截止到2010年6月，F(xiàn)acebook有將近2000名員工，10個月前只有1100名，一年之間差不多翻了一番。

兩個最大的部門是工程和運維，每個部門大概都是400~500人。這兩個部門人數(shù)大約占了公司的一半。

產(chǎn)品經(jīng)理與工程師的比例大約為1:7到1:10。

每個工程師入職時，都要接收4~6周的培訓(xùn)，通過修補bug和聽高級開發(fā)工程師的課程來熟悉Facebook。約10%的受訓(xùn)者無法通過，并被請出公司。

培訓(xùn)結(jié)束后，每個工程師都可以接觸線上的數(shù)據(jù)庫（更大的權(quán)力意味著更大的責(zé)任，也有一份“勿做清單”，寫明那些行為會導(dǎo)致被開除，比如分享用戶的隱私數(shù)據(jù)）。

［根據(jù)網(wǎng)友fryfrog意見修改］ 有非常牢靠的防范體系，以免內(nèi)部人員做惡。如果應(yīng)要求需要以其他人的身份做事，必須將原因記錄，并接受嚴(yán)格審查，此外都是嚴(yán)厲禁止的。

每個工程師可以修改Facebook的任何代碼，隨時可以簽入（check-in）。

濃厚的工程師驅(qū)動文化

“產(chǎn)品經(jīng)理基本可以被忽略”，這是Facebook一名員工的原話。工程師可以修改流程的細(xì)節(jié)，重新安排工作任務(wù)，隨時植入自己的想法。（作者原注：我就是產(chǎn)品經(jīng)理，當(dāng)然對這一點特別關(guān)注。其實從下文可以看出，F(xiàn)acebook的文化其實全面吸收了產(chǎn)品管理實踐，他們不是忽視產(chǎn)品管理，而是創(chuàng)造了一種人人對產(chǎn)品負(fù)責(zé)的文化。）

在每月的跨部門會議上，由工程師來匯報工作進度，市場部和產(chǎn)品經(jīng)理會出席會議，也可以做些簡短的發(fā)言，但如果說得太多，很可能就會被打小報告。他們確實想讓工程師來主導(dǎo)產(chǎn)品的開發(fā)，對自己的產(chǎn)品負(fù)責(zé)。

項目需要的資源都是絕對自愿的

產(chǎn)品經(jīng)理游說工程師，讓他們對自己的想法產(chǎn)生興趣。

工程師們決定開發(fā)那些讓他們感興趣的特性。

工程師跟他們的經(jīng)理說：“我下周想開發(fā)這5個新特性”。

經(jīng)理通常會尊重工程師的選擇，可能有時會讓他優(yōu)先完成一些特性。

工程師負(fù)責(zé)所有的特性——前端JavaScript/后端數(shù)據(jù)庫代碼以及之間所有部分。如果需要得到設(shè)計人員（公司內(nèi)部設(shè)計團隊很�。┑膸椭�，需要先讓設(shè)計人員對你的想法產(chǎn)生興趣。架構(gòu)師之類的也是一樣�？傮w來說，工程師要完成所有的任務(wù)。

對于某個特性是否值得開發(fā)的爭論，通常是這么解決的：花一個星期的時間完成，并在小部分人群中（如1%的內(nèi)華達用戶）進行測試。（劉江注：蔣長浩介紹，實際操作時通常會選擇某些服務(wù)器上的用戶進行測試。）

工程師總是希望解決基礎(chǔ)設(shè)施、可擴展性以及其他難題，這能獲得聲望和尊敬。他們很難對前端項目或UI設(shè)計產(chǎn)生太大的興趣。這與其他公司工程師喜歡做前端并向用戶吹噓“看，這是我做的”的情況，可能正好相反。在Facebook，后端任務(wù)，比如新的feed算法，廣告投放算法，memcache優(yōu)化等等，是工程師真正感興趣的。

所有的代碼修改必須經(jīng)過審查（通過一個或多個工程師），但News Feed是個例外，因為太重要了，Zuckerberg會親自審查所有改動。［根據(jù)網(wǎng)友epriest意見更正］

所有的修改至少要被一個人審核，而且系統(tǒng)可以讓任何人很方便地審查其他人的代碼，即使沒有得到邀請。簽入未經(jīng)審查的代碼將被視為惡意行為。［根據(jù)fryfrog］

工程師負(fù)責(zé)測試、代碼修復(fù)和維護自己的項目。有一些單元測試和集成測試框架，但只是偶爾使用。

還是有QA環(huán)節(jié)的，只不過沒有正式的QA部門。每個辦公室或通過VPN連接的員工會使用下一版的Facebook，這個版本的Facebook會經(jīng)常更新，通常比公開的早1~12小時。所有的員工被強烈建議提交bugs，而且通常會很快被修復(fù)。［根據(jù)fryfrog更改］

對于很奇怪只有很少的QA或自動測試的說法，F(xiàn)acebook員工這樣回復(fù)：“大部分工程師都能寫出基本沒有bug的代碼，只是在其他公司他們不需要這么做。如果有QA部門，他們只要把代碼寫完，扔給他們就行了。” ［作者原注：這當(dāng)然是主觀之見，我加上這一條是為了與其他公司的標(biāo)準(zhǔn)實踐做比較。］

［epriest對上一條的意見］ 我們有自動測試，包括代碼發(fā)布前必須要通過push-blocking測試。我們不相信“所有的工程師都能寫出沒有bug的代碼”，更不可能將公司基于這樣不靠譜的理念。

對于很奇怪缺少產(chǎn)品經(jīng)理的影響和控制的回復(fù)：產(chǎn)品經(jīng)理是很獨立的和自由的。具有影響力的關(guān)鍵是與工程經(jīng)理們搞好關(guān)系。需要大致了解技術(shù)，不要提一些愚蠢的想法。此外，確立路線圖/backlog時，無需任何許可或者通過什么評審。產(chǎn)品經(jīng)理相對比較少，但是他們都覺得自己負(fù)責(zé)的是公司確實重要而且自己也有興趣的領(lǐng)域。

所有提交的代碼每周二默認(rèn)打包發(fā)布一次。

多費點力氣的話，修改也可以在同一天發(fā)布。

星期二代碼發(fā)布時，需要所有本周提交過代碼的工程師在場。

代碼打包前，工程師必須在一個特殊的IRC channel上候命，否則會被公開批評。

運維團隊是逐漸發(fā)布代碼上線的：

Facebook有大約60000臺服務(wù)器

有9個代碼發(fā)布級別（［epriest］這些級別并不都是全局的，只有三個全局：p1=內(nèi)部發(fā)布，p2=小規(guī)模外部發(fā)布，p3=完全外部發(fā)布。其他6個是輔助性的，包括內(nèi)部工具、視頻上傳等）

最小的級別只有6臺服務(wù)器

比如，星期二的代碼發(fā)布會先發(fā)布到6臺服務(wù)器上（級別1），運維組會觀察這6臺服務(wù)器，保證代碼正常工作，然后再提交到下一級

如果發(fā)布出現(xiàn)了一些問題（如報錯等等），那么就停止下一級的部署，提交出錯代碼的工程師負(fù)責(zé)修復(fù)問題，然后從頭繼續(xù)發(fā)布。

所以一次發(fā)布可能會經(jīng)歷幾次重復(fù)：1-2-3-fix，回到1，1-2-3-4-5-fix，回到1，1-2-3-4-5-6-7-8-9

運維團隊是受過嚴(yán)格訓(xùn)練，倍受尊敬，而且很懂業(yè)務(wù)的。他們的工作包括分析錯誤日志，負(fù)載和內(nèi)存使用狀態(tài)等等。還包括用戶行為。比如，如果一個新的發(fā)布改變了用戶使用某些Facebook特性的百分比，運維團隊會從數(shù)據(jù)中看到，可能因此停止發(fā)布，進行調(diào)查。

代碼發(fā)布期間，運維組使用基于IRC的呼叫系統(tǒng)，如果需要，可以通過Facebook/email/irc/im/sms找到每一個工程師。對運維組不做回應(yīng)會被公開批評。

代碼一旦發(fā)布到第9級，并且穩(wěn)定運行，就算發(fā)布成功了。

每周發(fā)布時如果一個特性沒有按時開發(fā)完成，也沒什么大不了的（除非有嚴(yán)重的外部依賴），特性通常都是完成后再發(fā)布。

如果被svn指責(zé)、公開批評或項目經(jīng)常延期，工程師就很可能被開除。“這是一個高績效的文化”。不夠高效或者不夠聰明的員工會被剔除。經(jīng)理們會在6個月的時間里觀察你表現(xiàn)，如果不合格，只能說再見。每一級都是這個待遇，即使是C級別和VP級別，如果不是特別高效，也會被開除。

［epriest］代碼中有bug不會開除。只在發(fā)布時要求加入自己的修改代碼，卻在出錯時沒有提供支持（而且也沒有讓別人替你），才會被開除。

［epriest］被責(zé)罵不會導(dǎo)致解雇。我們在這方面特別寬容。大部分高級工程師都或多或少犯過一些嚴(yán)重的錯誤，包括我。就我所知，沒有人因此被解雇。

［fryfrog］我也沒有遇到過因為上面提到過的犯錯而被解雇。有些人犯了錯，他們會非常努力地去修復(fù)，也讓其他人得到了學(xué)習(xí)。在我看來，公開批評比用解雇來嚇人更有效。

我非常感興趣的是，F(xiàn)acebook的開發(fā)文化接下來會怎樣演變，當(dāng)公司發(fā)展到幾千員工的時候，這種文化還能繼續(xù)擴展嗎？

你怎么看？開發(fā)人員驅(qū)動的文化在你們公司能推行嗎？

（CSDN注：Hacker News、Slashdot和Reddit上的討論也很有價值。)

標(biāo)簽：  �发软�

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。