孙宇聪：服务器自动化是发展的必经之路

个人简介 孙宇聪，Coding CTO, 负责 Coding.net 平台的技术方案与架构。 曾任 Google SeniorSiteReliblity Engineer(2007-2014) 就职于Moutain View 总部， 曾参与设计维护Youtube视频转码/存储/直播管理系统(系统吞吐量超过1Peta bytes/月)， 参与研发管理全球 Youtube CDN 网络(峰值流量~10Tbps)， 后就职于Google 内部云计算部门开发维护全球百万台服务器生命周期管理系统及任务管理系统。

全球架构师峰会（International Architect Summit，下简称ArchSummit）是由InfoQ中文站主办的一次全球性架构师峰会。ArchSummit专门针对架构师人群，讲述与架构和架构师相关的各方面趋势、技术和案例。这也是继QCon之后，InfoQ中文站主办的又一次高端技术盛会。

   

1. 大家好，我现在在ArchSummit深圳2015大会现场，非常荣幸能够请到孙宇聪，Coding的CTO。宇聪以前在Google担任SRE，主要是负责全球的Hub System的一些流量，在Google的内部云计算部门追踪了一些百万级服务器的生命周期管理系统以及任务管理系统。针对于这方面内容，刚才您在演讲的时候是没有提到的，能不能在这里给大家讲一下？

孙宇聪：我觉得在数量级上去之后，最重要的是自动化。因为这个数量级已经不可能用人力去处理了。我们的两个团队加起来一共可能二十人，但是有百万级的服务器需要管理，所以所有东西都必须是自动化的。我们服务器的上线是自动化的，下线也是自动化的，连服务器的修理其实也都是一个自动化的流程。每一种服务器都会自动检测有什么问题，产生问题之后会自动生成一个流程图，告诉机房人员需要怎么操作，然后再重新把它接上。所有东西全都自动化也是比较有意思的，每天几千台机器故障，然后又恢复，这样往复循环。整个流程就相当于生命周期在全程管理。

   

2. 您从Google加入到Coding，相当于从一个大公司转入一个创业型公司，能谈谈您在这方面经历的一些转变吗？

孙宇聪：我觉得最大的转变就是以前在Google里觉得理所应当的事情在现在的公司发现原来是这么困难。包括研发工具，研发环境，人员管理，这些全都变成了需要从零开始。我对这个变化触动很深，引发了一些思考——以前在Google到底是什么东西能够保证它能持续不断地创新。小公司要想比大公司做的更好，它就必须在这些方面赶上大公司甚至做得更好，这才有可能与Google的这些团队竞争。

   

3. 根据您以前在Google SRE多方面的经验，创业型公司在工具上是否有更多的选择？

孙宇聪：对。与大公司相比，创业公司人力更少，所以需要更多的借力，也就是所谓的站在巨人的肩膀上，开源软件就是这样。以前在大公司可能会觉得，东西不好就自己再写一个，但是在小公司没有办法，大家都要用开源去实现。

在选择方面最重要的一点是一定要看清潮流，要想清楚自己要用什么。第一，你不要有特别奇葩的需求，这个需求一般是错误的。如果你发现你在做的这个事情没有别人在做，那其实是90%以上的几率都表明你的需求是有问题的。第二，你要积极参与社区，你不光要利用开源软件，你也要参与到它的开发环境部署上去，你一定要明白这个东西解决了什么实际问题，最终如何去应用并解决你的具体问题的。

   

4. 您一般会去哪些地方去寻找工具呢？

孙宇聪：一般所有的开源软件都是存在于Github上的，包括国内也是这样，这是一个不可避免的潮流，但因此我们Coding更专注私有项目，我们平时会积极参与架构师的交流会，去更多的了解大公司做的分享，我觉得听的时候最关键的是要把握住中心，就是他用什么东西解决了什么事情，因为他用的这个东西你可能没有，但在理解问题之后，我们可以找到开源的替代方案，或者是用几套方案来组合，或者对需求做一些改动，来更好地实现你的需求。这方面最关键的是要适应自己的团队，用工具来改善自己的团队，而不是颠覆自己的开发过程。

   

5. 你们在评估开源工具时，可能会涉及到一些商业机密，这种情况下你们会怎么去处理呢？

