从QQ群看到，又参考 http://www.budoou.com/article/1368600/ 做了一些修改
原文在此，看完之后，终于明白为什么优秀的工程师都去了/想去facebook，因为那里是工程师们的天堂。
译文:
我对facebook的运转着迷。这是一个很独特的环境，不容易被复制（他们的体系并不适合所有的公司，即使他们努力尝试过）。下面是我和facebook的朋友们关于他们如何开发和管理项目的记录。
现在距离我收集的这些信息又过去6个月了，我相信facebook肯定又对他们的项目开发实践进行了改进。所以这些记录可能会有点过时。同时facebook的工程师驱动文化也越来越为大众所知。非常感谢那些帮助我整理这篇文章的facebook的朋友们。
记录：
- 截止到2010年6月，facebook有将近2000名员工，10个月前只有1100名，一年之间差不多翻了一番。
- 两个最大的部门是工程师和运维，每个部门大概都是400-500人。这两个部门人数大约占了公司的一半。
- 产品经理和工程师的比例大约是1:7到1:10之间。
- 每个工程师入职时，都要接收 4-6 周的 Boot Camp 培训，通过修补bugs和听高级开发工程师的课程来熟悉facebook。大概10%的新兵无法完成这个过程被劝退。
- 培训结束后，每个工程师都可以接触线上的数据库(更大的权力意味着更大的责任，也有一份”勿做清单”，不然可能会被开，比如公开用户的隐私数据。
- 有非常牢靠的安全体系，以免有人不小心/故意做了些不好的事。
- 每个工程师可以修改facebook的任何代码，随时可以迁入。
- 浓厚的工程师驱动文化。”产品经理基本可以被忽略”，这是facebook一名员工的话。流程执行到一半的时候工程师还能去修改规格，工程师有权利调整项目优先级，任何时刻插入自己新的idea
- 在每月的跨部门会议上，由工程师来汇报工作进度，市场部和产品经理会出席会议，也可以做些简短的发言，但如果说得太多，很可能就会被打小报告。他们确实想让工程师来主导产品的开发，对自己的产品负责。
- 项目需要的资源都是自愿的
- 一个PM （产品经理或者项目经理?）把工程师们召集到一起，让他们对他的想法产生兴趣。
- 工程师们决定开发那些让他们感兴趣的特性。
- 工程师跟他们的经理（Manager）说：”我下周想开发这5个新特性”。
- 经理（Engineering Manager）会让工程师独立开发，可能有时会让他优先完成一些特性。
- 工程师独立完成所有的特性——前端/后端/数据库，等等所有相关的部分。如果需要得到设计人员的帮助(FB里只有非常少的专职设计师)，需要先让设计人员对你的想法产生兴趣。其他如架构师之类的也一样。但通常来说，工程师要独立完成所有的任务。
- 对于某个特性是否值得开发的争论，通常是这么解决的：花一个星期的时间完成他，并在小部分人群中(比如1%的内华达州用户)进行测试。
- 工程师一般来说都比较喜欢做做基础架构，高负载高并发，所谓”真正的技术难题”…等等以获得声望和尊敬。很难让一个工程师对用户界面修修补补而燃烧热情，但FB相反，每个人都希望做那些影响用户体验的事情，这样他们就可以指着网页某处说：”这是我做的”。在FB，后端的工作比如newsfeed算法，广
告精准投递算法，memcached优化，属于饭后甜点型项目。 - 所有的代码修改都要进行审核(通过一个或多个工程师)，但News Feed是个例外，因为太重要了，Zuckerberg会亲自review。
- 所有的修改至少要被一个人审核，而且这个系统可以让任何人很方便地审核其他人的代码，即使你没有邀请他
- 工程师负责测试，修补错误，发布后的维护。确实也有个单元测试集成测试框架，但很少被使用
- 必须说FB是有QA的，只不过没有一个正式的QA团队。每个员工在内网使用系统的测试版本。版本经常升级，通常内部使用1-12个小时后就被发布到生产系统。强烈鼓励每个雇员去报告任何他们碰到的问题，这些问题也都飞快的得到响应
- FB有自动测试，代码发布前必须要通过测试。我们不相信”所有的工程师都能写出没有bug的代码”，毕竟这是一个商业公司。
- 缺乏产品经理来影响/控制项目好像有点奇怪——但是产品经理有非常大的独立性和自由度。PM拥有影响力的关键是和工程经理搞好关系。产品经理需要有足够的
技术头脑，别提傻想法，除了这点，产品经理制定其路线图的时候无需任何权限和额外许可。”我的产品主管并不完全了解我想做什么”。只有很少的产品经理，但
所有PM们都很有责任心的去做那些真正重要，以及个人最感兴趣的部分。 - 缺省所有的代码提交集成在一个周发布里(周二)。
- 通过额外的努力，提交也许可以被当天发布。
- 星期二的代码发布，需要所有的提交过代码的工程师在场。
- 代码打包前，工程师必须在一个特殊的IRC channel上。
- 运维团队运行代码，逐步的将代码发布给所有人
- facebook有大约60000台服务器
- 发布要分3个阶段：p1=内部发布、p2=小规模外部发布，p3=完全外部发布. 关于一些外围系统比如视频上载什么的被划到了另外6个发布阶段。一共是从p1到p9。
- 最小的级别只有6台服务器
- 周二的代码发布会先发布到6台服务器上，运维组会检测这6台服务器的反应，保证代码正常工作，然后再提交到下一级
- 如果发布出现了一些问题（如报错等等），那么就停止下一级的部署，提交出错代码的工程师负责修复问题，然后从P1开始发布。
- 所以一次发布可能会经历几次重复：1-2-3-fix. 回到1. 1-2-3-4-5-fix. 回到1. 1-2-3-4-5-6-7-8-9
- 运维组是受过严格训练，倍受尊敬，而且有商业意识的。他们的控制面板上不仅仅有错误日志、系统负载、内存占用，他们还计算用户行为。如果某个发布后导致FB用户的某项行为特征的百分比也有所变化，控制面板上就会显示出来，然后他们就会中止发布，然后去寻找原因。
- 代码发布期间，运维组使用IRC-based页面系统，可以通过facebook/email/irc/im/sms 呼叫每一个工程师，如果需要他们注意的话。没有及时回应运维团队的开发者会被公开批判。
- 代码一旦发布到第9级，并且稳定运行，就算发布成功了。
- 如果一个特性没有按时完成，也没什么大不了的，下次完成时一并发布即可。
- 被svn-blamed（qyb:我猜测svn-blamed的意思是某人提交了一个特别弱智的bug，然后被svn blame命令检出这次提交的作者信息贴在内部邮件组里…也许FB定期公布这些工程师名单，被称之为svn-blamed），被公开批判的或工作经常延期就很可能被开除。”这是一个高效的文化”。不够高效或者不够聪明的员工会被剔除。管理层会在6个月的时间里观察你表现，如果不合格，只能说再见。每一级都是这个待遇，甚至对于C级，VP级员工如果没有达到更高的预期也会被立即解雇。
- “如果只是写出了bug，工程师不会被公开点名。但要是发布出问题被要求支持的时候不在现场或者自己也没能找个替班的人，那就会被点名了”
- “被svn-blamed的并不会被导致解雇。我们还是很宽大的。即使是资深开发工程师，大多数也避免不了被blamed，包括我。据我所知，没有人因为这种情况而被解雇”
- 我也没有遇到过因为上面提到过的犯错误而被解雇。有些人犯了错，他们会非常努力地去修复，也让其他人得到了学习。