基于MVP原则构建DevOps体系(转)

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

分享内容包含如下四个方面：

DevOps 建设面临的挑战

在这些挑战面前如何找到突破口

MVP 是如何助力 DevOps 建设？

我会在这里重点分享我在 Qunar 落地 DevOps 的过程中，是如何结合 MVP 的原则，逐步优化和完善的。最后是我总结的关于 DevOps 体系的两张图，希望给正在搭建体系平台的朋友一些启发。

一、DevOps 建设面临的挑战

首先看一下挑战，回到 DevOps 的价值来讲，很多人在想 DevOps 是什么，DevOps怎么做？其实我们要重新回到 DevOps 本身的价值来看，我们为什么要做 DevOps？DevOps 的核心价值跟精益、敏捷是一致的，都是要实现企业从一个需求，甚至是idea到交付给用户，整个过程快速、灵活、质量可靠。

这里面提到一个又要速度又要质量，同时我们还希望从用户那儿快速获得反馈，形成闭环。所以我们做 DevOps 其实服务的是企业的业务目标，这个大家一定要记住，因为只有知道我们为什么出发，我们才不会走偏。

企业内部实施DevOps，会面临各种挑战，我把它总结为四个方面，每个方面展开都会特别多。第一：DevOps 的体系是非常复杂的。大家在很多大会中都有见过《研发运营一体化成熟度模型》，从模型中我们就不难看出，其体现所覆盖的技术范围和影响的人群范围都是非常广泛的。纵向来看，第一层研发运营一体化过程，下面依次还有应用架构、安全管理和组织结构。

第二：关于企业文化。很多人说 DevOps 是一种文化的运动，需要先从组织结构的调整开始，因为没有组织结构的调整，我们永远打破不了那堵墙。在很多大师的演讲PPT中，一个箭头就打破了 Dev 与 Ops 的那堵墙，而在不同企业落地的时候，想做到这一点，可能需要几个月，甚至几年。所以这个是我们需要克服的点。

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

第四：是成本收益。我们回到商业的本质来讲，企业一定是要盈利的。我们搞 DevOps 落地，不是在搞科研，不是要把 DevOps 水平达到一个世界的先进水平或者国内的先进水平，我们一定要回归到服务企业的商业目标这个点。所以，落地 DevOps 也必然逃不了计算投入产出比。

回想当初自己做 DevOps 的时候，要在企业内部立一个OKR，经常会被挑战，“你的ROI是怎样的”？一开始自己很不舒服，我做那么多事，为什么总是觉得我这个事不值得做呢？后来我转变思路之后，反倒觉得这是很好的考量一件事情价值的度量方式。没有度量就无法管理，持续优化更是无从谈起。所以怎样考量投入成本和取得的收益，也是非常重要的点。

面临这些挑战，我们很容易陷入一个困局。我们是不是要新招 DevOps 工程师，或者成立独立的小组？谁应该来主导这个事比较合适呢，是运维、项目管理还是基础框架呢？从哪里开始呢？有没有标准的实施路径呢？每个部门的职责边界怎么划分呢？陷入困局的我们，总是要找到突破口的。

接下来我就与大家分享一些个人经验，如何在不同阶段找到突破口。可能你只需要找到一个突破口，后面的路就会很顺畅的走下去了。

二、如何找到突破口

关于实施 DevOps，我总结了九个字，这九个字说起来很简单也朗朗上口，那就是“搭班子，定调子，迈步子”。

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

定调子就是统一目标，统一目标的时候我们要明确实施周期和实施目标。明确实施周期，是说我们是要一年搞成，还是作为企业内部的优化项目慢慢搞就好了。这个是很重要的，因为有一些企业现在是非常看重 DevOps，觉得自己落后很多，想快速把这个搞起来。

经常有人问我你在去哪儿七年做成这样，如果我请你过来你能几年做好。这个问题其实是很难回答的。首先，一定程度上，投入资源的比重越大，实施的周期会越短。但是，实施周期不会因为投入资源的无限扩大而无限缩短。

我们可以缩短踩坑浪费的时间，可以省去走弯路浪费的时间，但是，在企业内部摸索出一条适合的路子，必然是需要一定时间的，揠苗助长的方式只会损害长期利益。举例来说，我买了一辆跑车回来，我就能成为一名优秀的赛车手了吗？

