QingCloud核心技术揭秘：自动化运维与机器学习

摘要：作为全球架构师峰会坐看云起时专题出品人，创始人接受了记者的采访，就标志性的招牌技术自动化运维与机器学习进行了阐释。请介绍一下你们的机器人，它们是做在哪一层的，它们身上的职责有哪些黄允松非常乐于谈这样的话题。

作为全球架构师峰会“坐看云起时”专题出品人，QingCloud创始人&CEO Richard Huang接受了InfoQ记者的采访，就QingCloud标志性的招牌技术“自动化运维与机器学习”进行了阐释。大波技术干货来袭。

以下是采访实录。

大家好，我是InfoQ的主持人，现在我在全球架构师峰会ArchSummit的现场。今天很高兴能邀请到青云的联合创始人兼CEO黄允松来接受我们的采访。今天我们聊聊你们在做的机器人的事情。请介绍一下你们的机器人，它们是做在哪一层的，它们身上的职责有哪些？

黄允松：非常乐于谈这样的话题。我在很多场合都讲过，做Cloud Computing真正最后落脚点在于去Replace人，而不是说仅仅是为了将物理资源虚拟化。恰恰相反，我认为云计算跟虚拟化实际上是不划等号的，你完全可以使用物理的机器去做一套云的System，这是没有问题的，只要你做得足够的好，那都是一样的。

所以我们在机器人层面做得最多的事情，基本上计算存储、网络、安全，每个层面都涵盖到。现在这个阶段cover最多的还是计算、存储和网络三块，因为安全相对偏简单——安全是L2、L3跟L4，而我们目前的L4还没上线，也就说只有L2跟L3，所以它会比较简单，因为它就是一些规则，所以复杂度并不高。 我可以举几个例子。比如说计算层面，有好多很重要的事情，而第一步要做的事情是什么？我们称它为resource placement policy，资源安置策略。简单来讲，比如说有一个用户发一个指令，他要一百台虚拟的Server，这就是典型的偏计算的活——Server一般是CPU跟Memory组成的，当然磁盘也有，但不是特别重要。那这个时候，你要做的最多的事情就是去判断它应该安置在哪里。

最简单的安置策略是什么呢？均匀化的法则。这是一点问题都没有的，不外乎就是我旗下有一千台物理服务器，下面就看谁身上的资源比较空闲，我就往谁身上放就好，这是非常非常简单，也非常有效率的。我相信基本我们能找到的大部分的系统都是这么安放的。

但这个里面其实是有问题的。问题在哪呢？就是物理设备身上已经在运行的资源，它不一定是在做决策的那个时刻正在吃资源，所以有可能会发生的情况就是，你根据Workload所做出的Placement的决策导致了一些机器压力会比较大。当然如果说有钱人，这个事情是不怕的，他们在平均在每一个物理机上只跑八个VM，他们的Placement的策略是极其简单的，就是均匀化分布法则，没有其他的，基本上不太考虑未来很可能产生的大的起伏。

这种做法有没有问题呢？其实没有问题，为什么？因为它的冗余度非常高，资源的实际的占用率偏低，所以他就不用担心突然之间，比如说什么量上来了之后，会产生一些坏的影响。

但是这种做法的话，在过去是没问题的，现在问题非常大：这会使服务商根本活不去。因为硬件的成本实际上不是一个小钱。因为这毕竟是一场生意，因为这不是一个totally for free的东西，就像你去打开一个网站看新闻一样。所以如果一个云计算的一个服务商，它完全看不到有利润的未来的话，这个服务商的服务是不可持续的，这是最大的不安全和不稳定和不可靠性。因为服务商如果关门，实际上这会使的消费者的系统会非常的艰难，因为你要迁移，要搬家，非常艰难。所以我自己觉得，在每个物理机身上，可能密度要增大，比如说增大到20个或者30个，取决于你的硬件的配置。高配的时候，可能密度会更高，低配的时候，密度要降低，但总之来说，我们密度应该适当的要有一点增长。

