转型的灯塔！DevOps标准评估权威指南及案例解读

未分类

作者简介
牛晓玲，
景韵，

首先我也是非常高兴，恭喜去哪儿网和郑州银行分别通过了第二批三级能力成熟度模型的评估，这个标准可以在企业实践中起到这么大的作用，这也是我们希望看到的，也是我们当时做标准的初衷。

我今天演讲的题目是《转型的灯塔！DevOps标准认证评估权威指南及案例解读》，由我和景韵一起演讲，我演讲上半场，他演讲下半场，这也是一种创新的模式。

首先大家要思考一个问题，为什么我们要做标准？这个图是非常经典的标准图，可能出国的人必带转换插头，这个插头上涵盖各个国家的接口标准，这是一个非常经典的案例。

大家想象一下，如果所有的电子产品都有自己的接口，那我们可能出一趟门需要带多少的充电器以及数据线？如果没有统一的标准，我们的生活会变成什么样子？我们可以带着这个问题思考一下。

做标准化有五个目的。
第一，做好互联互通。
第二，做到市场开放。
第三，如果没有标准化，就没有办法做到互联互通、市场开放，包括没办法做到规模化，就是我们所说的规模经济，没办法规模化。
第四，如果不能共识，想规模化是很困难的，也没办法做到安全可靠。
第五，很重要的一点是用户选择权，用户有权利选择符合标准的东西，这是做标准的五点重要原则。

首先，标准化是大家协商一致的过程，标准有三个原则。第一个是要尽可能快，往往出现标准的地方大家可以看到，一个新的概念往往会出现标准，这是标准的原则。第二个是需要得到尽可能多的认同，国标也行，行标也好，都需要得到大家的认同，大家认这个标准才是标准化的意义和作用。第三个是在相当一段时间内有效，标准需要在一定时间内有效，起码是正确的。标准涉及多个相关方，一开始大家的意见都不统一，大家会说我们有不同的场景，有不同的应用情况，我们有不同的利益驱动，解决方案也各不相同，大家的认知水平也不尽相同。包括交流互动过程中大家的理解、表达上的误解，大家的认知都不一样。

最后的标准，就是大家协商一致的结果，你退一步，我也退一步，大家都认可这个标准。带着这些问题看一下今天的内容。

第一个，标准背景。
第二个，标准内容。
第三个，DevOps评估体系。
第四个，评估案例。

从DevOps的概念产生一直到后续的发展，包括敏捷开发管理、持续交付、微服务架构、安全等等，它经历了最快的发展九年。这张图是借用DevOps一位大师演讲的PPT内容。可以看到这九年它发展得非常快，正因为最开始没有给DevOps下一个严谨的定义，造成DevOps的发展现在涵盖了越来越多的内容，发展趋势也非常好。

我们现在都在说DevOps，但真正的DevOps实施成什么样了？就像这张图表达的感受一样，大家都在暴风骤雨的黑夜里摸索着前行，大家都不知道方向，这是共同的痛点。

我们做DevOps的转型和落地，要先弄清楚七个问题。

第一个，DevOps到底长什么样子？其实我们做DevOps的标准，是为了让大家清楚看见DevOps的全貌到底是怎样的，它的起点和终点的每一部分到底在哪，DevOps应该长什么样？

第二个，DevOps真的有用吗？我们做这个标准，就是为了有一个参考的路线。

第三个，DevOps是否真的对我有用？大家回头也可以看一下我们的系列标准，从中找到答案。

第四个，DevOps的常见路线图。本来前面已经有路了，我们还在摸着石头过河。为什么这么说？其实大家应该看到了，别人已经开始做标准了，我还在摸着石头过河，为什么不看看别人的标准是怎么做的呢？

第五个，我在哪？我做的如何？同样，DevOps标准能给你一个解答，告诉你定位的位置在哪里，包括你在全行业是什么水平。正好DevOps的系列标准是成熟度模型，能够清楚告诉你自己在什么位置。

第六个，我做什么才能变得更好？整个DevOps标准的能力成熟度模型可以告诉你后续的改进方向，包括我们往哪个方向改进，这是标准的特色。

第七个，我要用什么工具？大家可能会问这样的问题，因为DevOps很重要的一部分就是工具。同样，这个标准也给了你解答。目前第八部分的系统和工具，就在讲工具这件事情。

再看一下研发运营一体化能力成熟度模型的架构。框架分为五个大的部分。

