七牛韩拓谈公有云：扩容，持续集成与拥抱故障

个人简介 韩拓，现任七牛云存储首席技术官（CTO），全面负责领导七牛云存储平台架构，功能研发和产品运维。韩拓是一个热爱生活，自封吃货的程序猿，酷爱运动尤其擅长踢球，喜欢阅读尤其喜欢科幻类小说。其毕业于中国地质大学，物理学学士。先后在金山、童话网络等国内知名的IT企业从事研究，架构等技术负责人工作。有接近10年的IT行业开发经验，对服务器端技术尤其是分布式存储技术有非常深入的了解，曾经作为核心架构师，成功的主导和上线了多个以存储为主题的互联网产品。

作为InfoQ主办的全球顶级盛会，QCon在伦敦、北京、东京、纽约、圣保罗、 杭州、旧金山举办过多次，这次是首次走进中国首都北京。希望能给当 地的公司、技术社区和技术人员提供一流的学习、交流平台。

   

1. 韩拓你好，感谢你接受我们采访！您先自我介绍一下吧。

韩拓：我是来自上海七牛的韩拓，上海七牛主要是提供云存储的服务，主要是面向企业和一些中小开发者，提供类似于S3的存储服务，并且在这个基础上提供一些上传和下载的加速的功能，还有一些富媒体数据的处理。

   

2. 以下有几个问题我问一下。首先是作为公有的S3的服务，增长肯定是非常快的，像一个互联网服务一样，而且我们这种服务对扩容的需求肯定是司空见惯的，七牛对扩容的处理有什么心得吗？

韩拓：这个问题是从两方面来说，首先从我们软件的层面，就肯定是要去做处理，就是在我们的这个从基础架构上来讲，要做到，就做扩容时候很容易，包括运维的支撑的系统，像部署系统、监控系统这些东西，首先要把它做得很完善。也就是说从软件层面，要做到扩容的边界成本要很低。另外一方面就是从硬件上来讲，可能是跟软件是不太一样。因为硬件的采购是需要一个周期的，包括买服务器，去做IDC的选址这些东西。我们的原则大概是预留一个月的余量，我们会预估一个月以后使用量是多大，然后去采购。当然我们现在也处于一个快速发展的时期，所以很多时候，我们会打破这个一个月，可能就是以周为单位去买服务器。

   

3. 其实七牛行动还是很快的，作为新兴的互联网企业，行动力是很强的，我们从发起扩容的需求到完成一般需要以天为单位，几天能完成这个动作？

韩拓：如果是说要快的话，我们最快的一次大概是，并不是用按天算的，是按小时算的。我们有一个真实的案例，我们有一个客户，他们在教育网的用户很多，就普遍反映教育网慢，那我们就需要去扩，在教育网去扩了一个机房，带宽大概有大几百兆这样子。我们当时大概是七个小时就OK了。当然这算是比较加急去处理的，常规的大概就是一周。

   

4. 扩容是这边做得非常好的一个事情。之前听到说，你们有讲体系集成，应该和持续集成有关系？

韩拓：是有关系的，对。

   

5. 我想知道，七牛对于持续集成肯定是有一定经验的，持续流程它的整个流程是比较长的，如果要把它做大，从我们工程师commit代码，到单元测试的处理，到最后打包，到重新构建测试，到最后发布，一大串的流程。有很多企业是一个流程是一个判断，从头走到尾就完了，是说构建完成，然后以这个发布为单位再去发布一次。那也有企业是，比如说我们工程师从成立到打包是一个阶段，然后从包到测试是一个阶段，从测试到发布，然后人工去处理这个过程。七牛是什么样的形式呢？

韩拓：我先介绍一下我们持续集成的几个关键的环节。首先就是，工程师写Code，然后配套的单元测试都做好，代码就commit到它的功能的分支上，然后由代码的审核人员去做好几个轮的Code Review，通过之后，就会把这个代码给合到我们的发布分支上。当然被合到发布分支上，也不光是只有这个功能的这个Code，它还包括对运维支撑系统的一些变更，也会在里面包括，比如我新上了一个服务，针对这个服务的监控的脚本和代码就要上。然后就是针对这个服务的集成测试的案例也要上。甚至说这个服务去部署的时候，部署的描述，这也是同时是在开发的。那我们认为刚才说的这几个组成，就构成了一个持续集成的一个最小的单元。这个单元被合到我们的发布分支上以后，由我们的系统自动的去构建，到这一步是自动的。构建之后，当然构建的时候要跑单元测试和集成测试的案例，都通过之后，就算是构建成功。然后构建成功会推到我们预发布的环境，去再运行那个集成测试的案例。到目前为止就全都是自动的，当然我们目前也是很保守，下一步往线上推的时候，是要人去点一下的。

   

