从工具系统到智能平台-滴滴DevOps建设和演进之路

白凡

讲师：武鑫
编辑：白凡

讲师介绍：
我叫武鑫，来自滴滴出行，我之前在跟阿里合作进行转型，还有Devops建设，今天很高兴来到Devops2018这样的场合，在座的跟大家分享一下我们做Devops建设方面的经验，希望和大家碰撞出思想方面的火花。

整个演讲分为四个部分：

• 第一个做滴滴Devops的现状
• 第二个部分会回到当时我们怎么起步的
• 接下来是怎么做的不断深入的领域系统
• 第四个体验驱动的智能平台

1. 滴滴Devops的现状

先从现状讲起，从一个乘客联系不上司机的小故事讲起，大家都用过滴滴打车，我叫一辆车，司机也接单了，就是联系不上司机，打不通电话，这个时候就要取消重叫一辆车，在以前的版本，取消重叫已经过了等待时长，这个时候是要扣你的信用分，从用户体验来讲还是不太合理的事情，乘客是无责的，没有联系上司机这一点不应该扣乘客的钱或者是积分，这需求简单，最后一通电话没接通，豁免用户不就行了吗？

就目前来讲在滴滴目前做这样的需求是有很庞大的Devops在跑，从需求来跑需要做不断的需求评审，要不要排期，不断的去反馈，这个需求是不是合理的，供应商的模块，进入开发运营以后，会做大量的验证工作，包括自测，Codereview，自动化测试，QA测试，预览，需求会做云端测试，还有底部的测试。

等它进到线上以后，依然是在不断快速反馈，上线以后就会有大量的监控，除了机器层面的监控，还有业务指标的监控，线上统一治理监控，最后在评估运维，会做客户行为分析，收益评估，还有 A/B testing 分析，包括需求的收益到底怎么样，右上角我们会把实验组合对照组的情况全部数据拉出来，当年我们做的最后一通电话没打通，豁免用户的需求整个投资量下降的比较明显，用户在线下降量还是比较明显的。

在产品需求域我们会用大量的评审，包括技术、产品里面的评审，在代码开发运维我们会做大量的验证，也有人的验证，也有车的验证，在线上运维可以做大量的监控，机器层面、业务指标层面，在整个效果评估运维结合大家的实验，整个网络当中就是在强调快速反馈，在每个域都是在做不同的反馈，去做修正，这是我们一些去年我们做的一些数据，去年的代码量应该是增加了90%，全年我们做了几十万次的构建， A/B testing 去年增加了几十倍，整个容器数量也增加了数十倍，我们在交付的时候往前做了一点，我们的APP是固定两周一发的，但是我们的服务端是随发的，现在的规模大概会随发数百次。

这样大的研发规模，而且今年的数据还没出来，但是今年上半年在这个规模上又发了好几个数量级，我们怎么做到的？实际上因为我们有大量的Devops工具系统的LOGO，每天滴滴大量的PM研发人员测试、运维人员在平台上面去做各种各样的研发协同来支撑在这样的业务量上才能支撑住，我们做到今天也不是一蹴而就的，跟大家回忆一下当年我们是怎么上线的，有一天我们有一个同事用了我们最新的研发平台以后发了一个朋友圈，终于要换了，这是当年上线的情况，上线内容是什么，上线文件把什么版本，懂的人一看这就是做SVN，把什么版本上到哪儿去，上线时间，回本方案，当时我们的运维人员、研发人员就在线上去进行操作，去连接、上线，如果我们一直是这样的上线是支撑不住这样的模式，我们怎么样一步步走到现在，我们有一套完整的工具平台体系去支撑这样大的研发量？我想跟大家一起来回应一下，我们走过的这条路，在这条路上的选择，可能会对大家更有意义一些。

2. 当时我们怎么起步的

先从概念讲起，我们从最早做的时候，我们做的是效能，什么意思？除了保证效率和质量，我们还会格外注重效果，刚才我们讲的线上的评估，我们认为效能是在效率和质量的基础之上再加上效果才等于效能，我这三者是一个 trade-off 的关系，从做事的角度，我们最早是从外采的系统来做成的，没有什么别的办法，最早我们也是用 Jira\Confluence\gitlab等，慢慢像愚公移山的过程，慢慢的爬山，爬到了我们开始做解决问题的特定资源系统，我们有了自己的交付平台，DPM。