第一部分，研发运营一体化（DevOps）过程。第一类是敏捷开发管理，第二类是持续交付，第三类是技术运营。这是整个DevOps的第一个大部分，是过程域。
第二部分，应用设计。
第三部分，安全及风险管理。
第四部分，组织结构。
第五部分，系统和工具。大家也可以看到我刚才说到的系统和工具部分，

目前最为成熟的是DevOps核心的工程实践，就是持续交付的部分，目前这部分是最成熟的。这个标准的主管单位是工信部中国信息通信研究院，也就是我所在的单位，它是国家级智库，是可信云出品单位，是国家标准化单位。这个标准的联合发起单位是高效运维社区、BATJ，起草单位包括移动、电信等等，有很多企业参与。目前的进展，去年6月29日我们有一个征求意见稿的首次发布，在去年的7月20日左右已经在ITU正式立项了。

这是我们单位的具体情况，我们单位是工信部下直属的科研型事业单位，对标。DevOps标准的顾问团由何宝宏博士担任组长，John Willis是能力成熟度模型的全球顾问，是《DevOps Handbooks》的作者。

这是我们的参与单位，包括谷歌、BAT、银行、保险、华为、中兴、证券、金融等等。

这张照片是是在去年的7月26日，其实提前十几天我就过去了，当时有20多个国家的大概190多名代表参与了这次会议，我作为中国信息通信研究院的代表，我是代表工信部过去进行立项的。当时也是经过了两周的努力，包括修改了七八个版本的立项文件，包括跟国内专家远程连线讨论，经历了一个艰苦的过程，但最终的结果是好的，我们正式立项成功。如果您的企业在ITU也是会员的话，其实可以在网上查到，有一个在研标准。

说回到国内标准，我们国内标准也是以PDCA为内核的，是非静态的标准，以互联网的思维驱动和行业实践来做。因为现在的DevOps和AIOps发展得非常快，我们的标准也不是一成不变的，我们会以小迭代的方式让标准跑起来，更加适合大部分行业的应用，尽可能完善这个标准。

可以看到这个标准的安全性风险管理、组织结构情况。刚才说到现在最成熟的是核心实践，就是持续交付部分。持续交付包括七大域，包括配置管理、构建持续集成、测试、部署发布管理、环境、数据管理、度量与反馈，底下分很多细的项，这七个大域分下来，大概有49个子项，每一个项都是一级到五级的评估维度。

第一级，初始级，这些企业可能在局部范围内才开始尝试DevOps。第二级，在较大范围内推行，并且有一点实践。第三级，全面推行并贯穿整个生命周期，获得整体的效率提升。就像刚刚说到的郑州银行和去哪儿网等等，之前有通过很多企业，其实三级是现在国内比较领先的水平。第四级，这是现在最领先的水平，可以说是顶级的水平。第五级，现在没有人达到，我们也在持续优化当中。

大家可能好奇怎么进行评估？首先需要研读细节标准，有八个部分。我们研读需要评估的部分，然后会有一些自评材料的提交，这个材料大概是将近两百份的文件。自评材料交后有现场评估，采用创新方式评估，除了研究院专家外，还会结合业界顶级技术专家参与评估。再往后会由双方专家出具改进方案，我们会出具评估报告，大概是130-140页左右。最后还有外部专家评审，会邀请企业资深的专家，基本工作经验都在15-20年以上。最后你会获得评级证书，包括大会的授牌。

这是我刚才提到的自评表，我们会在评估前发出自评表，这里面有五级，可以大概对标自己在什么位置，企业可以自行评估。

这是评估方法，就是刚才说到的，我们去现场评估的时候会有一份评估方法，专家会依次根据评估方法来做，比如有人员访谈、材料审查，再比如模拟演示，需要演示什么实践，我们都会进行详细评估，包括我们会有一些详细的记录。

比如三级的时候，会考察你是否建立了标准化的构建体系，比如构建化模块定义和接口信息。四级可能会增加一些模拟演示，除了上面的之外，还有更高的要求。可以对比三级和四级，会有一些更高的要求，包括四级要看当前构建职责的负责人，你所在的团队，你构建的设计方案，还有自助化使用的指导手册，包括我们还希望你演示。比如演示场景化构建编排、可视化构建过程及功能等等。这是我刚才说到的人员访谈、材料审查、模拟演示相结合的方式，是实操型的，不是只看材料，只看材料是看不到企业痛点的。

这个也是非常有意思的部分，通过评估以后，前面说到的是持续交付的部分，后面分了49个子项。从表格中可以清晰看到，比如公司A，得分最高的达到75分，最低的是42分，它可以明显知道自己的优势和短板在什么位置，很清晰地把自己的短板展示出来。公司B可能配管达到45分，但环境达到80分，我们可以明显看到需要改进的地方在哪儿，一见了然。

