The content of this article is excerpted from the record of "Eliminating Inefficient Black Hands - Qunar devops Practice Sharing " shared by Wang Xiaoxiang, then director of the Engineering Efficiency Department of Qunar , at the 6th Global Software Case Study Summit, focusing on sharing: problems in improving engineering efficiency, Results achieved, things to do. (PPT + manuscript).
Wang Xiaoxiang has been committed to the work and research of software configuration management, software quality management and software process management, and has more than 10 years of experience in the field of software configuration management. Worked successively in China Customs Data Center, Sony Mobile Communications, China Sports Lottery Technology Co., Ltd., Qunar.com and other companies.
Editor's note: On November 9-12, 2017, the 6th Global Software Case Study Summit was grandly opened at the Beijing National Convention Center, and the 2017 "One Hundred Cases List" was interpreted on the spot. Wang Xiaoxiang, the then director of Qunar Engineering Efficiency Department, brought a case sharing of "Eliminating the Inefficient Behind the Scenes - Qunar devops Practice Sharing".
[Introduction] Devops is an organic combination of culture, process and tools. Qunar has an innate devops culture and is supported by many automated tools in the development process. Driven by the traditional "what can I do" mindset, each tool is an island of information, and engineers use these tools with multiple wastes. With the help of the devops idea, the wall of the original "separate" automation tool was demolished, and an application-centered full life cycle management platform was established.
1. Existing problems
Qunar currently has 1200+ engineers, 500 project managers, 6500 online applications, 200 requirements are released every day, 3000+ beta environment updates, and 500 application versions are deployed to the online environment. The figure below is the data of the whole day on September 20, according to the statistics of the IC system. There were 3,338 beta deployments and 529 online updates.
As early as three years ago, Qunar's publishing system already enabled multiple applications to be published in a predefined order with one click. However, is the process composed of multiple single-point efficient tools necessarily efficient? Listening to the feedback from the line of business, the answer is not difficult to come up with. The figure below shows the process of expanding an online application to a machine before doing devops. The steps are cumbersome and inefficient.
Problem and root cause analysis
The above simple scenario exposes the problems we are currently facing: too many tools, high learning costs for engineers; different dimensions, inconsistent data of the same type in different tools; chaotic rights management .
There are two reasons for this:
1. Each tool is developed by different parts, and this part has different starting points due to the division of work responsibilities. This is often referred to as "departmental barriers".
2. The management objects and goals of different tools are inconsistent, which makes it difficult to integrate information, and it is difficult to promote process automation.
Qunar's devops approach: one center, two main lines
The so-called "one center " is to improve engineering efficiency as the center . Implementing devops is not the goal, improving efficiency is the goal, so we rarely talk about the word devops internally. Instead, we constantly collect and discover the needs of business lines, discover the links that affect efficiency through on-site observation, and collect high-frequency problems through the on-duty hotline. These are not only the driving force for our improvement, but also directly verify our improvement effect. The so-called " two main lines ", the first is the "application line" . After an application is registered, it is an iterative process from development to launch to operation and maintenance; the second is the "demand line". Continuous delivery focuses on the time from a requirement to delivery. The shorter the time, the more efficient an enterprise is. With the prevalence of microservice architecture, in many cases several or even a dozen applications need to be changed for a business requirement. How to manage this process to make it efficient is also very important. After clarifying the policy of "one center, two main lines", our thinking of solving the problem is also very clear. The picture below shows the macro performance of our tool platform after implementing this policy.
2、取得的成果
一、应用的生命周期管理
解决思路
为了解决过去的部门壁垒和信息孤岛问题，我们在建立应用的全生命周期管理时，第一件事情就是为每个应用创建一个全局唯一的ID：APP_CODE。一个拥有了APP_CODE的应用，就好比一个被分配了身份证号的合法公民，享有很多合法权益。以前分散在各个阶段各个系统的信息，都将与这个APP_CODE建立联系，或作为应用的基本属性，或作为应用的孤岛资产（典型资产：机器，IP）。当然应用也要“遵纪守法”，这里特别强调做devops的一大原则——规范先行。所谓没有规矩不成方圆，而没有规范的devops就是无稽之谈。
关于应用的属性：
在对应用的属性数据进行梳理后，我们把它分为三类：基本属性、部署属性、服务属性（偏运行时）。其中，基本属性数据包括：服务类型，服务归属（业务线或BU），Owner，member等；服务属性包括：对机器资源的要求，对操作系统／基础软件的要求，服务启/停配置等；部署属性包括：源码地址，打包命令，部署时个性开关等。
关于应用的资源：
我们把应用所需的机器、域名等都做为资源来管理，尤其是机器资源，能够精确到具体应用，不仅给OPS运维提供更大的便利，一旦机器出现问题可以快速定位APP_CODE的owner，而且在做成本核算时也更清晰准确。为了方便对不同用途的机器进行管理，我们又引入了一层逻辑概念，即环境。一个应用可以被部署在多个环境，一个环境可以包含多台机器。典型场景就是一个应用，先被部署在一个dev环境（1台机器），然后部署在一个beta环境（2台机器），最后部署在prod环境（4台机器）。
为了实现信息的自动整合、工程师操作的流畅，我们对原有工具进行了系统点整合。是的，是整合，而不是推翻重建，我希望你们也是这样去做。
整合后的平台（我们后面都叫它Portal）的系统结构如图所示：
当我们把原有散落在各个工具平台中的信息，按照以上维度重新定义后，应用的生命周期脉络变得非常清晰。下面，我们再看看一个工程师的日常工作模式吧。如下图：
工程师进入Portal平台后，选择要处理的一个应用便进入该应用的详情页。这个详情的版面被分为4块：（1）左上角展示应用的基本属性；（2）左下角展示服务属性；（3）右上角是线上服务的变更事件：如定时任务执行情况；服务重启；服务发布等；（4）右下角是应用的环境/机器信息，以及运行在机器上的服务版本信息。原来需要在多个系统间切换才能收集到的信息，在这样一个详情页直观的展示出来，而且高频动作也都有相应的快捷按钮，非常方便。
与此同时，我们还做了一些过程可视化的改进。
如图：
二、项目的生命周期
解题思路
与应用生命周期保持一致。在项目管理中，有两个明显的问题：（1）项目进入开发阶段的过程对于项目经理来讲就是黑盒，想要了解细节沟通成本很高。（2）项目的实际数据靠手动填写，既不及时，也不准确。为此，我们通过规范源码的分支命名规范，将工程信息与项目信息建立了联系，通过工程中的不同事件映射到项目的不同阶段，从而自动填写项目管理中的“实际时间”自动。
先以一个实际的项目为例，看看整合了工程信息后的项目管理平台都有哪些变化吧。
除了原有项目管理平台维护的需求详情，计划安排，人员信息外，我们通过嵌入页面的方式，将所有与这个项目相关的工程信息进行了集中展示。在这个工程信息窗口中，除了应用名称，源码地址，分支名称外，还将CI结果进行了汇总展示。不仅可以清晰看到进度，还可以看到质量。
能够做到项目信息与工程信息的集成，关键一点就是通过分支命名规范建立关系，即：在分支名称中包含PMOID的，之后项目管理平台通过消费各种工程类消息，进行信息整合。稍后我也会再单独介绍为我们的devops平台立下汗马功劳的消息系统IC。用下图更能直观看到消息的生产者和消费者的关系：
说到这里，不得不介绍一下为我们的devops平台立下汗马功劳的消息系统IC。IC的诞生背景就是为了降低系统集成的复杂度，消息生产者只负责发送消息，任何对该消息感兴趣的一方都可以来消费它。比如PMO中展示的工程信息，就是由项目管理平台消费了这样几类消息：
1. branch-created： 生产者——git
2. sonarResult：生产者——Sonar
3. codediff：生产者——codereview
4. beta-released: 生产者——发布系统
5. prod-released: 生产者——发布系统
IC中已经定义的消息类型已经有40多种，在我们内部工具集成中发挥着越来越重要的作用。
三、其他基础服务
测试环境管理平台Noah
当我们的服务拆分到一定程度后，马上会面临的一个新问题就是——要验证一个业务场景，需要部署N多个服务。如何提高这个过程的效率，在Qunar也有一个强大的平台支持，那就是Noah。在Noah平台，用户可以通过选择应用的各种组合快速构建满足业务测试的环境，或基于一个已有环境快速copy出一个全新环境。目前使用Noah的典型场景有两类：一类按照项目创建环境，满足开发工程师和测试工程师的验证需要；一类是满足接口自动化测试。关于Noah是值得专门写一篇文章来介绍的，这里只贴几个截图让大家有个直观了解吧。
在Noah平台新建环境，选择一种新建类型。如果是复杂的应用组合，我们建议用户以环境模版的形式保存下来，方便其他用户复用。
如果是自定义方式新建环境，用户可以按需添加应用信息，数据库，以及配置网络以及环境变量。
环境的创建过程我们也做了可视化展示，方便用户了解进度或定位问题。
环境的每一次变更我们也会如实记录下来：
一个被成功创建的环境，我们还提供对其服务的监控：
四、实践总结
提高效率、以始为终
我们实践devops的目的是要提高效率，那么第一步是要能够准确发现那些地方效率低下。精益生产中定义了七大浪费，而这些问题在软件开发过程中同样适用。发现这些浪费最直接的办法就是走进现场。去哪儿王老师的经验是：没有比现场观察更能发现问题的根源所在。
一旦找到低效的根源，接下来我们还需要用系统的思路去解决它。而不要简单的头痛医头，脚痛医脚。最终改进方案上线后，我们还要去验证那个被我们识别为低效的问题，是不是真的被消灭了。
Qunar devops工程实践总结
1. 每个应用有自己的唯一标识，贯穿应用整个生命周期
2. 每个项目有自己的唯一标识，贯穿项目管理生命周期
3. 通过分支命名规范建立起项目与工程信息打通的基石
4. 每个工具是一个独立服务，通过消息中心实现系统集成
5. 做自己工具的第一个用户
工具一览
3、还要做的事情
没有最好，只有更好，注定了提高工程效率是一条没有终点的路。接下来去哪儿在工程效率提升上，将要完成信息可追溯到可预测，过程自动化到智能化的迈进。
以上内容来自王晓翔老师的分享。
二、项目的生命周期
解题思路
与应用生命周期保持一致。在项目管理中，有两个明显的问题：（1）项目进入开发阶段的过程对于项目经理来讲就是黑盒，想要了解细节沟通成本很高。（2）项目的实际数据靠手动填写，既不及时，也不准确。为此，我们通过规范源码的分支命名规范，将工程信息与项目信息建立了联系，通过工程中的不同事件映射到项目的不同阶段，从而自动填写项目管理中的“实际时间”自动。
先以一个实际的项目为例，看看整合了工程信息后的项目管理平台都有哪些变化吧。
除了原有项目管理平台维护的需求详情，计划安排，人员信息外，我们通过嵌入页面的方式，将所有与这个项目相关的工程信息进行了集中展示。在这个工程信息窗口中，除了应用名称，源码地址，分支名称外，还将CI结果进行了汇总展示。不仅可以清晰看到进度，还可以看到质量。
能够做到项目信息与工程信息的集成，关键一点就是通过分支命名规范建立关系，即：在分支名称中包含PMOID的，之后项目管理平台通过消费各种工程类消息，进行信息整合。稍后我也会再单独介绍为我们的devops平台立下汗马功劳的消息系统IC。用下图更能直观看到消息的生产者和消费者的关系：
说到这里，不得不介绍一下为我们的devops平台立下汗马功劳的消息系统IC。IC的诞生背景就是为了降低系统集成的复杂度，消息生产者只负责发送消息，任何对该消息感兴趣的一方都可以来消费它。比如PMO中展示的工程信息，就是由项目管理平台消费了这样几类消息：
1. branch-created： 生产者——git
2. sonarResult：生产者——Sonar
3. codediff：生产者——codereview
4. beta-released: 生产者——发布系统
5. prod-released: 生产者——发布系统
IC中已经定义的消息类型已经有40多种，在我们内部工具集成中发挥着越来越重要的作用。
三、其他基础服务
测试环境管理平台Noah
当我们的服务拆分到一定程度后，马上会面临的一个新问题就是——要验证一个业务场景，需要部署N多个服务。如何提高这个过程的效率，在Qunar也有一个强大的平台支持，那就是Noah。在Noah平台，用户可以通过选择应用的各种组合快速构建满足业务测试的环境，或基于一个已有环境快速copy出一个全新环境。目前使用Noah的典型场景有两类：一类按照项目创建环境，满足开发工程师和测试工程师的验证需要；一类是满足接口自动化测试。关于Noah是值得专门写一篇文章来介绍的，这里只贴几个截图让大家有个直观了解吧。
在Noah平台新建环境，选择一种新建类型。如果是复杂的应用组合，我们建议用户以环境模版的形式保存下来，方便其他用户复用。
如果是自定义方式新建环境，用户可以按需添加应用信息，数据库，以及配置网络以及环境变量。
环境的创建过程我们也做了可视化展示，方便用户了解进度或定位问题。
环境的每一次变更我们也会如实记录下来：
一个被成功创建的环境，我们还提供对其服务的监控：
四、实践总结
提高效率、以始为终
我们实践devops的目的是要提高效率，那么第一步是要能够准确发现那些地方效率低下。精益生产中定义了七大浪费，而这些问题在软件开发过程中同样适用。发现这些浪费最直接的办法就是走进现场。去哪儿王老师的经验是：没有比现场观察更能发现问题的根源所在。
一旦找到低效的根源，接下来我们还需要用系统的思路去解决它。而不要简单的头痛医头，脚痛医脚。最终改进方案上线后，我们还要去验证那个被我们识别为低效的问题，是不是真的被消灭了。
Qunar devops工程实践总结
1. 每个应用有自己的唯一标识，贯穿应用整个生命周期
2. 每个项目有自己的唯一标识，贯穿项目管理生命周期
3. 通过分支命名规范建立起项目与工程信息打通的基石
4. 每个工具是一个独立服务，通过消息中心实现系统集成
5. 做自己工具的第一个用户
工具一览
3、还要做的事情
没有最好，只有更好，注定了提高工程效率是一条没有终点的路。接下来去哪儿在工程效率提升上，将要完成信息可追溯到可预测，过程自动化到智能化的迈进。
以上内容来自王晓翔老师的分享。
能够做到项目信息与工程信息的集成，关键一点就是通过分支命名规范建立关系，即：在分支名称中包含PMOID的，之后项目管理平台通过消费各种工程类消息，进行信息整合。稍后我也会再单独介绍为我们的devops平台立下汗马功劳的消息系统IC。用下图更能直观看到消息的生产者和消费者的关系：
说到这里，不得不介绍一下为我们的devops平台立下汗马功劳的消息系统IC。IC的诞生背景就是为了降低系统集成的复杂度，消息生产者只负责发送消息，任何对该消息感兴趣的一方都可以来消费它。比如PMO中展示的工程信息，就是由项目管理平台消费了这样几类消息：
1. branch-created： 生产者——git
2. sonarResult：生产者——Sonar
3. codediff：生产者——codereview
4. beta-released: 生产者——发布系统
5. prod-released: 生产者——发布系统
IC中已经定义的消息类型已经有40多种，在我们内部工具集成中发挥着越来越重要的作用。
三、其他基础服务
测试环境管理平台Noah
当我们的服务拆分到一定程度后，马上会面临的一个新问题就是——要验证一个业务场景，需要部署N多个服务。如何提高这个过程的效率，在Qunar也有一个强大的平台支持，那就是Noah。在Noah平台，用户可以通过选择应用的各种组合快速构建满足业务测试的环境，或基于一个已有环境快速copy出一个全新环境。目前使用Noah的典型场景有两类：一类按照项目创建环境，满足开发工程师和测试工程师的验证需要；一类是满足接口自动化测试。关于Noah是值得专门写一篇文章来介绍的，这里只贴几个截图让大家有个直观了解吧。
在Noah平台新建环境，选择一种新建类型。如果是复杂的应用组合，我们建议用户以环境模版的形式保存下来，方便其他用户复用。
如果是自定义方式新建环境，用户可以按需添加应用信息，数据库，以及配置网络以及环境变量。
环境的创建过程我们也做了可视化展示，方便用户了解进度或定位问题。
环境的每一次变更我们也会如实记录下来：
一个被成功创建的环境，我们还提供对其服务的监控：
四、实践总结
提高效率、以始为终
我们实践devops的目的是要提高效率，那么第一步是要能够准确发现那些地方效率低下。精益生产中定义了七大浪费，而这些问题在软件开发过程中同样适用。发现这些浪费最直接的办法就是走进现场。去哪儿王老师的经验是：没有比现场观察更能发现问题的根源所在。
一旦找到低效的根源，接下来我们还需要用系统的思路去解决它。而不要简单的头痛医头，脚痛医脚。最终改进方案上线后，我们还要去验证那个被我们识别为低效的问题，是不是真的被消灭了。
Qunar devops工程实践总结
1. 每个应用有自己的唯一标识，贯穿应用整个生命周期
2. 每个项目有自己的唯一标识，贯穿项目管理生命周期
3. 通过分支命名规范建立起项目与工程信息打通的基石
4. 每个工具是一个独立服务，通过消息中心实现系统集成
5. 做自己工具的第一个用户
工具一览
3、还要做的事情
没有最好，只有更好，注定了提高工程效率是一条没有终点的路。接下来去哪儿在工程效率提升上，将要完成信息可追溯到可预测，过程自动化到智能化的迈进。
以上内容来自王晓翔老师的分享。