DPM是我们APP端研发的系统，阿波罗是我们配置可分发的平台，AlphaCloud是我们容器云的平台，慢慢由资源系统进化到语音系统，慢慢把工具系统做合并，变成现在的项目的管理平台，交付管理平台，现在我们的这个点位，我们在做不同领域的系统和数据流程上去做整个过程的可视化和全程分析，是做全流程的分析和数据挖掘，接下来会简单详细讲一下我们爬山的过程。

最早其实是问题驱动，开场之前先跟大家分享一下DevOps，现在Devops很火，现在Devops的落地成本还是非常大的。

• 首先是变革成本大，首先会涉及到基础设施方面的改造，需求、代码、构建、测试、部署，甚至更多的工具都会被引进来去做改造。
• 第二个是软件架构的改造，容器化，微服务化，服务网络。
• 还有组织文化的改造，协作形式、组织架构。

这些做起来只是简单几个字，但是做起来都会很花成本。

第二项是建设周期长，第一个改变用户的习惯是需要时间的，而且需要大量的时间，刚开始用户的信心是满满的，如果一旦发现不符合他的心理预想马上就会下去。第二个从试点走向全面推广需要时间，如果大家做Devops就会发现一个问题，我们能在一个小团队玩的很好和初创的产品或者是成立 Startup 的产品，玩的很厉害，但是往重的业务团队去套，就会发现套不上去，一些比较重的业务团队，而且开发的模式和小团队完全不一样。

最后一点是效益评估会比较难，难的第一点是指标选取比较困难，虽然我们有大量的指标，如果是从需求层面来讲，我们有大量的工具、指标可以去选，很尴尬这个数据的准确性和有效性是很难保证的，比如说实时需求，那你肯定要知道需求的时间，假设有的人是在表格上面去进，根本没有办法去采集，我们在建设过程当中发现的Devops很难的点，我们怎么破局的？

通俗来讲我们把Devops建设这个事情当成了互联网产品在做，互联网产品怎么做？就是高频刚需，当时这几年以前，需求管理的混乱我们就开始利用 Jira/Confluence 快速去打造项目管理的能力，比较高频的，大家都知道 Jira 在故障管理上是有独特的优势，如果切入你直接从 Jira 切这个事情就会很艰难，要做容器化，要做各种基础设施的改造，短期就没法取得收益了，本身故障完了这一块对需求管理来说相对来说是低频的，从高频场景切进去快速打造。另外一块就是刚需的场景，我们最初的时候由于代码、构建不统一，我们做了迁移git，我们统一了Jenkins，Jenkins搭建也没什么难度，效益还不高，什么叫刚需？有的时候我们做Devops切入可能会从测试级，但是大家都明白有一些小项目测试他们的压力很大，没有时间测试，你如果从测试接入，你是进入不了研发开发的主流，根本没有办法渗透到整个研发活动当中去，导致你的实践很难落地，会导致我们刚需的场景。

另外找一些低成本，易度量的场景，代码质量差，代码无评审，这些都是开源的软件，很容易建起来并且很容易取得效果，我们自己写了一个用了SonarQube对比以后的效果，左边这张图是问题不同下降的趋势，右边是代码变化量的趋势，我们可以看到组织变化量很大，不断有代码进入，但是整个问题得到了控制，你用这两张图很容易的说明我们的工作是有效果的，我们的代码要变化很大控制了代码的需求，这是当时最早切入的方式，从问题驱动、场景驱动的角度，高频、刚需的场景去切入，这种做法也会产生一个问题，你会引入大量的工具，当时把我们的阶段叫做工具箱阶段，只要能解决具体的一个具体问题我们就把它引入进来。

Jira快速满足业务需求，这个可能远远比它没有容器化，或者是没有故障管理、熔断，这些问题相较而说，更需要项目管理，另一点就是快速解决通用的问题，做代码扫描，当时做了以后，也有团队提出来能不能做定制化扫描，Package A 摆弄韩 Package B之类的，我们也接了这样的需求，后来做完之后发现，这个路子不太对，因为你很难规模化，这个团队它是这样的，下一个团队不是这样的，你很难把你的功能实现做规模化，只能在小团队去做规模化，这样就进入了第二段，不断深入的领域系统，当时我们也深刻的反思了我们大量引入开源采购工具的问题。

首先是整个工具链整个链接会过于松散，每个工具的功能都比较单一，明明可以一次性完成的事，但是要分散很多，看代码你要去Git，你做CI/CD，可能要跑Jenkins，你做CodeReview要去Phabircator，你看代码质量要去SonarQube，还有更多独特的东西，这实际上从本质来讲是完整的链路，很多的工具效率是很低的，另外就是开元和外采的工具没有办法去做深入的整合，改造成本很大。
比如说常见的一个需求，客户都会提一个需求搞一个功能叫体测，很常见，如果是外采你要做这个事情很尴尬，如果做Jira，我们去定制界面，如果Atlassian不是买全家桶，接下来跟你的CI/CD系统互相调用的时候就会发生很多问题，有一些开源的插件但是不一定好用。