最后有一个非常好的特点，也是能帮助到企业的地方，就是专家改进建议。这个非常详细，包括每一个子的能力项，包括分支、变更过程、环境类型和环境构建，专家会根据公司具体情况提出定制化改进建议，这个建议不是通用的，每家的情况都不一样，我们的建议都是定制化的，建议也非常详细实用，这是很有意思的一点。

这是我们之前评估的第一批企业，包括中国移动浙江公司、中国银行软件中心、腾讯IEG、招商银行的四个项目、广东移动、北京移动，都通过了三级评估。腾讯是唯一一个通过四级的互联网企业。第二批的结果公布是去哪儿网和郑州银行。去哪儿网通过的是酒店订单系统，郑州银行通过的是新一代的核心业务系统，非常恭喜这两家单位。

接下来由景韵介绍第四部分，一些实际案例的分享。

景韵：非常高兴今天可以代表我们的评估师团队跟大家分享这次的评估案例。目前通过评估的企业一共有8家，项目有12个，我们总结出很多有意思的事情想跟大家做分享。在这里我们可以看到“332”，这个代表目前参与标准评估的企业类型。有3家是通信企业，浙江移动、广东移动、北京移动；3家是金融企业，中国银行、招商银行、郑州银行；还有2家互联网企业，一家是腾讯，另一家是去哪儿网。

看一下具体通过评估获得了什么样的有意思的信息。我刚刚看到大家拿了很多书进来，我们准备发书。大家觉得在持续交付的七个能力项当中，哪个能力项是平均能力最强的？

第一，配置管理。主要指源代码管理、变更，比如需求缺陷。
第二，持续构建。主要是CI维度，跟智能化构建相关。
第三，测试策略。自动化测试和测试数据管理。
第四，部署与发布。具体指自动化部署和流水线相关能力。
第五，度量与反馈。核心是度量指标体系，包括度量做的改进。
第六，数据管理。重点指在线SQL变更。
第七，环境管理。

大家觉得能力最强的是哪个？大家都猜错了，没机会了。大家猜猜能力最弱的是哪个？大家又猜错了。

首先是环境管理，构建与持续集成是相对来讲能力比较强的，然后是部署发布管理、度量与反馈、配置管理、测试管理、数据管理。实际数据管理和测试管理都属于常见弱项，一会儿我们会详细分析具体原因。

环境管理为什么强？至少目前来说参与评估的企业当中，大部分或基本都没有上云的情况，很多即便没有在生产中使用，在很多其他环境都开始应用了。除了常见的云技术外，还有容器化技术。另外是基础设施及代码，已经定义好了基础设施长什么样子，也有用虚拟机镜像方式标准化基础环境的。

弱项是比较常见的，现场是运维的同学举个手，看来今天的运维同学是弱势群体。我们大部分资源还是在运维部门这边，当我们需要测试环境时，这是比较长的审批流程和资源提供流程，甚至很多时候提供裸服务器，剩下的一切都不管，所以很多时候把测试逼成了做运维的同学。我们之前有家公司的运维总监是测试出身的，因为每天翻来覆去装机器，后来装成了运维。

构建与持续集成，现在很少有通过手机打包情况来做的，但做移动APP的同学要注意，依然有很多同学导包对外发布，这个不够安全。包括本地环境的问题，相信大家都听说过。因为伟大的防火墙从外网下不来包，但国内的可能是别人植入后上传的，你打出来的所有东西都有这个后门，很恐怖，所以自动化构建是一定要做的。得益于Jenkins的深度应用，今天大家也听到了Jenkins创始人KK他们的演讲，至少在2017年的调研数据里，国内85%的企业都是使用Jenkins来做的，国际上目前解决方案越来越多，但Jenkins的使用也是非常普及的。顺便也给大家做个广告，在7月5日到6日，主办方在北京的会议中，会重点请国外专家，就是KK的同事，给大家讲JenkinsX究竟怎样在生产级别使用，它已经不类似于玩具了，在很多生产场景都会使用。

还有服务化的CDaaS，我们之前有一次机会去荷兰的一家银行跟他们交流，他们内部持续交付的平台就叫CDaaS（5/8），大家猜猜这个5除8是什么意思？一共是8家企业，其中有5家都是自研，要么是全部自研，要么是基于开源工具的封装来做。

