基于 MVP 原则构建 DevOps 体系

未分类

大家好，很高兴今天可以在这里跟大家分享，今天也有将近两个多小时的分享，非常辛苦，接下来我准备用比较轻松的方式跟大家讲一些段子，讲段子之前

王晓翔，前Qunar工程效率总监

我先做一下自我介绍，我是王晓翔，是前去哪儿的工程效率部总监，之所以说前去哪儿就因为我在3月份刚刚离开了去哪儿，我是2013年入职去哪儿，当时是配置管理组的第二位员工，在我三月份离开的时候，这个配管组其实已经更名为研发教育部，是隶属于平台事业部的二级部门，是直接汇报给公司CEO的，认识我的很多朋友也对我的离开表示不太理解，就是各种猜测，最后说估计我是财务自由的，说实话这个跟钱没有半毛钱关系，说白了我是财商为零的人，但是作为社会人放弃高薪其实是需要勇气的，在这里透露一下去哪儿的薪水不错，大家如果有想法可以试一试。

这个勇气从哪里带的？两方面，第一就是我在去哪儿7年一直做工程效率相关的事，那在比较漫长的时候里面，我觉得自己做的这些事不仅给企业的功能效率带来很大的提升，自己也带领团队完成从传统的配管到DevOps的转型，自己的综合能力也得到很大的提升，去哪儿是第二批参加DevOps能力成熟度模型评估的，而且是一次通过三级的认证，当时校方组（音）参加我们的评估过程，说了一句话我们很开心，说你们这就是学霸来考试，不带提前准备的。

说实话我确实是没有去让项目组提前准备特别多的资料，因为我们平时就是那么做的，然后也是在DevOps模型出来之后我一直也参照那个模型去做不断的优化和改进，所以这一点我觉得还是比较骄傲的一个地方。

另外一个方面我在过去一年多次参加大会的分享，我发现不少企业虽然现在看到模型之后觉得这个东西如果能够落地是很好的，但是站在转型的路口不知道怎么迈出第一步，所以最终确定离开培养了我很多的去哪儿，走出去希望能给到更多的企业一些帮助。在这里因为有很多原来的同事也有说要过来听直播的，这次疫情对旅行行业的冲击比较大，我在这里也祝福去哪儿，和我的同事们能够扛住压力，共度难关，去哪儿的明天会更好。

言归正传，前面做了很多自我介绍，我今天带给大家分享的题目是基于MVP原则构建DevOps体系，今天分享的内容大概是从四个方面：

• DevOps建设面临的挑战
• 在这些挑战面前如何找到突破口
• MVP是如何助力DevOps建设？我会在这里重点分享我在去哪儿落地DevOps的过程中结合MVP的方式是怎么落地的
• 最后是毕生所学的集成了两张PPT，所以大家一定要坚持到最后。

一、DevOps 建设面临的挑战

首先看一下挑战，回到DevOps的价值来讲，很多人在想DevOps是什么，DevOps怎么做？其实我们要重新回到DevOps本身的价值来看，我们为什么要做DevOps？其实它的核心价值跟我们所谓的精益敏捷是一致的，都是要实现企业从一个主意到用户之间能够有快速的交付、按需交付，需要交付的东西是可靠，这里面提到一个又要速度又要质量，而且我们还希望从中获得一个反馈形成闭环，所以我们做DevOps其实服务的是企业的业务目标，这个大家一定要记住，因为只有知道我们为什么出发，我们才不会走得太偏。

那么我们做这个事情的时候面临的挑战有四个方面，每个方面展开都会特别多，第一个本身DevOps的体系是非常复杂的，大家在很多大会中也好包括雷老师最后的PPT也分析了模型的复杂性，也就是说这个体系的复杂性从覆盖的技术面和公司影响到的人群来说都是非常大，那这样复杂的体系我们如何找到那个点，其实还是挺难的。

