为帮助工程师更好地进行产品开发，Facebook对内部工具（Tools）是非常非常关注的。招聘我进公司的总监黄易山，就是这方面一个最有力的倡导者。他极力强调，公司要把最好的人才放到工具开发那一块，因为工具做好了，可以达到事半功倍的效果，所有人的效率都可以得到提高，而不仅仅是工程师。

　　Facebook有两个工具组。一个叫研发工具组（DevTools），专门负责研发工具的开发和维护，包括所有有助于工程师开发速度和质量的工具，主要服务对象是内部工程师。另外一个叫网站支持和工具组（SiteSupport andTools），主要负责公司里所有通用工具的开发和维护，关注的主要是如何方便用户和Facebook的交流以及Facebook内部的沟通，主要都是通信工具，服务对象是用户和所有员工。

　　研发工具有哪些呢？

　　新的工程师刚加入Facebook时，需要分配自己的开发服务器，公司就做了一个工具来管理分配所有的开发专用服务器。在一个页面上，你可以很清晰地看到所有的开发服务器，包括哪些人是现在的使用者、什么时候申请分配的、服务器的操作系统版本、配置信息等。对于空余的服务器，你可以一键申请，并自动初始化该服务器。这让刚加入的菜鸟们可以迅速地获得自己的研发活动空间。

　　工程师最重要的工作就是写代码。针对代码管理，公司也开发了很多工具。我在这里介绍部分工具供参考。Facebook的代码库管理是通过一种叫GIT的开源管理系统，为此开发了一些工具来集成GIT。比如有一个工具是在提交代码之前自动检测所修改的代码是否符合公司代码规范，如果不符合，该工具会自动警告，但把决定权交给工程师。Facebook提倡对修改的代码写测试案例，在代码提交时自动检测是否存在覆盖这些修改的测试案例，如果没有则会警告，但工程师仍然可以强制提交。但这种情况下，代码若出错给网站带来巨大危害的话，工程师可能会被严厉批评，因为这本是可以避免的错误，是人性的狂傲忽视了工具的提醒。在代码审查（CodeReview）方面，Facebook做了一个可视化的工具，现已开源，叫Phabricator。工程师可以在页面上非常方便地针对每一段（单行或者多行）代码进行交互讨论；负责审查的工程师可以接受代码改变，可以提出疑问要求原作者继续修改，可以提出自己不适合以退出该代码审查，等等。只有代码被明确接受后，才能被工程师提交到服务器端的代码库，这一点被集成到提交工具中强制执行。这些工具的基本理念就是，凡是被很多人不断重复的好习惯，要将其自动化，绑定到工具之中。以“Don’tMake Me Think”（别让我多想）的方式来推广好习惯。

　　Facebook的代码发布是灰度发布，所以开发了一个方便设计灰度发布的工具。在这个工具中，工程师和产品经理（也可以授权给其他非研发人员）可以设计新产品发布的目标人群特点（比如对年龄、性别、地域、受教育程度等方面的限制）及发布的人群比例（在0%～100%之间自由调整），所有的改变都不需要修改代码，只需要在工具页面上点击鼠标即可，让灰度发布变得很轻松。

　　发布过程由一个利用点对点（BitTorrent）算法实现的工具进行多线程同时发布，更新几十万台机器只需要几十分钟。由于是不间断地发布，对公众的服务不可以停，所以Facebook会将一部分机器从公众服务状态中拿下来，更新之后再放回，然后继续下一批，直到所有机器都被更新。这样就可以保证在任意状态下都有足够多的机器来支持用户访问。整个过程都是通过工具自动实现的。而监控这个发布过程的进展，也有一个工具用于监测并且将其进度可视化，你可以很方便地看到哪些服务器更新了，现在正在更新哪些服务器，整个网站的进度是百分之几，等等。

　　发布之后的数据监测更是重点，Facebook做了很多工具使之变得容易。数据收集只要1～2行代码即可完成，数据的整理、分类和存储皆在后台的上万台服务器上自动完成，数据的可视化报表只需要通过一个页面工具点点鼠标设置便可即时生成，不需要任何代码。数据波动的自动警报也可以设置，可以自动发邮件、发短信，可以要求24小时全球轮班的站点稳定工程部门（SiteReliabilityEngineering）按照你既定的反应方案去解决。如果还不行，最后会打电话给你，直接把你从床上拽起来。在Facebook工作的四年半时间里，这样的事件至少在我身上发生了10次。

　　还有一种工具是人为的，我们组经常用，就是把最最重要的目标及相关的任务、目标日期、负责人等信息写到白板上，挂在离我们最近的墙上。每天一抬头就可以看到，每次开会都会路过，时刻提醒我们最最重要的事情是什么，这种工具对我们组非常有效。

