7月15日，优维科技和数人云在上海举办了“DevOps&SRE超越传统运维之道”第三期，现场座无虚席。在这里再次感谢顶着酷暑来参加活动的小伙伴们！以下为优维科技刘劲辉的演讲实录。
刘劲辉 优维科技高级解决方案架构师
曾就职于阿里巴巴移动事业群，具有多年的业务运维和运维研发经验。曾负责开发建设基于阿里游戏中心JWS框架的自动化运维平台，对DevOps实践落地有丰富经验。
《优维科技内部DevOps研发实践》
一、Why DevOps？
首先，我先简单跟大家讲一下DevOps基本的理念，可以简单问一下现场对DevOps有比较深刻了解的举一下手。好的，大部分都是比较不清楚的。
我先讲一下这部分内容，其实在企业生产的过程里，他们关注的核心都是3个东西，就效率、质量和成本，不管是哪个企业，不管是互联网金融还是科技公司还是传统的制造业，他们关注的点，在生产过程里面关注的点一定是这三个目标，基于这三个目标传统行业里是怎么做的？
传统行业制造业里面会提出一些模块化的生产、流水线生产、自动化废品检测等等很多的自动化流水线，精益管理是想帮助他们做制造业的生产过程，精益化的过程，但是对传统的IT服务业来说是怎么样的？
IT服务业不会生产实际的产品，它会生产服务，而服务来源我们用户需求，比如说我们要听网易云音乐，要玩游戏等等其实是线上的用户服务，不会产生实际的东西，但同样这也是一个生产过程，只不过这两个生产过程生产的东西不一样而已，这两个生产过程同样要遵循刚才所看到的企业在生产过程中遵循的三个核心。一个是质量，还有成本、还有效率。
对于我们的IT制造过程里面遵循这三个目标会去关注什么方面？会关注这些方面，如下图所示。比如说我们把用户的需求变成线上的服务，比如说你能够多快去发布我们的用户需求，还有你发布这个需求需要多长时间？还有你发布这个需求出问题了，该怎么去解决？还有最终怎么防止？
这里列出一些是不是你组织高性能的一个衡量标准。比如说我们的谷歌、facebook 在这四个指标上执行上是非常好的。谷歌每天发布量高频率会达到3万次。
然后，面对这些挑战的话，我们提出了DevOps 的概念，其实它也是来源于传统制造业里面的精益管理的思想，跟传统制造业其实是一样的，只不过换一种方式变成了IT服务业里面的一个落地而已。最开始它的思想是来自于传统制造业的精益管理，精益管理抽象成到IT里面会变成3个基本的模块，一个是敏捷管理，一个是持续交付，还有一个是IT服务管理。所以DevOps是一种文化，基本模块就是分成这3个模块。
在这些模块里，这些东西以前都已经有了，也就是不是DevOps提出的，而是它以前都已经有了。比如说敏捷管理里面，涉及到很多敏捷开发，版本管理，SE开发等等这种规范或者一些版本规范、分析规范、部署规范这些，这些都是属于敏捷管理里面的内容。
还有一个持续交付，肯定在DevOps出现之前，你们都已经做过一些运维自动化、测试自动化这种东西。还有一些IT运营的东西，可能以前的产品会分析线上的性能，或者是研发会分析系统性能这些，去搜集这类的问题管理等等。
所以DevOps的话，并不是这几个模块具体的产生，而是它把这几个模块做一个比较好的整合，根据传统的DevOps 精益管理的思想把这几个模块很好的串通起来，这才是DevOps 整个文化理念基本的概念。
二、How does DevOps Team works？
首先，我们先看一下DevOps 团队一般是怎么构成的，从研发的模式来了解DevOps 的模式的话，以前我们会采用瀑布流的模式，团队可能会分成3个团队，一个是研发团队，一个是QA团队，还有一个是操作团队。然后当这种效率其实是违反了持续交付模式里面很多内容的，比如说手动部署、开发完成再生成部署，所以它的迭代效率会慢一点。
随着而来，我们会在研发还有测试这一块会提出一些敏捷开发的思想，希望能把这个过程加快一点，基于这种模式的企业一般它的团队都是研发本身是一个合作的团队，但是操作还是比较严格的，这其实违反了一个模式，就是说这里研发是快的，但只快在研发和测试方面。
它的生产环境还是会出问题，因为它在开发完成之后才出现生产环境问题，之前一直开发的时候都没有部署过生产环境的，所以环境不一样可能会有一些问题出现。因此，从DevOps 来看，DevOps 希望它是一个功能团队，希望在这个团队里面把开发、测试运维拉在一起互相合作，这才是一个DevOps 团队基本的构成。
来讲一下EasyOps，接下来会讲一下EasyOps 的DevOps实践是怎么样的，先讲一下EasyOps 产品研发流程，就是需求变成一个产品之后会有一个功能的时候，它的流程是怎么样的，一般分成这几个阶段，先是需求和概念提出，比如说客户提出一个功能，见简单的，他提出一个功能说我要回滚功能，那回滚功能我们先提出这个概念会做需求讨论。
然后首先会去做调研，你回滚平时是怎么做的，大部分用户是怎么做的，大部分企业又是怎么做回滚的，这里面在调研里其实有一个误区在里面，很多用户在做需求调研的时候用户都会说你帮我在这里加一个什么东西，或者是你帮我在这个页面加一个按钮就好了，这样做就OK了，它的需求就搞定了，它的需求真的是这样子吗？其实最终很多时候做这种的需求都是失败的。
一般正常逻辑都是这样的，我不让用户指导我来做什么，而是说我会问用户，你为了完成这个需求，你现在是怎么做的，你一五一十告诉我，我回答之后我会把你做的那个工作，业务流程划出来，我会分析这个过程里哪些是好的，哪些是坏的，哪些是有问题的，哪些是可以优化的。
然后我会去做一个流程创新，我会把用户故事的流程进行一个创新再设计，设计出一个业务流程图，包括这个原型需求的设计文档，然后再交给我们的研发团队去做这次任务的编写，然后最终是一个功能的发布。
好的，那就是我们一个DevOps 团队组成至少要包含这一块的东西，DevOps 基本组成会是这样子的，比如说第一个，我们至少有一个产品经理，而且这个产品经理负责做我们的需求的收集、分析、业务流程等等的调研，这个需求分解完之后会有需求轮岗出来，这边的需求轮岗会交给测试和QA控制组做这个事情。
QA这边有一个评委组出一个文出来，然后再根据需求文档去写那些根据需求出来的知识，我们的这个用户就看情况了，比如说这个需求需要前端支援的话，可能有UI、前端和后端，所以一个虚拟团队的话基本组成大概会有一个7人的小团队这样子的。
但是大部分的情况，这不是固定的，大部分的情况下，很多产品不同，可能产品会经常穿插于各个功能特性上去，所以不是固定的，会在团队里去穿插，我们的QA也是，当它根据需求写完这个测试和场景覆盖的话，可能去帮助其他的功能团队去做更多的测试。这些也是按照实际情况来调整的。
比如说我们的功能比较简单，需要一个后端，需要一个前端就搞定了，有可能会出现这样子。但是，这些角色的话是一定要存在的，它是一个单独的团队。这些团队一般是按照产品线来划分，它在组织架构上会调整。
来看一下EasyOps 迭代效率是怎么样的，如果是按照这样的组成来构建内部一个团队，功能研发团队的话，首先我们会去产生一个功能，比如说用户级的回滚功能。
我们同时在一个版本开发里会有同时很多这样的功能在开发，比如说有一个团队正在开发回滚的功能，有一个团队正在开发版本类型的功能，有一个团队正在开发持续交付流水线的功能，所以它会有不同的小组一起正在进行工作，这些功能最后合并成一个上线时的一个版本，比如说这个版本里面就可能发很多内容在里面。
我们的EasyOps 研发大概是35人左右，比如说按照7人团队来做的话，同时能够并行5个功能的开发。但是实际上其实很多功能都不需要那么多人的，也是可以穿插各个功能一起做这个事情，所以平时基本上EasyOps 内部同时迭代的功能大概有10个或者是10个以上，这就是EasyOps 内部产品研发团队的工作模式。
三、How Does Aglie Management works？
接下来我会讲一下我们的产品研发团队组成在敏捷管理这一块是怎么工作的，其实这个也是DevOps 最主要的内容，DevOps 里面两个最核心的模块一个是敏捷管理，还有一个是持续交付，大家平时听得比较多是持续交付，很少讲敏捷管理，我会简单的讲一下。
我们EasyOps 内部敏捷管理是怎么做的？首先看一下整个产品研发的流程，我们把刚才的那个圈细化一下，首先在需求概念阶段的话，是怎么样的？有用户提出我要回滚，然后我们就会把这个需求提交上去，它会有一个通道说这里显示一个回滚的功能是需求待讨论的。
我们会把这个拿出来一起讨论，我们的研发会一起讨论确定这个功能确实是需要做，然后把这个功能立项把它给到一个分支号，比如说f056。就我们现在已经立项做这个事情了，立项做这个事情怎么做呢？
首先还是按照刚才所说的，在你的调研和设计阶段，你必须要去做调研，你必须要知道你一个回滚的流程整个流程图是怎么样的，你必须画出来，这个流程图出来之后会产生一些用户操作的场景，这实际上是用户用你的功能以后会出现一些场景，比如说回滚，它可能立即回滚，比如说他发布完一次之后，马上有问题了系统帮它立即回滚。
或者是另外一种场景，他选择发布之后，15分钟之后发现业务上有问题，但是他本来原来刚才启动的时候是没有问题的。后面事后回滚的话是怎么做这个产品的，然后多应用，比如10个应用、10个应用发布了，现在要回滚这些应用怎么去做，这就是用户故事的场景。
然后根据这些用户故事的场景我们会去设计一个原型出来，根据不同的场景设计这些原型，最终得出我们的需求文档，这个需求文档包含了我们的设计原则和业务流程图。然后产品，研发和测试就是看到这个测试流程图干活的，当然也有需求讨论会去讨论这个需求文档。
简单看一下业务流程图是怎么样的，这里是f063是我们的docker 开发的业务流程图，用户是怎么样在我们平台上使用docker 的镜像管理的，比如说这个有一个docker 镜像管理它会有不同的业务流程管理它，不然研发没有流程图，没有需求原型是很难精确理解到这个需求，最终做出来很容量变样的，所以这块在管理里是非常重要的。
这是业务流程图，这是业务原型，产品性大概做这个东西做成什么样子，会给一个原型出来，可能可以交付给我们的后端研发或者是前端的UI等等去参考，然后最终这个需求文档会出来，明确一下这个功能的详情是用来做什么的，功能描述等等，还有里面包含很多的流程图，还有我们的业务原型图。
需求文档提出来进入讨论阶段，我们会开需求评审会，需求评审会完了之后会有特性面板去跟踪，这是我们EasyOps 内部的特性面板，特性面板这个功能面板是正被在做的，一部分是正在做的功能，一部分是已经完成功能，另一部分是准备发布的功能，还有一部分是已经发的那些功能，可以在历史的版本里会找到这些功能。
这是每一个功能的项目，比如说f056持续交付流水线这个功能所包含的一些基本的描述，根据这个基本的描述我们会有专门的面板跟踪这个功能的开发，比如说这里需求已经定稿的，这是研发出来的大概的任务，这些任务会跟需求1，有标签1，比如说这个是01、02的需求，那些研发任务上面会打标签说这是属于哪一个需求分解出来的研发任务，全部都在这里。然后研发的那些比如说待办的、开发完成的，正在QA测试的都能看到。
这个是我们的项目管理进度，就是研发任务分解完之后我们有面板跟踪，分解了明确的研发任务，分解了明确测试的编写任务。当所有的任务完成了就标志着这个功能已经被完成了，所以我们会时刻跟踪这个面板上面的那些任务完成的进度，比如说这里有总的任务数，每天完成的趋势，还有每个人的任务统计，防止延误的风险，这里还会精确到个人的分析，比如说这个人工作状态是怎么样的，他每天完成的任务是怎么样的。
我们在分解这个任务的时候要小心，如果他是比较大的功能，我们分解任务的时候希望分解到每人每天，这样项目经理还有研发经理就很容易判断，他这个人挂了多少任务，他现在是不是空闲的，他还有多少的工作开发量，还有天的开发量，这个面板还有多少的任务没有完成，他就看一下比如说有10个任务没有完成，这个团队有10个人的话，他就知道这个任务今天就可以投入使用，它是这样的模式。
在敏捷管理里刚才说的都是整个的需求分解、研发分解、研发分解、测试用例分解等等一些管理，敏捷管理还包括其他，比如说我们的分支管理是怎么做的，版本管理是怎么做的，分支管理我们没有做很多的创新，直接用了git-flow做我们的分支管理和版本管理。
这里面敏捷管理还有环境管理规范，我们EasyOps 的环境管理规范首先包含这几个东西，首先我们采用分支开发模式，所以那些功能之后分支都有独立的环境。然后我们会有固定的功能开发和服务器，这个是QA控制组立项的时候，会分配一个独立的环境，比如说同一个功能我就分配163给他做这个开发，还有持续交付流水线，我们就分配164给他做功能开发。
接下来是我们的产品管理。比如说2.27.0版本我们都会开一个产品发布会，这个版本带来哪些功能去，比如说2.27这个版本前端支持开发，应用部署支持什么，还有什么流程工具版本控制，流程工具的支持配置管理等等这些功能在这里。
然后我们一目了然的，知道这个版本发完了什么东西，有什么新的特性。这是敏捷管理里面的产品管理。其实还有很多的东西，比如说EasyOps 的部署规范，由于时间关系，有兴趣的可以后面跟我聊一下。
四、Why Pipeline？How Does it work？
我们讲完敏捷管理，讲第二个核心模块，持续交付是怎么做的，大家会比较熟悉一点，这里就简单的讲一下EasyOps 是怎么做的？
刚才出现了两个产品研发的流程图，那是项目管理里面的流程图，这一页是持续交付的流程图是怎么做的，首先在研发和交付阶段分成几个模块，刚才我们拿到需求文档，开需求评审会，可能研发就会分解他的任务。
然后进行代码研发，在这里少写了一个就是测试分解测试用例的场景，所以在代码研发的时候同时测试用例正在编写，有可能测试用例写完了研发都还没有把代码写完。研发写完了以后就可以马上进行集成，进行版本交付的过程。
讲到持续交付肯定要讲流水线，我们讲一下流水线，这个流水线经常会看到很多教科书写的可靠、可重复流水线，大家知道可靠可重复是什么意思？为什么流水线是可靠可重复的？我来简单解答一下，可靠是什么意思？
可靠就是说流水线它也是一种基础环境，你可以认为它是一种代码环境，它也是一种代码，输入1，输出E永远是这样子的不会输错，是不可变的。这是它的可靠性。第二个可重复是什么意思？它永远只干一件事情，这个过程可以追踪、可以审计的，从来不会做其他的事情，你让他干A活就A，干B活就B。
再举个通俗一点的例子，比如说我线上部署应用A，如果人去做这个部署，可能我给上面5个人做部署应用A，可能这5个人最终都是专家应用到部署上去，但是应用部署方式不一样，比如说第一个人先把包上传下来，然后解压放到临时目录，然后再把文件覆盖过去，但是另外一个人不是这样做的，另外一个人也是先把包上传下来，解压把原来目录备份一下比较安全，然后再把这个文件放进去，可能不同的人来做过程不一样，但是结果有可能一样的，有可能不一样。
就是人去做部署的时候非常不可靠的，这就是为什么持续交付里面非常反感那些人做手工部署，这些手工部署不仅要理解部署文档，而且你做的事情换另外一个人来做有可能不一样，所以这是为什么用流水线做这个东西是可靠可重复的。
我们来简单看一下一个需求发布的基本工作流程是怎么样的，至少包含这4个阶段，第一个是需求设计和研发。就是你会有不断的研发，需求设计完之后就是本地研发，本地研发之后最常见的就是提测，提测就会进入到我们的测试环境去做功能验证，因为很多已经做了自动化的测试，这里测试环境更多是做什么？
做人工性的探索测试，演示性测试，会起到一些安全性的，比如说容量的压缩等这些测试，可能会测试环境做，当测试通过之后这个版本就可以进行版本上线，版本上线比较复杂，生产环境会按照这个测试来做，比如说滚动部署。
一般的功能流程包含这4个阶段，我们认为这四个阶段用一条流水线来做实在是太困难了，而且是不同的阶段在干不同的事情，所以我们认为流水线可以分成多个阶段来做这个事情，真正的流水线之间是有衔接的，在敏捷管理里面它是同一个需求就可以了。我们把流水线分成三个阶段，一个是开发阶段本地的，一个是开发运营的流水线，一个是测试的流水线，还有一个最终交付上线的发布策略相关的交付流水线。
在EasyOps 内部开发流程是这样子的，就是它关注研发本地开发，我在这个功能环境里，比如说研发正在做回滚的功能，我在163这个服务器上不断的提交我的代码，它会自动的更新163这个东西，这里涉及到一些我们的代码管理怎么做，分支管理怎么做，以及构建设施怎么做，你的单元测试怎么做的，结构测试怎么做的，还有流水线构建的能力，就包含这些能力在里面，不要小看这么广，其实包含一个一个的东西在里面。
像我们的研发，在本地一旦提交代码，就会代码构建，构建完之后就去做打包管理，打包管理注册我们的版本，把版本注册上去就部署到我们的163环境，然后就跑自动化的接口测试，它就包含这几个东西。等会会讲一下为什么这里不是单元测试，代码覆盖率，为什么这里内部只有一个接口测试，我会在QA环节解答一下。
然后就是测试流水线，测试流水线比较严格一点，跟开发流水线有什么不一样，其实大部分都是一样的，但是有一个地方不一样，就是它有一个明确的版本是二进制的包提出来，开发不关心这个过程的，所以他导入的包可能没有真正录入到我们的二进制仓库里去，但是测试和运维关心的不是某一个分支，而是明确的版本。
所以这里构建的时候，在版本管理里面还涉及到一些版本管理，我们会通过打标签的方式，标签就是我们的版本号，打标签的时候会自动触发这个流水线，比如说给一个标签出来，注册成一个测试版本，在我们的二进制仓库里面去，要运行一些测试的自动化的接口测试，还有自动化的UI测试等等，最后就进入了人工确认的环节，人工确认比如说有一些手工测试，有一些探索性的测试要做，做完之后我就上线，如果他不想上线就结束了，这样的模式。
简单看一下在构建流水线的时候本身具备什么能力才能适应，就算公司开发自己的流水线你要注意有这些能力，比如说你要有串行的能力，有并行的能力，因为有些自动化测试可以并行调的，一定不能忽视这个环节。有串行、并行、合流、分流，有子流程，可以穿插子流程，可以放一个任务，失败了可以继续进行，失败了也可以停下来。然后还有判断，一些人工确认也是需要做的。
比如说它不是OA流程的，那种人工圈是比较简单的应用人工暂停。还有输入输出共享，这个在流程设计里非常重要的，它是跟OA流程完全不一样的地方，就是每一个模块里面的输入输出在后面的时候模块都是共享的，在构建这个流水线的时候能力非常的便利。
##五、EasyOps封闭开发
讲完了流水线具体来看一下我们的封闭开发是怎么做的？比如说把上个月持续交付的流水线，就是开发这个功能，我们是怎么开发的？把这个例子给大家说一下。
EasyOps 开发特性的案例，比如说开发持续交付流水线的功能，这个功能去清远做了封闭开发，在那里我们用了两周的时间来设计持续交付流水线，只用了5天的时间开发，7个小组3个模块，一共分解了56个研发任务。
为什么设计这里这么复杂，研发周期为什么那么短，其实你在设计阶段，刚才不断强调敏捷管理里面的作用，一旦需求在里面，业务流程图非常明确，业务原型有参考的意义，这样研发拿到这样的数据文档才好开发，开发的效率才会高，在简单的测试用例才不会有偏差。
需求文档设计得好，研发的效率其实会大幅度的提升，绝对不会慢，而且开发出来的东西也不会偏离场景的意图太远。这个能力因为我们核心团队人都是来自于腾讯的，腾讯内部也非常重视这个东西，腾讯的产品经理的权利是最大的，只要这个需求文档说我要做研发，基本上没有讨价还价的机会。
因为他的产品都非常的专业，会画出非常详细的业务流程，把用户的使用场景一步步的列出来，比如说正常的流程是这样子的，异常的会是什么样子，规划得非常的详细，然后研发就看就懂了，这东西就开发成这样子。业务员也觉得很详细，有参考的意义，而且看完之后不需要弄太多，所以他们的产品经理都是有非常高的权限。
接下来看一下用户场景，我们流程图出来之后就会搞一些用户故事出来，总结一些用户故事出来，用户故事就是用户的使用场景，在这个使用场景上我们去分解我们的研发任务，比如说在持续交付的流水线有哪些的使用场景，比如说第一个创建流水线，第二个维护流水线，第三个使用流水线，用户会有这三个基本的场景使用，在这个场景里可能会分解出哪些的使用场景和研发任务，我们用小卡片的方式把它列出来。
这就是我们的流水线的业务流程图，比较模糊，大家可以参考一下，这个是我们的需求流水线F056，持续交付流水线是F056，原型图是怎么样的，然后就用需求文档。
这个需求文档包含了流程图还有原型，分解完之后CTO就可以简单看一下这个功能的研发任务有多少个，这里有一些统计在里面，每天他可以看一下统计，可以根据持续交付流水线开发的进度，这是我们一些项目进度的分析，交付流水线基本上就是这样子。
接下来讲一下交付流水线里面测试是怎么做的，其实在整个持续交付流水线里面，测试是最重要的环节，在我们的EasyOps 平面，刚开始也想做单元测试、代码覆盖率这些，后面想一些这些直接体现价值的没有接口测试高。
因为在现代应用研发里，比如说它是很多微服务架构，那些服务组建接口就是它最基本的功能，只要这个接口功能响应是正常的，内部大部分的逻辑都是OK的，所以大部分的团队都非常希望写接口测试，比如说关注小写的单元测试，这个现阶段可以补上，但是现阶段马上要完成就是我们的接口测试，保证在开发过程中每一个接口都是OK的。
六、QA、Not QC！
我们EasyOps 接口测试怎么做的？我们的接口测试首先也是基于robolframe work封装，这个接口测试是全自动的，据说不需要人工干预，这个研发不需要谁接口测试用例，它是怎么做到的？
首先，它基于robolframework的封装这里会使用一些robolframe work，只要你按照这个规范去写接口，这上面是一个接口，按照那个格式来写接口注释，把这个参数写好，robolframe work的一些关键字写好，它就能够自动的把这东西生成出来，比如说它会生成这样子的，两个接口测试库就出来了。
这样只是一个库，因为它是通过代码接口生成的，通过注释生成的，没有维护测试用例的数据在里面，所以测试用例的数据是我们的研发自己维护的，比如说这个测试库上面支持测试数据，这些测试数据也是作为代码的一环回到代码库里面去的。
这里还有在开发过程里不断的迭代我们的代码，不断的做自动化的接口测试，自动化的接口测试质量也是可以去看的，比如说现在CMDB这个项目特性接口测试用例大概有多少个？它的成功率、覆盖率是怎么样的？这里有两个衡量接口的东西，第一个是你的覆盖率，第二个是你的成功率，覆盖率是什么意思？这个项目已经覆盖满了没有，接口就全部写入那个接口测试里去。
这是覆盖率。另外一个是成功率，我不断的提交我的代码，在每一次提交代码的时候他就会刷一下这个自动化测试的面板，把这一次提交他的覆盖率和成功率算出来展示给大家看。这个面板是挂在我们公司大屏上去的，所以CTO就坐在前面每天监控看的，然后他看到哪个项目说，为什么你这个成功率失败这么多？因为我们提交代码是用企业微信通知的，每一次都会发出来，或者看这个面板就知道了。
这里简单总结一下，我们的注释通过我们对robolframe work自动化的生成一个测试库，然后我们自定义我们的测试资源，测试资源就是我们的测试数据，这里有一个规范，测试库加我的测试资源就会形成一个测试用例，在这个逻辑里我们的研发只需要把注释写好，剩下来不需要关心，结果都是自动化生成的。
为什么说在EasyOps内部，测试是QA不是QC，这里重点讲一下，我们没有测试组，只有质量控制组，质量控制组的工作就是需求文档出来了，现在产品让研发和质量控制组的同学一起去开需求评审会。
需求评审会之后研发就自己分解自己的分解任务，测试去做测试用例的编写，所以他会提前参与到设计里，当需求文档一旦明确了，测试用例就可以开始了，完全不需要等研发了。随着需求在研发过程中有细微调整的话，最终开发完成之后，UI用例会被重新审查一遍，已确保和需求完全吻合。
还有一个接口测试和UI测试有成本上的考虑，我可以告诉大家整个版本所有项目的任务，一个项目资源项目大概有30多个组件，跑完所有的接口测试大概需要10分钟－15分钟左右，这里跑完所有的UI测试需要40多分钟，所以一般UI测试很少跑，只能在一个地方跑，只会在什么地方跑？
就是说你会做一个测试工程，这就是平时我们经常说的测试工程为什么会去做，我们在本地经常跑组件接口测试，基本上一分钟内跑完非常快，所以在本地开发的时候不断去跑这些接口测试保证功能是OK的。
但是UI测试在打版本的时候，比如说这个版本包含了几个特性在里面，比如说回滚的特性，持续交付流水线的特性，还有版本类型的特性都包含在里面了，所以会做比较严谨整个系统的测试。
这里有一个QA组还要提一个规范，就是我们的研发就是维护测试用例数据，但是没有规范，比如说一般的研发只会显示两个，一个是OK的，一个是失败就搞定了。
但是质量控制会规范整个开发过程，比如说这组测试要写的数据至少符合哪些场景，哪些场景这个接口必须要，接口用例数据都补充完，不然这个就是不通过的。我算一下，多少个接口？接口用例是多少个？一算我就知道你这个完不完整，这就是质量控制在定这个规范，要研发去遵守，这就是质量控制组平时工作的一环。
有一个工作就是这个东西，所以大家看到质量控制和测试人员不一样的，质量控制是做规范，定规范，然后去控制整个生产过程的质量，但是测试人员只是这个产品出来我做一下校验是可以OK而已，起码要承担更多的东西，之前我看到老王发一张图，说工程图里面薪水最高的是哪些工程师，就是说QA人员的工资是最高的，比研发还高。
##七、总 结
最后总结一下EasyOps 的实践，其实我们做更多的事情，现在没有时间做，比如说我们提交之前就做静态扫描、单元测试、代码覆盖率这些，后面也是可以提升一下我们的质量，但是现在是重要不紧急。
还有一个代码审核平台，比如说回滚功能完成后，我就直接合并到上面，没有人审核，这个东西风险也是有的，到后面可能会有代码审查，当你的功能完成之后，我们有跟开发分支部的人审查一下这个代码是不是OK的，然后才把它合并到分支上面去，因为一定要保证它是否稳定可靠才行。
第二个是用例数据的规范，QA组会定这个规则，所有的接口测试都要去覆盖。我们这边也要支持docker ，可能后面的组建会容器化，就算我们创建一个环境，功能测试环境怎么快都要10分钟，它是一个完整独立可以运行的环境。
如果用容器这方面可能会提高一点，但是在创建环境的需求平时不是很频繁，10分钟还是能接受的，因为你只是创建一下环境而已。还有降低生产维护的成本，我们现在微服务的架构上组建比较多，虽然用微服务来去做动态的变化调整，对于客户来说还是组建太多了，后面通过容器来降低生产维护的成本。
我来总结一下DevOps 基本的理念，我认为DevOps 是一种文化的精神，它是一种组织工作的方式，也是持续不断的进步，不是说一下子就能完成整个能力链条，而是慢慢在DevOps 迭代过程里慢慢把这些能力给补上来，比如说我们的自动化UI测试，自动化的接口测试，还有流水线的接入等等这些方式，后面慢慢的补上来，刚开始也是什么都没有的。
以上就是我今天分享的内容，谢谢大家！