在这种模式下，实际上你最需要做的事情就是如何去判断。判断的因素非常多，比如说当前的workload运行状态。另外一个，历史状态。这个是很有意思的，所有的计算机在运行过程中，不管是物理的还是虚拟的设备，他们在运行过程中，实际上是有大量的历史的数据的，每时每刻每分每秒的数据我们都应该把它记录下来，予以分析。这样我才能够非常清晰的知道，每一个设备，不管是物理的还是虚拟的，它的曲线图是怎样的，这个是我们要抓住在手上的第二个历史的因素。第三个因素在于credit，信任值，就像我们人，每个人在银行，我相信每个人在银行基本上都会多多少少有一些credit，银行根据每个人在银行的历史记录，他会有一些对这个人有些判断。

说个小题外话就是，互联网金融为什么它有魅力？有魅力的地方在于它通过技术手段获得了很多数据，于是他就对消费者，或者是小商家能够迅速的做出判断，我觉得你可不可信任。这是非常大的一个买卖，而这个买卖不仅仅适用于我们有血有肉的人类，它同样适用于那些冷冰冰的机器的世界，这是我们要考虑的第三个点，就是所谓的device credit。因为实际上，并不是每台设备都非常靠谱的。长期跟硬件打交道的人应该非常清楚，硬件有两个时间点是最容易出问题的。第一个时间点是刚上线的时候，比如说像我们上线一个项目，一般的设备规模差不多在一百台到两百台的规模，规模不是很大，而我们平均一般比如说一到两个月会上线一套设备，保持这样的一个频率。你上线一票设备，假设是一百台或两百台，这里面不可能是百分之百都OK的，它一定会有那么几台有问题。比如我最近刚刚在北京的亦庄，我们上线了一大票设备，然后坏了，上线以后，开箱即损，几台呢？四台都是坏的，每个坏的这个表现还不一样，但是它是坏的，这就是现实。另外一个会有故障的时间，一般是在三年左右开始出现，尤其是硬盘。运行期间相对来说比较安定，但是也不一定，比如CPU都可能会出错，尤其是高压力的情况之下。我们在鲁谷中心，就是西五环的一号区里边，我们已经三台设备的CPU出过问题，所以你会看得到，在运行过程中，实际上每一台设备，就跟我们人一样，它实际上是有不同的表现的，这个就是我们要抓住的第三个值。其实还是对历史的分析，但是这种分析，它就相对来说要要求要比较实时的能体现这些东西。

所有这些数据我们拿到之后，我们首先要做的事情是怎么存放它，接下来的事情是怎么分析它。把这两步做好之后，于是我们就可以大致得出一个对这个系统的一个判断，这个是非常关键的。对于计算这一头，就是所谓的resource placement policy的这个判断是极其重要的，这是第一步。第二步，里面有个非常关键的，就是当资源已经up and running，它已经被分配出去，它可不可能出问题？太可能了，在我们QingCloud里面，用户如果有资源正在跑的，然后他比如说跑在A location，它真的是永远跑在A location吗？NO，不是这样子的，因为硬件，还有各种网络的格局，随时可能会有改变，我们一定要有技术的手段，让这些可能出现的risk，或者disaster，它可以被预测，就是所谓的prediction。这就跟我们看那个中央电视台的这个天气预报是一个概念。预测非常关键，而且一定要求它是越来越精确。我相信各位，大家看天气预报的时候肯定会有两种心态，昨天说今天下暴雨了，今天没下，那个鬼天气预报太差劲了，这是一种表现，因为它没有预报准。还有一种说昨天说今天要36度高温，果然这么热，好热好热，就觉得那个天气预报好准，对不对。实际上预测这件事情对于IT这个行业来说，对于IT 运维这个行业来说非常重要，你怎么去形容它都不会过分。

预测是一个极其艰难的过程，而且它这个分析跟我前面讲的那一步的分析还有点区别。前面我讲那一步，实际上大部分的分析是静态分析，就是所谓的static，这种静态分析讲求的地方在于追溯你的历史，然后我对你做一个未来的行为的一个大概的预判。但Prediction不同，Prediction权重更高的是Real-time Data Stream，Data Stream是非常关键的，那这个地方就是所谓的我们要引入一种超级快速的，而且那个overhead要偏低的这种实时的数据分析技术，所以你会看到在这个层面上来说的话，我们要把这些事情做好，实际上要花大力气，这也是我们目前正在重点做的事情。我们目前的Prediction准确率还不是特别理想，所以最近这几个月我们花了很大的力气在增强RD的力量这个上面，我们也增了很多兄弟在这个上面做。