部署与发布当中，自动化部署是强项，比如Python脚本，大家都在做这种部署。这里面的弱项是制约着我们往前进步的点。第一个，做环境部署的时候，这里面的数据不完全是参评企业的情况，更多是之前交流的情况。在不同环境部署时，部署过程不一致。业务代码在测试环境都有，但部署过程、部署工具没有经过测试验证。测试了包之后不应该改，应该直接生产上线，做一些参数化配置，但上生产的部署不一样，这对部署结果会起到比较大的影响。第二个，安全和测试内嵌到部署过程。安全问题大家都比较熟悉，需不需要对包的安全进行更多扫描，部署出来之后甚至也会有一些安全问题，一会儿会提其他的一些考量。

还有测试内嵌到部署过程，这是目前比较争议的点，我们也可以做一个调研，在生产环境下部署之后引入业务型的自动化冒烟测试，就是部署之后通过自动化方式去跑，跑的类似于接口测试或者说UI测试，但跑的内容是属于业务型的，不仅仅是测断口、进程是否起来了，而是要看业务能否跑通。比如刚刚刘婷老师讲的，几个核心的业务流程是否能跑通？在生产环节下部署结束直接做这个事情，反对的同学举手。那剩下的都是支持的同学了，那我可以写入标准了。

大家都说希望能把测试更多在生产环境下得到应用，很多时候部署之后才做邮件通知或者打电话，让业务人员做手工验证。很多时候没有引入汇入机制，应用已经暴露给了用户，用户已经在APP上看到功能有问题，这时候可以尝试用智能化方式解决，这个问题不深入展开，有兴趣可以台下交流。

度量与反馈。度量体系是目前大家做的不错的，可以针对自己的情况做识别，引入一些度量指标，但做的不好的点是跨领域指标，指标过于单一，只是开发、测试、运维指标，没有横跨几个角色的指标。目前来讲大部分参评企业都有自己的DevOps度量平台，要么是自研，要么是基于BI工具，也有基于刘婷项目里介绍到的普罗米修斯这种方式，也可以解决当前度量的需求。

我们也希望基于度量做决策支持，刘婷刚刚也讲了一个案例，有一个同学一天提交了两次三百行的代码，不知道大家自己做开发的时候是不是这么高产，这是我们让大家按照天提交代码的决策，你跟他一沟通就知道问题有哪些。

配制管理。版本控制、统一变更管理大家肯定做到。我跟大家简单解释一下统一变更管理，它指的是在提交代码的时候，我们一定要关联变更，也就是需求或者缺陷，如果不关联就不应该修改代码。因为很多时候开发同学会有加代码的现象，把不应该跟着需求上的代码都加上去，这样会明白无故出现一些问题。我看网上很多同学做了Gitcook，说非工作时间不允许提交代码，这个实现机制跟做统一变更管理一样，提交代码的时候一定要校验。

测试管理这边，代码质量和SonarQube大家肯定在做，但很多时候用的是默认规则，不做裁减，开发同学很多时候比较抵触，做的规则团队实现不了，或者有其他问题。弱项是能把测试集成到流水线，还有单元测试的程度不足，这是比较常见的问题，跟投入产出比有关。还有一个是自动化测试误报率，很多时候最尴尬的是，做了这么多测试，会变成了“狼来了”的现象。做运维的同学可能都熟悉，到一定阶段最后撑不住一宕机，重启之后会拼命给你发报警邮件，那时候你应该立马把它注销，这个邮箱就再也不会给你发邮件了。

数据管理。强项是测试数据来源。上午也有嘉宾提到，目前来讲只有去哪儿网有一个很好的数据，而且也有一个企业目前仍然是手工变更，真的非常恐怖。

我们问一下七个问题，DevOps的标准评估结果，到底有哪些是我们可以思考的点？
第一个，参评企业中最常见的问题有哪些？
第二个，参评企业在重点投入建设的平台是什么？
第三个，有哪些优秀实践值得借鉴？
第四个，有哪些度量指标值得借鉴？
第五个，弱项能力是什么？
第五个，管理模式是否兼容？
第六个，DevOps平台应该怎么建设？
第七个，相关领域？

DevOps领域重点建设的平台和工具你认为是什么？我们讲的是持续交付评估，一般不做监控，会放在技术运营的标准中。

