优秀公司的实践（一）：Facebook的工作方式

Andy_AgileDo

墨衍会员 · AI 创作全网分发码龄17年

关注

原创最新推荐文章于 2026-07-05 15:10:23 发布 595 阅读 AI 写同款· GEO 优化 ›

优秀公司的实践（一）：Facebook的工作方式

本文介绍Facebook如何工作。文章摘自网络，在文章的结尾会注明所有的出处。文章的目的是分享成功的公司的成功经验。成功经验很难单一复制，但思路值得思考。

1) 工作方式

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

b) 产品经理跟技术人员的比例大概是1：7到1：10。产品经理有很大的独立性和自由度，影响力的产生关键在于和技术经理建立好良好的关系，需要有足够的技术知识来避免自己提出愚蠢的建议。

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

d) Facebook的企业文化对产品的管理工作是十分重视的。所以，产品管理这个角色并不是可有可无的。并且，这个公司的企业文化是让“每一个员工”都感到对产品有责任。

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

f) Facebook代码产生的过程包括写代码（write code），测试代码（test code），审查代码（review code），提交代码（check in code），发布代码（release code）。写代码指在自己的开发机器上做好修改，这些修改只存在于自己的开发环境中；测试代码指在本地端测试自己的修改以保证修改不引入明显的问题；审查代码指找合适的工程师同事来查看待提交的代码；提交代码是将经审查的代码提交到服务器端的代码库之中；发布代码是将提交的新代码同步到所有的服务器端让最终用户使用新的功能。

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

h) 我们有自动化测试，包括每次软件发布前必须通过的“push-blocking“测试。我们根本不相信所谓的”大部分的开发人员都有能力写出没有bug的代码“的说法

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

j) 一般情况下，所有提交的代码会每周一次的打包发布(周二) ；如果努力些，本周做的修改也可以在同一天发布。如果在特定的周期里没有足够的时间把功能开发出来，这个问题不大(除非有硬性的外部依赖)—功能会在完全完成后打包发布。

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

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

m) 员工不会因为制造了bug而被开除。他们只会因为当有他们的代码被发布，有问题需要他在现场出现，但却没有出现来提供支持时被开除；被公开批评要比被开除恐怖的多

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

a) 整体思路：测试通过后，产品质量基本有保证。即使有漏测的bug，只会影响很少量的用户。及时监控到问题。及时修复。

b) Facebook大概有6万台服务器

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

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

e) 如果发布过程中出现问题(例如，抛出错误信息等)，发布会终止。提交这些导致错误的程序的程序员会被叫来修正问题。然后发布会重新从级别1开始。所以，发布有可能会反复重复几个级别： 1-2-3-修复。回退到 1. 1-2-3-4-5-修复。回退到 1.1-2-3-4-5-6-7-8-9。

f) 实施组的服务器测评是基于常见错误日志、负载&内存使用统计—包括用户行为统计。例如，如果新推出的发布导致了用户使用Facebook功能特征的百分比下降，实施组能在他们的统计工具里看到这种变化，他们会停止这一版的发布，调查其中的原因。

g) 发布过程中，实施组使用以IRC为基础的调度系统，用它可以在需要的时候通过Facebook，email，IRC，IM，以及短信找到相应的人。对实施组的呼叫不响应的会受到公开批评。

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

3) 如何培养新人

a) 第一周的周一，新来的工程师们在公司自助餐厅里和负责他们的导师（Mentor）吃完中饭后，为期六周的强制性训练营就拉开了序幕。每人会看到6封电子邮件，其中1封是欢迎信，另外5封介绍了他们将要执行的任务，包括修复Facebook网站上的错误。训练的目的很多，其中之一就是让新员工充分认识到，他们拥有直接改变Facebook网站的力量。

b) 头三周有很多课程要上。一般公司的COO（首席运营官），CPO（首席产品官），工程副总裁都会在第一周给新人们介绍各个部门概况，给大家一个全局的认识。第二周，重点在于公司各个重要产品，常用的技术框架和技术工具的介绍。第三周，集中在公司的运营（包括市场，销售等部门），商业模式（Facebook主要的广告模式和虚拟货币的盈利手段）和其他非产品技术部门的介绍。

c) 从第三周开始，新人们就开始接触很多相关的需要招人的组，和这些组的经理交流，了解这些组的产品，参加这些组的会议和讨论。一般要求在第三周的周末，新人要选出不多于三个组作为他们感兴趣的备选组。接下来每一周的事情就是进一步缩小目标范围，以达到在第六周时只剩备选组的目的。这个组当然就是新人最后要加入的组。

d) 从第一周到第六周，所有新人60%以上的时间，都需要花在修复代码错误上面。其他所有的事情应该在剩余的40%时间内完成。Facebook相信，让工程师融入公司最好的办法是通过代码的交流。毕竟，产生高质量的代码的确是所有工程师最主要的工作。

4) 招什么样的人？

a) 高智商的人。经验丰富的10年以上的工程师可以可靠的完成事情，但是高智商的人，即使经验不丰富，但是他们会在很短的时间做到前者一直都做不到的事情，这才是Facebook最需要的人

b) 对Facebook的事业有认同感。这样的人会真心付出！

5) 产品研发

“我们并不只注重单一用户的使用体验，而更关注其是否影响整个社区和产品，所以需要在产品开发的各个环节做取舍。例如用户的信息只分享给与之有联系的其他用户，而不是所有的用户。取舍的度，那是靠直觉。直觉依赖于产品的目标，我们产品的目标是长期的使整个社区和用户群体的利益最大化”