还有Jenkins的需求，如果我们把它移到Jenkins，我们要做的Jenkins的插件，需要把价值流可视化出来，像工具箱价格里面摆了一些锤子、螺丝刀什么的，想用哪个用哪个，这个时候你根本没有办法做端到端的流动。

最后一个用户黏性差，没有办法固定研发流程，随着组织变动，往往无法持续改进，我们在小团队做的相当成功，团队的leader也非常买账，由于这个团队的成功，这个团队leader就升职了，你就会发现慢慢你做的事情就没有人再用了，我们做的事情没有固化的研发流程，跟他的研发流程是没有关联的状态。

3. 不断深入的领域系统

接下来就开始做我们的第二个领域系统的建设，这就是我刚才讲的工具箱，当时我们已经做了太多的工具光项目管理就有五六套，代码相关的工具也是很多，在持续交付领域也是有很多，效率验证平台也是，服务运行中心也做了很多，就存在我刚才说的事情，分离的比较厉害，也没有办法端到端，按照我们研发的领域去做聚合，比如说项目管理领域，IT管理领域，持续交付的领域，效果验证的领域，服务运行的领域，去把工具不断的做整合，去试图把所有的领域打通，在下层加上我们VM和容器的融合，这是领域系统。

最后一个会讲到在领域系统之上之下在下层做的数据挖掘。在上层会做用户体验。

我着重讲一下跟数据交付的数据，做的就是如何固化研发全流程管理，主要是三个方向，一个是构建的管理，刚才有一个同事来问，可以去聊一下这个问题，构建管理主要是做全云端构建，集成管理主要是做自动虚拟令牌，测试管理这一块主要是云端的测试，先从构建管理讲起。

我们分析了一下Devops研发链路当中从哪一点切进去做最合理或者是延展性最强，我们曾经考虑选项目管理领域切近，后来发现项目管理太浅了，也曾经考虑到从运维领域切进去，从后往前推把链路做进去，后来发现链路领域太后了，我们做领域系统是从构建系统切进去的，我们开始去做统一的全云端的构建系统，这个整个也会引起整个公司大量的迁移，不能说没有任何优点，我们主要是从三个角度牵引着用户，一个是效率，一个是稳定，一个是智能。

从效率来讲主要是做代码和缓存，在我们云端会做代码缓存，对于构建系统克隆造成的效率影响还是蛮大的，你可以做代码瘦身。

第二个我们会做预构建，就是预测用户的行为，根据他的频率或者是使用习惯去预测，或者是只要准备这个包上线，那个包已经打好了，或者是正在打的过程当中我们会把这个过程无缝的连起来。

再一个就是自动缩扩容，一般用好了Jenkins就会出现排队的现象，他们构建的团队五花八门，会把Level做上去做构建，资源又很有限，最后就越来越多，上去Jenkins就一大堆人在那儿排队，由于我们把所有的构建体系都缩在了一起，我们就可以做资源的自动缩扩容，整个构建集群的调度都是弹性的，发现哪个业务是比较频繁的。

最后一点是智能分配，刚才我们做的构建系统会利用最大限度去利用机器上已 有的东西，举个例子，比如说做镜像构建我们会看长期拉的镜像在哪些机器上有，大量节省它的构建时间。另外一点是Env As Code，这个是从Infrastructure Code 延伸出来的概念，现在我们在滴滴如果一个研发人员想要一个构建环境只需要在代码库提交一个文件，比如说他想要用JDK1.8，其他环境的准备，还有一些依赖的安装他要求了以后我们会自动帮他做装配。还有一些情况满足不了，这种自动交配都是基于预置的，比如说Env:Jdk，我们又提供了Build in Docker这样的功能，在构建的时候你可以指定一个镜像，把各种各样的环境做到里边，还是要兼顾灵活性和统一性，我们通过Env As Code来提供统一性，我们也通过Infrastructure Code去提供统一性。

在集成管理这一块我们主要是做自动虚拟令牌和悲观锁，做CI的人都知道，只有有令牌的人才可以做CI，当你准备合入子弹的时候，我们会给你一个令牌，持有令牌的人，做CI，只有两条路可以走，一条路要么就是通过了所有的测试。第二个只有是rollback，这样就杜绝了常见的CI出现的问题，一个CI过一段时间就不认可了，谁提交的代码总是红色的状态，我们强调的是悲观锁，要么就是通过。要么就是rollback引进代码，这个模式是有一个缺点，它实际上会影响效率，我们把整个CI的运行做了强制的处理，有点像分布式的限流，每次只能通过我的悲观锁出去以后，下一个才能进来，会影响效率，但是会最大限度提升CI的有效性，这是一个效率和质量上的保证。