第一个，基于发布窗口的开发模式，标准定义是版本火车，只能在那个时间点上线，很多时候提出之后会明确规划属于哪个发布窗口，周期一般来说比较长。这种模式会给我们带来一些小问题，并行开发情况比较严重，在分支策略上也有影响，会有很多并行分支做开发，而且都是活跃状态，所以有很多开发同学会在两个分支间来回切换。可能也是因为行业原因，我很难以想象为什么团队不能集中精力先解决高危险需求，再解决下面的需求，而是要同时处理很多需求？这和我们做敏捷的思路不太一致。刚刚刘婷老师的PPT也讲到，会深度做敏捷开发管理的事情，相信这个对我们解决并行开发的问题会有帮助，关键的点是基于规划的方式来做，并没有小迭代，或者说把需求拆小，我们依然定义大需求，落到具体的窗口里，这会影响到分支策略，也会影响发版发包的情况。

第二个，自动化测试体系不健全。这个怎么结合企业？我们要哪些东西？团队的UI经常变，但依然做UI测试，而且投入很多，这是我们认为得不偿失的地方。用例积累不够，这是需要花时间解决的问题，没有长时间的用例积累，很难做到测试维度的高度自动化。像在之前的公司里，大家积累了很长时间，积累了上万条用例，虽然是UI测试，相对来说UI也不强变化，可以对质量进行很好的保障，如果没有这部分，其实是难以继续往下推动的。而且也有误报率高的情况，之前有些团队是10%以上的误报，会让很多同学的工作难以推进。

第三个，工具链分散，缺少平台化。

第四个，流水线的质量内建不足。刚刚也提到，很多时候不把自动化测试放到流水线平台当中，不仅仅是功能性的，还有非功能性的问题，所以刚刚举手的运维同学，我们可以把运维很多能力嵌入进来，包括安全测试相关的，希望把非功能测试能力嵌入进来，不再是提需求单，我们希望服务能力能嵌入到流水线服务开发。

第五个，度量问题，驱动改进能力弱。度量很多时候只是给老板看的，不是给普通的同事看，所以同事们感知不到当前质量和进度的问题。

第六个，这是我们最新识别出来的需要大家关心的话题。虽然我们在项目维度可以做到三级能力，但到处置级能力的鸿沟巨大。我们定义出很好的代码质量规范，能不能在处置期推进？现在有一套工具链，能不能适配不同团队、不同技术站的不同需求？这是我们需要解决的问题，在这之间我们有鸿沟，就是从项目级到组织级能力。我们之前并没有开放DevOps组织级能力评测，我们有一个共识，当前DevOps在国内处在相对早期阶段，很多企业还在观望，领先者已经开始实施了，这时候提组织级能力为时过早。

第七个，这是老生常谈的问题，组织隔离。我曾经以为金融企业是一步两中心或者一步三中心就是很严重的隔离行为了，后来我发现前面还有需求中心，这是非常复杂的一套管理方式，会让组织隔离严重。尤其很多时候老板不是一个人，组织隔离的状态更加严重。

重点投入平台是流水线平台，刚刚提过，大部分企业都有流水线平台，因为要打通开发测试到运维之间，这是非常关键的技术要解决，是非常重要的平台要建立。比如我是测试部门，希望把质量贯彻到前面的研发侧，也希望贯彻到后面，只能依托DevOps的流水线平台。

另外，我们不会强求把组织打通，开发做的挺好，自动化工具做的挺好，部署工具做的挺好，一定要合并组织才能做吗？不是这样的，我们可以通过流水线平台把相应能力嵌入到流水线里，实现打通的过程，要不然部署能力永远在运维这一侧，需要把包给运维，运维通过他的方式部署，这个释放不了部署能力。

为什么大家要做这个事情？

第一个，固化实践。现在一些安全扫描的，还有分支策略，我们公司统一要求分支策略就一种，不希望每个开发团队自己定义内容，通过流水线平台把相应东西固化进去，包括流水线需要具备什么步骤。

第二个，端到端，这是现在遇到的问题，不一定是目标，但我会给大家一个推荐。如果流水线能尽量延伸，可以延伸到生产环境，直接部署到线上，但对网络隔离和生产隔离的同学来说困难。

第三个，没有覆盖到需求和任务。做开发的同学，最痛苦的就是要从IDE出去，要回复别的同学的消息，要避出字段。

看过类似的这张图的同学举个手。这是有一家银行之前的一个演讲，描述了他们公司流水线的质量门，我们管它叫DevOps流水线16个特性。这里面有一个段子，这是一个印度的同学，说他们公司有16个质量门，我们数来数去只有15个，我一度怀疑我小学是体育老师教的，后来我们讨论之后加了一个，大家猜猜哪个是国内社区专家加进去的？较高接口测试覆盖率。因为上面的80%以上单元测试覆盖率，我们认为这个投入产出比不太成正比。