6. 那我们知道这个流程，他需要的系统，软件是一个，大家都知道工具链这样的东西，那有的企业百度他提到Ruby中的一套组件，还有业界很多，比方说像Gerrit来管理，到最后的FaceBook这套系统，最后的发布系统也是。七牛用什么样的工具链？为什么选用这样的工具链，和团队和项目之间有什么样的契合？

韩拓：首先说一下在开发阶段。在开发阶段我们放的很开，不要求这个你是用什么操作系统，用IDE，这些是没限制的，所以你可以有人用VI，用emacs，这比较爽。包括我们公司有人用Mac，我们公司用Mac的人是最多的，然后Linux的、用Windows的也有，很杂。然后版本的管理是在Github上面的，就是去买的他那个最高的收费的档，可以支持创建几十个私有的库。所以我们的工程师基本上是分布式办公的，比如说你上午，你如果说睡过头了，你索性就在家里敲代码去提交，中午吃完饭再去公司，这样也是可以的，源代码管理是Github。我们的集成系统，编译这块是用Jenkins来做的，Jenkins我们认为是做得挺不错的，也基本上没有对它去改，就是用原生的。当然我们的makefile，这些编译的脚本，打包的脚本是我们来写的，就是由Jenkins去做触发的动作。触发的来源，比如某个分支的commit，或者有人去点按钮，这些东西都可以去触发这个编译的动作。还有很重要的是监控系统，我们是用的是Zabbix，用下来也是觉得挺不错的，因为它支持这种在大网络内的有properties的这种概念，它的性能也还OK。因为我们Zabbix的数据库用的是MySQL，我们现在监控点有三万多个，模板有一百来个，然后再乘以服务器数。剩下的系统就是部署系统了，我们是基于Puppet去做，但是对它进行了一些封装，也就是你在描述这个部署的时候。因为我们在贯彻DevOps的理念，就是任何人都可以去主张一次发布。所以我们认为，Puppet那个东西对于非专业的运维人员来讲太复杂了，所以我们对他进行了一些很简单的封装，你可以用我们的，我们那个格式也是在很大程度上是参考了Puppet，有花括号那些东西，但是很简单，我们去定义了那个类。所以这样的话，我们的开发人员、运维人员，包括是QA人员，他们都可以去写，他描述这个东西出来之后，再丢给我们的部署系统。部署系统把它给认为是编译也好，是转换也好，把它给变成Puppet能识别的那个配置，然后再由Puppet这个系统去推。工具链大概是这样的。

   

7. 正是因为得益于这套快速的随时构建的这样一个东西，所以我们才能做到快速的扩容，因为可以随时构建新的机群，并加入大集群工作。那我们的监控一般是分层的，比如说我有系统的监控，网络级监控，甚至说API级的监控，最后以客户为角度的监控。七牛是否有这样的监控分层等级，分层的力度是如何？