另外一点关于灵活性上面，在一个大的体系里面，你很难把pad保证是一模一样的，每个pad的样子都不一样，小团队会短一些，大团队会长一些，每个团队，开发的步骤哪个在前，哪个在后都会有不同的想法，我们会对判断提供引擎的东西，一般有一个很良好的时间，我们把这个事做成自动的，把代码做成自动的，整个任何一步都可以设置为必须通过也可以跳过，或者是跳过结果不影响，所有的过程都可以设置成是否并行，自动化测试，在开发链中自动打开，还可以都后续设置，下一步是手动执行还是自动执行，通过这样复杂的开关模型，最大限度提升的灵活性，不同业务线的需求，这个只能说是Practise，在最后一个会讲我们现在所做的事情。

在测试管理主要强调云端测试和流量回放，云端测试，我们原来在做的时候，经常会见到测试环境管理的问题，如果是用物理机做测试，物理环境可能会被你的同事影响或者是有一大堆人天天在修复测试环境，最后我们会把测试全部放在云端，最大限度保证测试的稳定性。

还有一个就是流量回放，我们做CI/CD常见的一个问题，业务线的同事太忙了，没时间写自动化测试，被逼出来的方案，你不写我们就帮你测，我们帮你流量回放，会把线上的流量给录下来，用tcpdump，请两份容器，一份容器跑的是线上的代码。一份容器跑的是你准备提交的代码，去跑同样录制下来的流量，看结果是不是一致，这种方式去帮你做测试，有的时候会遇到一个很尴尬的场景，自动化测试覆盖率，包括数量始终是很难提高的，我们用这样的方式去解决，这样的方式，如果结果不一致你只知道它的代码是错的，还得研发同学去看，如果大家能够推动团队去做，还是可以的。

这是2.0时代，我们把大量的工具做了统一，不再是分散在不同的地方，我们有了项目管理平台，代码管理平台，持续交付平台，效果验证平台，从开发到验证再到上线，再到反馈，我们会兼顾统一性和灵活性和研发过程中深度整合，我们有了这些平台以后，用户所有的研发活动是在这个平台上完成的，脱离开平台，研发活动是没法继续的，这样就能保证我们基于这样的平台不断深化我们的工程实践和我们的理念。

4. 体验驱动的智能平台

刚才讲了工具链，把工具箱打造成了工具链，工具链架构也会有一些问题，研发体验差，各领域系统间概念，模型不一致导致的摩擦，我们有项目管理的平台，里面肯定会有一个创建项目比较多，在容器管理上可能也会有一个功能叫创建项目，这样会使得用户在使用的时候会有大量的摩擦。

虽然在做，每个领域还是有比较专业度的，理解不同的概念，再加上就是数据、流程未完全打通，价值流还是比较模糊的状态，没办法进行数据分析，怎么做？这个是Devops很前列的思想，2016年有很多具体的理念，这个我就不解释了，总的来说它的核心有一句话，研发也是人，大家得把它当成人去对待，就像我们做产品，我们天天在强调产品的体验，对于我们这些做工具系统或者是Devops平台这些人来说，我们也得把我们的用户，使用我们平台的产品经理也好，研发也好，测试也好，运维也好，把他们当成用户去对待，考虑怎么样提升他们的体验，考虑怎么提升他们的方法和服务，减轻Devops体验当中的摩擦，基于这样的理念我们现在在做的事情，把我们以前做的工具链又做了一次改革，虽然是自己革自己的命，把我们以前做的所有工具去看哪个系统之间的东西，看它怎么流转的，去梳理一下各个节点之间的关系，以及在这次构建当中我们会建一个数据链路，一个统一的数据分析，不是特别清楚。

有一块会比较好玩，在我们重新构建的系统当中，我们会建立一个模块叫做（英）代码智能的模块，这一块也是比较新的方向，我们也还在探索，主要的目的通过代码的智能分析提前去发现问题。

这次我们会强调（英），统一整合研发的体验，我们会在这上一站式提供任务管理功能，代码管理功能，构建管理功能还有整个环境管理功能。