我给大家解释一下，蓝色部分是目前更多企业做的不错的地方。版本控制，大家肯定都要纳入流水线来做，分支策略没有最好，只有最适合自己的。虽然我们会推崇一些分支策略方式，但基于业务模式和开发同学的能力，我们会做一些选择。代码静态扫描，这个大家都加进去了。80%以上单元测试覆盖率，这个我标的绿色，这是大部分团队难以实现的。漏洞扫描相对是做的比较少的，但很多金融行业都在做，我们会在这个过程中用安全工具进行扫描，目前有不少企业在做，但一般来讲安全扫描漏洞工具都是收费的，而且据说是以色列的工具为主。制品管理都有，我们曾经也见过一家企业，他们完全是自己写的制品管理系统，没有问题，只要能实现制品的过程。开源工具扫描比较少见到，可能跟企业的性质相关，内部使用的时候，可能不太在意开源合规的问题，但当我们的软件需要对外销售的时候，大家一定要注意开源合规的问题，这是一个巨大的风险。环境自动化创建，这个国内用的也比较少，大部分时候直接部署到指定环境。还有不可变基础设施、集成测试，性能测试也比较少。自动化变更请求，会通过流水线跟系统对接，尽量减少手工和线下流转过程。功能开关，这个基本属于比较少用的，有的同学很喜欢功能开关的方式调整在线的应用，因为很多应用配置管理就是解决这个问题的。较高接口测试覆盖率，这是普遍都在做的事情。零停机发布，这是最重要的一条。在整个流水线里面，我们希望每次提交都能触发构建、部署、自动化测试。部署我们做不到，我们不需要每次部署都要提高生产环境，因为没办法按特性发布，我们希望泛泛构建，指编译单元测试和代码扫描的过程。自动化测试在提交的时候如果能引入service测试，也是非常好的事情。

这是DevOps平台里建设流水线的时候，要看这些点是不是都有，或者看哪些点值得参考借鉴。

后面是优秀实践，再给大家讲一下。我也标注了企业名称。

第一个是腾讯的全流程质量红线。大家都知道质量门禁，但腾讯这边有全流程的质量红线，在自动化测试阶段，在部署和开发过程当中，都会设置这样的红线保证质量，不仅仅是在代码维度。第二个是质量问题自动上报缺陷。腾讯内部有很多代码扫描的系统，扫描出来问题后会直接提交到缺陷系统中，你的扫描一定要非常准确，包括测试相关的。第三个，上午也有嘉宾提到，招行这边有非常完善的度量体系，他们经历过很长时间的积累，从传统的项目管理到敏捷项目，都有度量体系，而且指标很完整。当时在现场做评估的时候他们还在进行尝试，如果大家想了解他们在尝试什么，可以私下问我，这是基于度量的更高级的分析。第四个是数据库自动化变更，去哪儿网的Github上是有的，大家可以尝试一下，这里面包含变更的审计、流程，甚至还有模式，什么样的语句更符合标准化的要求，这些都有。第五个是单元测试的自动化生成器，这是基于自然语言处理的方式，基于当前案例的方式自动化生成，这个非常困难，但也不是全量，只是大框。第六个，刚刚郑州银行也有讲到他们度量指标的质量预警线，比如当构建时长超出了设定的阈值情况就会报警，比如最近有人动了构建环境，导致构建时间变长，这些都是非常好的实践。

度量维度有几个指标，跟大家简单说说，因为指标实在太多。

第一个，需求在各个阶段的停留时长，有效分析不同阶段的等待时间，看我们到底在哪个阶段，平均下来是什么样的时间长度。理论来讲开发阶段的时长越长越好，我们就有更多时间解决需求问题。我们之前在内部做工程效率改进的时候有一个一致共识，今天做这么多事情，要服务的就是开发同学，让我们的开发同学尽量以更简单的方式专注于开发他们的特性代码。说白了我们成天写测试，在这写脚本也好，搭建各种系统也好，不会对公司业务直接产生更好的促进业务，都是为了让研发的时间周期和效率质量更高。

第二个，缺陷逃逸率。刚刚郑州银行的老师也有讲到，他们这个层面有30%的提升。缺陷逃逸率是明显的跨领域指标，一方面叫缺陷逃逸率，一方面叫缺陷泄露。在这个版本当中的生产缺陷除以研发缺陷，这个比率代表有哪些缺陷是真正被客户发现的问题，这才是真正严重的问题，要用缺陷方式衡量一些质量层面的问题。

