Facebook 如何發布代碼 (How Facebook Ships Code 譯文)(2)

　　回復：很奇怪，缺少產品經理的影響和控制 — 產品經理是很獨立的和自由的。產生影響力的關鍵是與工程師和工程師的管理者搞好關系。需要大致了解技術，不要提一些愚蠢的想法。

　　默認情況下，所有提交的代碼每打包一次(周二)。

　　只要多一分努力，終于一天會發生改變。

　　星期二的代碼發布，需要所有提交過代碼的工程師在場。

　　發布開始前，工程師必須在一個特定的 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、IM SMS 通知每一個工程師，如果需要他們注意的話。對運維組不做回應會被公開問責。

　　代碼一旦發布到第9級，并且穩定運行，本周的發布宣告結束 。

　　如果一個特性沒有按時完成，也沒什么大不了的(除非外部依賴嚴重)，下次完成時一并發布即可。

　　如果被 SVN-blamed(應該指沒按照規范提交代碼會受到的懲罰)、公開問責(Public shamed, 示眾?還是通告批評?)或工作經常疏忽就很可能被開除。”這是一個高效的文化”。不夠高效或者不夠聰明的員工會被剔除。管理層會在 6 個月的時間里觀察你表現，”你不能適應這種文化，只能說再見”。每一級都是這個待遇，即使是 C 級別和 VP 級別，如果不夠高效，也會被開除。

　　[更正, 感謝 epriest ] “人們不會因為導致 Bug 而被解雇，只有在發布他們的代碼時導致問題，而他們恰恰又不在場(也找不到其他可以替代的人)”。

　　[更正, 感謝 epriest] “被問責不會導致解雇。我們特別尊重別人，原諒別人。大部分高級工程師都或多或少犯過一些嚴重的錯誤，包括我。但沒有人因此被解雇”。

　　[更正, 感謝 fryfrog] “我也沒有遇到過因為上面提到過的犯錯而被解雇。我知道有人不小心將整個網站宕掉過。一旦有人犯錯，他們會竭盡全力修復問題，也讓其他人得到了教訓。就我來看，這種公然蒙羞與被解雇的恐懼相比更為奏效”。

　　分析 Facebook 的研發文化如何隨著時間演化是件非常有趣的事。特別是當公司發展壯大到數千員工的時候，這種文化是否還能夠延續?

　　你覺得如何?在你公司里，”開發者驅動(developer-driven)文化” 將會可行么?

　　譯者后記：很多時候是管中窺豹也是非常有趣的，而且，應該細致一點兒。另外，或許我們更應該關注為什么 Facebook 能夠形成這樣的文化。你說呢?

　　譯者后記續：Facebook 能形成工程師主導的文化，應該和 Facebook 的產品形態有很大關系。畢竟 Facebook 人人都會用 Facebook … 換言之，如果是 Amazon / eBay 這樣面向商業的用戶的公司，業務邏輯會讓工程師陷入五里霧中。

原文轉自：http://dbanotes.net/arch/facebook_how_facebook_ships_code.html