互联网研发效能实践之去哪儿网 (Qunar) 核心领域 DevOps 落地实践

本文从业务目标角度出发，确定了开源+自建模式搭建 Qunar 研发工具链整体生态；通过 APPCODE 打通工具链，流程规范化自动化；多种手段+发布门禁助力质量提升；建立应用画像确定运维最小单元，可发布可运维；最后通过流水线加速整个流程更顺畅高效。

本文根据张春芳老师在〖deeplus 直播：逆袭生产力担当，云原生时代的运维新归宿〗线上分享演讲内容整理而成。我自己为了消化里边的内容，整理了一个脑图，各位可以把图片打印下来对照着看，这样帮助更大，另外以后翻到这篇文章通过这个脑图也能大概了解主要内容。

张春芳

去哪儿网 系统运维总监，2014 年加入去哪儿网，就职于基础研发基础平台组，近来一直致力于整个公司研发体系的标准化及效率提升，涉及开发、测试、运维等多个领域。目前主要负责全公司的 DevOps 生态体系建设，为业务交付的速度和质量提供保障。原文标题《去哪儿网核心领域 DevOps 落地实践》

今天的分享主要包含以下几个方面的内容：

一．Qunar devops 生态概览

1、项目流程

看我们生态之前，大家先看一下我们的整个项目流程。

在整个项目流程中，

• 首先是业务，我们做 DevOps 的时候一定要从业务目标出发，业务人员先去确定业务目标

• 然后进行产品的规划，规划完成之后进行产品的设计。

• 设计拆分成具体的功能，功能对应我们的需求。

• 在需求出来之后，我们进行敏捷开发。

• 开发完成后进行集成测试验证，

• 最终发布运维上线。

我们 DevOps 其实主要是致力于为产品设计到发布运维这一过程提供支持，完成服务目标。整个过程也是我们项目管理的过程。

2、目标和方法

基于整个项目流程，我们看一下我们 DevOps 的目标和方法。

这个目标和方法我借鉴了百度工程能力的定义：工程能力是使用系统化的方法，在保证质量的前提下，更高效率地为客户/用户持续交付有价值的软件和服务的能力。其中有几个关键词，首先它是系统化的方法，对应去哪儿我们这么拆解系统化的方法。

首先要有流程规范，因为有了流程规范，具体的一些落地才有章可循，而不是做各种单独的一些场景化支持。有了流程规范，我们去落地，先落地到我们的工具平台，这一层落地工具平台都是先做一些普适性的工具。但普适性的工具虽然对所有的场景都支持，但也存在对真正具体的一个场景化支持不流畅的问题，因此我们拆分出具体的场景化实践。遵循这一闭环，我们来建立我们 DevOps 的生态。

有了方法之后，我们的目标是什么呢？当然是提升交付速度。但是在提升交付速度的过程中，我们又必须保障质量，所以我们的两大核心目标就是提升交付速度和保证交付质量。

基于以上的目标和方法，我们落地了 DevOps 生态。

3、完整生态

首先看一下完整的流程。

贯穿全部流程的是项目管理。在上层，我们根据不同的域进行了拆分，可拆分为开发、测试、上线和运维。

• 开发部分包括的内容就是应用注册、代码管理、sonar、Cr 等。

  
  

• 测试部分包括缺陷管理、case 接口、测试性能、接口测试和代码覆盖率。

  
  

• 上线包括发布步骤编排、产物管理、回滚管理、负载均衡等。

  
  

• 运维包括监控、日志、事件、报警等。

  
  

上图右方是我们的一些公共服务，底层的资源是 KVM 跟 k8s。整个过程我们也遵循云原生的基本原则，开源与自建结合。图中蓝色部分是使用开源的，黄色部分在使用开源的基础上进行了二次开发，红色部分完全由我们自建。

生态是以是以唯一的管理单元——APPCODE 串联的，APPCODE 是指应用的唯一标识，因为有了 APPCODE，才会使我们整个过程可追踪，数据可追溯，服务可运维。所以 APPCODE 是我们非常核心的要素，建立生态的关键。

4、效果

建立生态之后，看一下我们现在基于生态实现的效果。

这几个数字是基于月均的数字统计。我们现在每月平均有 3000＋项目发布，15 万次＋部署，涉及到 2000＋应用，1000＋开发测试运维。由此来看，我们的体量还是相当庞大的。

