如何打造业务驱动的DevOps智能闭环？

彭小阳

作者简介：朱少民 ，CSTQB 资深专家，国内软件测试领军人物，Certified ScrumMaster。曾任网讯（中国）软件有限公司QA高级总监，创建并领导近，300 人的国际化软件测试团队。从事软件开发、测试、QA和过程改进等工作近二十年，在软件测试过程改进、自动化方法和测试管理等，方面进行了大量探索和实践，先后出版《完美测试》、专著《全程软件测试》、译著《自动化测试最佳实践》和主编《软件测试方法和技术》、《软件测试》、《软件质量保证和管理》等多部高等精品教材。

一、新时代模式-DevOps

我们经常讲有一个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溯源，然后到其它的方面，就是你可以再细化，这样才真正的可以快速反馈到我们研发那边，研发那边才会更有效的做出对用户更有价值的功能特性来服务用户。

三、不只是智能运维AIOps

最后一个就是智能的运维，我们刚才也提到了通信院他们在搞一个成熟度模型，这个不是通信院的模型，当然我也不能确定他们有没有参考这个，但最可能早期的运维完全是体力活。
后来就像亚马逊讲的所有的基础设施都是代码，我们所有的运维都是自动化的，然后到今天我们可能有更多的工具，来帮助我们更好的去做编排，或者怎么去灵活的调度相关的。

然后，再到真正的我们能做到持续交付或者持续运维，然后到智能，所以这个是我们一个成熟度的过程。我们刚才讲因为我们讲的智能的DevOps，不仅仅是智能的运维，你应该是智能的整个生命周期，整个研发智能起来。

整个DevOps和AI牵扯融合起来，你整个研发的生态包括运维是完全不一样的，你更多是要站在刚才讲的业务角度，更好的去提高架构的灵活性，包括它的部署，它将来可维护的特性，也提高了测试。

下面有一个专场，他们会更多的讨论这方面的一些内容，怎么从测试的角度来更好的去支持DevOps。我们从AI的角度来看，可以更好的去助力DevOps，所以从各个方面都是有许多的事情可以去做的，之前也做过分享，可能在8月初也会在专门的会议上分享AI或者对测试更好的去支撑。
我们以前在这方面可能会做的多，我们通过这个角度讲AI的分析，数据的分析，或者讲智能的运维，我们可以告诉他正在发生什么，我们现在像浙大或者其它的一些学校也在做Bug自动的定位和修复，这个就是讲我们要知道问题出在哪里，反过来我们也应该知道这个问题出在哪一行代码，至少讲哪一行代码更具有可能性在这个地方出错，然后我们自动的去做修复。
所以，这个你不仅仅是描述性的分析，还有诊断性和预测性的分析。时间关系，我们就快速的过，但总的来讲，就是怎么更好的去通过这种AI的技术，对整个的研发是有帮助的。
后面我们简单的讲几个例子，一个是讲业务创新方面，一方面是讲你要真正的做度量，以前写过一篇文章讲CML把度量放在我们4个Level，可能思想主要是讲，你如果过程都没有定义，度量不够系统、不够全面、不够完整，实际来讲，你想我们本身就是做计算机数字化的东西，我们度量一定是先做起来。
即使是不够系统，那也可以慢慢优化，所以持续优化我们的度量，最终让我们的度量更系统、更完整。我们这种数字化的特点，也是我们一直要提倡的。过去这方面，有时候就把别人的领域、别人的行业去数字化，结果自己还不够数字化。

其它研发这边创新的模型、运维的模型、平台工具，我们可以更好去做更深的分析，不是表面现象。你看到表面给你的一些特征，能透过表现来深入到业务，我们能真正洞察业务，这要做更深的分析。
有时候也不仅仅是互联网这样的企业，今天包括汽车行业和其它行业，汽车也越来越数字化。我们也可以更多拿到用户的数据，也不涉及到个人隐私的问题，可以更好去完善我们汽车的设计。
这是一个顶级的会议，上面有一篇论文，做了这样数据的分析。我有时候也会去观察华为、小米的市场手机APP数据，做这样的分析，反过来去了解这个产品的特性设计或者质量。

时间关系，我们最后总结一下观点。我们强调DevOps1000人有1000种理解，最终来讲是为了持续交付和改进，更重要的你真正服务于业务，不仅仅是运维是智能的，应该是整个生命周期从需求，甚至讲你的业务创新、产品创新，到你的设计改进、开发测试，都可以融入我们智能的一些技术。