揭秘：Facebook如何發(fā)布代碼
我對 Facebook 的運作方式著迷。這是個非常獨特的環(huán)境，很難被復制(這個方式并不適合所有的公司，即使有些公司嘗試過這么做)。下面這些筆記來自我和Facebook的許多朋友的交談，關(guān)于他們開發(fā)、運維與軟件發(fā)布等方面。
好像很多人都對 Facebook 感興趣... 這家公司的工程師驅(qū)動文化(Developer-driven culture)已經(jīng)被公眾大加研究，并且其它其它公司也在探求是否/如何實現(xiàn)工程師驅(qū)動文化。Facebook 的內(nèi)部流程實在夠神秘，當然，工程師團隊也會發(fā)布一些關(guān)于新功能以及部分內(nèi)部系統(tǒng)公開備忘，不過這些大多數(shù)是"說明"類的文章(What)，而非講述"機制"(How)... 所以，外部人員很難明白 Facebook 的創(chuàng)新以及如何比其它公司做到更有效的對服務(wù)進行優(yōu)化。我作為外部人員嘗試深入理解 Facebook 的運作，匯集了幾個月來的這些觀察信息。出于對信息來源的隱私保護，我去掉了特定功能/產(chǎn)品的名字。我又等了6個月以后才發(fā)布這些記錄，所以，有些信息肯定過時了。我希望發(fā)布這些信息會有助于了解 Facebook 的管理機制如何在組織中進行決策的推行而非逐步陷入混輪...很難說這與 Facebook 的成敗或是 Facebook 的產(chǎn)品協(xié)作相關(guān)。我相信很多面向消費者的互聯(lián)網(wǎng)公司會從 Facebook 這個案例受益。
*非常*感謝那些幫助我整理這篇文章的 Facebook 內(nèi)部的朋友們。也要感謝項 epriest 和fryfrog 這樣的朋友，他們協(xié)助我進行對本文進行校正、編輯。
記錄：
◆截止到2010年6月，F(xiàn)acebook有將近2000名員工，10個月前只有大約1100人，一年之間差不多翻了一番!
◆工程部和運維部是兩個最大的部門，每個大概都有 400-500人。這兩個部門人數(shù)大約占了公司的一半。
◆產(chǎn)品經(jīng)理(PM)與工程師的比例大約為1-7到1-10。
◆每個工程師入職時，都要接受 4 到 6 周的 "Boot Camp" 培訓，通過修復Bug 和聽更資深的工程師的課程來熟悉 Facebook 系統(tǒng)。每次 Boot Camp 大約有 10% 的人無法完成課程而被淘汰。
◆培訓結(jié)束后，每個工程師都可以訪問線上的數(shù)據(jù)庫【標準課程"能力越大，責任越大" ( "with great power comes great responsibility") 對此有闡釋，另有一份明晰的"不可觸犯的天條"，比如共享用戶的隱私數(shù)據(jù)】。
◆[修改, 感謝 fryfrog] "Facebook 有非常牢靠的安全保障，以免有人(你可以想象內(nèi)部有人有這個權(quán)限的)不小心/故意做了些糟糕的的事。如果你已經(jīng)"成為"了需要別人支持的人，事由將被記錄，并且有謹慎的審計。這里不允許鉆空子。
◆任何工程師都可以修改Facebook的代碼庫，簽入(Check-in)代碼。
◆濃厚的工程師驅(qū)動文化。"產(chǎn)品經(jīng)理基本可以被忽略"，這是Facebook一名員工的話。工程師可以修改流程的細節(jié)，重新安排工作任務(wù)，隨時植入自己的想法。[評論] "本文的作者是一個產(chǎn)品經(jīng)理，所以這個論斷引起里我的注意。你看完整篇文章后會發(fā)現(xiàn)，很顯然，F(xiàn)acebook 的文化實際上是擁抱產(chǎn)品經(jīng)理的實踐的，所以，不是產(chǎn)品經(jīng)理的角色被忽略，而是，這家公司的文化看上去是想讓"每個人"感受到對產(chǎn)品的責任"。
◆在每月的跨部門會議上，由工程師來匯報工作進度，市場部和產(chǎn)品經(jīng)理會出席會議，也可以做些簡短的發(fā)言，但如果長篇大論的話，將如實反饋給他們的主管，"產(chǎn)品人員在上次會議說的太多"。他們確實想讓工程師來主導產(chǎn)品的開發(fā)，對自己的產(chǎn)品負責。
◆項目需要的資源都是自發(fā)征集的：
◆某個產(chǎn)品經(jīng)理把工程師們召集起來，讓他們對自己的想法產(chǎn)生興趣。
◆工程師們決定開發(fā)那些讓他們感興趣的特性。
◆工程師跟他們的經(jīng)理說："我下周想開發(fā)這5個新特性"。
◆經(jīng)理會讓工程師獨立開發(fā)，可能有時會讓他優(yōu)先完成一些特性。
◆工程師獨立完成所有的特性 -- 前端 JavaScript/后端數(shù)據(jù)庫，等等所有相關(guān)的部分。如果需要得到設(shè)計人員的幫助，需要先讓設(shè)計人員對你的想法產(chǎn)生興趣(專職的設(shè)計師很少)。請架構(gòu)師幫忙也是如此。但總體來說，工程師要獨立完成所有的任務(wù)。
◆對于某個特性是否值得開發(fā)的爭執(zhí)，通常是這么解決的：花一個星期的時間實現(xiàn)，并在小部分用戶中(如1%的內(nèi)華達的用戶)進行測試。
◆工程師通常樂衷致力于架構(gòu)、擴展性以及解決"難題"，那樣能獲得聲望和尊敬。他們很難對前端項目或用戶界面產(chǎn)生太大的興趣。這跟其他業(yè)務(wù)為導向的公司可能正好相反，那些公司人人都想做客戶能直接接觸到的東西，然后會指著某個特定的用戶體驗說，"那是我做的"。在 Facebook，后端的東西，比如 News Feed 算法、廣告投放算法、Memcache 優(yōu)化等等，是工程師真正傾慕的項目。
◆News Feed 因為太重要了，扎克會親自審查任何變動。這是個特例。
◆[更正, 感謝 epriest ]"所有的代碼變更都要經(jīng)過強制性的代碼審查(比如一個或者多個工程師)。我相信這篇文章只是說 扎克并不自己審查每一個變更"。
◆[更正, 感謝 fryfrog ]"所有的修改至少要被一個人審查，而且這個系統(tǒng)可以讓任何人很方便地審核其他人的代碼，即使你沒有邀請他。提交未經(jīng)審查的代碼，將被視為惡意行為"。
◆工程師負責測試、Bug 修復以及啟動對自己項目的維護。有單元測試和集成測試的框架可用，但很少使用。
◆[更正, 感謝 fryfrog ] "補充一下，我們是有 QA 的，只是沒有正式的 QA 組而已。每個辦公室或通過VPN連接的員工會使用下一版的 Facebook，這個版本的 Facebook 會經(jīng)常更新，通常比公開的早 1-12 小時。所有的員工被強烈建議提交 Bug，而且通常會很快被修復"。
◆回復：很奇怪只有很少的 QA 或自動測試 -- "大部分工程師都能寫出基本沒有bug的代碼，只是在其他公司他們不需要這么做。如果有 QA 部門，他們只要把代碼寫完，扔給他們就行了" [編輯：請注意這是很主觀的，我選擇包括這部分內(nèi)容是因為這和那些其它公司的標準開發(fā)實踐完全相反]
◆回復：很奇怪，缺少產(chǎn)品經(jīng)理的影響和控制 -- 產(chǎn)品經(jīng)理是很獨立的和自由的。產(chǎn)生影響力的關(guān)鍵是與工程師和工程師的管理者搞好關(guān)系。需要大致了解技術(shù)，不要提一些愚蠢的想法。
◆默認情況下，所有提交的代碼每打包一次(周二)。
◆只要多一分努力，終于一天會發(fā)生改變。
◆星期二的代碼發(fā)布，需要所有提交過代碼的工程師在場。
◆發(fā)布開始前，工程師必須在一個特定的 IRC 頻道上候命，否則將會被公開問責。
◆運維團隊通過逐步滾動的方式進行代碼發(fā)布：
◆Facebook 有大約 60000 臺服務(wù)器。
◆有9個代碼發(fā)布級別。
◆[更正 感謝 eriest] "九個級別并非同軸的(concentric)。有三個同軸的階段(p1=內(nèi)部發(fā)布, p2=小范圍外部發(fā)布, p3=完整的外部發(fā)布)，其余六個階段是輔助層，比如內(nèi)部工具、視頻上傳主機等等"。
◆最小的級別只有6臺服務(wù)器。
◆比如，星期二的代碼發(fā)布會先發(fā)布到 6 臺服務(wù)器上(第一級)，運維組會觀測這 6 臺服務(wù)器，保證代碼正常工作，然后再提交到下一級。
◆如果發(fā)布出現(xiàn)了問題(如報錯等等)，那么就停止下一級的部署，提交出錯代碼的工程師負責修復問題，然后從頭繼續(xù)發(fā)布。
◆所以一次發(fā)布可能會經(jīng)歷幾次重復：1-2-3-修復，回到 1， 1-2-3-4-5-修復， 回到1， 1-2-3-4-5-6-7-8-9。
◆運維團隊受過嚴格訓練，很受尊敬，而且極具有業(yè)務(wù)意識。他們的工作指標不止包括分析錯誤日志，負載和內(nèi)存使用狀態(tài)等等，還包括用戶行為。比如，如果一個新的發(fā)布導致一定比例的用戶對 Facebook 功能進行聲討，運維團隊將查看相關(guān)指標，可能基于他們的調(diào)查停掉該次發(fā)布。
◆在發(fā)布過程中，運維組使用基于 IRC 的通知系統(tǒng)，可以通過 Facebook、Email、IRC、IMSMS 通知每一個工程師，如果需要他們注意的話。對運維組不做回應(yīng)會被公開問責。
◆代碼一旦發(fā)布到第9級，并且穩(wěn)定運行，本周的發(fā)布宣告結(jié)束 。
◆如果一個特性沒有按時完成，也沒什么大不了的(除非外部依賴嚴重)，下次完成時一并發(fā)布即可。
◆如果被 SVN-blamed(應(yīng)該指沒按照規(guī)范提交代碼會受到的懲罰)、公開問責(Public shamed, 示眾?還是通告批評?)或工作經(jīng)常疏忽就很可能被開除。"這是一個高效的文化"。不夠高效或者不夠聰明的員工會被剔除。管理層會在 6 個月的時間里觀察你表現(xiàn)，"你不能適應(yīng)這種文化，只能說再見"。每一級都是這個待遇，即使是 C 級別和 VP 級別，如果不夠高效，也會被開除。
◆[更正, 感謝 epriest ] "人們不會因為導致 Bug 而被解雇，只有在發(fā)布他們的代碼時導致問題，而他們恰恰又不在場(也找不到其他可以替代的人)"。
◆[更正, 感謝 epriest] "被問責不會導致解雇。我們特別尊重別人，原諒別人。大部分高級工程師都或多或少犯過一些嚴重的錯誤，包括我。但沒有人因此被解雇"。
◆[更正, 感謝 fryfrog] "我也沒有遇到過因為上面提到過的犯錯而被解雇。我知道有人不小心將整個網(wǎng)站宕掉過。一旦有人犯錯，他們會竭盡全力修復問題，也讓其他人得到了教訓。就我來看，這種公然蒙羞與被解雇的恐懼相比更為奏效"。
分析 Facebook 的研發(fā)文化如何隨著時間演化是件非常有趣的事。特別是當公司發(fā)展壯大到數(shù)千員工的時候，這種文化是否還能夠延續(xù)?
你覺得如何?在你公司里，"開發(fā)者驅(qū)動(developer-driven)文化" 將會可行么?
譯者后記：很多時候是管中窺豹也是非常有趣的，而且，應(yīng)該細致一點兒。另外，或許我們更應(yīng)該關(guān)注為什么 Facebook 能夠形成這樣的文化。你說呢?
譯者后記續(xù)：Facebook 能形成工程師主導的文化，應(yīng)該和 Facebook 的產(chǎn)品形態(tài)有很大關(guān)系。畢竟 Facebook 人人都會用 Facebook ... 換言之，如果是 Amazon / eBay 這樣面向商業(yè)的用戶的公司，業(yè)務(wù)邏輯會讓工程師陷入五里霧中。
原文鏈接:http://www.dbanotes.net/arch/facebook_how_facebook_ships_code.html
【編輯推薦】
