转载

专访葛俊：16亿用户背后的高效率，定义Facebook工具文化

人类在进化过程中最显著的变化是学会使用工具，也许进入互联网时代后工具的定义越发模糊，但使用工具的最终目的没有变化——提升效率。在互联网工具中，Facebook的内部工具和开发效率在业界非常有名，以Facebook为例现代互联网企业内部需要怎么样的工具，内部工具团队又应该如何建设，研发内部工具时又应保持怎样的原则，这些都是优秀的技术管理者应该考虑的问题。

2016年7月15-16日， ArchSummit全球架构师峰会将在深圳举行。本届大会，我们邀请了Stand Technologies研发总监葛俊，前来分享《Facebook内部工具：揭秘服务16亿用户背后的高效率》的内容，讲述的是Facebook高开发效率的几个关键原因和创建发展一个成功工具团队的经验，以及提高公司整体效率的思考和建议。

现在我们就来采访葛俊老师，和他一起回顾互联网公司内部应有的工具文化吧。

受访嘉宾介绍：

葛俊，十二年开发和管理经验，系统构架和工具方面有丰富经验。在Facebook任职期间负责核心工具Phabricator的开发和开源，以及Nearby Friends项目的开发。最近任创业公司Stand Technologies研发总监，负责所有产品的构架设计。

InfoQ：您已经有十二年开发和管理经验了，能谈谈自己的从业经历吗？

葛俊：我研究生毕业后加入微软西雅图总部，在Windows组做了三年测试开发，在Office组做了三年多开发；然后在2010年底加入Facebook，之后于2015年初离开Facebook加入创业公司Stand Technologies任研发总监。

在微软Windows组做的是WinRE的测试。WinRE是修复Windows启动的一个小型操作系统，当主操作系统不能启动时用户可以选择进入WinRE对主操作系统进行修复。我的职责主要是写程序破坏Windows然后启动WinRE测试它的修复功能；在微软Office组做的是 Office.net 网站的开发。

在Facebook首先加入内部工具组，与两个同事共同负责Phabricator的开源（2011年4月开源）。Phabricator是一套核心功能是代码审核的网站应用，Phabricator开源之后我负责Phabricator在Facebook的继续开发、维护以及和开源社区的协调合作，同时有参与少量其他内部工具的开发和维护；之后加入Nearby Friends组，负责News Feed和后端大数据存储，Nearby Friends产品于2014年4月上线。

2015年二月离开Facebook加入Stand Technologies，作为技术总监负责所有三个产品的构架设计和部分开发，以及负责产品的推送、监测、自动扩展、可靠性、数据分析。

InfoQ：能否介绍您负责的Facebook核心工具Phabricator的技术框架，Phabricator的设计思路是如何形成的，研发过程中遇到哪些印象深刻的问题以及如何解决？Facebook给类似项目会提供怎样的资源和帮助？

葛俊：Phabricator开发在PHP + MySQL 环境上，是一个典型的分层网站应用：

数据库上是一个很薄的数据抽象层叫Lisk，是Phabricator自己开发的库；
其上是Business逻辑层，提供一些常用的对象的操作功能；
最上面就是应用层：网站逻辑网站逻辑有十几个应用，代码审核只是其中一个。Phabricator还有一个命令行工具叫Arcanist. 它利用一个叫Conduit的库与Phabricator网站服务API联系。

因为Phabricator是一个开源产品，很多使用的公司会有不同的需求。为了满足一些不太常见的需求，Phabricator提供了一个插件机制，使用者可以在许多地方加入自己的功能。具体实现方法是实现一个类，然后在一个配置文件中指定新类的名字。为了和使用者公司的其他工具集成，Phabricator使用了类似的插件机制。另外它还有一个用户ID镜像机制支持多种第三方登录。

Phabricator的设计完全是有机产生的，它最早是因为Facebook内部需要代码审核但是市场上没有足够好的工具而由Facebook员工自主开发的。基于内部开发需要，它的功能的不断增加演化，另外每隔一两年会做一次重构提高速度。在开源之后，又根据Facebook以外其他使用公司的需求继续增加和提高功能。

