taoCMS是基于php+sqlite/mysql的国内最小(100Kb左右)的功能完善、开源免费的CMS管理系统

自动化运维与机器学习

2014-08-27

大家好,我是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,别的团队也会在这个方向上做出非常卓越的努力。
2.我还有一个问题,就说你们现在这个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:十分感谢黄允松接受我们的采访。


类别:技术文章 | 阅读:177214 | 评论:0 | 标签:

想收藏或者和大家分享这篇好文章→

“自动化运维与机器学习”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

公告

taoCMS发布taoCMS 3.0.2(最后更新21年03月15日),请大家速速升级,欢迎大家试用和提出您宝贵的意见建议。

捐助与联系

☟请使用新浪微博联系我☟

☟在github上follow我☟

标签云