第二个来自于企业文化，因为很多人说DevOps是一种文化的运动，需要先从组织结构的调整开始，因为没有组织结构调整我们永远打破不了那堵墙。上周有一个朋友跟我说他想写DevOps实践的分享，是不是可以把原话的东西放在里面，因为你知道一个PPT里面一堵墙就穿过了但是落地的时候你知道有多难吗？所以这个是我们需要克服的点。

第三是团队的能力，我们在实践的时候会发现DevOps是流程、规范、工具三维一体才能真正落地，那如果原有的团队不具备这种能力怎么做自动化？所以这个时候团队的能力就会变成实行的短板。

第四个点就是成本收益，这个地方就是说我们一个企业回归到商业的本质来讲，企业一定要盈利，所以我们不是在搞科研，不是要把DevOps达到一个世界的先进水平或者国内的先进水平，我们一定要回归到服务企业的商业目标，那必然逃不了在这个事投入多少成本，能够真正给企业带来什么收益，虽然有时候在企业内部立一个OKR，很快会被挑战的是你的IOI是怎样的，一开始自己很不舒服，我做那么多事，你为什么总是觉得我这个事不值得做，其实后来我转变思路之后我觉得这是很好考量这个事本身价值的度量方式，所以怎样考量自己的投入成本和拿到的收益这个也是非常重要的点。

从这四个点来说，我列了一个体系的模型，涉及到体系的复杂度，那从纵向来看，不光是涉及到整个过程，包括从需求阶段的开发，还有整个开发的持续交付阶段，以及上线之后的运营阶段，可能现阶段聊的还是仅限于持续交付，或者原的项目管理做敏捷的事，基于运营这一块，还是相对被弱化的。

除了这个过程我们还有三层，第一是框架，就是单纯运用还是微服务，现在也有（英文）的技术也不断涌现，再过一年可能我们也会涌现新的技术架构。

另外在跑得快又要去快速交付还要按需交付的时候其实我们必然要考虑安不安全的问题，尤其是这两年做转型的有很多是金融，还有国企，那么他们在安全上面也是有很大的顾虑，这个事是不是会因为自动化过于快导致自己安全上面的降了一个等级，等等等等这些都会对我们的实施带来很大的挑战。

基于这样的挑战之后我们陷入一个困局，第一从哪里开始，很多人经常说你这个公司跟我们很像我们是不是按照你的实施路径开始就行了，或者你这个事为什么是你做，别的部门会不会不开心，还有我们边界怎么划分，或者我们是不是要新招DevOps工程师，或者是不是在公司内部成立一个小组，那么谁来主导这个事比较合适？是运维的同学还是项目管理的同学？还是我们的基础框架的同学，谁是主导者？接下来就是我们开始搞了之后我们怎么自证价值？那在这些困局面前我们总要找到突破，所以接下来带着大家根据个人的经验把它找到一个突破口，可能只需要找到一个突破口后面的路就自然而然可以走下去了。

二、如何找到突破口

在这里九个字，这九个字说起来很简单，第一是搭班子，第二定调子，第三迈步子。

搭班子是明确职责，不一定要从外面引来很多专家，只是说做这个事的时候大家有明确的人明确的职责，这个叫做搭班子，比如说我在去哪儿的时候，我们一开始做的时候就是配置管理组做这个事，一开始做的就是发布系统的自动化，当然我去的时候本身去哪儿就是借鉴阿里的发布自动化，就是一套，可能有些人觉得不可思议，但是没有关系，每个公司都有特点，或者每个公司的工作岗位边界不同，只要我们在这个阶段明确下来这个事谁在搞，在搞什么事。

定调子就是统一一个目标，统一这个目标的时候我们到底是一年搞成，还是作为企业内部的优化项目我们不断提升就好了，这个是很重要的，因为有一些企业现在是非常看重，觉得自己落后很多，想快速把这个搞起来，经常有人问我你在去哪儿七年做成这样，如果我请你过来你能几年做好，其实这个问题很难回答，因为做任何事都有一个投入和产出，可能有一些东西可以快，快在哪里？就是过去踩的坑，过去内部做的不断迭代的事，这些弯路可以省去，但是也一些东西是省不了，就是我们在摸索正确的那条路子的时候找到适合企业自己方式的时候这个是省不了的。