关于遇到的问题和挑战，我印象比较深的有两个：

开源的挑战

首先我们需要去掉Facebook内部代码的依赖性。具体实现就是把所有的依赖的代码模块化，然后在开源的repository里做一个相同的实现，另外需要实现和其他工具的集成。在开源之前，Phabricator和其他工具因为在一个repository里，所以很容易，但是也很乱。我们的解决办法是在Phabricator和Facebook内部代码里各实现一个API接口提供服务，然后双方面各自实现客户端进行数据交换。工作量不小，但是它强迫我们提高代码的模块化和质量。
开源以后怎么最好地继续满足Facebook的需求

我们主要有三个办法：

A. 在Phabricator开源代码里实现;

B. 在Facebook的插件里实现；

C. 在Facebook内部代码里实现，然后直接访问Phabricator的API甚至是数据库。

从代码的模块化和可维护性来说都是A > B > C。但是从难度上来说也是 A > B > C。因为Facebook的需求很可能其他公司的需求并不相同，所以我们不可能简单地把功能直接加到Phabricator代码里。我们的具体做法是尽量用方法A，不行就用B，实在不行就用C。

举一个例子，Facebook有一个需求是允许一个组的多个开发成员可以审核涉及到他们的代码的所有commit以保证代码的安全性。但是这个需求太细节，很多其他公司用不到。我和Phabricator开源社区进行了多次讨论，最后把这个需求普遍化，实现了一个功能使得用户可以对所有的commit在推送后进行审核。然后重新利用Phabricator原有的“团队”概念实现的“一组开发人员”。之后我负责一部分开发，Phabricator开源社区负责一部份开发。他满足了Facebook的需求，同时对其他用户也有用。这个功能后来成为Phabricator的一个很重要的功能，叫做Audit。这样做还有一个好处：Facebook不用单独维护这个功能。

Facebook很重视工具，因为它非常注重提高效率。根据投入和产出进行分析，Facebook进行资源分配以达到效率最大化。比如在公司从网站向移动平台转型的时候，需要很多工具的支持，Facebook就投入了很多的人力物力保证开发能够高效的执行。而当一个工具稳定之后，它又会降低投入。

InfoQ：Facebook目前已经服务16亿月活跃用户，每一项功能都有海量用户使用，这对你们技术开发有哪些考验，对开发思路产生了哪些影响？Facebook是否存在处理海量用户请求的通用思路？

葛俊：我没有觉得有一个通用思路，但是始终在考虑海量用户。绝大多数项目都会

在计划和构建时都做Capacity Planning，提前设计好数据存储的种类和使用方法，提前部署；
分析数据读取的可行性。根据读写频率决定缓存层的使用，决定可以支持几层朋友关系的查询，决定是否需要加入新的缓存；
做Stress Test；
逐步扩展产品发布的区域，确保Capacity和Performance。

InfoQ：据传Facebook最厉害的工程师都需要进入工具部门去锻炼深造，能否介绍Facebook的工具文化？对你们开源技术或者架构产生了哪些影响，中国互联网企业有哪些可以借鉴的地方？

葛俊：我没有听说过“工程师都需要进入工具部门去锻炼深造”这个说法，不过Facebook对工具非常重视，而且每个员工在入职时候会有六个礼拜的Bootcamp去完成公司各个组的任务，工具组的项目也在其中。

我觉得Facebook的工具文化是公司的文化上面再加一条“重视效率”。公司的文化有“Move Fast and Break Things”、开放、连接等。“重视效率”则是在各个方面都考虑投入产出比，以及优化员工的效率。举几个与开发没有直接联系的例子，办公室走廊上会有大屏幕显示办公室地图可以查找同事和会议室地点，公司自己开发会议工具方便安排会议，公司内部设置有银行分部，理发店，牙医诊所等使得员工可以更高效的工作，总之方方面面都注重效率。

因为Facebook注重开放性和连接性，它也很注重开源。2013年开源90个项目。2014年107个（没有找到2015年的数据），是业界开源项目最多的公司。

我觉得有两点中国互联网公司可以借鉴。第一是”方方面面都注重效率“，第二是”开放性“。展开讲一下”开放性“，Facebook绝大部份代码（如果不是全部）都对所有开发人员开放。工具的代码也在里面。整个开发环境和测试环境设置都非常方便，所以任何开发人员如果觉得哪个工具不太理想都可以非常方便的做改动或者开发新工具然后进行测试、推送，这大大提高开发人员的工具开发积极性，我个人觉得这是Facebook工具做得如此出色的最重要的原因。在与国内互联网企业的交流中，我发现很多国内企业倾向于把代码保护的特别严，我觉得可以在公司内部放松一些。

InfoQ：设计内部工具和设计对外产品在开发思维和开发各环节上有哪些不同？

葛俊：设计内部工具面对的是公司内部的员工，与面对外面的用户相比有三个特点：

第一个特点是距离近，所以可以更方便地拿到用户需求和用户反馈，所以可以用更快的迭代速度实现；
第二个特点是对产品的美观性，易用性要求没有那么高。比如工具可以更多地考虑用命令行界面而不是图形界面。在图形界面的实现上对美工要求也没有必要像对外产品那么高；
第三个特点是内部工具重点在于提高效率，所以要多注意整个开发流程中的痛点以及在对开发有干扰的任务切换部分进行重点优化。

InfoQ：您在本月16日ArchSummit中将分享Facebook内部工具对提升效率的作用，那么企业应该什么时候考虑建设内部工具的问题？在解决哪些特定需求的情况下，您建议企业集成现有开源项目还是选择内部开发，为什么？

葛俊：我觉得任何时候都要考虑建设内部工具，然后根据投入产出比较决定应该用什么样的工具和怎样实现工具来做到效率最大化。比如在公司刚成立的时候，应该会更可能去选择现有的开源工具或者购买工具；在公司成长过程中，如果出现现有工具有缺陷，就会要考虑提高已有开源工具或者自行开发新工具。总之任何时候都应该考虑使用工具来提高公司的效率。

至于应该使用集成开源项目还是选择内部开发，我觉得是依情况而定。选择的原则是尽量提高效率（产出减去投入），考虑短期效率的同时适当地考虑长期受益。

InfoQ：您从Facebook离职后应该会面临很多选择，为什么最后选择去创业公司Stand Technologies？能否分享分别在大公司与创业公司的体会与感受？如何看待职位的转变？

葛俊：我离开Facebook加入Stand Technologies有两个原因：一是我对Stand的方向很感兴趣。我出生成长在云南，那里有很多贫困山村，人们生活很贫困。我时常在网上看到一些相关报道，比如曾经有一个报道一个村子留守儿童上课的事，他们一起吃饭只用一个盆装一些白菜，也不知道能不能吃饱，非常可怜。如果在国内发达地区的人们能给他们一些资助，对发达地区人们来说很少量的钱就可以对这些小孩带来很大的帮助。Stand Technologies当时计划就与这样的公益事业相关。

第二个原因是我当时已经在大公司工作了超过十年（Microsoft + Facebook），我希望去一个非常小的创业公司从头做一些事并且全盘负责。我加入Stand的时候公司只有两个开发人员，作为技术总监我全面负责公司全部三个项目的技术，既做了更多的事也提高了自己。

在Facebook这样大公司的好处是技术、企业文化比较成熟，公司生存压力较小，有很多强大的决策、技术、产品人员，可以学到很多的东西，这些让我受益匪浅；在Stand这样小公司的好处是我可以更多地从头到尾设计产品构架和协调开发人员去实现，还可以从头建立工程师文化和公司文化，另外可以学到创业公司的开发以外很多的东西，比如运营、市场、产品设计等等。