本文是从 How Facebook Ships Code 这篇文章翻译而来。

---

    

     Facebook的工作方式让我着迷。那是一个非常独特的工作氛围，无法复制(也并不适用于其它公司)。下面的是我从很多在Facebook工作的朋友那里搜集到的关于这个公司如何开发和发布软件的只言片语。

    

     看起来对Facebook感兴趣的大有人在。这个公司以程序员为主导的企业文化受到人们的极大关注，很多公司都在努力现实这样的企业文化。尽管Facebook对于其内部的开发过程讳莫如深，但他们的技术团队还是会对其新功能和一些内部系统做一些公开的说明，可这些说明通常是关于“是什么”之类的文章，而不是关于“如何做”的 …

    所以，作为一个外人，你很难知道Facebook是如何做到比其他公司更有效的对其产品进行改进和优化。我作为一个外部人士，尝试着去了解更多的关于Facebook内部是如何运转的信息，我把这几个月的观察收获进行了汇编。出于对于信息来源者的隐私保护，我删除了所有涉及到的人名和特定产品特征/产品名称。而且我把这篇文章延迟了6个多月才对外发布，所以，文章中所涉及的内容都不会太新太敏感。

    我希望这篇文章能给那些试图看清Facebook如何做到决策权“下放”而不引起管理混乱的人增加一些亮光。你很难评论Facebook这种做法的好坏，以及Facebook的产品质量跟这种做法的关系。我想、也希望如此多的互联网消费型公司都能从Facebook公司的例子中学到有用的知识。

    非常感谢那些在Facebook内部工作、帮助我得到这些信息的人，同时也感谢像epriest 和 fryfrog这样对本文进行校正和修改的人。

    语录：

截止到2010年六月，这个公司的员工已经接近2000名，而在此10个月之前只有大概1100名。一年内几乎翻了一番！

公司最大的两群人是技术开发人员和实施人员(Ops),各自有400～500人。这两部分人占去了公司构成的50%。

产品经理跟技术人员的比例大概是1：7到1：10。

所有的技术人员都要通过4到6周的“新兵训练营”培训，培训中他们通过修改bug来了解Facebook系统，听资深/终身司职技术人员做演讲。每次训练营培训大概会有10%的学员不能通过考核，会被淘汰出公司。

新兵训练营后，所有的技术人员都要接触真实现场数据库(先会有个专门的讲座，关于“责任越大，能力越大”，还有一个明确的“违反即开除”的清单，例如泄漏私人信息)。

[感谢fryfrog的修改]”公司有很多非常有效的防护措施来防止内部拥有这种能力的人做出各种恐怖的事情，”，如果你不幸成为需要做这种危险操作的人，你需要登记原因，而且会被密切的审查。一点疏忽都不能有，否则你完了。

任何技术人员都可以修改Facebook代码库里的任何一段代码，并按自己的意愿提交回代码库里。

非常强势的技术人员为主导的文化。“产品经理在这里基本上没有什么用处。”―引自一位开发人员的话。程序员人员可以在中途修改产品规格文档，重新调整要做哪个项目，随时都可以按自己的想法加入新的功能特征。[编辑评论]这篇博客的作者是一位产品经理，所以这段文字着实让我意外。你会在余下的语录里看到，Facebook的企业文化对产品的管理工作是十分重视的。所以，产品管理这个角色并不是可有可无的。并且，这个公司的企业文化是让“每一个员工”都感到对产品有责任。

在每月的跨团队会议中，进度报告由开发人员提交。产品市场和产品管理部门会出席这些会议，但如果在会上他们说了太多的话，会后领导会收到会议反馈“产品部门在会上说的话太多了。”他们真的希望开发人员能公认的完全控制产品，让成为公司开发的产品的主要主导成分。

每个项目的人力调配完全是根据自愿。

产品经理要游说开发人员，让他们对自己的想法感兴趣。

开发人员选择他们听起来感兴趣的任务。

开发人员会对他们的经理说：“本周我打算做这5块工作。”

技术经理会尽可能的由着各程序员的喜好行事，但有时会要求某项工作必须先做。

程序员自己把握所有的技术特征―前端的javascript，后端的数据库脚本，以及所有这之间的东西。如果他们需要设计人员的帮助(只有少数几个专职设计人员)，那他需要找到一个对他们的项目感兴趣的设计师。找架构师也是如此。但通常，程序员会自己处理所有所需。

一个功能特征是否值得做，通常的判断方法是用一周快速实现，然后在抽样用户里测试它，例如找1%的内华达州用户进行测试。

开发人员通常喜欢关于基础架构，系统扩展性，“难题”等的任务―这些都是能产生威望的地方。你很难让一个程序员对前端项目或用户界面工作提起兴趣。这跟你在一些面向客户的业务公司里发现的现象正好相反，那些公司里所有人都喜欢干客户能接触到的东西，他们会指着某一个界面功能说：“这是我做的”。在Facebook，后端的工作，例如新闻feed算法，广告定位算法，memcache优化工作等，都是程序员们的抢手工作。

对某项具有高优先级的功能有影响的修改(例如新闻feed)，在代码提交合并前要经过代码审查。新闻Feed非常的重要，任何的改动都要经过Zuckerberg(Facebook创始人，总裁)亲自审查，但也有例外的时候。

[纠正―感谢epriest]]“任何的代码的修改都必须进行强制性的代码审查(由一个或多个技术人员执行)”。我想这篇文章中说的是Zuck 本人并不会亲自审查每一处变动。“