第三个，自动化测试误报率我刚刚也有提到，用误报的失败用例除以整体的失败用例数，判断自动化测试工具是否稳定完善。因为构建环境、测试数据和测试环境的问题，少量是因为业务代码的问题。

第四个，债务指标，这个大家都关注，相当于是具体的重复率指标。

第五个，可以做个简单分类，从我们把代码提交之后部署到线上，然后是部署频率，我们是什么频率在进行部署？还有稳定性这边，变更的失败率和MTTR，我这次专门把详细公式给大家写出来了。第一个是MTTI，我们发现了生产有问题。第二个是MTTK，我们知道了原因。第三个是MTTF，花了多长时间修复它。第四个是MTTV，要花时间验证生产修复。这几个维度的每一个时间都要尽量降低。

光说指标大家可能没有感受，我抽了几个数据，可能不一定非常高，至少可以有一定代表性。第一个，需求交付周期。这里面有很多企业可以缩短到一个月，需求已经提出来了，做过需求，交付给开发，在一个月之内可以上线，对很多企业来说这依然是巨大挑战。第二个，流水线数量超过10000+，这到底是什么规模？可以考虑我们自己是什么情况，上午也有嘉宾讲过这方面。第三个，自动化接口用例10000+。今天我们列了很多指标，依然是冰山一角，度量是非常庞大的体系，如果津津有度量指标也不好使，怎么去实现，包括有多少系统，怎么去抽取，具体用什么平台做分析和展示？有很多可以挖掘的。

包括有很多同学跟我说，很多企业有一些实践，我们可以做统计和分析，驱动大家更多去review这些内容，这都是我们的解决方式。

弱项就快速过了，刚刚反复给大家提到的，测试和数据库变更是核心的弱能力。测试策略不完善，这个是比较常见的过程，包括单测、非功能测试引入。很多时候测试仅仅在关注功能，没有相对完整的测试体系。测试数据这个维度，目前标准定义有三种选择。第一个，基于生产环境的脱敏。这是比较常见的，现场有做测试的同学吗？你们当中有基于生产环境脱敏数据的举个手。还是有几位的。第二个，基于手工构造，就是基于对业务模式的了解写的手工数据。第三个，基于API的自动化生成，按跑批方式来做。

数据库变更刚刚提过了。

兼容性的问题，我们也做了一些想法和思考。

首先，DevOps和ITTL兼容吗？觉得不兼容的举个手，麻烦给这位勇敢的同学送个小礼物。我们理解DevOps和ITTL有兼容性，运维这边依然是维稳的状态，依然需要ITTL的思路解决具体问题，所以很多同学会有裁减过的管理方式。为什么我们认为兼容？主要是通过评估角度发现问题。第一个是开发、测试和运维当中的流程，相对来说可以实现自动化，而且是穿透的方式，比如刚刚说的自动化的生产环境的变更。第二个是环境，原来企业会填ITTL的申请单申请各种资源，现在大部分情况下可以自由分配资源，不是说每次一台机器都要经过很长的审批流程。

第二，DevOps和外包开发模式/项目管理兼容吗？很多企业，尤其是联动依托于外包甲方的企业，为什么要做DevOps？这里面有一个很大的考量点，希望通过DevOps把甲乙方的协作模式更顺畅。第一个是协同转型，在广东移动去年底评估的案例可以看到，外包团队和甲方企业是非常好的协作模式，大家在协调做转型，可以采用敏捷方式管理整个开发过程。第二个是工程能力统一，甲方提供全套DevOps流水线和工具平台，大家按照规则、规范和质量要求来工作，这时候大家是在同一个尺度工作的，流水线用我们的，开发环境也用我们的，甚至很多企业有云桌面规范开发环境，甚至把常见的包都拉下来，你可以直接把工具放上来。第三个是统一部署工具和过程，比较常见。第四个，前两天跟广东移动的老师沟通，大家发现了一些很好的案例，当产品交付的模式下怎样做外包模式和DevOps的衔接？可以把两个企业间的流水线对接起来，关键的对接点一般以制品为主。经过内部严格的流水线，制品可通过一定机制推送到甲方企业，甲方企业再走他的流水线进行验证，而不是传统的移交和签收。第五个是项目管理三角形，之前有同学跟我说他们要做敏捷，老板问是不是做了敏捷就可以变快，开发团队可以处理更多的需求？我个人理解项目管理的三角形永远存在，我们的范围、成本、时间、质量依然需要考量，很多时候做了敏捷不是变快，关键是在相同容量情况下可以交付更有价值的内容。我曾经也见过需求经理给了开发100页的word文档，这个怎么做？我们之前的开发计划都是按照好几个月来做的，这个没有任何弹性存在，我的个人观点是它不会变快，吞吐量也不会变大，更多是我们可以交付更有价值的内容，而且是高质量的过程。