另外还有一件事情，就是你看前面讲的都是为了防止你出问题，但是肯定不会百分之百的能防得住，一定会有些时候会出问题的，下面的一件事情是出了问题怎么办？How to action，怎么样去针对那些已经正在发生，或者是已经刚刚发生，Just moment ago，发生的那个灾难，怎么去把这个事情做好。这个事情更多的实际上是叫动作的触发，很多的trigger。这些trigger在我们早期的版本，就是在2012年和2013年的时候，尤其是2012年做的版本，我们的基本上的逻辑非常简单，实际上就是把我脑袋里面那些逻辑写成Code，然后再配上一些触发的条件，最后它就会形成一种可重复使用的操作规则，或者是操作指南。发生这样的情况，你要Take这样的Action，非常简单的一个逻辑。但实际上我们规模，因为现在QingCloud规模相当大了，我们服务的客户群极宽，而且现在有很多美国客人也是在，直接在用我们在中国的部署，所以我们显然这个压力上来之后，灾难的概率也会变高，这个是很好理解的，因为你基数变得很大了。

这个时候就会看到，就是原来这种单纯的就是以我已有的知识结构所形成的这样的一些trigger的库，那么实际上是不足够的，所以这个里面要加入什么东西了？new action creation的过程。我们要能够授权我们的robots system，能够去在具备一些条件的情况之下，去自适应和创建一些新的规则集。这是我们正在做的这个，就是在这个机器学习范畴之内的第三件事情，就是非常关键的。

这三件事情基本上都是跟——第一件事情可能跟计算的关系会比较重，后面两件是比较带有通用性的——计算和存储最相关的。其实计算跟存储之间是比较紧的，因为一般说来我们讲一台设备，CPU、Memory跟Disk它是少不了的，我想基本上我讲的这三件事情，基本上能够涵盖他们这个双方。

网络就不太一样了，网络会稍微特殊一点点。前段时间大家有个很大的争论，我觉得很有意思，就是大家在微博上跟林源有一些探讨，行业里面很多兄弟都加入了，比如像盛科的苏总，张总，在讨论到底什么叫SDN。我觉得这个事情就好像大家在讨论以前一句老话，叫一千个人心中会有多少个哈姆雷特的那个意思。我倒不是说就有一千种SDN，但是SDN这个东西实际上就看你从哪个角度去看，你可以叫它SDN，也可以不叫它SDN，无所谓，就好像我经常讲，就是虚拟化这个东西跟云到底什么关系，我要说的绝情绝意一点，我就可以明确的讲它们没关系，就比如说IBM收购了Softlayer，它到底是不是云计算？没错，它是一个物理资源出租的业务，但是你不能说它不是Cloud的模式，因为它的这个业务模式，还有用户的体验，它都是Cloud那个范，只不过它偏物理设备的Delivery。那你不能说它采用的是物理资源，所以你说它就不是Cloud business，我觉得这是不对的。

同样道理，我们讲网络层面也是这样的，实际上现在我觉得我们更应该强调的事情是说IT这个工具，或者说IT的思维，对于通讯行业、传统的电信行业它的影响是有多大。我们使整个网络可编程化，就是可以被Program，然后使得转发和控制能够得以合理的分离，使得一旦网络出现问题，或者网络出现抖动之后，我们能够快速的Recover。像这些东西，实际上我觉得它就可以称之为SDN这个范了。而你不应该去强调说，我一定要基于某一种协议，之后它才能叫做SDN，或者说我一定要基于某一种特定的规范之后，它才能叫SDN，我觉得我这个是需要稍微声明一下的。当然这个每个人看法可能不太一样，但我觉得这无外乎就是一个广义和狭义的话题。