比如说我买一辆跑车回来我就成为赛车手吗？其实不是，这个距离还有很远。所以这个时候要确定下来我们的目标是什么，搭班子的时候谁来实现这个目标，最后就是迈步子，今天跟大家分享的就是坚持MVP原则去落地我们的DevOps整体的体系，所以会重点在迈步子里面，至于搭班子这个事可能会是我们组织结构的一些文化或者一些结构调整的事情，会比较复杂，我不在这里涉及。

关于统一目标还有一个想跟大家分享，当年我倡导技术组建组和团队一起搞门户网站作为技术运营平台的入口，当时讨论这个事的时候真的是很简单画了一个手串，就是画的时候就是把应用放在中间，周围画两个圈，说未来做的平台，这个平台从需求管理到开发到最后的测试都可以完成，但是看了这个图之后觉得太好了，可能是去哪儿的文化决定的，大家认为这个目标正确，是值得做的，就是一拍即合。

就是后面多次拿出这个手串跟内部的同事交流，一个清晰的目标对于推进有多么重要，这个清晰是好理解，不是讲大道理，是告诉大家我要做的东西，每个人都很清晰。上周还有一个离开去哪儿的同事找我说，离开去哪儿才知道我们的工具链有多么好，就是不知道这个有多香。

接下来我们说一下在迈步子的时候，说这个MVP是什么。MVP其实是三个英文单词，翻译过来是最小化可行产品，其实这个概念是在《精益创业》这本书里面首次提到，本来这本书是指导创业公司如何走向成功，以及在创业的过程中如何提高成功概率。

但是为什么在这里提到MVP？我觉得MVP有一个目标，就是以最快的速度最小的精力完成一次反馈的循环，这个反馈的循环对于我们搞持续改进的时候我们也是在找到一个真正推行的最佳实践，而且是确实有效，对质量有效或者对速度有效，总之我们假设这个实践应该是可以，但是我们要在企业快速落地，形成一个闭环告诉自己这个假设是否正确。

所以这个闭环对于创业公司里面的CEO去找到自己的第一批用户验证自己的商业逻辑是否可行是完全一致的，所以后来我们经常提到MVP，也经常鼓励我们团队，我们就是一个内部的创业团队，我们做的事就是要去证明这个事是否对的，如果对继续做深入，如果不对再快速找到下一个应该重新开始的点。

三、MVP 助力 DevOps 建设

接下来跟大家分享四个案例，都或多或少用到MVP里面比较好的实践。

第一个从解决一个痛点开始，刚才讲到我们面临那么多复杂的挑战和自己所陷入的困境，我们总要找到一个突破点，这个突破点我建议大家从找到第一个痛点开始。谁痛？有可能是开发人员痛，有可能是测试人员痛，总之需要找到一线去了解谁最痛，这个人会是你第一个解决方案的忠实用户。

那这个事的背景是说在三四年前，那时候项目管理出于管理的目标是需要收集很多项目数据，比如说计划提测时间什么时候、实际提测、计划上线、实际上线，这些数据拿到之后对我们分析项目的过程是否可以发现一些问题。

但是带来的问题工程师不愿意填这些数据，那等到发现的时候就发现这些是空的，那工程师就是根据记忆填，或者是工程师觉得已经够忙你还要我做这些事，甚至出来的报告没有人看。

第二个工程师写代码的时候，一定是以写代码作为经常干的事，但是写完这些变更之后要提测的时候要写一个长篇大论的操作步骤给到测试人员说本次需求我改了多少步骤，非常详细，对于工程师来说，做的时候做了五步，写的时候只有三步，那测试人员拿到长篇大论就开始弄。