关于统一目标还有一个想跟大家分享的，就是当年我在与 Ops、基础架构组一起讨论搞DevOps 门户网站，关于它的作用和功能，真的就是很简单的画了一个手串。手串中间是应用，周围每个圈是一个个散在各处的系统。

我说，有了这个入口平台，工程师可以从需求管理到开发到测试再到最后的上线、运营，都能一站式搞定。大家看了这个图之后觉得太好了，一拍即合就开始搞了。我们甚至连正式的立项过程都没有走。

可能这也是去哪儿的文化决定的，大家认为这个目标正确，是值得做的，就可以得到资源和支持。可见，一个清晰的目标对于推进工作有多么重要，这个清晰是好理解，不是讲大道理，是告诉大家我要做的东西，每个人都很清晰。

最后就是迈步子，今天跟大家分享的就是坚持 MVP 原则去落地我们的 DevOps 整体的体系，所以会重点在如何迈步子上。

MVP 是什么呢？MVP 即：Minimum Viable Product，翻译过来是最小化可行产品。这个概念是由硅谷创业家 Eric Rise 在其创作的《精益创业》一书中提到的。这本书是指导创业公司如何走向成功，以及在创业的过程中如何提高成功概率的。

但是为什么在这里提到 MVP？我觉得MVP有一个目标，就是以最快的速度、最小的精力完成一次反馈的循环，这个反馈的循环对于我们做持续改进的人来讲，也是非常重要的。我们会假设某个实践是有效的，或对提高质量有效或者对加快交付速度有效，但是我们要在企业快速落地，就需要快速实践，形成一个闭环告诉自己这个假设是否真的正确。

这与创业公司CEO去找到自己的第一批用户，验证自己的商业逻辑是否可行是完全一致的。

三、MVP 助力 DevOps 建设

接下来我跟大家分享四个案例，每个案例都是从坚持MVP原则，开始一个新的优化方向。

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

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

但问题是，工程师不愿意填这些数据。等到被发现数据空着的时候，工程师就凭借记忆去填，甚至按照计划时间与补实际时间。这样的数据，不仅没有分析的价值，而且工程师还会抱怨，我已经够忙了你还要我做这些事。

另外一个问题是，开发人员在提测前，需要给测试人员写一个非常详尽的部署步骤。而因为时间一久，开发工程师开发的时候可能做了五步，但到写的时候就只想起三步，测试人员拿到长篇大论的部署步骤开始搞，结果还是经常出错。

这些都是我们识别出来的痛点，那我们当时做什么呢？我们对这些问题进行了根因分析，初步判断是数据分离，信息不互通导致的。

于是，我们做出如下假设：如果能够建立项目与工程信息的互通，这些问题应该能够迎刃而解。所以当时就做了第一个尝试，建立一个分支规范，就是拉取代码的时候在分支名称上标注需求编号，利用 githook 方式监测工程师的动作。如果新建一条分支，我们就自动回填到 Jira 需求中的实际开发时间。

等我们的发布系统开始做发布，我们会打 Tag，那时候我们会把测试用的 Tag 的生成的时间点作为实际提测时间点。当时我们就想先去尝试这样的东西，看开发工程师是否接受这个规范。第一次尝试非常成功，大家觉得原来这个数据你不仅帮我回填了而且还是最准确的。

当然在这个方案里面大家看到这些 githook 其实不是一个最优的技术方案，因为我们如果后面想要做更多集成的事情，修改 githook 很麻烦，而且 hook 是一次性不可重试的。所以我们做完第一个尝试发现这个路是完全正确的时候，我们就推出第二个迭代，优化技术方案。我们把 githook 去掉了，开始建立工程效率的消息中心，系统间通过消息驱动的方式实现流程自动化。

比如说 Git 拉了一条 branch，githook 就只管发一条信息出来就好了，不用管哪个系统来消费，以及消费完这条消息以后做什么，这些 gitlab 都不用关心。对于 JIRA，它就可以来监分支创建的消息，更新项目的实际时间，构建流水线系统可以消费这条消息，实现代码自动扫描。