那回到QingCloud我们在网络层面上的一些实践，我觉得首先要做的事情就是什么呢？就是很多人，反正我个人是这个看法，我记得盛科的张总他们对此也是高度一致的看法，就是转发和控制必须分离。你如果不分离，我们对于盒子有很明确的依赖。而你看看，我相信你们做Cloud相关的这些各种报道，还有研究，我相信你们现在应该有很深的体验。就是我们做Cloud跟传统IT有一个很大的区别，就在于我们不可以把我们的系统的可靠性依赖于某一些特定的硬件。我们在传统的运维概念里面对于硬件的可靠度要求是很明确的，这就是IBM公司能成功的非常核心的原因。为什么IBM能成功？你只有买了IBM的东西，你的系统才能不坏，所以你的core banking，核心银行业务，大家就买IBM的mainframe或者是小型机之类的，对不对。因为只有IBM能够有这个能耐保证你的东西不坏。但是实际上我们看现在这个时候，首先一个IBM这种做法有一点点过时了，对于尤其是新业务，所以我们做Cloud实际上有没有发现，我们实际上苦心孤意在做的事情是，让我们各种各样的应用，不管是互联网应用，Web的、游戏的、Mobile的，或者是偏传统的业务，各种比如说什么办公系统、ERP、CRM，甚至包括电子邮件系统，那么这些东西的话，我们用云的方式Run的时候，我们实际上心里面有个预期，就是你这东西它能不能不坏。但什么叫能不能不坏呢？实际上设备一定会坏，设备只要一上架一定会坏。消费者心里面的潜在的预期是什么呢？如果设备坏的话，我的系统能不能不坏？

实际上这个地方落到根本上，说的就是我们的系统在运行过程中，它不应该对某一些特定的设备有期待。简单来讲，就是任何的失败，任何的一个exception、error、failure还有disaster，它都应该是什么呢？In planing，都是在计划中的，这样才对。所以这件事情，我们在计算和存储的身上，我们已经表现的非常明显，你看看七牛的兄弟们做存储，毫无疑问，他一定要做冗余。当然也可以通过新的技术，比如纠删码这种方式能够提高容量的复用率。但是无论你怎么做，最终你肯定还是有一些冗余的成分在里边的。我们将文件碎片化、打散分散存放，也都是为了这个目的，就是简单来讲，我不依赖于你这张硬盘，我也不依赖于你这一个服务器，我也不依赖于你这一堆服务器。网络也是一样的，为什么转发和控制、分离那么重要？原因就在这，我们一定要让设备仅仅充当简单的角色，让它可以快速被取代，这是非常关键的。所以控制这个过程是极其重要的。SDN的语境范围里面，大家把这个东西称之为controller，控制器，这个真是简单明了。但是因为我们QingCloud System里面，因为我们整个系统都是一个称之为一个robots community，所以在我们的开发里面没有用controller这个单词，我们用的是一个Bot这样的一个单词，其实概念是一样的。

我们的做法其实非常的简单，我们主要是把它任务分成两步，第一步就是二层的功能，另外一步就是三层的功能。二层的功能偏简单，实际二层的功能基本上就是几件事情，就是组网及网络隔离，就是干这两件事情。网络隔离就是所谓的私有网络，就是VPC的范畴的一个东西。组网呢，就是有两种组网，你自己的局域网的组网，以及局域网和局域网之间的组网。然后三层的功能是最复杂的，三层功能涵盖了很多。最简单的一个就是说，我怎么样确保外部的流量能够到达那一步，就是所谓的EIP的功能，elastic IP address，这个地方涉及到的实际上是一个转换的过程。这个转换的过程大伙都知道，这个东西就是做流量转发。做流量转发有好多种技术，传统的技术NAT，新的技术，就看你用什么协议了，那每一个东西都是有自己的做法的。我们两者都有。

为什么两者都有？这是我经常讲的，我们做事情千万不可极端，就是在这个事情上没有某一个技术，它是绝对的好，也没有一个技术是绝对的差的，我们一定要将技术混合起来用，以确保你的系统是最优化的，这个是非常非常重要的。我经常在外边，你也知道我这个人特别喜欢跟人讲技术，我经常在外面讲的时候说，大家的视野千万不要被某一种概念牵着走了。我记得前段时间，我忘了是一个什么会议，就前两个月，他们请我过去讲一个小话题，叫“云计算中的那些坑”，其中我就讲了大概好几个坑，其中有一个我自己都觉得蛮重要的，我把它放到前面讲的。就是说，概念重不重要？非常重要，像你们做媒体也是这样的，要推进新的概念，然后去promote这些东西在市场上，这个很重要。但是我们是做实施的工程师，我们做工程师的人一定要记住，我们要学习这些新的理念跟概念，但一定要辩证的去看，要权衡它。所以在SDN这里边，比如EIP，我们两者皆有的原因是在于，对于Rack内的通讯，显然传统的方式更加有效。而对于跨长线路，长距离的通讯，显然新的、类似于OpenFlow这样子的做法更加有效。这个大家可以通过测试，通过长期的观察，就能够很明确的表明这一点。你在Rack内，TOR（Top of Rack），用这种东西的话，你用新的模式做实际上得不偿失，所以这两者我们都需要去做它。我们做这个network bot，就是controller，这两方的东西都要关照，那么这是一个。