这些都是我们识别出来的痛点，那我们当时做什么？我们第一个假设是这个数据是分离的，需要人填，以及工程师在开发到测试的时候需要填，是因为我们的信息没有打通，因为信息打通的话第一部分就是向第二部分的代码工厂，所以当时做了第一个尝试，建立一个分支的规范，就是拉取代码的时候在分支上面标注上需求变好，利用githook方式检测工程师的实践，如果现在拉出分支，我们就自动回填到里面的实际开发时间。等我们的发布系统开始做发布，我们会打一个Tag，那时候我们会把Tag第一个生成的时间点认为是计划的提测时间点，当时我们就先去尝试这样的东西，是不是开发工程师是接受的，他们愿意不愿意说我要遵循你这样的策略来去降低我去回填数据的成本，第一次尝试非常成功，大家觉得原来这个数据你不仅帮我回填了而且还是最准确的。

当然在这个方案里面大家看到这些githook其实是一个不OK的技术方案，因为它会涉及到我们任何后面想要做集成的时候就要改githook，而且改githook这个事也是比较烦琐的，所以我们做完第一个尝试发现这个路是完全正确的时候，我们就推出第二个，我们把githook去掉了，就是我们上了消息监听，就是有自己的消费系统，就是会监听各个系统关键步骤发出来的消息，比如说Git拉了一条branch，就只管发一条信息出来就好了，不用管谁来消费我，以及消费完我这条消息以后做什么，这些他都不用关心，只要发出来消息就好，那比如说JIRA就想监听说分支拉出来之后认为这个是开发开始了，然后我们的发布系统会发出发布部署的动作的消息，至于这个消息会被谁去监听，它也可以不关心，所以我们第二阶段的时候就把技术层面做了一个优化。

第三次再去迭代的时候在扩充整个平台的功能范围，这个功能范围就是我们不仅能做数据管理的集成，我们要把所有关联的这条需求的分支、工程以及谁拉取的分支的信息做集中的展示，同时那时候我们有一些CI的实践，CI的结果我们直接发到平台上面能有直观的展示。所以在第三阶段的时候重点放在平台上面做集中的信息展示上面，也是非常好的反馈。

第四个阶段的时候又深入的一步，我之前看到了那来这里看的时候是不是能顺道完成一个动作，所以我们又把触发部署的动作都集成过来，接下来给大家看一下最新的平台界面。

今天给大家SHOW的这些都是我在去哪儿团队做的平台。比如说这个在需求上面有36558的需求编号，下面涉及到的五个工程都是为这个编号做的改动，那大家从分支号上可以看到关联到这样的需求，后面的要发贝塔环境还是发测试环境以及当前这个项目是不是已经发布上线了，还有集成CI的那种结果都可以在这里做一站的展示。

而且更有趣的是这个平台其实不是我的团队做的，而是我们的业务部门做的平台的东西，所以回到搭班子的时候不是所有事我都做，只要大家明确功能边界，而且大家向着一个目标做就可以，就是第一个案例，我们找到第一个痛点大家快速去试，针对这个痛点的解决方案是否可以。

进入第二个方案，借势发力、乘势而上，我们做DevOps目标要让业务团队灵活起来，交付快起来，但是首先自己要是一个很敏捷的团队，我们自己的需求要能够随需而变。

当时的背景就是我们把很多的CI工具都做了很多，但是就发现推行一段时间之后有的人会看，但是有的人不会看，从技术经理或者QA那块觉得结果已经有了，或者你们在开发阶段知道有这些问题，那就不要再测试阶段做，所以大家的需求是要有一个质量门禁，那我们就去把Sonar的结果集成进来，因为当时Sonar已做的已经相当完备了，就是拉一条分支之后我们自动创建Sonar，去给它分析，就是每一次我们都会生成一个Sonar的报告，然后我们还做了全量的报告扫描、增量的报告展示。

所以我们觉得这个东西很成熟，所以做门禁很有利了。就在我们还在规划这个事情的时候我们支付的团队技术负责人找到我说我们最近出了两起故障，这两起故障全都是因为慢查询导致的，那我们在线下有一个慢查询的工具，你能不能让我在慢查询测试环节直接拦截不要上线，但是跟我提这个需求的时候我一下想到在规划的这个系统，就一拍即合觉得可以做这个，所以第一步我们本来想做Sonar，同时也支持了慢查询工具的进入，而且在这次沟通的时候我紧紧抓住这个业务线，那这个业务线就是我们整个门禁系统的第一个用户，而且是我的免费宣传用户，就是他用完之后就会各处说这个东西有多么多么好。