保障方面，DevOps是你的DevOps吗？希望在座同学一定要重视这一点，不要把你的DevOps平台当成边缘系统和玩具对待，它一定是核心的生产系统，包括我们前两天跟一些企业同学沟通，像代码管理、集成服务，都是生产级别的，甚至比生产级别更高，因为一旦宕掉，整个企业会停止运转。之前出现过缺陷系统宕机，偏偏我们处在集成后期，大家都在解决缺陷，这时候查不了缺陷，提交不了代码，所有的开发同学就在内网开始骂人，相信很多同学都经历过这种场景，所以标准会明确要求，DevOps的相关工具一定要有完善的运维规范和要求。像腾讯，他们内部是有专业的运维同学负责保障的。

DevOps工具平台建设的三个核心阶段，有一些专家给了我反馈，在什么场景下应该建设什么平台。我个人建议从无到有的情况下，独立工具是更好的模式，这只是我的个人想法。因为从我的角度，我更推崇专业化工具解决专业化问题，而不是大一统平台解决全量化问题，国内很多平台都喜欢一揽子解决方案，分好几期，这会带来很多适配性的问题，包括我之前的企业做ERP软件，一个项目做三年，验收不行，再看一个项目做三年。所以从无到有的时候，独立工具是比较好的解决专有问题的方式。

当有了很多工具，会变得很复杂，从繁到简的情况，可以把内容封装起来降低复杂度，因为开源工具最致命的问题就是过于灵活，功能过于强大，导致使命成本过高。Jenkins里面有一个功能，但我从来没有用过，我一直用freestyle的方式来做。从繁到简有几个思路，第一个是同一个界面来操作，不需要让所有同学重新创建。也有思路是从度量入手的，工具分散，度量统一，当我们从繁到简以后要从小到大，会有这种场景存在，很多参评的企业中有两家是完全替代Jenkins做自研工具的，很多时候没办法满足。

这个图大家看得很多，是DevOps建设平台时可以参考的，现在写的第八部分的标准，叫系统工具。我认为这是顶级的，在全球都可以排上名。国内顶级的工具团队、工具厂商包括甲方很多企业，都在参与这个标准，这不仅仅是写给厂商用的，更多是给企业内部建设DevOps平台的，这个标准是开源的，在Github上可以看到。

思考一，运维如何参与？因为我们今天是全球运维大会，虽然我们是从做运维角度来做这个事情，从我的角度运维应该怎么参与？这也是我之前回答一些朋友问题时总结下来的。第一步，一定要参与研发自动化部署与发布工具与灰度机制的建设。这是我们的强项，如果部署被研发和测试团队拿走了，你做运维的路就到头了。第二步，将安全和非功能测试能力嵌入到流水线。第三步，为测试团队提供比较好的方式，提供脱敏生产数据。第四步，希望不仅仅是提供环境和机器，希望能提供更多的服务，让开发测试同学直接使用机器资源完成自动化部署的过程。第五步，业务可靠和连续性重点投入。

上午刘扬清提过一句话，在生产环境理性引入一些故障，在技术运营的标准中大家可以看到，这是开放出来的，来业务连续性里明确可以提出，要主动往生产环境引入故障校验。现在大部分企业的生产环境应对跑在云服务上，云服务对你们而言是黑盒，不像到裸机，所有一系列的东西都可以排查，需要靠这套模式验证云服务的可靠性。第五步，转变子维稳的方式。第六步，这不是标准的要求，但我可以跟大家分析一下。

当前的标准提出如果按照四级应该长什么样子？这是我们的目标。第一个是每天可按需多次发布上线，上线由开发团队完成，把部署权限和能力交给团队。变更失败率低于10%，如果一年只有12次窗口，那就没什么可说的了。还有高度全面的自动服务化和平台化能力。如果想在持续交付里达到四级，开发管理和技术运营两部分都需要做到很好的维度，这就是在DevOps更好层面的全链路过程。

之前阿里发过一篇文章讲他们的“211”，讲阿里部分企业80%的场景可以实现需求两周之内交付上线，一周之内开发完成。一个小时指的是变更前置时间，代码提交之后一个小时就可以上线。

这就是我们今天所有的内容。DevOps的标准是座灯塔，它不是强制说必须要停靠到这个港湾，是引导我们的，是方向性的内容，更多是指引我们的前进方向。