值得一提的是，在这 3000＋的项目发布中，有很大一部分是开发自测自发，即完全没有测试人员的参与。这完全依赖于我们 DevOps 生态建设对开发测试进行赋能，也因此，我们的开发同学自测自发不仅保证了质量，同时也保证了我们的交付速度。

二.核心领域实践

在了解我们的生态之后，下面来具体地看一下我们在一些核心领域的落地实践。

1、规范化助力开发提效

上述分享的方法论中有一步很关键，那就是规范流程。那么规范流程有什么意义呢？ 

1）背景

下面我们来看一个具体的案例，看它如何助力我们的开发提效。

在我们公司，可能其他公司也相同，在开发项目过程中一个核心资源就是开发资源，我们的理想状态就是要实现开发资源利用最大化，理想状态就是开发人员只需专心投入写代码即可。

但是现实情况是开发同学被各种角色干扰。主要有以下几个问题。

• 对开发来说，频繁的被打扰导致其时间碎片化，在各种任务之间切换导致效率无法保证。

  
  

• 对项目经理来说，无法得知项目的实时进度，项目是在开发过程中，还是在测试过程中。因此只能去跟开发进行去人为沟通，这不仅导致了开发被打断，也使项目经理无法掌控整个项目过程。

  
  

• 对 QA 来说， QA 最终要为质量负责，但是 QA 不知道项目的这次需求变更了什么内容，这就会导致变更靠人为的梳理很容易被遗漏，从而导致上线出故障。我们有很多血淋淋的教训，因为没有更新 DB，或者是一个配置忘记更新了，上线出现过很多次故障。

  
  

• 对 PMO 来说，PMO 要收集整个项目过程的数据，通过数据去确定我们的改进优化分析，分析优化改进。但现在我们项目的所有数据全都依赖人工去填写，很难保证数据的准确性，从而给改进优化带来困难。

通过上述分析，我们可以发现，我们对于整个过程的跟踪是基于项目去跟踪的，但是这个项目变更的内容又是应用维度的，所以导致我们没有办法被跟踪，人为操作多。核心问题就是我们的应用跟项目没有建立关联关系，所以我们要去建立这一关系，从而解决这个过程中的问题。

2）方案

那如何建立关系？依靠规范化。看看我们是怎么做的。

① 分支命名规范化

我们对分支进行了命名规范的要求，分支名必须包含一个 PMO 标识。这样当分支被创建、被 push 的时候，就自动将其关联到项目上面，建立了应用跟项目的关联关系。

② 质量检查可视化

知道了项目变更了哪些内容，变更的时候每次提交都可以去自动的触发一些相应的检查，相应的检查结果报告就可以展示在这个项目上面。对于 QA 人员来说，可以直观的了解项目当前的质量状况；对于项目经理来说，可以比较直观地了解这个项目的状况，从而去控制风险。

③ 数据回填自动化

对于 PMO 来说，之前很多数据难以收集，有了关联关系之后，我们会把这一次项目的发布数据，包括发布的次数，以及变更的行数等都自动回填，相当于获取了这个项目整体的变更数据。

④ 状态流转智能化

因为我的代码已经跟它关联起来了，在开发中如果是提交到代码，可以自动从项目已排期状态变成开发状态。当我做了一些 Beta 验证的时候，就可以自动地流转到我现在是要提测了或是要发布了，所以这个状态的流转实现了智能化。结合完整的方案，我们就解决了各种开发被打断，自动化手动操作过多的问题。

这个是我们的架构。

相当于开发与应用关联的工具，我们内部把它叫做 Qodin，底层是 DB，Cache，其次是我们的数据存储，然后各个工具平台会把自己执行的一些结果通过发送消息推送到我们的消息平台。Qodin 通过消费这些消息，通过外部的 HTTP 接口触发各种工具平台去执行。上层是我们通过 js 一些页面给用户提供一些查看入口、操作入口等等。

3）效果

下面再来看一下我们实现的效果。