那我们做这个事情的时候，其实完整规划这个平台我们大概知道首先要支持用户能够灵活配置，同时支持在紧急的情况下还要跳过就会有复杂的审批流，但是第一次上线的时候就商量好审批这个事第一是低频事件，第二如果真的出现这种，后台改数据库让他过，所以第一次没有审批的事。

上线之后用户口碑非常好我们就做审批，同时我们也有移动办公，把审批接入手机端，随时随地可以做审批。

做完这些我们才开始扩展平台应该去展示更多的工具，所以到后来基本在平台所有CI的工具，不光是工程效率部自己按的这些Sonar，还有业务部门自己做的测试框架都已经集成到我们平台。

所以想跟大家说的自己做 DevOps 工具落地还是改进的时候我们可以先把自己的功能规划出来，因为一个好的架构师可以帮助我们在做后期的时候非常快，但是做功能的时候不是一次性，一定要全部做好。

所以你看这样的过程，其实是分了三步走，一开始我们只有在Sonar和慢查询是接入，后面又接入一些自动化的工具，包括这些我们还测试APP侧的自动化测试工具。

所以我们所谓的MVP就是要快速试错，也是说真的证明我的正确的决策，但是首先要快起来，找到你的用户是谁，这是第二个案例。

这是在平台展示的分支，面前接了哪些CI，还有分支上面跑完的结果是否通过，如果不通过就有一个X，可以有一个详情可以看一下问题出在哪里。

第三个案例，这个案例会更直接一些，愿意分摊成本还是真需求。

因为前期的时候看去都是问题，就随便改，只要确定下来目标做踏实了就一定有用户，因为前期没有做改进的时候满地都是问题，改就对了，但是把这轮问题扫过一遍就会发现你需要找优化点，那什么才是真需求？而不是一个锦上添花，或者是臆想出来的需求。

就拿这个来衡量，愿不愿意跟你分摊成本，这也是我前领导告诉我的秘诀，就是你看看你的业务线是否已经有人开始做，因为业务线真正的目标是业务往前，而不是工具做得多么好，不要说业务在做我也在做，就是打架，不会的，如果人家做，只能说我们过去做得不够，如果我们做得够他们是不会在这个上面花成本。

那这个背景是什么？就是环境管理平台跟前面的老师讲的环境治理解决的问题是类似的，那我们这个平台解决的更广一些，这个不是针对单应用，是针对业务测试的场景里面来的，就是我们现在做微服务的架构拆分，那微服务带来的问题我单测一个应用是不够的，是需要把周边的都测起来，那这个很麻烦，因为很复杂，很考验我的经验积累下来需要配哪些。

所有当时有很多用户，我们的支付部门等等都尝试在这个部门做事情，当时有一个解决方案就是申请一台巨无霸的虚拟机，把所有的服务往里面去，然后申请20台虚拟机，但是这个方案是你申请一台就是一台的环境，20台就是20台的环境，申请10台就有10台的环境，还是不能从根本上动起来。

所以基于这个我们就想说我们应该提供一个更灵活的去创建这样一套业务测试环境的平台，这个当时提出方案的时候，我们既没有直营 Docker，也没有有多么自动化的东西，我们就觉得这个方向是对的，所以我们更是花了好几年的时间在打磨。

