以Facebook为案例剖析科技公司应有的工具文化

编者按：本文由 @王淮 Harry 哥 撰写，摘自他即将出版的新书。王淮是 Facebook 早期员工，中国藉第二位工程师第一位研发经理。

　　前言

　　前段时间和大众点评的 CEO 张涛聊天的时候碰到内部工具这个话题，我们都非常推崇一个优秀的技术公司应有有一个非常强势的工具文化。在工具上，我有很深的体会，我说那不如我把我的理解通过 Facebook 的一些实践例子来阐述一下，希望对科技公司有些帮助。

　　不断发展、改进公司的内部工具，可以极大提高每个员工的工作效率，可以减少运营人员的数目；这样既改善了整体协调，又减少了整体开支。

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

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

　　研发工具有哪些呢？

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

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

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

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

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

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

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

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

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

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

　　关于工具的一些思考

　　在 Rypple 的例子中要强调一点，Facebook 是一个工具驱动的公司，但这并不表示所有的工具都要自己开发。工具开发是手段，而不是目的，Facebook 的目的是打造一个最好的社交网站。因此，如果某个需要的工具有其他更专业的人做得更好的话，Facebook 非常乐意付费买他们的服务，而把自己的精力集中在核心产品上。这就是为什么 Facebook 花大笔钱购买数据库软件 MySQL 的支持服务，购买 Rypple 的工具的原因。

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

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

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

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

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

　　工具文化的最大挑战

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

　　一种方式是用一些具体的工具提高效率的案例和数据来做理性说服；这需要在开发工具的同时要检测工具使用前后的效率变化。当你有确确实实的数字来告诉最好的工程师，来吧，我们对公司的贡献不比做产品的那些人差，正是我们的工具让他们的效率提高了这么多，所以所有人的工作成果都有我们的一部分功劳。当然，为了吸引内部最好的人才愿意到工具团队，企业文化中也一定要着重反映出这一点：在不同的公开场合私下会面都不断的强调其重要性，让所有人都清楚，公司将内部工具视为持续的重要投资。另外一个可供参考的窍门就是集中精力努力说服几位整个工程部门认同的顶尖工程师加入工具组，具有很好的示范效果和磁铁效应。如果真正做到如此重视，最优秀的工程师是愿意加入工具团队的，可以大大提升同事们的效率，从而更好地服务于用户，这也是一种外部用户所感受不到的成就感。