@gaoxiaoyunwei2017
2019-11-14T11:11:20.000000Z
字数 10698
阅读 615
彭小阳
作者简介:朱少民 ,CSTQB 资深专家,国内软件测试领军人物,Certified ScrumMaster。曾任网讯(中国)软件有限公司QA高级总监,创建并领导近,300 人的国际化软件测试团队。从事软件开发、测试、QA和过程改进等工作近二十年,在软件测试过程改进、自动化方法和测试管理等,方面进行了大量探索和实践,先后出版《完美测试》、专著《全程软件测试》、译著《自动化测试最佳实践》和主编《软件测试方法和技术》、《软件测试》、《软件质量保证和管理》等多部高等精品教材。
我们经常讲有一个AIOps,更多是讲运营是智能的,但是我们因为DevOps强调的是整个生命周期的智能化。
所以,软件工程这个概念提的是比较少的,就是我们去年是在深圳大学那边举行了一个会议,庆祝软件工程50周年,软件工程的历史也不算长,从1968年开始,在北大西洋公约组织有一个会议,那时候才诞生我们的软件工程。
我们讲现代软件工程,更多的是基于互联网,但互联网还不是最重要的,当然没有互联网,我们现代软件工程也诞生不出来。可能当初我们更多是讲结构化编程或者结构化分析、结构化设计、结构化编程,大家可能也清楚80年代的时候,面向对象的分析,面向对象的设计和编程。
所以,这个对整个的软件工程有是有比较大的影响。然后,开源软件运动,现在大家也感觉到它的价值,像最近IBM也要收购红帽,所以这些方面都可以看到开源软件带来的运动,关键不是讲本身这个产品的价值,它的开发对大家整个开发是有影响的。
因为开源软件运动它的这种管理也是比较少的,然后更强调的是这个系统的架构更要好,更要简单,这样更有利于重构,这个和今天的敏捷也是息息相通的。
大数据,可能也催生了我们今天讲的人工智能。更重要的可能是软件企业服务,在今天来看软件不是一种产品,更重要是一种服务。
大家可能深有体会,前面把那个S换成X,相当于所有东西都是服务了,甚至讲区块链也是一种服务,或者云计算更是一种服务,平台是一种服务,基础设施是一种服务,就催生了我们今天讲的持续集成、持续交付、持续运维最基础的支撑。
因为你如果产品作为一个包装,就不可能做到持续交付的,非常困难。如果是作为一种服务,部署在我们数据中心,才会做到这一点。因为我们可以在几秒钟完成一次部署,或者我们真正有问题了,因为我们可以自己控制,或者回滚回来,或者可以做到灰度发布。从各个方面来讲,这样一系列的实践,都可以帮助我们更好去实现持续交付。
所以,我们早期一般谈到软件即服务,Salesforce应该是一个代表。所以一般谈到软件即服务,都会谈到Salesforce,因为它是最早做软件即服务的,就是最早做CIM客户关系管理系统,这个企业再小,都要把客户管理起来,所有企业都关心的,所以从这个来做。
我之前也是在Webex、思科工作,我们基本跟它同时做软件即服务的。公司是Webex1996年成立,2000年上市,总体来讲,还是比较快的。而且2000年是互联网泡沫崩溃的时候,那时候上市应该相对来讲是不容易的,1998、1999年还比较好,正好是互联网特别热的时候。我们也不是卖产品,也是卖服务,类似于相当于网站的电话沟通这样一个平台。
从20年前我们就开始运维数据中心,因为2000年,我们1996年公司成立,1997、1998年开始有产品了,应该是超过了20年。
从数据中心建立来讲,以前大家可能是运营商或者其它一些也有数据中心,但都不是自己的数据中心。真正建立自己数据中心是从Salesforce或者Webex开始,建立自己的数据中心。我们产品部署在自己的数据中心上,相当于部署在自己公司内部。这样的话,从管理来讲和维护来讲,比较方便。
这是13年前(2005年)当时我主要负责质量和交付,更多是从质量来讲。总体来讲,可以看到今天讲的DevOps最大的两块:
1、研发。
2、运维。
这里可能没有把架构设计、编程等开发的东西更好体现在这里,这里更多是从需求评审、设计评审,更多是从质量保证角度来写的。
但整个思想应该是一样的,要把开发和运维全线贯通。这边有一个沟通协作,就像我们今天讲的DevOps更多把研发和运维中间的一堵墙推倒,真正把研发和运维之间贯通。
另一方面,我们反过来你的需求也是来自于客户,或者你的产品改进,也是基于客户的反馈来改进。或从敏捷开始,都是强调我们最快或者更快、尽早拿到客户的反馈,更好提升我们的产品功能特性。
至于像去年到工商银行去跟他们做交流,工商银行在去年做了比较大的改动,就是北京的数据中心。原来主要做验收测试,现在要把两头(需求定义、验收测试和用户反馈、数据分析)放在这里,更好了解客户满意度,对特定的功能特性的客户反馈,或者是质量做更多的分析,反过来做改进。
这样的话,相当于两头都在北京数据中心大的部门(叫类似于业务开发中心),负责整个业务,这样的话体现了更大的价值。因为在前面像建行等几大行,都把测试中心撤掉了,只有工行保留下来。从这个角度来讲,如果仅仅是从测试来讲,形成一个独立的部门和今天敏捷、DevOps是不是有点冲突?和大势和整个趋势好像不是一致的。
但是,做了这样一个大的改造,两头都在这里,真正也算是把闭环接起来了,形成了一个闭环。
你可以看到,这里面包括性能的在线测试,今天我们已经是做得非常多了。经常讲对于一些小企业(不是像腾讯、阿里这样的大企业)都没有必要在实验室或者在研发环境下做性能测试,因为他们的用户,一开始产品上线并没有太多的用户。用户也是慢慢增长,在增长过程当中,慢慢去做性能监控,调优就可以了。
我们很早之前开始做这样的事情,有一个部署验证,可靠性保障,这叫全球系统备份,也类似于工行这种灾备,工行真正的数据中心在上海,灾备在北京。我们之前也在不同的地方,因为这个灾备还不仅仅是数据的备份,我们还有代理、其它的引擎或者其它的连接,有一次也出过问题,类似于阿里那种,光纤被挖断了,正好是在使用比较高峰的阶段。
因为你想一般施工,也不是在半夜施工,许多时候也是白天,正好是用户用的比较多的时候,把光纤挖断了,整个系统要故障转移到另外一个备份的数据中心去。
但这个事情有一段时间了,我们还有一个类似IDY的连接,但这个连接花比较多的时间,大概超过了60分钟。不是几分钟,那时候发现这个地方有一个Bug,不能及时转移。
我们这里有一个全天候监控,整个服务生命周期的管理。那时候已经把产品作为一种服务概念很清楚了,而且我们要全生命周期去管理这个服务。包括技术支持、竞品分析、客户满意度调查,形成一个完整的闭环。
DevOps应该是更晚诞生的,我们这里刚才讲的只是一个雏形,并没有真正提出DevOps概念,真正提出这个概念在一个会议上(2009年)提出来,那时候强调一天有10次部署。我记得早期像马丁弗乐定义持续集成概念的时候,每天至少有两次以上的构建,这个构建还要通过我们的验证BVT。
因为在更早的时候,微软有每日构建、每日集成,那还不叫持续集成,所以马丁弗乐在类似于,当然不能考证他是不是在微软基础上提出这个概念。他提出来要比微软至少更前进了一步,每天要两次以上。
DevOps和每天有10次部署,相当于有10次交付。大家以前玩图像、图片等应用的时候,应该对这家公司比较了解。后来好像被Google收购了。
至于像这种交付速度,一般公司很难达到的。因为我们有时候讲持续交付,要做到随时能交付嘛。什么叫持续交付?哪一天想要,或者哪一个时刻想要这样一个新的版本,就能交付。
这也像刚才白老师讲的,我们要做到持续交付这个瓶颈可能是测试,本身也有一个调查,今天没有把这张图给大家秀出来,大家也普遍认为持续交付的瓶颈在测试上,测试也要做到持续测试。因为交付的东西是要经过验证的东西,才能交付给客户。
或者从这个角度来讲,你才能对客户负责。没有经过验证的东西,不能交付。这样的话,怎么做到持续测试?相当于任何一个版本做完了,能交付,你要通过验证,能做到及时验证,这还是很有挑战的。
今天我们看到有一个标准,现在可能是工信部通信院牵头做一个成熟度标准,有1级、2级、3级、4级。大家对这个DevOps的理解不一样,简单理解就像我们刚才讲,把开发和运维之间的这堵墙打倒,就像敏捷更多把开发和测试之间紧密协作的障碍清楚。
简单理解讲,DevOps是敏捷的一个延伸,敏捷可能原来在研发环境下提倡的。DevOps在整个软件生命周期提倡的,所以从研发延伸到运维。
我们有时候讲软件产品作为一种服务,也有它的好处,我们有一个功能如果上线以后不成功了,是不是有一个开关可以关掉,这个可以做到,如果你配置的好,是可以的。有时候跟学生讲课的时候,讲回归测试比较重要,或者回归缺陷比新功能的缺陷更严重。
因为你老的功能,客户已经用了。你想关掉是不容易的,因为客户都用了,或者比较熟悉了,你一关客户就知道,会有抱怨。但这个新的功能客户用的比较少,有的客户根本还没有用到,你就关掉了,客户还不知道,没有感知。这样的话,也相当于在研发的时候考虑到运维的需求,或者在线以后,可能会出现的问题。
我们以前讲如果能提交数据库升级的Sgaima,这两份Sgaima同时提交,数据库还是最危险的。你提交升级,必须要随时想到,如果一旦出问题,可以快速回来。如果不提交,就不用做升级。
同样讲到工商银行之前有一个很大的问题,大概2013、2014年,在数据库升级的时候,有好几个小时不是能很好Work,所以数据库升级也是比较敏感的。你要做到快速持续交付,一定是比较小的部署。
就像刚才讲的,如果一天能部署10次,你是全量部署,肯定不可能,风险也特别大,不可能做到很快。一定是非常小的,就像我们的敏捷,为什么用用户故事来描述需求,其中有一个原因,也就是用户故事的颗粒度比较小。
大家都知道吗?特性团队是一个大的团队,或者是一个大的特性,把特性要分解成许多用户故事,可以按照用户故事来交付,这样的话颗粒度比较小,我们才可以做到快速交付。用户故事还有其它的一些好处,更是面向客户,不断培养大家的客户意识,从用户的角度去想问题,另外更体现价值,所以敏捷一般提倡让交付有价值的东西给客户。
还有其它的一些理解,我们讲DevOps更多是工具,你可以看到我们外面许多厂商在展示工具,这个DevOps做得好,就是自动化做得好,从开发、测试、部署、运维全生态的自动化。
就像刚才前面介绍的DevOps的定义,或者2009年诞生那一刻起,DevOps更多强调持续交付,随时随地交付。反过来,如果从研发的角度来讲看交付,或者部署。
如果从运维过来,也会提出一些问题,给我们的研发,所以这本身也是我们刚才讲的闭环,形成一个改进。昨天腾讯那边专场出现三个:持续集成、持续部署、持续运维。
从持续运维,我们更多是强调业务的驱动,到开发、测试,如果测试不是持续的,有时候问什么是敏捷测试?我们讲,你如果能做到持续测试,或者保证能持续交付,你的测试才是真正敏捷的,或者讲这是最简单的一个解释。到协作,可以看到是持续的运维监控,然后到持续的反馈。
这样的话,相当于形成我今天要讲的主题,这个图是以前大家熟悉的,我在两边加了两个注解。这边是业务驱动的,这边是基于数据驱动的智能分析。如果把这两个原动力再加上去,可能对整个持续交付更有价值。
我们先讲业务驱动研发和运维,这是我们一直在讨论的。有时候大家做敏捷,跟风现象比较严重,甚至像大的公司(思科等),也觉得工业界都在搞敏捷,我们也要搞敏捷,对吧?这好像还是一个普遍的现象。
但实际来讲,一定是要从业务出发。如果业务上不需要敏捷,如果业务角度讲需求是稳定的,需求也是比较容易搞清楚,需求比较明确,可能就没有必要去搞敏捷。虽然敏捷的教练或者其他敏捷真正的粉丝,对我这种观点不认同。这也是正常,大家应该有不同的观点。
总的来讲,一定是业务敏捷,需要研发敏捷去支持业务敏捷。因为我们所有做研发嘛,最终来讲为了解决业务的问题,或者为业务服务。我们经常讲“一切不以业务为敏捷的敏捷是伪敏捷”,不可能会真正敏捷起来。我们同样也是讲,如果不以业务为目的的DevOps,只是玩弄技术,只是想要去秀技术,或者秀能力,并没有多大价值。
所以,我们讲真正要做到是为了更快交付市场,提升运维效率,降低运维成本,更好提升服务质量,甚至也包括留住员工。刚才讲有时候秀你的技术和能力也有好处,员工愿意留下来。
如果你测试和开发都是手工的,运维也比较机械重复劳动,这样员工也不想干工作,你做自动化的实现,或者通过脚本和其它方式来实现开发、测试、运维,大家也愿意投身于整个研发过程当中。即使不是直接跟业务相关,因为我们留住了人,业务做得更好,毕竟是有一个积累。
所以,我们讲DevOps如果再打通的话,实际应该把DevOps打通,所以讲有时候名字读起来也不是特别好读,我觉得可以更简化一点叫BDO,就像我们讲的行为驱动开发(BDD)这样的,这个大家还是比较记住。
实际来讲,因为你不管业务打通,我们刚才讲的它的价值就比较低了,所以你只有把它的业务打通了,才能能体现它的价值。这里我们就用循环来表示,刚才我们可能是看到一个大的循环,实际上我们产品的本身也是一个循环,要不断的创新。
即使是对于互联网这样的企业或者是传统的企业,就像我们刚才讲的有些需求是明确的,但需求还是可以提升的或者有些需求还是可以挖掘的,即使是明确的需求,可能更多的是显性的需求。
许多隐性的需求或者是一些潜在的需求,还是需要去创新和挖掘的。甚至讲这个需求本身的业务流程可能是明确的,但它的功能特性是可以去挖掘的。所以,这样才会产生一个新的特性,因为有时候你的用户界面改了,让用户更好用了,本身也可以看作是一个新的特性。
然后,我们测试可能更多的是体现在这里,内部验证,或者是像刚才讲的性能测试一样的,可以做到持续调优,然后我们有新的部署去优化。因为优化本身它也不仅仅是研发这边去做优化,运维的环境,我们经常讲DBI跟我们数据库的开发工程师,他们还是有区别的。
数据库的开发工程师更多的是在数据存储、存储过程,或者是讲Circle语句,当然Circle语句优化可能更多是在应用的开发工程师,但至少包括数据库的结构或者其它方面,数据库开发的工程师可以发挥更大的作用。
但是,在生产线那边,就是DB怎样去配置,DBI可以发挥更大的作用。在运维这边它也是可以去优化,昨天我们吃饭的时候,有时候讲出了问题,好像至少从运维的角度来讲,都是让研发这边背锅,就觉得是我们没做完,其实也不完全。
因为有时候你如果配置不好,它的性能也会比较低,就像你去优化你的配置,也是可以提高这个产品的效能。因为你部署以后,你的验证实际是交给市场去检验了,你的产品好不好,最终还是要让用户去检验的。
所以,这个有时候像我们做应用性测试,还是要交给用户去检验,所以才会有IB测试,因为只有用户才能代表用户,我们测试人员即使你用户体验理解比较深的人,毕竟还是有你自己的一些偏见,所以你也不能代表真正的用户。
然后,有新的业务,我们要能支持他新的业务。从这个来讲,我们是要做到快速的创新,所以今天我们可能会更多的强调这种持续的交互管道,所以今天可能讲就像微服务这样的架构,它就可以提供多管道的交付,就是每个管道相对比较独立,就像刚才讲的一样,你自有的颗粒度比较小,你才能做到快速的交付,或者你这个系统的核心降低了。
今天可能这样的概念更极致的体现出来了,我们过去可能跟学生讲高内聚、低耦合,可能学生有时候体会不到。
今天他可能越来越体会到了,过去因为你是整个系统交付的,开发版本构建都比较大,或者半年、一年构建一个版本,然后像高内聚、低耦合大家不容易体现出来,但今天这样一个模式下,这样的设计理念和设计的实践,会得到大家更多的体会和应用。
反过来也是一样的,就是我们要做到快速的基于业务反馈,来优化我们的系统,改善我们的功能特性,最终的目的就是让客户更满意。业务驱动开发,不管你是用什么样的模式,我们经常讲服务的重组编排,还是讲我们基于以前组件的分解,就像刚才讲的我们软件的复用,不管你处于什么样的目的,可能是想更好的降低我们开发的成本,我们如果复用了,可以提高我们的开发效率。
所以,提高开发效率也是为了更好的满足用户的需求,就像我们之前讲内部质量、外部质量,外部质量是用户能体会的,内部质量可能用户体会不到,好像对用户没什么影响,但实际最终来讲对用户有影响的。
因为当用户提出新的需求时候,如果你的内部质量不好,你代码耦合性比较高,你的系统比较复杂、代码比较复杂,这个时候你要去实现一个新的特性比较难。以前我了解到一个互联网的公司,好像改一个电话号码,就是改一个小的功能特性都特别困难,然后上线以后每个月大概都有好几个在线的问题,至少有5、6个在线问题。
后来请了一个阿里的架构师去当他们的CTO,然后花了一年半的时间重构他们的系统,以后的开发就很简单了。
所以,这个你本身讲,假如做电商或者做其它业务的一些产品,实际就是这种业务的需求,要求你必须要快速的去满足他的变更,所以这个大家深有体会。不管你下面的架构怎么样,但最终来讲最上层的都是我们的业务流程,或者都是为了更好的满足业务。
我们要实现这个业务快速的功能特性重构,或者是增加新的功能特性,你下面的东西如果分解的越好,或者他们的耦合度越低,或者分解的越细,或者更灵活的可以相互组合,可以满足不同的需求,这个就是我们开发要做的事情。
这个业务领域建模实际是有关系的,所以白老师前面讲了他的完整的基于模型驱动,所以刚才有一个老师也提到DSL(特定领域语言)这样的一些描述,基于这个来更好的去实现我们的系统。
今天大家可能对这方面的关注比较少,就像有时候讲YML今天没有太多人在用了,如果你真正要做的彻底,有时候做的快也还是需要你的,就像我们讲的磨刀不误砍柴工一样的,就是前几个人花的比较多,就像我们有时候谈需求也是这样的,你如果在需求上少花时间,你在后面的设计编程测试上就花很多的时间。
但你如果在需求上花比较多的时间,你的设计、开发、测试就会比较少。所以,从业务领域模型驱动设计,就会更好的让我们的设计开发,更好的满足我们的业务需求。
所以这里面讲到类似于DSL和YML,甚至就像刚才白老师讲的BDD这种,它好像没有像我们通常理解的DSL,但它也是通过GWT这样的定义来描述我们的场景,相当于描述了我们的验收条件,实际也就是澄清了需求,就跟我们讲BDD包括需求识别化,都是更好的去澄清需求。
另外一方面,可以让我们的需求变成活文档,更好的去变成可值钱的文档。另外一方面,我们讲软件工程都是有一个上下文,强调上下文驱动,世界上任何一个团队,任何一个产品,任何一个项目,实际都是基于不同的环境和不同的团队,或者不同的领域来实现的,所以你一定要去区分上下文。
我们一个模型的描述,可能更多大家关注的是实体,服务可以看成方法,这种值可以看成它的属性。然后,我们可以做一些对象的封装,或者是更好的构建实体库,来满足我们业务的描述,然后我们也可以进行分层来实现隔离不同的业务。
在今天我们如果是从敏捷开发来讲,就是用户故事,实际就是用户行为,有时候你可以理解为事件,然后这个事件和行为一定在特定的场景下发生的,所以特别强调这种场景的挖掘。
刚才白老师最后那个例子也是特别强调场景,或者像我们讲的BDD,它更多是验收条件把它变成场景。有时候相对讲是一个业务的需求,我们希望我们的这个东西,产品更生动,你不希望像这样的,好像这个比较容易实现。
但这样的话,大家就觉得不喜欢,太机械了,你一定是希望比较丰富的,它感觉起来是比较随意的,这样的话,对用户来讲还是有一种吸引力。你如果是比较呆板的界面,用户一定不喜欢。
如何做到这一点?你一定是要建模型的,你如果不建模型,因为不满足这种需求,这时候你可能有遮挡,或者做不到这种有大有小,因为我们这里有的大、有的小,就相当于带有一定随机的概念。
所以,这块你就构建模型,模型构建出来实际这个问题并不那么复杂,或者你就彻底的解决了这个问题。
从我们来讲,你即使更复杂的情况,我们也是可以通过模型来做的,或者我们从理论上讲,就是越复杂的问题,越需要模型,简单的问题当然你就不需要模型了,可能你就一眼能看到,就像我们讲到那个测试一样的,如果简单你就用决策表,复杂的话,就要有因果图来帮助你,去做因果分析,或者做输入输出的分析。
所以,这个就涉及到我们讲的业务驱动测试,开发我们实际讲到了需求,设计可能讲话也讲了,前面包括基于微服务架构,这个也是基于业务驱动开发的设计。从测试来讲,这个是大家比较熟悉的四象限,所以也是特别强调面向业务,不仅仅是看到这个技术。
这个实际我做了一些改造的,就是把ATDD加进去了,BDD,就是结合我们真正的敏捷来看,这个原来是没有的,像实例化需求,测试驱动设计,原来的四象限没有的,这个是我在原来四象限的基础上,做了比较大的一个改进。前段时间也看到一些文章,就是相对讲你不搞TDD或者是ATDD的敏捷,最终一定会死掉的。
我们讲的测试的分析设计,你是要从业务来驱动,这个业务不是抽象的,它是很具体的业务决策、流程、规则、业务数据,所以是实实在在的从这些角度分析你的测试,然后设计你的测试用例,最终你的分析设计是不是充分,或者你的覆盖率是不是足够高,还要通过业务来检验,或者通过市场来检验。
像我讲的敏捷测试是持续测试,或者讲大家敏捷测试还是做的比较困难,刚才讲的80%的瓶颈可能是出现测试这边,就是因为大家可能没有真正的做好这个需求的分析,就像我刚才讲的你不是真正的ATDD,你最后还是会死的比较快。
但是,你如果真正把ATDD做好了,像我们讲的特性变成用例或者用户故事,然后用户故事的验收标准是场景,这个过程是不断的分解,就是分解的越来越细,如果你分解到场景,就是有了验收标准,这时候开发也清楚了,就是它也相对写代码出错的可能也很小了。
测试是相当于它就已经完成了大部分的设计,它唯一少的是还加什么,这中间还差一个什么。就是场景和测试用例之间还差一个填充的内容是什么,所以就是数据,可能要用到我们的等价类、边界值包括组合。
这时候可以是自动生成,就像刚才白老师研究的API,关于我们知道一个值域,我们秋收知道它的边界值,我们就可以生成等价类,或者是无效等价类、有效等价类相关的数据,这部分实际是很容易去做的。
所以,这块你的测试反而很简单了,从运维来讲,我们也是要做到这些方面的功能特性,就是让用户感知,或者怎么去感知用户的体验。然后刚才讲的快速交付、数据分析、可视化,最终体现了我们这样的一个效果。
如果再细的分析,更多的指标可以从业务指标的监控,业务最终IT溯源,然后到其它的方面,就是你可以再细化,这样才真正的可以快速反馈到我们研发那边,研发那边才会更有效的做出对用户更有价值的功能特性来服务用户。
最后一个就是智能的运维,我们刚才也提到了通信院他们在搞一个成熟度模型,这个不是通信院的模型,当然我也不能确定他们有没有参考这个,但最可能早期的运维完全是体力活。
后来就像亚马逊讲的所有的基础设施都是代码,我们所有的运维都是自动化的,然后到今天我们可能有更多的工具,来帮助我们更好的去做编排,或者怎么去灵活的调度相关的。
然后,再到真正的我们能做到持续交付或者持续运维,然后到智能,所以这个是我们一个成熟度的过程。我们刚才讲因为我们讲的智能的DevOps,不仅仅是智能的运维,你应该是智能的整个生命周期,整个研发智能起来。
整个DevOps和AI牵扯融合起来,你整个研发的生态包括运维是完全不一样的,你更多是要站在刚才讲的业务角度,更好的去提高架构的灵活性,包括它的部署,它将来可维护的特性,也提高了测试。
下面有一个专场,他们会更多的讨论这方面的一些内容,怎么从测试的角度来更好的去支持DevOps。我们从AI的角度来看,可以更好的去助力DevOps,所以从各个方面都是有许多的事情可以去做的,之前也做过分享,可能在8月初也会在专门的会议上分享AI或者对测试更好的去支撑。
我们以前在这方面可能会做的多,我们通过这个角度讲AI的分析,数据的分析,或者讲智能的运维,我们可以告诉他正在发生什么,我们现在像浙大或者其它的一些学校也在做Bug自动的定位和修复,这个就是讲我们要知道问题出在哪里,反过来我们也应该知道这个问题出在哪一行代码,至少讲哪一行代码更具有可能性在这个地方出错,然后我们自动的去做修复。
所以,这个你不仅仅是描述性的分析,还有诊断性和预测性的分析。时间关系,我们就快速的过,但总的来讲,就是怎么更好的去通过这种AI的技术,对整个的研发是有帮助的。
后面我们简单的讲几个例子,一个是讲业务创新方面,一方面是讲你要真正的做度量,以前写过一篇文章讲CML把度量放在我们4个Level,可能思想主要是讲,你如果过程都没有定义,度量不够系统、不够全面、不够完整,实际来讲,你想我们本身就是做计算机数字化的东西,我们度量一定是先做起来。
即使是不够系统,那也可以慢慢优化,所以持续优化我们的度量,最终让我们的度量更系统、更完整。我们这种数字化的特点,也是我们一直要提倡的。过去这方面,有时候就把别人的领域、别人的行业去数字化,结果自己还不够数字化。
其它研发这边创新的模型、运维的模型、平台工具,我们可以更好去做更深的分析,不是表面现象。你看到表面给你的一些特征,能透过表现来深入到业务,我们能真正洞察业务,这要做更深的分析。
有时候也不仅仅是互联网这样的企业,今天包括汽车行业和其它行业,汽车也越来越数字化。我们也可以更多拿到用户的数据,也不涉及到个人隐私的问题,可以更好去完善我们汽车的设计。
这是一个顶级的会议,上面有一篇论文,做了这样数据的分析。我有时候也会去观察华为、小米的市场手机APP数据,做这样的分析,反过来去了解这个产品的特性设计或者质量。
时间关系,我们最后总结一下观点。我们强调DevOps1000人有1000种理解,最终来讲是为了持续交付和改进,更重要的你真正服务于业务,不仅仅是运维是智能的,应该是整个生命周期从需求,甚至讲你的业务创新、产品创新,到你的设计改进、开发测试,都可以融入我们智能的一些技术。