`
袁斌_AgileDo
  • 浏览: 63601 次
  • 性别: Icon_minigender_1
  • 来自: 北京
文章分类
社区版块
存档分类
最新评论

优秀公司的实践(一):Facebook的工作方式

阅读更多

优秀公司的实践(一):Facebook的工作方式

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

 

1)       工作方式

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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为基础的调度系统,用它可以在需要的时候通过FacebookemailIRCIM,以及短信找到相应的人。对实施组的呼叫不响应的会受到公开批评。

 

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/

 

 

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics