专访葛俊：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 环境上，是一个典型的分层网站应用：

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

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

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

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

1. 开源的挑战

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

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

1. 在计划和构建时都做 Capacity Planning，提前设计好数据存储的种类和使用方法，提前部署；
2. 分析数据读取的可行性。根据读写频率决定缓存层的使用，决定可以支持几层朋友关系的查询，决定是否需要加入新的缓存；
3. 做 Stress Test；
4. 逐步扩展产品发布的区域，确保 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 这样小公司的好处是我可以更多地从头到尾设计产品构架和协调开发人员去实现，还可以从头建立工程师文化和公司文化，另外可以学到创业公司的开发以外很多的东西，比如运营、市场、产品设计等等。

InfoQ：感谢葛俊老师接受我们的采访。期待您在 ArchSummit 全球架构师峰会上的分享。

感谢陈兴璐对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。