　　网站支持和内部通信工具有哪些呢？

　　在如何处理用户和Facebook之间通信这个问题上，针对常见的问题（尤其是关于如何使用某项功能的问题），Facebook在用户提交时，尝试将其引导到网站帮助或FAQ的页面。但这并不能满足所有人的需求，尤其是和个人特殊情况相关的问题，仍然有很大一批用户会坚持提交问题，这时候Facebook内部处理工具就要把问题自动分配（Routing）到最相关的运营组，比如，和支付欺诈相关的问题应当自动分配给反欺诈运维组的那十几个人。然后，工具会提供常见的通用解决方案，比如，若选择退款，可以做到一键退款，绝大多数回信内容自动产生（用户姓名、原问题等个体信息都会自动嵌入），运维人员可以选择要不要修改内容，然后发送。如果针对某一个功能的问题突然多起来，工具会自动发现并提醒运维人员手动查看，运维人员可以根据实际情况决定要不要工程师介入寻找并修复可能的问题根源。所有用户问题的回复率、回复满意度、交互次数等信息都会被统计或抽样统计，以保证客户服务的质量。

　　另外一个重要工具是招聘工具。Facebook有一套专门的做题系统（PuzzleSystem）尝试去筛选可靠的工程师。这套系统是一个专门的招聘工程（RecruitingEngineering）组做的，包括题库的管理和更新、自动提交系统和打分系统等。如果在解题这个环节脱颖而出的话，公司猎头（Recruiter）会给工程师打电话，安排他下一步的电话面试。另外一种获得电话面试的途径是通过内部推荐。所有的内部推荐都是通过专门的人才提交工具上传简历，这个工具和整个招聘系统结合，并注明这是一个内部推荐、谁是推荐人。而整个面试过程里，包括谁应该参与面试，谁实际参与了面试，每一步面试官对应聘者的评价和打分，都在工具里被很好地记录和显示出来。当然还有必不可少的权限控制——只有参加面试的人员才能够看到关于应聘者整个流程的所有资料。最后，该工具允许打印所有的相关资料以帮助决策委员会在讨论该应聘者时拥有全部的相关数据。

　　还有一个重要的工具，就是每六个月一次的业绩评价工具。这个工具允许员工对自己评价、员工互相评价、员工和老板之间互评等，还要考虑权限的管理。这并不是一个很容易开发的工具，一开始是内部开发，但后来还是决定使用Rypple来提供专业的业绩评价工具。

　　从这些工具可以看出，Facebook是一家工具驱动的公司，但这并不表示所有工具都要公司自己开发。必须清楚的是：工具开发是手段，而不是目的，Facebook的目的是打造一个最好的社交网站。因此，对于某个需要的工具，如果有更专业的人做得更好的话，Facebook非常乐意付费购买他们的服务，而把精力集中在核心产品上。这就是为什么Facebook会花大笔钱购买数据库软件MySQL的支持服务。

　　还有很多其他工具。Facebook希望通过工具来解决所有可能想到的问题，比如，要请假有相应工具，你可以说明休息多长时间，需要让哪些人知道这些情况等；所有新想法的提出、讨论，让网络头脑风暴变成了可能；各种电子设备如电脑、手机等IT服务的请求和处理，通过工具来解决……能够想到的地方就尽可能用工具。与物理工具不同，计算机工具可以实现“杠杆效应”的反复累积，通过组合这些“杠杆效应”可以达到更高的层级。

　　因此，公司的工作效率，影响到你需要雇用的员工数，影响到公司的成本究竟是多少，并将直接影响到公司内部产品的独创性。黄易山就认为，工具团队不应该是一个由二线员工组成的“事后诸葛亮”的后勤部门，公司里最有才华的工程师应该用公司自己的工具来工作，并且企业文化里要优先反映这些。编写出优秀的工具并继续加以改善、更新，这比寻找下一个伟大的创意更重要。

　　我最近跟国内一些技术公司的高管们讨论过有关工具的话题，有些人非常赞同，也想通过工具来解决很多工程性问题。比如你要在公司里推广一些规范性的规则，一种传统的方法是反复强调，另一种是开发出好用的工具，把这些东西固定化在里面，借助工具进行强制性推广，就能解决很多问题。Facebook没有专门的软件质量测试人员，都是工程师自己进行。公司就有这方面的工具，把测试过程中重复性的工作集中起来，自动化实现，只有一些必须要个性化处理的部分由工程师具体再去做。我在开发反欺诈系统时，将欺诈案例识别直接抛给人工处理当然是最简单的方式，但我们希望通过自动处理来解决大部分欺诈案例，而把精力放在那些确实需要单独处理的特殊案例上，最后决定的方向是“进行自动处理”和“建立反馈机制”，设计出用于用户报告（外部工具）和案例审查（内部工具）的工具。这样一来，我们也可以自动采集客户支持部门的处理意见，并集成到下一轮的机器学习中去，工具会越加精确、聪明，且与时俱进。