[更正 感谢fryfrog]”所有的代码的变更都会经过至少一个人的审查，这套系统让其他人很容易的查看、审查你的代码―即使你没有邀请他。想让未经审查的代码进入代码库属于一种蓄意的不良行为。”

没有QA的事儿，完全没有。开发人员完全负责代码的测试，bug修改，后期维护。有一些单元测试和集成测试的框架，但很少人会用它们。

[更正 感谢fryfrog]”我要说的是，我们实际上是有QA的，只是不是一个正式的QA团队。每一个在办公室或能连接到VPN的员工都能看到一个包含所有的变更内容的、下次将要对外发布的网站版本。这一版本的网站更新的十分频繁，你能比世界上其他人提前1～12小时看到这个即将发布的版本。公司鼓励所有员工积极的报告发现的任何问题，对于问题会做出快速的应变。”

回复：很吃惊这里没有QA和自动单元测试―“大部分的开发人员都有能力写出没有bug的代码。只是在大多数的公司里他们没有动机主动去达到这种境界。当有QA部门存在时，你会轻松的把代码抛给他们，让他们去发现错误。“[编辑：请注意，这只是一种主观论断，我之所以把这样的话语收录到这篇文章里，是因为它跟我们其他公司里标准软件开发方法形成鲜明的对比。]

[更正 感谢epriest] ”我们有自动化测试，包括每次软件发布前必须通过的“push-blocking“测试。我们根本不相信所谓的”大部分的开发人员都有能力写出没有bug的代码“的说法，更别说一个公司会接受这种观点了。”

回复：很吃惊产品经理会没有影响力/控制权―产品经理有很大的独立性和自由度。影响力的产生关键在于和技术经理建立好良好的关系。需要有足够的技术知识来避免自己提出愚蠢的建议。除此之外，产品经理建立开发路线/Backlog不需要任何的批准或通过任何的审查。产品经理的数量相当较少，但他们都认为对公司里非常重要的、自己感兴趣的一个区域负有重要的责任。

一般情况下，所有提交的代码会每周一次的打包发布(周二)

如果努力些，本周做的修改也可以在同一天发布

周二程序发布时，所有在本周有提交过代码的程序员都要求在现场留守

在发布开始前，所有的开发人员的需要在特定的IRC频道里等候“点名“，如果没到的话，将会得到一次公开的批评。

实施组发布程序上线是一个逐步的过程

Facebook大概有6万台服务器

程序的发布有9个集中操作的规模级别

[更正 感谢epriest]”有几个级别的发布并不是集中式的。有三个阶段是集中部署的(阶段1 =内部发布，阶段2 = 小规模外部发布，阶段3 = 完整外部发布 )。其它6个阶段是辅助操作，包括内部工具部署，视频部署等。”

最小层级的部署只涉及6台服务器

例如，周二的新版本发布会从6台服务器开始(级别1)，实施组观察这6台服务器，确保它们都能正常工作，才能推进到下一级别发布。

如果发布过程中出现问题(例如，抛出错误信息等)，发布会终止。提交这些导致错误的程序的程序员会被叫来修正问题。然后发布会重新从级别1开始。

所以，发布有可能会反复重复几个级别： 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，以及短信找到相应的人。对实施组的呼叫不响应的会受到公开批评。

一旦程序部署到级别9，稳定下来，这周的发布就是完成了。

如果在特定的周期里没有足够的时间把功能开发出来，这个问题不大(除非有硬性的外部依赖)―功能会在完全完成后打包发布。

受到svn相关批评，公开批评，或经常的误工期会导致开发人员被辞退。“执行力非常的强“。没有效率或不是非常有才的人会非常的扎眼。经理通常会对低效能的员工观察6个月，然后说”我们无能为力，你不能很好的接受公司的文化。“对公司各个级别的人都是如此，即使是C级别和VP级别的人，如果他们不能做到非常的有效率，也会被迅速的辞退。

[更正 感谢epriest]“员工不会因为制造了bug而被开除。他们只会因为当有他们的代码被发布，有问题需要他在现场出现，但却没有出现来提供支持时被开除(还没有发现有人遇到这种情况)。“

[更正 感谢epriest]“被批评不会导致你被开除。对这样的事情我们受到了极大的宽容，大多数的资深程序员都曾干过至少一件恐怖的事，包括我。据我所知，没有人因为犯这样自然的错误而被开除。“

[更正 感谢fryfrog]我也没有听说过有任何人像本文中提到的那样因为犯错误而被开除的。我知道有人曾疏忽的把网站给能瘫了。他们努力的修复遇到的问题，每个人都从中学到经验。被公开批评要比被开除恐怖的多，我的感觉。

    观察Facebook的软件开发文化发展过程是一件非常有趣的事情―特别要注意的是随着公司的迅猛扩展，这种文化发展能否跟得上步伐。

    你有什么样的想法？这“以程序员为主导的企业文化”在你的公司里也适用吗？

建议继续学习：

1. Facebook 网站架构    (阅读：9767)
2. facebook 的工程师文化    (阅读：6292)
3. Facebook 的系统架构    (阅读：4998)
4. 谈谈Facebook的聊天系统架构    (阅读：4619)
5. Facebook性能大提升的秘密：HipHop    (阅读：4366)
6. 以Facebook为案例剖析科技公司应有的工具文化    (阅读：3589)
7. 在信息架构层次对比开心网和Facebook的设计    (阅读：3247)
8. 《打造 Facebook》笔记    (阅读：3074)
9. Facebook的用户体验评判规则    (阅读：2597)
10. 60 TB 数据：Facebook 是如何大规模使用 Apache Spark 的    (阅读：1199)