另外一件事情再比如说，我们提供的三层路由器，路由器里面所涵盖的一些功能，我举个简单例子，因为混合云显然是一个，不说多的，我觉得10年、20年的时间应该是主流，那么企业用户，因为我们主要服务于企业用户，尤其是现在越来越高的比例是带有一些传统属性的企业用户，当他们开始拥抱这种新IT模式，Cloud Based IT的时候，他们实际上对于自己既有的legacy有很高的期待，就是你的新系统，你可以用一种云的方式，你的新系统应该跟我的老系统能够无缝的怎样怎样。那这个地方实际上就存在一个问题，就是我们在云端所交付出来的virtual router，那个东西能不能够无缝的去兼容、支持所有市面上现在这些传统的设备，供应商的设备，不管是华为，华三，还是瑞杰，Cisco，Juniper，无所谓是谁的，能不能做得到，这个地方是非常重要的一件事情。这就是为什么我们做出来的三层路由器实际上看上去非常传统，比如说我们支持的隧道协议就是GRE，为什么是GRE，大家都知道，因为它最老牌，最权威。再比如说，当然我们也会支持新的规范，比如说类似于像VxLan这种，能够帮助用户去走这种新的协议，当然我们也会做。再比如说像DHCP地址的分发，那么这些东西，其实都是，我们就原原本本的，就照着传统的路由器，它三层设备具有这样的能力，我们去做它。
所有这些东西我们在做的时候一定要把这个就是转发能力，放在哪呢？放在盒子身上，而且控制能力放在一个virtual的设备里面，说白了就是一个虚拟的控制器，就是一个虚拟的Linux或者是一个Process。这个里面内嵌的一些规则，我们可以是去跑一个虚拟机来做，我们也可以是去跑一个Container来做，这都是很容易做得到的。那么两者，我们目前都有，针对不同的型号来做到它。

所以说你会看到以前，你会看到，就是我们以前，我们讲hypervisor，那么QingCloud显然是百分之百，fully KVM based。但现在显然不是这样子的，为什么？因为我们还是有一部分Container相关的东西在里面的，为什么会有这样的变化呢？还是那句话，一定要寻求变化，就是有些东西，它可以百分之百用在这样的一个层面上。但是另外一些层面，他可能就不一定适用，那这是在网络层面的控制，网络层面的机器的做法。

网络层面，我们目前有一个很大的缺失，就是所谓的L2 learning的过程。因为我们现在走的设备是偏传统的方式，那么在Rack内如果发现了设备的故障的时候，它差不多有一到两分钟的L2 learning的时间，这会使大家非常的沮丧，为什么？因为实际上一两分钟的时间还是有点长的，虽然它是一个自动发生的过程，因为也是一个设备的一个特性，但实际上有点长，我们目前正在想办法解决这个问题。
解决的方案非常简单，我们会做自己的硬件。这边我可以给你透露一下，我们自己设计的硬件已经设计完了，并且发给了广东的一家工厂，我星期天就会去广州，跟他们谈很多细节。为什么要做这种设备？实际上这个，在我们这个行业里面有个专门的词叫融合型设备，融合型设备就是说这个设备它既不是服务器，也不是存储柜，也不是网络交换机，而是一个合成体。当然这个东西，你说是不是就是原来的刀片机的刀箱？NO，不是那个样子的，它不是一个刀片机的概念的东西，他是一个全新的一个OCP Based的设计。在这个里面，你会看到很清晰的一个东西，就是说我们要想在传统的路径上面去做，但是同时呢又要解决一些传统的路径所遗留下来的问题，我们必须要去改变一点点。

