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