第三次再去迭代的时候，我们的重心放在扩充整个平台的功能范围，不仅是做消息中心，我们还要对收集的CI数据进行聚合展示。

第四次迭代，更深入一步，开始把动作集成进来了。就是测试工程师进入这个界面后，顺道还可以执行一个发布动作。以下，就是这个平台最新的界面展示：

这个需求上面有36558的需求编号，下面涉及到的五个工程都是为这个项目做的改动，从分支号上可以看到关联。最后的beta／prod标签，是表示该分支改动已经发布到测试环境还是线上环境。同时，每条工程分支的最新CI结果也可以在这里做一站的展示。

而且更有趣的是这个平台其实不是我的团队做的，而是我们的机票业务部门做的。所以回到搭班子的问题，真不是要所有的事情都由我来做。只要大家明确功能边界，向着一个目标做就可以。能够团结到业务线参与其中是更好的。

第二个案例：借势发力、乘势而上。

我们做DevOps的目标是要让业务团队灵活起来，交付快起来，但是首先自己要是一个很敏捷的团队，我们自己的需求要能够随需而变。

这个案例当时的背景就是我们做了很多的CI工具，但是发现推行一段时间之后使用效果并不好。比如Sonar检查结果，虽然已经精准的推送给了开发人员，但是开发工程师如果不修复，问题还是会流到测试阶段。所以为了控制问题蔓延，还需要有一个质量门禁系统。鉴于当时我们的 sonar 系统已经比较完备，我们可以做到对工程师 push 代码后自动执行 Sonar 扫描，1分钟后工程师收到 Sonar 报告。于是我们就准备在门禁系统中，优先实在 sonar 增量问题的拦截。

就在我们开始规划这个事情的时候，支付业务线的技术负责人找到我说，我们最近出了两起故障，全都是因为慢查询导致的。我们在测试环境有一个慢查询的工具，有什么办法能够做到，发布线上前去系统中校验一下是否有慢查询。如果有，就不允许上线发布。

我马上想到正在规划中的质量门禁系统，于是一拍即合，把接入慢查询工具加入到第一次迭代需求中。通过这次沟通，我们紧紧的抓住了这个业务线，这个业务线不仅是门禁系统的第一个用户，而且成为了系统的免费宣传用户。

其实一个完整的门禁系统，还需要支持用户能够灵活配置，同时支持在紧急的情况下还要跳过的审判流程。但是第一次迭代中，我们评估了低频事件和个性需求，仅把最核心的功能放入第一次迭代。上线之后用户口碑非常好，我们才开始做审批，而且还把审批接入手机端，随时随地可以做审批。

做完这些我们才开始扩展平台中接入的其他CI工具。现在，已经集成到平台的，不仅有工程效率部自己负责的工具，还有业务部门开发的测试自动化工具。

这个案例想跟大家分享的核心思想是， DevOps工具落地时，系统架构和功能需要有认真的规划，一个好的架构才能支持未来的功能扩展。但是，开始功能开发的时候，不是要一次性全部做好。选择做什么容易，反倒是选择不做什么是比较难的。一定要规划好每次迭代的功能范围。

所谓的MVP，就是要快速试错，为了证明决策的正确性、可行性，首先要快起来。

第三个案例，愿意分摊成本还是真需求。

DevOps 转型前期，需要优化的需求很多，你随便抓住一个痛点，踏实做完就会有收益，用户就会认可。但是，这些表面问题扫过一遍后，再去找优化点就需要花些心思了。什么才是真需求，而不是一个锦上添花，或者是臆想出来的需求。

这个时候，就可以拿一个最简单直接的标准来衡量，那就是用户愿不愿意跟你分摊成本。我的前领导告诉我一个秘诀，就是你看看业务线是否已经有人开始做了。业务线真正的目标是业务量往前冲，如果他们都愿意在工具上花精力了，那一定就是刚需。