韩拓：我们的监控系统为分有几大块，首先我们的那个集成测试的案例，会挂到那个监控系统上去跑，其实这两套的案例是同一套。这一套案例我们在每个机房是有一个点去跑这个案例，这一套案例可以认为是黑盒的，比如说我新做了一个服务，针对我新的API，他正常的行为应该是什么样的。比如说一个我上传再下载，然后再转缩略图，它的行为什么样是OK的，这个东西要被一个代码给固化下来，所以我们也积累了很多这样的集成测试的案例。我们在每个机房会有一个点去把这些集成测试案例全挂上。外部我们是用监控宝，因为监控宝它监控的是一个HTTP，它就看你这个网页是不是OK的。但是它访问这个HTTP到我们那之后，会在后台把所有的集成测试案例都跑一遍。如果通过了就是两百，如果有一个没通过是五百，这个时候监控宝就会有报警。我们之所以选择监控宝，就是因为它的监控点比较多，更重要是因为它是一个第三方的，一个异构的一个监控点。比如说就我们这个机房之间，如果有问题的话，就可能查不出来。但是如果用它的就是OK的。这个是你认为是黑盒的那个监控。刚才提到有Zabbix，里面那三万多个监控点，这个认为是白盒的，三万多个里面有一部分是那个系统层面的，比如说是带宽，就磁盘的使用率、机器的负载和CPU的占用率等等这样的值，我们会把它监控起来，并且有对应的阀值去报警，这个所有公司都是一样的。其实一多半以上是和业务相关的，比如说我单个一个服务它缓存的命中率是多少，它最近十五分钟被访问的平均的速度是多少，它这个磁盘IO的IOPS是多少，这样的东西我们会监控起来。包括每个服务它的存在性我们也会去监控。因为你后面做到高可用的服务，他挂到一个之后，其实前面的那个黑盒子是看不到的，这个时候Zabbix那个三万多的监控点去做监控。你刚才提了一点就是非常好，对业务数据，我们也是很关注的。对业务数据这块我们也是分了几个层面，首先最外层的访问的HTTP的Code，比如说200，平均一秒钟是八千个，然后404是0.8个，500是1.2个，这个我们会监控起来，对每一个的指标会有报警，超过某个值有报警，这个是很有效的一个手段。另外在更高阶的这个业务数据上，我们也会做监控，这个中间有很多层面。到最高层面就是什么？就是钱，就比如说你上个月在我们这花了，就存了数据又有流量，你的费用是一万块钱，我们会平均到每五分钟，你花的钱比如说是15块钱。因为我们这个帐单是实时去算的。如果发现上五分钟突然你的钱少了或者多了，通常这也是代表出问题了。这个时候我们的原则是，先和客户一起去查问题。这个问题查到以后，咱们再商量一下，说是怎么样弄一下，然后再避免以后再发生这样的问题，大概就是这样。

   

8. 现在很流行拥抱故障啊，故障可以给我们带来进步。先清查问题，最后你排除故障之后再总结问题。那提到这个公有云的服务，其实他客户越多，你的量越大，你的社会责任就越强。因为我们的客户，有教育界的客户，有传统行业的客户，有互联网客户，有各种客户。比如我们某个公有云服务一旦有紧急状况，我们损失了千分之一的SLA，但是正好被中招的客户，可能就是他的全部。其实我们作为公有云服务，我们的压力是比较大的，那如何去在压力下来确保我们尽可能接近完美的SLA来给客户信心？

韩拓：其实你提到这个问题对我们来讲也是很困扰的，当客户的客户那出问题了，你要怎么去查，我们也是在很长一段时间内是很困扰的。因为你能拿到的信息其实非常少，我们就采取了一个措施，我们做了一个客户端的诊断小工具。客户端有本地的那个可执行版本，还有网页的版本。这个时候比如说我们客户的客户，他报告说这个图看不到了，或者说这个单词我听不到了，我们就会建议我们的客户说，你把这个链接给发过去，让你的客户去Run一下，再把这个结果给发回来，我们去排查。这个事实证明是很有效的。另外一个措施，当然这个是还没上，我们准备做一个Feedback的一个系统，也就是这个Feedback，比如说是网页的一个插件，会提供给我们的客户，他们在他们的站上就可以放。也就是说这个终端客户的这个Feedback，就可以很直接的回来，传到我们这来之后，就由我们去处理。可能这个客户就在家睡午觉，好像什么都没过发生一样，这个问题就OK了，这个也是比较少的事情。当然就是说这两种措施呢，也不能是百分之百的都覆盖到，也有一些很极端的情况，说怎么查也查不出来了，这个时候我们怎么呢？也挺有意思，就是我们会跟我们的客户去取得一个授权，就伪装成他的技术支持去加客户的QQ、加MSN去聊。甚至说就聊完之后，就我们的小的那个纪念品会给客户寄过去，去感谢一下。

   

9. 所以我们知道公有云的提供商，他往往面临这种问题，就是我们客户的客户，甚至客户的客户的客户，这样就多层信息沟通会比较困难，像你刚才提到的这样，我们的工作人员、运行人员、市场人员会伪装成我们客户的人员，那各种，特别像七牛这种Startup，成立时间也不长，而且人数肯定不如那些巨头那么庞大。而且最关键的是我们是，我们大部分的员工是技术牛，那怎么样去控制我们的团队，在做客户支持这块的这个时间占用率这个方面，七牛有什么样的心得？

韩拓：这个东西就不得不得承认确实是对工作是有干扰的，就包括一些很疑难的问题，我都可能会亲自去跟客户去交流。但是我们认为这个是必须要做的，就宁可说你的功能开发慢，甚至你去加班，这都是OK的。但是让我们的客户爽，这个是第一位的。
InfoQ：今天感谢你参加QCon北京2013的采访，我们经过这个采访也对七牛更加深入了解的更多，谢谢。