上图是我们的一个项目，我们可以看到这个项目中到底变更了哪些内容，首先是变更的一些质量的情况，以及它的发布情况。其次是我们自动回填的数据，可以看到包括研发阶段的市场自动计算，项目总市场等，线上发布的次数，代码变更的一些信息，同时我们在一些项目的关键节点，根据时间计算关键节点的状态流转以及是否 delay，这些都会有一个及时的项目提醒，这样保证了开发和项目经理等都可以及时地关注到整个项目过程，一旦有任何风险也可以及时地暴露出来。

总结这一实践，主要是通过规范化确定一个分支的命名规范来实现我们的应用跟项目的关联，然后保证了我们项目整个流程的自动化与高效。

2、多种手段+发布门禁助力质量保证

我们再来看一下速度有保证后如何保证质量，这就是我们的第二个实践，通过多种手段和发布门禁助力质量保证。

1）背景

我们先看一下理想，理想的状态是开发修改完代码之后，通过测试，提交给 QA，然后 QA 同学集成测试，最后愉快地上线。但实际中常常会出现开发跟测试同学的相互抱怨。

开发人员表示我测了。QA 人员却说你这提交的是什么，你自己测了没有？

QA 人员常说为什么我测试了，到上线还是会遇到问题，其实总结起来主要是以下问题：

• 对开发人员来说，首先测试条件是难保障的。开发人员做测试的时候，其实有环境的依赖，也有数据的依赖，有一些前提条件的准备。但是这些常常会特别耗时间，准备也非常困难，导致测试不足的问题。其次修复成本高，因为开发人员在前期的测试不足，提交给 QA 人员之后，通过 QA 人员发现了问题，然后再反馈给开发人员，反馈的周期就拉长了。开发人员这时可能已经进入到其他项目了，从而又有一个切换成本。

  
  

• 对 QA 人员来说，没有办法让开发保证提测的质量，更多的是依赖于自己的测试，对其来说非常不友好。还有上线的质量也难以保证，很多其实我测到了，但是可能依旧带着问题上线了。

2）方案

所以该如何避免上述情况呢？来看一下我们的实践。

① 多种手段保证效果

首先我们采用的第一个方法是先用多种手段保证效果。我们的手段包含以下几种：

• 代码 review（code review），即人工的 review，现在我们公司已经建立起了较好的 code review 文化，大家都已经形成了这种习惯。

  
  

• 静态代码检查 sonar，这个地方 sonar 不只是 sonar，在我们公司的话，主要技术栈是 Java，所以我们会在 Sonar 里边会做一些 java 规则的检查，比如说非法的包名、重复类、然后依赖多版本等检查，同时也会把一些原数据的信息记录下来，例如记录变更的内容，变更的依赖等。除此之外也会做 sonar 本身的一些规则级检查，我们这个规则也会定期做 review。

  
  

• 接口自动化，接口自动化我们分了两部分，第一部分是我们的线上回归测试，所用回归的工具我们叫灭霸，它会在每次开发提测时自动执行，把线上现在存量的一些接口做回归验证。如果你是新增的业务接口的话，我们也会有一个自动化测试平台叫 Qunit，它是基于 unit 的，去做一个新的业务的验证。

  
  

• 代码覆盖率检查，我们 sonarqube 等各种的自动化工具，都可以看到当前的测试的覆盖度。测试覆盖度这块大家其实一直有一个疑问，那就是我测试的时候就是代码百分百覆盖，也不能保证上线完全没有问题。但是反向也有另外一种说法，起码百分之百覆盖了，还是会增加一定程度信心的，所以覆盖率是非常重要的。

  
  

② 环境管理提升测试速度

手段多样是有前提保证的，尤其接口自动化有环境依赖，如果没有环境做接口自动化或者没有这个环境管理，接口自动化、执行接口自动化的可行性或速度都是没有办法保证的，所以我们又有一个环境管理平台，通过这个环境管理，我们可以快速的交付一套环境，这个环境中包括了自己的应用以及它的依赖，为自动化的可行性提供了保障。

③ 报告消息反馈结果

自动化的可行性有了，多种手段也有了，最后的这些报告信息怎么通知给开发人员？我们做了多维度的报告展示，包括项目维度，个人维度，还有组织维度等，同时我们也会通过内部的 Im 消息精准的通知到具体的开发人员，这样方便他可以快速地解决问题，相当于质量阻力左移，降低了问题修复的成本。

④ 质量门径预防蔓延

我们会结合我们的项目管理系统、发布系统等去做质量卡点，如果不通过，我们就会去做一个拦截，然后避免带着问题上线。