通过这种方式，我们可以使的转发这样子的能力会变得更加的，即便是设备出问题的时候，他也不会波击太多，就是包括那种比较短暂的学习周期。其实所谓的学习，就是refresh的过程，然后也会变得更加的短。甚至是说，虽然内部还是在做这样的refresh，但是用户感受不到。然后从controller角度来说，我们目前走的路径是全虚拟化，全虚拟化的好处就是第一个是，这个就是Scale可以非常的大。因为从调度的角度来说，有些时候出问题是很正常的，这是网络层面上。另外一个，我觉得还有一个很重要，就是整体来看，我们越来越多的看到一个东西，就是所谓的，就是这个，因为我们现在不是因为全局化做得比较多，像哈尔滨、北京一、北京二，然后广东，就是我们现在分区分类比较多，上海很快就会有上线，香港就是下个月，8月份，今年已经在香港那边的前站工作都已经做完了，美国是11月末。所以都很快，就会变得很大。这个地方我们就是面临一个很大的问题，就是全局调度的问题。全局调度，尤其是跨越这种超级长的广域网线路，实际上我们面临很大的压力，这个确实是一个实际的情况。分区部署是一个解决方案。但是分区部署之后，会使的我们的成本变高，然后资源复用率变低，所以我们目前在这一方面，就是说广域网的环形网络建设及调度，这一方面我们在花很大的力气在做这方面的事情，这个它就涉及到更进一步的所谓SDN的话题。

那么这边，我觉得有一件事情，大家至少能够非常确认的，这边我们是totally OpenFlow based。我们目前在看的比较多，就是纯OpenFlow的跨广域网的这个Traffic调度过程，包括我们现在IP地址也是自己购买的IP地址。为什么要这么做？就是因为要做到这个跨广域网的assignment。当然IP比较特殊，它是有国家特性的，一般给中国大陆用的IP就只能在中国境内用，但至少我们能够做到北京跟广东之间的IP可以飘动，是这样子的，所以你会看在整个的这个其实归根结底，我们今天谈的这个主题，归根结底就是怎么样去做Operation。Operation这件事情呢，我认为是从IT本身来说是最主要的工作，这是最最重要的工作。但是Operation这件事情，正是因为它的重要性，所以我们应该让它消失。我说这句话，它是不矛盾的，就是我们要让它消失，消失的原因就是因为它太重要了。因为它太重要，所以这个活不能交给人去手动的去做，当然我知道这个过程非常的漫长。我们在青云里面，也没有说做到百分之百的没有人工的干涉和参与，但是我们至少说已经做到90%以上的工作没有人工的参与和干涉了，就绝大部分都不会有。所以我们在我们的范畴，我们是没有值班的概念的，我们就是设备损坏也是一个正常的逻辑，我们在哪一个数据中心，都不是百分之百的设备在线上跑，因为总会有坏的设备的。所以从这个角度来说，我们其实最终的，用一个词来讲，我们虽然我经常讲P2P的robots community management system，但实际上，其实说白了，其实说的简单一点，实际上是一个什么东西呢？是一个自动化运维的过程。

我总结一下，就是我们要大规模引入的东西，实际上就是什么呢？就是所谓的机器学习的过程，就是海量的数据的捕获和处理，以及相应的计算机的自我学习和规则集的更新的过程，这是一个非常长期的行为，我相信各位都对搜索引擎这个东西是毫不陌生的，搜索引擎就是非常典范的这样的一个东西，我们就以百度为例。百度它从网页上去爬别人的数据，然后放到自己的索引库里，这是最传统的做法。接下来他做百度知道，百度是人肉的一个过程，是一个“有人有问题，然后有人去回答问题”，百度在做一个Match的一个过程，是一个人肉的过程，然后半自动化，然后你会看。所有这些我们人，对于知识的掌握过程中的努力，实际上就是一个所谓machine learning的过程，就是让机器不断的掌握一些我们的规则，实际上我们现在要做得事情，我们对于Cloud Computing，对于IT这个行业来说，我觉得我们要掌握的事情就是什么呢？就是我们要把这些，我们过去用在人身上，为人提供服务的机器学习的东西我们要下沉，下沉到为谁提供服务呢？为设备提供服务，就是这样子的，这件事情我觉得并不是更加的艰难，而是更加简单，只是大伙可能不一定认为这个东西有那么重要而已。为什么？因为看起来说做运维，招一帮兄弟去做其实也蛮OK的。对，是蛮OK的，这个事情可以做，但实际上Long Term来看是不行的。如果大伙自己的这个运维的设备规模越来越大，就是像我们这样子增长非常迅猛，我们的增长速度是极快的，就是你招人都来不及。这个时候你会发现，你唯一的救世主就是machine learning，非常精确，非常高效，所以我觉得这个，我想应该就是非常非常关键。对于每一个从事Cloud行业的兄弟们来说，大伙都要往这个方向努力。

