这是 2017 年王晓翔在 msup 全球软件案例研究峰会上的分享，重点分享了提高工程效率过程中存在的问题、取得的成果和要做的事情。内容详实，具有可操作性。我有幸看到了，所以在征得晓翔的同意下重新截图、排版后发了出来。希望大家读有所得。
可能和去哪儿有缘吧，认识好多去哪儿的朋友，包括董老师，晓翔，唐老板，张宁等好多小伙伴。曾经有次和晓翔团队有过交流，团队里的每个人都给我一种踏实的感觉，都是干事出活的。其实我们内部在做应用中心的时候，找到了网上唯一一篇应用中心的文章就是去哪儿网的。我一直觉得去哪儿的技术比较扎实，去哪儿网的很多技术文章都很干，干货的干
我的老东家 IGT 之前就在苏州街，之前我们那环境还可以，自从去哪儿搬过来啊，他们就把我们给卷的吃饭没地啦，赶地铁没座，电梯上不去也下不来，有的时候赶点我要向上爬 18 层楼。但是每次看到楼里楼外的年轻人，让我这种喜欢折腾的人莫名的感到一股活力。青春不就是应该这样么，遇到值得做的事情，投入激情，一往无前的干它。我当时真觉得就凭去哪儿这股干劲肯定能把携程薅下来，谁哪知道携程不想一起玩儿了，直接掏出一沓美金甩给了百度把去哪儿合并了。
我自己为了消化里边的内容，整理了一个脑图，希望对大家有帮助。
原文题目《消灭低效的幕后黑手——Qunar DevOps 实践分享》
2017 年 11 月 9-12 日，第六届全球软件案例研究峰会在北京国家会议中心盛大开幕，现场解读 2017 年「壹佰案例榜单」。时任去哪儿工程效率部总监王晓翔带来《消灭低效的幕后黑手——Qunar devops 实践分享》的案例分享。王晓翔一直致力于软件配置管理、软件质量管理和软件过程管理方面的工作和研究，拥有 10 多年的软件配置管理领域的从业经验。先后在中国海关数据中心、索尼移动通信、 中国体彩科技有限公司、去哪儿网等公司工作。
devops 是文化、流程与工具的有机结合。Qunar 具有先天的 devops 文化，在研发过程中有很多自动化工具的支持。在传统的“我能做什么”的思维模式驱动下，每个工具就是一个信息孤岛，工程师使用这些工具存在着多种浪费。借助 devops 思想，拆掉原先“各自为政”的自动化工具的墙，建立以应用为中心的全生命周期管理平台。
1 存在的问题
去哪儿目前有 1200+工程师、500 个项目经理、6500 个线上应用、每天有 200 个需求发布、3000+的 beta 环境更新、500 个应用版本被部署到线上环境。下图是 IC 系统统计出的 9 月 20 日全天数据，beta 部署 3338 次，线上更新图 529 次。
早在三年前，Qunar 的发布系统就已经可以做到多个应用按照预定义的顺序一键发布了。但是，多个单点上高效的工具组成的过程，就一定是高效的吗？听听业务线的反馈，答案就不难得出。下图，是在没有做 devops 之前，线上应用扩容一台机器的过程。步骤繁琐，效率低下。
问题及根源分析
从上面这个简单的场景暴露出我们目前面临的问题：工具太多、工程师学习成本高；维度不同、同类数据在不同工具中不一致；权限管理混乱。
究其原因分为两点：
1. 各个工具由不同部分负责开发，而这个部分由于按照工作职责划分，所以出发点不同。这就是经常说的“部门壁垒”。
2. 不同工具的管理对象和目标不一致，导致信息集成困难，流程自动化就很难推进。
Qunar 的 devops 方针：一个中心，两条主线
所谓“一个中心”，就是以提高工程效率为中心。实施 devops 不是目的，提高效率才是目的，所以我们内部都很少去讲 devops 这个词。而是不断去收集和发现业务线的需求，通过现场观察发现影响效率的环节，通过值班热线来收集高频问题，这些不仅是我们改进的原动力，也可以直接验证我们的改进效果。所谓“两条主线”，第一条是“应用线”。一个应用被注册后，从开发到上线到运维，是一个不断迭代的过程；第二条是“需求线”。持续交付关注的是一个需求从提出到交付的时间，这个时间越短说明一家企业越高效。而随着微服务架构的盛行，很多时候为了一个业务需求需要改动几个，甚至十几个应用。如何管理这个过程让其高效，也是非常重要。明确了“一个中心，两条主线”的方针后，我们解决问题的思路也非常清晰了。下图是落实这一方针后，我们工具平台的宏观表现。
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 还要做的事情
没有最好，只有更好，注定了提高工程效率是一条没有终点的路。接下来去哪儿在工程效率提升上，将要完成信息可追溯到可预测，过程自动化到智能化的迈进。
Q&A
Q：配置中心可以解决配置带来的效率问题，想知道去哪儿的配置中心如何实现？能不能讲一下基于开源框架和自主研发。
A：这个平台是我们自研的，它的初衷是为了做到应用和配置的剥离，在代码中不要有配置的东西。
Q：应用之间的依赖是自动分析出来的吗？应用服务的注册是基于某种自动发现机制吗？
A：依赖关系目前来说不是自动发现，我们内部有 rust 数据，所以那个数据我们分析的不全。目前还是靠人工配置这个数据，但是我觉得不远的将来我们可以解析依赖数据。关于先注册还是基于发现做这个问题，首先一定先有这个标识才能去发现，如果连这个 ID 都没有其实无从谈起，注册一定是手工先做的事情。
Q：jira 的项目质量表格是怎么实现的？自己开发插件还是 jira 的某个可定制页面？
A：表格是自研的，大家如果有 jira 的二次开发经验并不难。插件也是自己开发的。
以上内容来自王晓翔老师的分享。