这个案例是围绕如何快速搭建一套可测试环境的。其实这也是微服务架构所带来的一个挑战。一个业务需求哪怕只修改一个应用，但是要想完成对变更的验证，就需要搭建其他的几个甚至几十个应用才能完成。在当时Qunar业务快速发展的情况下，基于固定环境进行维护、分配，已经成为影响交付效率的瓶颈。于是好几个业务线的测试同学就开始做各种尝试。了解到这些情况后，我们觉得公司应该有一个可以提供更灵活、快速的创建一套业务测试环境的平台。提出方案的时候，我们既没有开始使用Docker，也没有特别先进的自动化运维。我们就觉得这个方向是对的，所以这个平台更是花了好几年的时间在打磨。

经过三个版本的迭代，到现在Noah平台已经是一个非常棒的产品。在与同行交流的时候，我也经常拿 Noah 出来炫耀。一个由几十个应用外加几十个中间件的环境，从点击创建按钮到交付给测试人员使用，仅仅十几分钟的时间。

但是，这个平台能做到今天的样子，过程中需要克服的困难有很多。比如说第一个难点就是如何解决应用自适应环境的问题。环境动态起来了，应用的配置文件怎么更新呢？接下来，我们承诺用户说可以10分钟内交付一个包含100个应用的环境。但是基础设施能不能扛住这样的并发呢？所以解决环境管理的问题，绝对是一个系统工程。过程中涉及的技术难点多，需要配合的部门多，需要考虑的业务场景也会多种多样。你不可能等到把所有问题都解决了，再推向用户使用。

在1.0版本的时候，因为业务有刚需，所以当时在界面交互的友好性上就不需要特别关注。而是集中精力先攻克第一个核心的技术难点——应用的配置文件模版化。在这里还要分享一个实践成功的经验，就是向你的第一批用户提供VIP服务。Noah产品的第一批用户，我们都提供哪些VIP服务呢？我们的产品经理真的是申请一条开发分支，亲自帮业务线修改配置文件。

大家可以看到，即使是针对刚性需求提出的解决方案，都需要提供这样的贴心服务才能真正落地。其实背后的原因不难解释，人都是有惰性的。而由惰性带来的惯性力量巨大。而我们做DevOps转型，就是在跟各种惯性抗衡。

所以，每一个DevOps从业者要慢慢建立起服务意识。我们不再是仅仅制定标准或提供工具，我们是在提供服务。我们的用户是整个研发过程中的所有角色，可能是产品经理、开发、测试工程师，或是项目管理人员，还有做决策的管理者。用户的需求就是我们应该想办法去解决和满足的。当然，大家千万不要误解为，是他们说什么我们做什么。我们要解决的是真正的需求，不是表面现象。

我们的平台，也是给去哪儿的产品再打一次广告，这个是真实的环境，

下面要演示的就是通过Noah平台真实的一次环境构建。从截图中可以看到，一个包含83个应用，23个数据库，7个中间件点环境，创建时间仅需要9分钟。

第四个案例与度量有关。在做度量的时候，大家首先要区分虚荣性指标和可执行指标。

虚荣性指标和可执行指标也是精益创业中提到的两个概念。什么是虚荣性指标呢？所有假大空的指标，都是虚荣性指标。看到这样的指标，你完全不知道指标说明了什么，或者自己要做什么。

而可执行指标恰恰与其相反，指标就是一个风向标，当前的优势或不足，以及下一步的行动，一目了然。

DevOps 的最终目标是要按需、快速交付可靠的软件。那我们就要看每一次的改进，到底在这三方面做了哪些贡献。是帮企业节约了成本，还是加快了流程，或是提前发现了质量问题。那么节约了多少成本，流程加快了多少，，发现多少问题，这些问题都是什么级别的问题。下面给大家一个直观的例子。

比如说这是我们当时推行CI工具的时候做的一个统计，统计指标的是接入平台的工程数是多少。从图中看，这个值还是很可观的。已经有四千多工程接入，当时公司一共6000多个工程，除了不活跃的，基本已经全量接入。

但是现在想想，这个就是个虚荣性指标。因为接入不代表真的产生作用。如果大家无视Sonar的扫描结果，那么整个事情就是在浪费资源。

那这件事情该用什么指标度量呢？Sonar问题的增长趋势，Sonar问题的修复时长，这两个指标是可执行指标。如下图。从问题修复时长数据的变化，能够验证我们的门禁系统的价值假设。这也就完成了MVP的一次认知循环。