说实话因为我们经过三个版本的迭代，到现在还是非常棒的产品跟其他的同业交流的时候我也会讲这个东西，他们觉得你居然可以做成这样，我们几百个应用点一个按纽，十分钟之后你可以过来拿到一个可测试的环境。我们走到今天其实过程遇到很多困难，比如说第一个我的环境要动起来，第一要解决的问题是我的配合能适应我的环境，举个例子，我的应用是在配置文件里，你现在承认我要动态创建一套环境，那环境创建出来我的IP跟应用之间的互联怎么办？所以第一个我们要想环境动起来，首先配置得要动起来。接下来就是快速创建环境的时候，我的基础平台也就是数据中心到底能不能支撑这个快？就是前面承诺用户说一下交付两百台机器，但是基础能力能不能交付，如果卡在机械的创建上，两百台机器要等一天，这也不行，所以解决环境管理的时候真的是系统的问题，这个问题涉及的面非常广，包括跟基础框架讨论过我们的配置中心怎么修改能够快起来，包括跟其他的一起从模块大小，就是我们应该给他多大的资源才是合理的，以及我们应该怎样优化创建的队列，并发数，才能保证业务目标，以及我们怎么帮助他们快速创建还要回收，有的人说我创建完了用完了就爽了，你回收这个事对他来说又不是一个痛点，所以等等这些事我们都需要一点一点解决。

那在1.0的时候因为业务很痛，那当时在界面上交互友好上不太关键，那时候最要解决的是配置中心的事，在这里还要提醒一个实践成功的经验，就是第一批用户要提供VIP的服务，就是我们用1.0的时候当时的产品经理贴身服务，你配置不改也不知道怎么改，那你帮我拉一个小分支我改，你做代码审核，审核之后试用一下，虽然这都是刚性的需求，我们都需要提供这样的服务才能让产品落地，说明人的惰性带来的惯性很可怕，而我们就是跟惯性做抗衡，包括DevOps都是在改变过去的行为方式，所以我们内心要有服务的意识，这种服务的意识是涉及到所有参与在DevOps活动中的任何一个人，因为我们要找到我们在服务的客户是谁，我们虽然不直接接触一线的业务，比如说去哪儿我们从来不接触订单，就是大家买机票，我有的朋友说你帮我解决一个客户的问题，虽然我也帮了，也是在内部走正常的途径，但是我不直接接触一线的用户，所以我要识别出来我的用户是谁，我的用户就是使用我工具的那些人，可能是产品经理、开发测试，甚至是项目管理人员，还有可能是我们做决策的管理者，那我就要去服务于他们，所有的他们的需求就是我应该去满足的需求。但是大家不要误解他们说我们就做什么，我们要找到的是需求，因为有人带着需求就带着解决方案给你说，我要十台机器给我，那我说你要机器做什么，聊着他可能给你说透了，然后你再放到你的平台看，这个事应该怎么优雅解决它。

那给大家SHOW我们的平台，也是给去哪儿的产品再打一次广告，这个是真实的环境，大家可以从截图可以看到，包含83个应用，数据库有23个，中间件有7个，这样的环境规模实际上在创建的时候只需要9分钟。所以我们是可以奔着这个目标去的，当然有一些企业做得比这个更好，大家也可以去看，但是大家要知道我们可以做到更高更快更强。大家可以看到有直观的成本核算，你在使用我的平台你在花钱，那我告诉你我的计算规则是什么，你愿意承担可以，那不愿意承担就看是快速创建还是快速销毁。

第四个案例讲跟度量有关系，就是叫虚荣性指标和可执行指标。什么是虚荣性指标？本身虚荣性指标和可执行指标也是前面提到的在精益创业提到的两个概念，就是要想成功不要被虚荣性指标蒙住双眼，而大家经常会看到业务经常用，但是我们内部企业要找到问题要往哪些方面发力，是不是后期的增加不足，我们不要使用虚荣性指标，而使用可执行指标。那哪些是可执行指标？我们在做DevOps这件事，DevOps 的最终目标是要按需、快速交付可靠的软件。那我们就要说每一次的改进，你到底在这三个上面做了哪些贡献，你是帮企业解决成本还是加快流程还是提前发现了很多问题，发现几个，节约的成本是多少，加快的流程是多少，这就是可执行指标。所以大家在做工具的时候不要让自己沉迷于虚荣性指标，给大家一个直观的例子。

比如说这是我们当时推行CI的工具的时候做的一个统计，统计指标的是接入平台的工程数是多少。那大家看到这很可观的是有四千多个已经做了配置，就是四千多个工程已经接入Sonar配置，同时有2365个做了阻断的配置，这个指标拿出去可以炫耀，我们公司一共6000个工程，除了不活跃的好几年不动，甚至是下线的我们基本已经全量接入。