上面说了我们具体的方案，下面让我们简单地看一下多种手段，我觉得在现在这个阶段，大部分公司都会有这几方面的保证，我这个地方只简单介绍我们公司的一些特色点。

• 在 CodeReview 方面，我们是基于开源工具 phabricator 实现的，我们会做到分支创建后自动同步仓库，同时代码 push 的时候自动去创建更新 diff，这样就避免了人工去创建以及后续操作。同时我们支持两次提交 diff 的变更，这是为了解决发现问题并修改重复提交后的全量 diff 问题。不需要全量的再次 diff，只需要看这两侧的一个变更。当然如果影响范围较大的话，还是建议全量的再 diff 一次。

  
  

• 静态代码检查方面，我们使用业界通用的 sonarqube，但我们的特色点是代码 push 的时候它会自动执行，然后消息反馈。同时我们有增量跟全量的报告。我们有很多历史在的基础上，如果你要求它去全量的解决问题，这在业务非常繁忙的时候是不现实的，所以我们做了增量，只去检查当前这次变更引入的问题，只要解决了这些问题并能够保证不新增，后续再去慢慢地解决全量问题。

  
  

• 接口自动化方面，接口自动化这里我讲的是灭霸即接口回归问题，接口自动化大家最头疼的就是要自己去写 case，业务变动又比较频繁。我们的时间点是怎么做的？我们会基于检查点的 case 自动生成补全清理。例如航司，航空公司是有很多公司的，比如说南航、国航、川航等，相当于每一个航空公司对应一个业务，我可能就要对这一个类型去进行验证，所以我们需要用户先定义一个检查点维度，然后业务在线上执行的时候，会去生成日志，我们通过日志去采集这些具体的 case，再生成补全。当过了一段时间，如果检查点没有这种业务的 case 请求了，我们就可以自动清理，这就解决了我们人工维护 case 的一个痛点。

  
  

• 代码覆盖率是基于 Jacoco 实现的，也是增量跟全量的一个报告，可以看这次变更的一个覆盖率情况。

  
  

上述是多种手段，下面看一下我们的测试环境。

我们对环境的定义是什么？这个环境肯定不是单应用的环境，这种单应用的环境是对于整个业务的测试，它起到的作用是非常薄弱的。所以我们对环境的定义是支持一种业务测试，能支持一种业务测试的应用去依赖以及它所用的资源的一个组合。所以我们环境的组成就包括 AppCode、数据存储、中间件、网络配置、环境变量等。

环境有了，但是不可能每次进行一个业务测试或项目测试的时候，都去重新搭建一套环境，这样成本是非常高的。我们之前去做项目复盘时，对于 delay 项目大家吐槽最多的是为什么 delay？是因为环境问题。所以我们把环境的这些信息做成了模板可配置，这样就实现了资源与信息的积累沉淀。

其次是业务巡检。开发同学、测试同学只是去使用提供的环境，服务提供方要保证可用性，让开发同学只是去用它，而不是再去为它的可靠性分担精力，所以我们有业务巡检。

我们之前创建一套环境后就实现了完全的资源隔离，相当于有一套环境给全部的应用分配资源，这是对于资源的极大浪费，同时创建速度也很低，所以我们又做了一个软路由环境，基准环境跟项目环境。

下面我们通过下图来详细解说。

• 首先是环境创建的流程，上图中我们可以看到我们包含了环境，即应用及其依赖，所以我们会先锁定资源，包括 Kvm、 DB 这些东西，然后再进行采集编排，然后去触发任务执行，调度执行。

  
  

• 其次是业务巡检，我们会定期去调用业务线提供的一些全链路测试 case，定期去执行，验证这个环境的可靠性。同时我们也会去消费一些变更消息，包括配置变更、代码变更、数据变更，去同步这个环境，这样就保证了我们基础环境的自运维。

  
  

• 然后是软路由，我们会有一套基准环境，是全链路的，包含了全部的应用，但是对于项目来说，只需要建环境值，包含自己变更的这些应用以及它的一些 DB 依赖。在真正业务测试的时候，从网关进来，如果在软路由，即自己这个项目环境里边有，我就会走到自己项目环境，如果没有就会请求到基准环境。从这个层面来看，项目对应的环境它只包含自己本次变革的应用，对资源的节约是非常大的。同时因为应用少了，我们创建的速度也提升了，这样就会保证在我们的测试过程跟开发过程中，环境不会成为瓶颈了。