再比如说，Noah平台创建环境很快，但是环境稳定性一直是一个头疼的问题。当我们开始在提升稳定性问题上投入精力的时候，我们需要首先分析引发环境不稳定的各种原因。然后持续去度量，来验证我们所采取的手段是否真的对稳定性有提升效果。所以，大家下次再定义度量指标的时候，首先要问问自己，这是一个虚荣性指标还是可执行指标。

这一页想跟大家分享的是，参与DevOps体系建设的团队，要经历的三个时期——依赖期、独立期，互赖期。

依赖期，表现有两种。一种是，我们的改进需求和方案完全依赖外界输入，别人让我做什么我做什么。这种依赖很可怕，其实隐含的一个根本原因就是我们可能不够专业。而另外一种依赖型是，团队没有开发能力，我的方案落地需要向外部团队申请资源。这种依赖型可能会因为资源得不到支持，而推进进度缓慢。处在依赖期的团队，务必要想办法尽快完成向独立期的跃迁。

而独立期的团队表现有哪些呢？第一，能够就业务线的问题给出专业的解决方案。第二，解决方案的上线时间可预期。比如我们承诺一个月上线的功能，一定能够在一个月之内完成。一个月听起来很长，但是如果我们真的说到做到，已经是一个很大的进步了。在这里，为什么我只提到交付的可预期，而没有要求特别快呢？对于内部改进团队来说，很多事情都是细水长流，持续改进的。

提前一周上线到底能带来多大收益呢？其实不是特别好衡量。而做到如期兑现承诺，对于一个团队的收益就会不一样。我们会慢慢建立起来与用户间的信任关系。这种信任关系，会是我们能够持续影响用户，不断优化过程的坚实基础。

在这里还想给团队几个建议，第一就是打造一个敏捷的团队。一定要记住这一点，我们自己先敏捷起来，才有资格指导别人如何变得敏捷。第二个就是做自己规范和产品的第一个用户。很多DevOps团队，做的工具都是给别人用的，让自己操作一下都不能很顺畅。制定的开发规范是给别人用的，自己团队开发恨不得连版本控制都做不到。

独立期的下一个跃迁阶段就是互赖期。与谁互赖，那肯定是与我们的用户呀。DevOps团队的终极目标其实是成就用户的成功。所以我们还要培养共赢思维。我们的目标不是要证明自己做的工具、平台有多么多么好。而且要看到业务线在使用了这些工具后有哪些提升。只要这样，我们才能与业务线建立良好的沟通。

比如说我们去哪儿的工程效率团队可以说是已经进入互赖期。业务线遇到什么困难，或有一些好的想法，都会想到先和我们讨论一下。一是我们积累了很多数据和底层的自动化平台，二是大家一起讨论后总还能碰撞出一些不一样的火花。我觉得达到互赖期后，公司的DevOps文化也就形成了。

四、遇见未来

我是这样理解 DevOps 的，DevOps 体系的核心有三个对象——人、项目、应用。人要做项目，项目要落在不同的应用中达到业务目标。人的部分要关注哪些点呢？比如工作量，团队合作怎么样，人的绩效怎么样等。项目需要关注哪些？需求现在是不是确定下来，进度如何，需要投入多少成本等等。应用则会关注，线上的服务稳定性如何，容量如何评估，服务之间的依赖有哪些等等。那么 DevOps 过程，就是对这三个对象所做的一系列的标准化和自动化。

经过这几年的 DevOps 实践总结，我对企业内部的 DevOps 平台做了一个系统架构上的抽象。其中，元数据中心是这个架构的小亮点。

在底层基础设施和应用架构之上，构建一个元数据层，主要目的就是解耦。在元数据层，需要不断完善不同对象对画像。而底层基础设施，就可以被当作满足不同对象的资源来使用。

在元数据层之上的元服务层，会有大量功能边界清晰的原子服务。比如制品库就管制品，那代码仓库就管代码，Sonar做代码扫描等。这一层，如果能有一个健壮的工作流引擎，一个可靠的消息中心，也是非常好的实践。

最上面一层，就是定义业务流的一层。企业不同的业务部门，可以按照需要灵活选择其使用哪些工具，制定合适的流水线。