但是我想想这个是虚荣性指标，因为接入不只是说真正在用，那哪个指标相对来说比较好？就是配置和阻断，就是真正配置门禁，说明已经在看这些问题，而且愿意为我发现的问题做修复和投入。还有一些比如说后来又回归到可执行指标上会采取什么呢，就是Sonar问题修复时长，当你不接入的时候蓝色的线这个是一个小时，就是两小时之内修复比是70%，12小时能修复的达到这个数，那大家回想一下我们第一次做门禁平台技术更新的技术人员，他在内部就强制说一刀切所有的都要接入平台同时设置门禁，所以就发现只要接入门禁之后整个运用的修复时长变得很快，所以这件事我们不仅做了，而且发现数据能够验证我们的假设，这也就回到MVP自己的认知的循环，就是我们做开发，我们采集数据，我认知发现OK这是一个成功的实践，这也就是可执行的指标。

再比如说，Sonar平台创建的多么多么快，其实快的背后带来的问题就是稳定性是我们优化的一个重点，那我们在优化的时候就会真的采集说我每一次环境新建或者创建的时候失败的原因是什么，那我应该聚焦在什么类别上，我们的改进是否有效，我们的稳定性是否有提升，所以在度量上面包括我们给业务线做度量设计的时候一定要注意，就是问自己这是一个虚荣性指标还是可执行指标，所谓可执行就是看到这个指标就应该知道自己该做什么。

这一页想跟大家说一下在DevOps落地的大潮中自己的团队要经历几个时期，这几个时期我觉得划分为依赖期、独立期，互赖期，这也是受成功人士的七个阶段里面个人成长的启发，我觉得团队也是这样。

比如说我现在没有开发的能力，我有一个好的主意，但是没有人帮我落地到好的平台，那我怎么办？我依赖别人。还有一种依赖是更低层次的，就是你让我干什么就干什么，这种依赖更可怕，表现在我们做这件事的专业性被弱化，所以我们一定要用最短的时期完成依赖期到独立期的跃进，要不就是快速提升自己团队的专业性，然后在独立期其实是要有一个不断向别人证明我们专业性的过程。

在这里我觉得内部的团队其实是有两个考核点，第一个考核点就是我们是否专业，就是我们给出的解决方案，业务团队是否马上眼前一亮说原来我没有想到这个点，第二是是否可预期，就是我擅长发现问题，而且我可以说出来，然后我们怎么落地这个东西，比如说我们承诺一个月，一个月听起来很长，但是一开始说就是一个月，一个月之后完成这个事，那一个月之后承诺说一个月可以在平台看到这个功能，如果敢说这个话，并且到那个时候真正上线，那你的独立期就是已经到了。

所以这一块我们要做到可预期，为什么不要求特别快？就是我觉得对于内部改进团队来说，除非说我们签了一个外面公司的说项目就是一年，但其实都是细水长流的过程，今天说我没有上线，那明天上了，那就差这一天有多大的坏处，其实不太好衡量，所以我们的指标反倒是回到可预期的指标数，就是我承认业务团队给我提的需求，说这个发布自动化体现在不够快，你能再快一点吗，评估完之后可能提效的问题改动比较大，评估之后要一个月才能上线你告诉业务团队一个明确的时间都是可以的，可以确定这种关系，总比说你等着吧这个事遥遥无期要好得多得多，所以在独立期的时候要培养自己团队的交付可预期性，同时我们跟业务线沟通需求也好，做改进的时候一定要站在用户的角度想问题，同时要建立共赢的思维。