下面看如何解决带着问题上线这一问题。

我们的质量文件叫 Cable，它会消费各种自动检查手段、自动化工具执行的一些结果，把他们推送的一些消息推送到 IC 中，然后我们的质量文件在消费这些消息的同时提供接口给 Qodin、发布系统进行拦截跟结果展示。

自动化工具我刚才介绍了 4 种，我们内部还会有一些项目流程、慢查询等自动化工具。这些工具并不全部都是我们来提供的，有很多是业务线来提供的。这是因为我们在实现 Cable 的时候，采用了一个通用的方式，即定义了一个通用的接入标准——业务线各种检查手段，你只要把你的结果推送 IC 消息即可，这样的话如果你某个业务线有自己的一些检查工具，你只要按照这个标准去推送消息，我就可以快速地接入，在你的业务线去落地，这样能极大的发挥整个业务对自己质量负责的积极性，同时也会更有利于我们整个公司的质量保证。

3）效果

① 环境效果

这个是基于之前环境不隔离即完全资源独立的情况下做的方案，可以看到我们有应用 83 个，数据库 23 个，中间件 7 个，我们能保证 10 分钟之内交付，每一次变更都会有一些变更记录。这是基于资源完全隔离的情况，基于上述新方案，我们应用精简后，环境交通速度就更快了。

② 质量门禁效果

这是质量门禁现在的状况。

我们上述说到，业务线也可以提供各种各样的检查手段。我们现在有丰富的检查手段，业务线根据自己的配置去选择需要的一些手段。这是我们组织维度暂时的质量情况，最终我们做的各发布系统集成的发布拦截。

总结这一部分的话就是质量，我们通过多种手段加发布门禁，确保了我们的质量。有了流程，保证了质量，我们现在要去发布上线了。

3、应用画像助力发布运维

1）背景

理想是测试完了，直接一键点击发布按钮上线。但是现实往往不是如此。

QA 人员发布时，先要去 OPS 那边申请机器，再去配置发布步骤，即发布的一些相关的信息，配置非常复杂，前期需要许多准备工作。

对于开发人员来说，开始运维，如果线上出现了一个问题，要先找到它这个机器的资源，然后再去找应用，找代码，这是非常割裂的。

还有一个问题，一旦遇到问题的网络，还要去各个地方找这些信息，定位也十分困难。

所以总结起来是什么问题？

我们会各种工具平台，虽然大家现在强调一站式的，但是在背后的话，各种资源服务还是不同的 Team 提供。因为不同的 Team 提供的时候只关注自己管理的领域，所以它的管理维度是不一样的，这样就会导致管理维度不一样，这些数据信息无法串联起来。

2）方案

① 应用画像

基于这个问题，我们可以思考一下，我们真正发布运维的到底是什么东西，它最小单元是什么？我们确定了我们最小的管理单元，其实就是我们的应用，那么我们应用有哪些属性呢？我们就猜出了我们的应用画像，包括基本属性、环境属性、发布参数和依赖信息。

• 基本属性是身份，Appcode 就是它的唯一标识。

这里强调一下等级，之前也有人问我等级有什么用，等级是非常有用的，我举个例子，有了等级，你才知道你这个服务的重要程度，你在运维的时候你才能知道优先把资源倾斜给哪些应用，先去运维哪些。

• 环境属性，包括应用要运行的软硬件环境配置等。

  
  

• 发布参数，包括编译参数、打包参数、发布策略等。

  
  

• 依赖信息，包括我有哪些网络依赖，例如我们的域名 owner，数据库依赖，以及服务之间的调用关系。

  
  

② 发布流程

只有真正拆分出来我们管理的最小的单元是什么，我们才可以对它进行运维，进行发布，所以我们基于应用画像拆分出应用。下图是我们的一个发布流程。

首先是应用确定了自己的应用画像，然后使应用画像存在一个配置系统中，然后调度系统去从配置系统拿到一些配置，完了出发到我们 Jenkins，部署到各种的调度资源中。

这里要强调的是我们这个地方有一些自定义的阶段，通过这些自定义我们可以把那些非标准的过程纳入进来，业务线就可以在这里去做自己的适配。