　　Facebook在2005～2006年的发展中，公司根据不断增长的用户数量，聘请了成比例的客户服务人员。当后来有1000万用户时，公司的客户服务人员还不到20个。到Facebook的用户数量达到1亿时，很明显，公司不能用相同的速度来增加员工数量，所以公司让内部方案团队与客户服务分析师更加紧密地配合，推出了更具创新性的工具和用户界面，极大地提高了客户服务部门的工作效率。通过内部工具团队研发的产品，客户服务部分析了目前已完成建立的工作并创建了定制方案，方法是让电脑去做可自动化处理的部分并优化用户体验，这样客户服务分析师就可以专注于人工最擅长处理的事务。

　　不断发展、改进公司的内部工具，可以减少招聘运营人员的费用，让每个员工的效率更高，这样既改善了整体协调（员工数量少意味着协调更容易进行），又减少了整体开支。如今，Facebook每一位工程师服务的用户数均超过100万人，随着用户数量的持续增长，这种效率优势将更加明显。

　　不过有一个现实问题是，工具团队要招聘新员工有一定难度。Facebook的用户已经达数亿，而且还在不断增长，如果你开发的是直接面向用户的产品，每天有那么多人在使用，那成就感显然非常棒。而你要说服新员工去开发内部工具，称这样可以带给工程师以及其他同事更高的效率、最终帮助公司做出更好的产品，这个理由显然缺乏吸引力。所以，工具团队在招聘上花了很多工夫，想各种办法找到合适的人。

　　一种方式是用一些通过提高效率的具体案例和数据来做理性说服，这需要在开发工具的同时检测工具使用前后的效率变化。当然，为了吸引内部最好的人才愿意到工具团队，企业文化中也一定要着重反映出这一点：公司将内部工具视为持续的重要投资，以保持公司的领先地位。集中精力努力说服几位顶尖工程师加入工具组，具有很好的示范效果和磁铁效应。如果真正做到如此重视，最优秀的工程师是愿意加入工具团队的，这样可以大大提升同事们的效率，从而更好地服务于用户，这也是一种外部用户所感受不到的成就感。

　　第四节　Facebook的招聘标准：只和最好的人合作

　　一流人才只愿意和与自己水平相当的人共事，他们聚在一起会变得更好。一流人才无法容忍二流人才。

　　在招人的标准上坚持一点，让面试官明白他们需要招到比他们更强（在某些方面），至少不会拖后腿的人，如果不是，那就拒绝平庸，不要妥协。

　　Facebook就是希望通过这样的程序能找到一流的、合适的人才，这样才能做出最好的产品，成就伟大事业。面试中的技术性问题就是解决“是否一流”的问题，文化性问题就是解决“是否合适”的问题。

　　一流人才只愿意和与自己水平相当的人共事，他们聚在一起会变得更好。一流人才无法容忍二流人才。那什么是“最好的人”？我个人的理解是能够尽其所知，用其所长，学其所不能，从而迅速完成目标并远超期望的人。他们的本能是挑战自我，超越别人的期望，超越自己的期望。对他们来说，仅仅“足够好”是不够的。

　　全部由一流人才组成的团队有很多好处。

　　1.这让你更加愿意被委以重任。从我的经验来看，他们不会轻易信任不熟悉的人。如果你还没有证明自己和他们一样出色甚至更出色，他们宁愿独立辛苦工作也不愿接受你的帮助，因为他们担心你会搞砸。但当你证明自己之后，他们会信任你，放心把事情交给你一起合作。一个互帮互助的一流团队才能真正做到1+1远大于2。

　　2.通过完成艰巨任务，一流人才互设榜样。你会想“真牛啊，这哥们儿竟然能把这玩意儿做出来，我得加油了”，对这种同伴带来的压力进行合理利用，可以大幅度提高工作表现，并在团队中形成良性循环。Facebook鼓励不同项目间公开分享他们的苦与乐、成果与教训，从不吝啬对好项目的公开赞美，这样才能让榜样的影响传播开来。