就是一个工具是我们做的，是业务线用的，那么真正带来价值是要业务线真正使用了才有价值，所以不是说我一定要说这个工具就是我做的，你用了我的就是多么好，不用我的就怎么样，这种就把我们跟用户建立了一个对立关系，所以我们要培养自己的共赢思维，就是我们的成功是业务团队成功了才能证明我们的成功，这话大家要一定有这种思维，才能跟业务线建立良好的沟通，才能跃升到互赖期，比如说我们去哪儿的工程效率团队已经快到互赖期，就是业务线在想自动化还是什么样好的点的时候会过来沟通，当然沟通是因为我们积累了很多数据，他想接入跟我们第一时间沟通，第二是跟我们沟通的过程中能够碰出不一样的火花，所以我觉得达到互赖期整个DevOps就步入正轨，就是优化永远没有止境，我们要找到正确的轨道，上到这个轨道上去。

另外想给 DevOps 团队几个建议，第一就是我们自己要是一个很敏捷的团队，一定要记住这一点，我们自己先敏捷起来我们才有资格指导别人你用了我的这些东西你可以敏捷。

第二个就是我们自己要是我们自己产品的第一个用户，很多人说我看他这些东西好，但是我让他演示他不知道怎么操作，那你都不去用他他用什么说服他用，或者你站在一个用户角度你怎么发现产品问题。最后一个如果我们制定了规范，首先我们要做规范的执行者，这一点其实在很多的团队里面，比如说配管自己开发了很好的系统，问他们用了什么分支，他们就说不用分支，那这个很打脸，所以我希望做DevOps改进这件事的团队要按照你们给公司制定的规范流程，你们自己开发的工具去管理整个改进的流程，这个是非常重要的点。

四、遇见未来

一开始我打的那个广告，说最后要说的我们建的DevOps生态，最后这两个PPT就是我的必生所学，大家可以听听。我是这样理解DevOps的，DevOps有三个对象，第一是人，然后这些人要做项目，这些项目要落在不同的应用中达到业务目标。人要关注几个点？有工作量，团队合作怎么样，人的绩效怎么样，我们需求会关注哪些？需求现在是不是确定下来，进度如何，我为需求投入多少成本，整个是项目管理的一套，不管是传统还是敏捷精益都会在需求上面有很多关注点。应用也会有应用的关注点，比如说线上的服务，质量怎么样，SIOA怎么样，当前的容量能不能承担未来的业务发展，服务之间的依赖怎么样，做变更遵循什么步骤，其实整个DevOps就是根据这三个对象做一系列的标准化和自动化。

不同的公司会落地成不同的展示，但是核心就是这点东西，这是我个人的理解，所以基于这样我的抽象之后，我就会对企业内部的DevOps平台有了一个系统架构上的抽象，我觉得这个架构其实看了很多公司的分享之后我觉得这个架构不错，在哪里会有一个亮点呢？就是这个元数据中心。

大家可能看上面下面没有太大的需求，但是在基础设施和应用架构和提供的DevOps工具中间加了一个元数据层，就是来做一个结藕，包括一会可能有一些答疑的时候有人问我们现在还是用实体机，用传统的虚拟化的方式，没有用Docker，没有上云，是不是搞不了DevOps？答案是否定的，是你可以搞。那怎么搞？我们要把抽象出来的这层做结构，那这层对应用做画像，对员工做画像，我是管理者还是开发人员还是架构师，我是一个微服务应用还是单体应用，当前是想部署在Docker还是部署在实体机上面等等的这些，都可以在这个层面描述清楚，就是所谓的配置要集中管理起来，而且画像是完整的。

下面这一层，就是人的项目是什么项目，项目涉及到的业务目标是什么，有的公司还会实行OKR，那项目对应的业务目标战略是什么，O是什么，这些也可以做管理。有了这一层元数据的抽象管理之后再往上搭基础服务，这就是边界相当清楚的元服务，比如说制品库就管制品，那代码仓库就管代码，我的Sonar就找扫描Sonar的规则代码扫描就好了，就是每一个服务它的边界都非常清楚，有输出和输入，为什么定义这个？就是我们不管往上做审批流也好，可能我们都会要调取元服务组成一个可以灵活应变不同的业务部门需要的，所以这个架构我觉得大家可以在实践的时候尝试一下，是提升我们整个DevOps平台可扩展性或者响应速度很好的架构。

讲到这里，我的分享就到这里，非常感谢大家能坚持到最后。