③ 运维流程

运维也是基于一个应用的，当一个应用的某些指标报警，我就可以去快速地找到应用对应的 Trace 链路、日志、事件系统。

根据这三板斧，我就可以去定位到我的问题，最后对应我们的运维系统去做对应的运维操作。

3）效果

这是我们的应用画像效果。其中有应用形式配置，包括它的一些服务依赖属性，服务调用属性。

上述是我们发布的过程，可以看到在发布过程中我们可以知道当前的发布进度，还会对接我们的异常日志，以及报警信息。还有我们的监控，变更的事件，Trace 链路，这三板斧实现了我们对应用的可运维。

4、流水线助力持续交付

最后是流水线。我们刚才说的是对单应用的管理，但是其实真正项目的时候是多应用的发布，多应用的交付，所以我们拆分了两种类型的流水线，第一个就是单应用的流水线，包括拆开发、测试、集成和线上。

流水线的好处我想大家应该都知道，我这边总结两点：

• 使整个流程更加的自动化；

• 使一些上游的数据向下游传递。

  
  

我举个例子，我们开发测试的流水线在这个过程中会产生一些数据，例如 DB 变更，DB 的配置变更，定时任务监控等，这些都可以自动的识别出来，这样的话就可以在线上的时候自动把这些信息拿到，然后业务线只需要改一下 Beta 和线上的一些不同配置以及具体的值即可，这样我就可以不用人工地去各个地方信息搬运，线上也可以快速地交付。

单应用的交付完成之后，其实是更多的不是项目维度，项目维度我们可以组织让业务线去做人工地编排，编排应用之间流水线以及它的一些前置依赖。

在一般情况下交付到了发布就完成，其实我们在发布完成之后还可以做一些服务治理健康保障，例如我们有触发的压测，以及强弱依赖等。

这就是我们具体的实践。我再总结一下，具体实践第一是规范化，保证我们整个流程的顺畅与自动化。第二是多种手段保证质量，质量门禁保证问题的蔓延。第三是拆分应用画像，使画像确定我们的运维最小单元，实现可发布可运维。第四是通过流水线使我们整个流程更顺畅。

三、未来规划

最后再来看一下我们近期的一些规划。

1、开发平台

第一部分是开发平台。在整个开发活动过程中，所占比例最大的还是写代码，我们怎么能让写代码效率更高，所以我们计划做一个开发平台，其实也是一个开发插件。这个插件主要有哪些功能呢？

它可以接口调用自动生成，我们会有原数据信息中心，去采集我们现在整个公司提供的接口信息，然后业务在开发代码的时候就可以自动拿到这些依赖，然后自动地生成代码。

生成代码的同时，它还可以进行一些服务治理的配置，后续我们希望联动其他的工具，例如我们联动 qconfig(配置中心)配置自动生成以及联动我们的服务治理，然后自动生效等。

开发平台，极大地提升我们的开发效率。开发平台最终要达到的效果就是让我们代码编写更简单，规范落地有载体，服务治理更有效。

2、混沌工程

第二部分混沌工程，这篇文章有详细的介绍。

《又一宕机事故！都怪当初没做好故障演练系统……》

3、服务可观测平台

第三部分是服务可观测平台，刚才我们说了基于应用画像让我们应用做到可观测，可发布，可运维，但是其实对于它整体的状态，我们还需要有一个可观测平台。基于云原生的思想，让我们的应用服务可观测，它主要分为三个领域的实践。

• 系统技术先进性，系统当前使用的是不是 TC 组件，TC 组件是不是最新的，TC 组件它其实是所有服务的一个基石，后续的 Trace 链路，各种的治理全都依赖于它。技术先进性可观测之后，尤其是团队维度，在整个公司技术演进的时候，我就可以先着力地去改进它，去发力去做一些感性的应用。

  
  

• 健康度，系统健康度是指我当前的系统是不是有报警，它是不是多机房灾备，质量保障手段是不是足够健全等，我可以据此了解应用的健康度。

  
  

• 一旦遇到了问题，我们可以快速定位，像上述我们说的日志、Trace 以及监控等。

已上是分享的全部内容，大家如果有什么想法，欢迎在评论区提出~

>>>>

Q&A

