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

优秀公司的实践（一）：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) 产品研发

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

 

 

 

文章摘自以下链接，感谢原作者的辛苦工作：

http://www.aqee.net/how-facebook-ships-code-facebook/

http://blog.jobbole.com/30278/

http://video.sina.com.cn/v/b/49752787-2036021381.html

http://blog.jobbole.com/29907/