像任务管理，我们会在这里提供一个看板，这个看把是内置在我们的系统里边去，本身内置的看板所有的任务会跟代码做无缝的关联，只要你在代码提交的时候写了用户号，我们会把所有的代码关联起来，我们的观点是做一个比较弱的关联，有两个思路，要么就是用Freshlink，要么就是用CommitID做绑定，我们发现CommitID的灵活性还是比较高一点，我们不会做强制的检查，如果你写了任务号，我们会把代码和任务自动的关联。

我们会提供全云端的WebIDE，代码库的管理也会放在一站式的管理去做，举个例子，它需要去改一些代码的时候，可以直接在库里面去改，提供一些Vison的功能，这一块用的是微软开源的系统，这一块其实自动补全后来又加上了我们自己写的插件，一站式去做代码的开发。

在开发这一块也是在一站式的代码回顾，每一步我们都会格外强调它跟其他领域的打通，比如说pipeline本身跟代码库的打通，跟jira的打通，我们会自动把你这次pipeline log 提取出来，我们会把log提交出来方便你检查每一个版本提高的速度，而另外我们做了web terminal，在每一个部署的station里边，web terminal 里边是可以通过web terminal进到这一台station的容器或者是机器里边去看它的运行情况，有的时候我们会看到变红色了，我们还需要从其他地方登陆，这个体验上在一站式直接点一下。

另外做了大量的库的相关功能，这里面显示的不是特别清楚，上一页看到的pipeline都是base在代码库里面的YAML去生成的，那个是自己可以控制这个pipeline，只要在它自己的代码库里面把YAML改一下，下一次提交以后就自动按照他改的生成pipeline。

另外一块刚开始提到的，包括它将来部署在哪一个Region，部署几个副本，基本上都是在Region可以定义的，比如说写A机房，就会在A机房，你写B机房，那我们就会自动给你提这个去做。我们把整个环境的管理，容器的管理，你现在拥有哪些环境，容器的环境，都可以一站式显示出来，每一个环境都可以一站式去做配置，查得到，看上面版本的分支。

这是我们现在做的事情，做的还是比较浅，引入的理念还是在Chatops理念，是去强调一站式协同，减少研发过程中摩擦的事情。

下一步我们要做的事情把这个平台跟Chatops怎么做打通，怎么跟企业内部的系统做更好的整合，我们在IM里面说一下你要用什么样的版本，我们会在机器里面自动的打包，在AIOps会跟我们的运维同学进行合作，这是我们现在正在慢慢引入的理念，也有一个单独的团队在去做，怎么把我们的研发平台做，在正常的情况下我们会在你的测试环境去做整合。

整体来说，我们这一路来说，第一步刚切进来的时候，我们的经验利用成熟的工具快速展现Devops的价值，一些建设流程比较长的时间可以会让你错过一些机会。

第二步连点成线固化工具链，使Devops成为一个习惯。

第三步我们再去建模分析价值流，推进Devops持续改进，拿黑字标出来的部分，正好是组合了Devops和CLAIMS的原则，我们的Devops应该是用精益的方式展开，我们要用Automation，我们要用不同的工具连线成线，我们要去做分析，价值流的分析，我们还要做增长，跟各位同行、老师、专家去做交流，这是我们的经验。

最后一页是我个人做这一块的模型，认为转型分为五步:

第一步叫做Awareness，让他意识到是有问题的。
第二步叫Desire。
第三步是Ability，提供技术和功能。
第四步是Promote，在组织内做宣传推广。
第五步是Transfer，在Devops里可以遵循这样的原则去做，我们之前做的时候会遇到一个常见的问题，我们过于侧重要打造一个特别厉害、能力特别强的Devops工具体系或者是平台，而忽略了我们用户的问题，应该从第一步入手先去提升意识，举一个很不恰当的例子，大家都看过赵本山卖拐的那个，首先你得把他忽悠瘸了。

第二步开始提升用户体验，用我们提供的方法论去解决问题，这一个也很关键，我原来碰到一个团队的情况，他也接受了他现在去做提升和转变，但是他会认为我只要再招十个人就会把这个问题给解决了，不需要用你这一套。

第三步Ability，问题的前两步Awareness做的比较好，第三步把我们的工具、技术、平台交给他的时候，他会有很高的积极性来做这个事情，难度并不大。

后两步在有些实践当中我自己遇到的会被忽略掉的，一步是宣传和推广，我们做的好还是尽量在组织内去做推广。

最后一步是Transfer，如果你只能做一个点，很小的点，你始终是无法在企业内形成规模效应，你要始终考虑到你做的这个事情能不能在前面做规模化，你怎么把你做的这个实践推广到全公司，你要考虑怎么规模化。