Q1:在 CI/CD 流水线执行通过后才可以进行 test 测试流水线执行。怎样控制两个流水线的执行顺序？建立两者的关联?

A1：我有三点建议。第一是流水线的出发尽可能的做到自动化，自动化的话就相当于避免人工的处罚，这样你的顺序基本上就可控了；第二是设置卡点，流水线需要有一些前置的卡点，就是达到什么标准，然后才能去执行这条流水线，这样就解决了这一问题，CI/CD 不通过是不允许执行测试流水线的；第三是在一个项目阶段，流水线其实是对同一个应用来说，或者是同一个应用同一次提交来说，它其实不是说同一次提交。同一个应用来说的话，流水线是区分开发，测试，集成，最终到线上的，所以我们可以确定一个唯一的标识，然后每一个流水线里边都会有一个唯一标识，可以把这个过程给串联起来。

Q2：怎么建立度量体系？

A2：我有几点建议，首先度量一定是为了解决问题的，我们做度量的时候，先要确定我们需要解决的问题的痛点是什么。根据我的理解，度量不是面向一线工程师的，所以在做度量的时候，一定要与 TL 一层的管理对齐目标，对齐目标需求，再建立对应的指标体系，进行指标的采集，度量。度量其实分为过程指标和结果指标。我们一般做度量的话，度量格就涉及到考核了。我觉得做度量这件事情，你首先要确定你为了做这件事情，可能需要获得更多的支持，我们要先去拿结果指标跟上层对齐目标，然后获得更多的资源，再去根据具体问题看过程指标。最后一个原则就是 MARI 原则(度量分析回滚改进原则)，我们遵循这个原则，让数据说话，用数据去解决问题。

Q3：如何进行需求的分层管理？

A3：我说一下我们公司的一个具体实践。我们公司是采用 OKR 的管理机制，首先我们确定了整个公司的业务目标，然后各个团队去制定自己的 O 目标，之后根据目标去设立对应的一些结果指标，然后结果指标再去拆分成具体的一些产品需求，再去对这个需求进行跟踪管理。所以就是分了三级，对于上级来说，我们关注的是整个目标的情况；对于中层来说，关注的是结果指标这一层，看这一个点我是不是要达标；对于一线来说，关注的是需求的交付。

Q4：DevOps 是不是一定要基于一些方法论？

A4：比如说项目管理，我们一般与敏捷相结合的话，有了敏捷方法论，然后我们去落地这个项目管理，例如现在最常用的是看板管理，它使用这些方法论会让我们解决问题更快捷，更高效，但是它不是必须的，比如说 TDD，我们在建立 DevOps 体系，当初并没有 TDD，TDD 测试驱动开发其实是在最近几年体系比较完善的时候才要做的事情。所以在没有这些方法论之前，我们做的是一些单点的提效，当然有这些方法论的时候，我们去做参考，然后把这些单点的流程做场景化的落地实践。理论跟实践结合起来，我觉得会达到更好的效果。前两天看一些大佬们分享，DevOps 实践其实是重在道法器术，道当然指的方法论，所以在一些方法论的指导下我们去落地实践可能会更好一点。

Q5：DevOps 跟 SRE 有什么区别？

A5：下面是我的一些理解，可能有些偏颇，然后大家如果觉得不合适，我们可以再探讨。从内容方面，我觉得是 DevOps 是一套方法论，它最终的体现是落地到一套工具，平台，它包含了项目管理、开发、测试、运维等多个领域，而 SRE 主要还是在运维领域；从目标层面来看，DevOps 是保证项目过程的质量和目标，当然它也对最终服务的健壮性负有责任。但是 SRE 主要还是为服务的可靠性提供保障；从执行人员来看，DevOps 发起方一般可以是 PM，质量保障运维或者工具等团队，而 SRE 主要还是运维人员。所以从我的理解层面来说，DevOps 是囊括运维领域的。 

相关阅读：

五八同城(58.com)研发效能建设

https://xie.infoq.cn/article/f7bd15594f324a6795469d9f6

滴滴(didi.com)工程效率建设

https://xie.infoq.cn/article/2f22d2f99ca676970fd211e33

去哪儿网 (Qunar) DevOps 实践分享-王晓翔

https://xie.infoq.cn/article/d3d027cb2d911aad91db0a4e7