孙宇聪：最重要的一点还是就像我刚才说的，我们鼓励内部对工具的使用，但首先我们要鼓励大家进行knowledge sharing。比如做某个功能的时候会用到一些东西，但是这些东西很多时候其他人是不了解的，就没法利用。我们每两周在公司内部都会组织一个技术交流会议，由一到两个同事来讲他最近做的功能用到了什么新的技术，他如何能把这个技术应用到其他的方面上。以前在Google我们做不到，因为公司太大了。但这种持续不断的内部交流是非常重要的，它能够把新的想法带给其他人，让别人领悟到新的想法。

我们公司内部很多方案都是服务性的，某个项目在设计的时候不只是为特定功能去考虑，更需要考虑如何普遍的去适应公司内部近期或者未来的业务变化。举个比较有特点的例子，比如所谓的Redis或是cache，一开始可能是针对于某一个业务做的cache，我们把它通用化、集中化后让所有的程序都能接入进来。另一个比较好的例子是异常报告，虽然是很小一部分，但是个挺重要的事情，它可以很容易地让开发者与生长环境连接起来，能够知道错误出现在什么地方，为什么出现，出现了多少次。在针对一个项目做了异常收集的功能后我们就把它应用到了所有项目上，结果连一些万年不动的项目也能收到错误报告，让我觉得这是非常有用非常关键的事情。

我们鼓励所有员工从公司角度出发。他要想采用某个新技术，对公司来说肯定会有一个cost，他要说明这么做有什么benefit，如何把benefit和cost平衡起来，如果他考虑过在更多的项目上应用到这个技术，那就会很容易去解释。

   

6. 在引入工具方面，你们是如何去做的？

孙宇聪：引入过程我觉得更是个feasility过程。因为我们是技术公司，所以更需要大家把东西拿出来在技术层面上讨论。可能很多公司会觉得这个流程很麻烦，耽误时间，但是我觉得对小公司来说，小是个优点，大家开会变得很容易，可以很纯粹地讨论技术。我们一定要是一个向前的态度，应该拥抱变化，而不是拒绝变化。有了新变化公司才有新的活力，技术才能越做越好。

   

7. 能透露一下您们引入了多少个工具吗，有没有做这方面的统计？

孙宇聪：我们可能有百分之八九十都是开源代码，用爱因斯坦的话来说我们都是在历史的沙滩上捡贝壳的小女孩。我觉得所有创业公司的现状，就是站在巨人的肩膀上，我们不可能写出巨型的系统，也不应该写，更多的应该是在整合工具。

   

8. 我所了解的是，如果在引入特别多的工具的情况下，会有包括code rview，CI，部署，监控等等大量的环节。能和我们分享一下Coding在这方面是如何架构的吗？

孙宇聪：我们应该要鼓励员工的横向创新，在不同的业务之间，我们鼓励大家去了解每个业务是如何进行的，采用了什么技术，并且在内部我们会推行技术演进。我们提出了一个口号——Coding one。意思是将我们所有的Java程序用同一种方式启动，这里会有一个很大的问题。写过Java程序的都知道，比如meven-compat、spring boot，它们有好有劣，但是我觉得用同一个方式启动或者配置，我们是可以做到的。这基本上属于一个小规范，但是我希望这个规范不是外部引进的，而是内部经过实践后得出的最适合自己的规范。 有Coding one这个口号，大家就能在写新的项目的时候考虑将来的应用，如何去用一个统一的流程来做。这从长远看来能够降低内耗，降低系统的复杂度，认知的复杂度，这样才能把东西做得更好，使业务发展得更快。

   

9. Coding one的整个体系是什么样的，它具体也是由工具来实现的吗，底层用什么样的流程做辅助支撑？

孙宇聪：我们把开发人员从逻辑上划分了future team和infoshaker team两部分，它的意思是说我们要在业务建立的同时考虑技术架构的演进，包括CI的建立，工具编排等等。这些都是大家从工作中抽出20%的时间来一点点做研究，最后从实践中建立起来的。这演进不是很急迫，短期内它不会对业务造成阻碍，但是长远地看来它又确实是一个障碍，所以我们牺牲一小点业务方面的时间来持续不断地演进内部架构，我觉得这是我们的一个小创新吧。

   

10. 能够进行不同的编排，这好像是全栈工程师才能够具备的素质，是不是不符合你们公司最一开始提出的招人的标准？这应该算是比较大的变动了吧。

孙宇聪：我们希望所有的人都是全栈工程师，希望给所有的工程师创造一个机会，让他们能够去了解不同的技术，按他的能力来专注，按他的兴趣去了解。在说大公司里你只能做你职责内的工作，我认为这在小公司里面应该是要尽量避免的。