　　3.一流人才喜欢互相挑战。我记得有一位工程师总监曾立下赌约——如果在规定时限之前完成网站翻译平台所需的代码修改，他将把头发染成蓝色。这样的挑战把“枯燥”的工作变成了具有挑战性的游戏。在玩游戏中写程序比纯粹地写程序要有趣得多。当然公司里也有很多更加认真的挑战。Facebook有个很知名的开源项目，公开叫HipHop，它是将PHP的代码重写成C++，然后再编译成二进制代码，可节省CPU资源40%以上。这个项目一开始没有人相信能完成，但推动这个项目的华人工程师赵海平坚持了下来，并做到了。赵海平后来被美国《快公司》（FastCompany）杂志评为2010年度全世界最具创新精神的50人之一。这种高难度的挑战在Facebook并不罕见。因为一流人才天生容易对挑战上瘾，不管是挑战别人还是接受新的挑战。

　　4.一流人才可以相互学到很多。每个一流人才都有自己“牛”的地方，彼此有很多可以互补之处。如果Facebook没有这种学习的环境，我就可能不会在那儿待四年多。对缺乏经验的人来说，这点很有用。我们雇用非常聪明的毕业生（潜在的一流人才），这些人希望“引爆”自己来证明他们“牛”在何处，他们不愿到一个舒适、无挑战的公司过日复一日的生活，他们希望通过不断学习来丰富自己的经验，完成不可能完成的任务，并在职业生涯中前进，证明“我行”。毫无疑问，和一流人才在一起，才能更容易地实现这些目标。

　　那如何才能远离非一流人才呢？首先，慢点招人（HireSlow）。在招人的标准上坚持一点，让面试官明白他们需要招到在某些方面比他们更强，至少不会拖后腿的人。如果不是，那就拒绝平庸，不要妥协。我曾好几次在招聘决策会议上发现履历看起来很漂亮的应聘者无法拿到Offer，只因为某个面试官觉得这个人没给他留下深刻的印象，没有让他“惊讶”。而有些获得一致通过的候选人仍被放弃，因为大家都只是觉得他仅仅“符合要求”而已，没有出彩的地方。在招人问题上，绝大多数情形下，要小心，不要冒进。Facebook也会雇用那些没有全票通过、但有一两票是“强烈推荐”的应聘者，或者这种应聘者本来就是通过内部推荐而开始面试的，因为对于已有员工的“强烈推荐”不应轻易忽视，这时可以适度冒险。

　　其次，炒鱿鱼要快（FireFast）。使用非一流人才就像服用慢性毒药，迟早会出事。Facebook要求所有的经理人员对员工的表现要特别敏感，经理如果发现员工所分配的任务经常没有完成或者答应的事情经常没有做到，如果是客观原因，一定要尽力帮助解决；如果判断为能力问题，那就通过合法的程序迅速将人炒掉。我见过几次比较慢的解雇，对团队造成了极大的负面影响。

　　这里讲一个合作的组里发生的故事。我们组做的很大一部分工作是设计机器学习模型以对支付欺诈做自动判断，所以对数据分析要求非常高。因此，我们在和我们合作的运营组中设立了机器运行数据专家的职位。     

      2010年时，面试了一个剑桥大学毕业的博士，年纪比较大，他在面试中展露出非常渊博的关于机器学习的理论知识。光他展示出的论文就有5厘米厚，当然我也懒得看。通过他做实际的编程题目，我感觉他的工程实现能力并没有达到我所希望的、能和我们组顺利配合的标准。所以在那次面试中就我给了“不推荐”，但由于我只是帮合作的运营组招人，而且职位也不是工程师，对工程能力的要求相对要低，所以我没有坚持反对招这个人。但后来发现，我其实应该坚持。因为这位学究式的人物最适合待在研究所，他只知道不断地提出一个又一个新办法，却不会把一个不完美的办法不断地实现出来，加以工程化，然后通过实际数据不断完善。我觉得他的表现应该被注意到，并给予适当的压力去改进。于是向他的老板反映了这个情况，但他的老板不够重视，没有马上采用我的意见。那我只能单方面地采取自己力所能及的措施——将他和我们组的项目隔离，因为我们组的工程师不希望他继续参与这些项目——我们开始不邀请他到我们的项目会议中来，自己在工程师部门内部去寻找相关的机器学习专家、有很强的编程实现能力的专家。此人后来在运营组内部也造成了各种不作为和损失之后，终于离开了公司。我觉得他早几个月就应该离开。倒不是说他不够聪明，只是他想做的是研究，而公司想要的是把想法迅速地、高质量地实现出来，然后在实践中不断改进，这种文化上的巨大差异和期望上的截然不同导致了必然的悲剧。