当然我们有没有一天，我们能够把自己的系统称之为人工智能，这取决于我们的能力了，当然现在这个阶段最多也就叫个机器智能，我希望有一天，不管是我，或者其他的这个团队，不管是谁，不管Amazon、Google，我希望有人能够真正做出一套百分之百、完全人工智能化的、不需要人类参与的纯机器的世界。当然我希望那个能够做出来这个东西的人是我。当然我觉得，我也毫不怀疑会有别的Team，别的团队也会在这个方向上做出非常卓越的努力。

我还有一个问题，就说你们现在这个Robots，它的更新是一个什么频率，包括，万一你们怎么去防止机械人的更新出现逻辑错误，万一出现错误怎么处理？

黄允松：很好的问题。我们目前的话，刷新的频率是两周一次的迭代，就是我们的Code Base是两周一次迭代，而且这个刷新的过程也是自动的，我们会有一整套的这个DevOps的过程，就是非常典型的，然后十万次无错测试。完成之后，自动的打包，Push到这个线上，它是个自动的过程。

怎么防止错误，这是非常关键的，这就是为什么我们目前没有百分之百自动化的一个非常核心的原因，就是我们核心系统，就是Global Service，就是Core System的话，我们现在每次做更新的东西都是靠人工做。但是Core的东西它更新不是特别的频繁，一般是一些细枝末节的东西；另外一个，还是没有办法百分之百防止出错，这就是要回到我们前面讲的那个，我们这个谈话最前面我讲到的就是，出了错之后，怎么样去Take Action。这个是非常关键的。实际上这里面其实就是一件事情，就是我把我们QingCloud做的这套系统，我称之为叫这个firmware，叫固件，叫Cloud firmware，就是有点像刷系统一样那个系统。我对于我们这套固件的要求就是什么呢？这套系统它可以被Stop，也可以被pause，也可以被refresh掉。但是在这个时候，在做这些事情的时候，上层的这个用户系统是必须是要在up and running，并且不受影响的。你可以理解成我做了一个Sand box，一个沙盒一样概念的东西，它可以保证说我下面的东西如果出了错的话，上层的业务系统，就是用户系统，它是还是在Up and running的，它是完全隔开的两个东西，这一点也是为什么我要设计自己的硬件的核心原因。

在我设计的硬件里面，CPU不是只有一种CPU，在我的系统里有三种CPU，非常复杂，就是有三种完全不同架构的CPU，这是非常非常有意思的一个东西。为什么这么做？实际上我要把我的Cloud firmware，因为我认为，我们做的QingCloud这个东西是一个operating system，它就是一个操作系统，只不过它是一个分布式的操作系统，分散在很多设备上。所以我对于它这个东西的定义，对于操作系统这个东西的定义，就是QingCloud这样一个分布式操作系统，它一定在它内部结构发生变化的时候，一定要不能影响上层的建筑，就是客户的那些workload，application system，那些东西不能被影响到，所以这一点是非常关键的。而好消息是，这个东西我们在13年，这个对外开放服务的时候，我们的系统就是这么来Run的。

所以简单来讲，你这个问题的答案就是我们就是三个步骤，三件事情去解决它，第一个就是Global，就全局分散的core service，我们现在在做refresh、upgrade的时候，我们一般是靠手动的方式在控制，还没有百分之百的自动化；第二个就是说我们的系统在设计的时候一定要确保，我们QingCloud这一层，这个Cloud firmware这一层，固件这一层，跟上层系统之间没有任何关系，完全隔离，纯沙盒模式。最后一个就是说我们这个出了错之后，要快速的Rebalance，那么这个是非常关键的一个救急法宝。

InfoQ:十分感谢黄允松接受我们的采访。

原文链接： https://community.qingcloud.com/topic/11