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