本文根据董璐老师在〖deeplus直播第236期〗线上分享演讲内容整理而成。（文末有获取本期PPT&回放的方式，不要错过）
本文主要分为四部分：
DevOps平台建设的目标：目标一致，在前进的道路上遇到的困难和阻力就更加相似，针对这些共性的问题，我们更容易找到合适的解决方案；
建设和落地的困难：京东数科在建设和推广DevOps平台的过程中遇到了不少困难，大家可以结合自身的情况，看看这些困难能否引起你的共鸣；
迭代式建设，层层推进；软硬兼施，逐步落地：这两部分内容结合上面提到的问题，分享在建设和落地的过程中，我们分别选择什么策略来解决这些问题。
一、DevOps平台建设的目标
我们为什么建设DevOps平台？因为领导觉得我们的工作进度太慢，其实本质上是市场认为我们的进度太慢。
引用杰克·韦尔奇的一句话，“如果外界的变化率超过了内部的变化率，那末日就不远了”。这句话其实是在讲，我们要去拥抱市场的变化，并且能够先于市场变化而变化，那么我们才能够有长远发展，有资格和其他公司竞争。
对我们IT行业其实也一样，如果你的产品还没上线，别人已经占领了市场。那么你就失去了先机，所以这也提醒我们：迭代的速度得跟上。
下面列出了几项我们建设DevOps时要关注的指标：
提升质量
提升效率
沉淀数据
辅助决策
1）提升质量
提升质量是首要的。而我们讲到质量，其实就是按照既定的要求去达成目标，有要求就要有反馈。整个过程一定不是一个人、或者一个角色在参与，而是多个角色都参与其中、相互制约，才能有反馈，从而保证质量。
我们讲DevOps，不只是包含了研发和运维的DevOps，而是说要把研发过程中各个角色的人都纳入进来，相互制约和影响，才能有效地保证研发质量。
各个阶段的人需要对自己的工作负责，保证符合要求，再由平台来确认是否按照要求进行，然后从上一个节点反馈到下一个节点。
这样的研发过程，才是一个保证质量的研发过程。
2）提升效率
提升效率也是我们建设DevOps平台的一个重要指标。
① 降低沟通成本
我们把沟通的结果都落实到平台上，以此来在线管理、共享信息，从而降低沟通成本。
这时有的同学会说，你这样做不仅没有降低沟通成本，反而还增加沟通成本了呀！我本来只需要一次线下沟通，只要发个会议纪要邮件就可以了，现在你还要我记录到平台上，根本没有达到降低沟通成本的目的啊！
大家想一下，第一次沟通当然是成本。而如果中途出现问题，我们就需要二次确认，那这是不是也属于成本？功能上线了，出了Bug导致资损，那复盘算不算沟通成本？
如果按照刚才说的结论，将沟通的逻辑、设计、问题、风险都落实到平台上，这些成本是不是被大大降低了？而且我们要复盘的时候，也会有据可依。
金融、保险、健康行业还会有审计的环节，对研发过程有监管，当他们要求你提供相关材料的时候，是不是也算是成本？
而如果是在线管理的话，这个成本就会被节省掉。
② 增加质量把控
我们做DevOps平台，肯定会集成很多质量管控的工具，比如自动化测试、代码扫描、漏洞检查等等。这些工作直接在平台上自动化实现，就会直接节省大家的工作时间。
③ 降低研发风险
我们经常会听到一个笑话，说研发同学的工作内容只有两个，一个是写Bug，另一个是改Bug，这说到底还是不能保障研发过程的质量。
如果把一部分研发规范、验证、分支策略，甚至是架构等要求都放到DevOps平台上，且由平台来实现，通过平台来规避、降低研发风险，就可以尽可能地缩短大家写Bug和改Bug的时间。
④ 提升自动化水平
更远一点的目标其实是提升数字化水平，既然我们已经开始进行DevOps平台建设，那么就应该让机器去做它应该做的。
自动化越完善，效率就会越高，就越能够节省人力和成本。
3）沉淀数据、辅助决策
整个研发过程都被管控起来了，是不是应该从沉淀的数据中挖掘一下我们的研发瓶颈和短板了？这就是我想跟大家分享的沉淀数据和辅助决策。
下面我给大家列出几个出发点，大家可以根据这些维度去复盘一下自己公司的研发过程是否有问题。如果有，那么哪里的问题最大？只有找到了问题，才能更好地解决问题。
我们要量化好这些数据并落盘固化下来，接着通过分析找到问题，才能根据这个根因来优化研发过程，提升团队整体研发实力。
二、建设和落地的困难
这个问题是一个最为共性的问题。因为DevOps平台的建设，基本上都是业务迭代到一定阶段时候的要求和产物。
没有哪个公司会说，虽然我们的业务产品还没开始，但是先建一套DevOps平台吧！那这个公司就是还没挣着钱就开始琢磨怎么花钱了，所以基本也没有公司会这样干。
历史包袱主要有这四点：
代码托管分散：公司越大，这个现象会越明显。像京东数科，因为很多收购而来的小公司和业务快速扩张，导致早期代码托管比较分散，很多部门或者子公司都会自己搭个Git或者Gitlab，然后就开始开发。这样做的问题是，产品下线了却都还不知道代码在哪台机器上；
上线无管控：无管控指的是可以自由上线。如果你突然让他上DevOps平台，有了工具，但他反而觉得还不如自己上服务器上折腾一下，发布一个版本更为方便和自由；
研发过程不持续：很多节点看上去都挺自动化的，但是真要把研发过程用到的工具都罗列出来，就会发现工具极其繁杂且不统一。这边测试过程用着禅道，那边用着Bugzilla，还有用Excel的；上线工具有的人直接用jenkins发布，有的人写一个脚本发布，还有的自己上传，你们想想公司里有没有这种现象；
源码不可追溯：平台建设到一定阶段，找个项目来试用，来迁移吧！结果源码找不到了，也说不清楚现在线上正在跑的项目到底对应哪个tag。
刚才说到的这些问题，在京东数科早期都有遇到过，都是真事儿！
在建设过程中，我们很容易进入一个误区——你会被研发和运维牵着鼻子走。
一开始我们会感觉研发、测试、运维的积极性特别高，后面就会发现我们做得越多，他们的需求也就越多，而且满意度却越来越低。做到最后，DevOps平台变成了研发工具仓库和集合，大家在平台上也只是使用工具。
那么平台的建设工作就变成了多个工具的集成工作，这个时候做得再多也只是在打通工具之间的联系，并没有在做平台建设。
另外就是缺乏规则，没有沉淀，导致这个平台就算做得再久也会没有价值。原本你要做一个游戏规则的制定者，制定统一标准让大家根据统一的玩法来工作。
但是最后却发现，你制定的游戏规则就是没有规则，最后也没有沉淀出有价值的数据和标准。久而久之，DevOps平台的建设就烂尾了，也无法再继续进行下去。
在落地过程中会发现更多的问题：
谈到落地，首先当然是要跟领导汇报工作，像是“平台要上线啦！我们做了多少功能，做出来的价值有多高！”
然后，领导就会在你画的这个饼上提出想法和要求，比如我们经常会遇到的，领导说：“我想知道咱们研发团队每天都提交多少代码？谁提交的最多？哪些项目进展的比较快，质量比较好？源码和需求有没有关联性？我知道他们在写代码，那他们写的代码和我这个项目进展有没有关呀？”
到这个时候就会发现，其实自己在做的主要内容是用户当前关注的问题，但却不是领导关注的主要内容。
还有就是项目迁移，我们将项目迁移到DevOps平台上肯定会产生成本，因为这需要研发团队对研发的过程做出改变，所以说研发团队的认可也是我们的阻力之一。
之前大家都是散养，现在要制定规则，大家多多少少都会有抵触的情绪。之前随便拉一个代码库就能干的事情，现在却要走流程，走立项。
但是规则制定得太松散，就会发现平台根本没有规则可言；规则制定得太严谨，就会发现平台上没有用户。上面列举的四项内容是一般的DevOps平台都会有的功能，但是在散养阶段却都是没有的。
刚才说的这些冲突会在平台落地的时候都爆发出来，那么我们能够采取了怎样的策略和手段呢？
三、迭代式建设，层层推进
上面提到，我们在建设的过程中会不断给产研测和运维人员打磨工具。这样的DevOps平台，真的是我们要建设的DevOps平台吗？
DevOps虽然不是业务平台，但也具备全局的产品视角，不然就会出现上面说的问题。
所以首先要对整个研发过程做一个抽象梳理，然后逐层递进地完成平台建设。
DevOps平台是要把研发过程中参与的人员都纳入进去：产品人员提出需求，然后组会确认可行性和排期，接着交给研发人员进行开发迭代，测试人员通过测试后，平台正式发布上线。这是研发DevOps平台的主流程，所有的工作都要在主流程上进行，只是不同团队做的是不同节点的工作。
主流程也需要明确下来，我们要做的是一款产品，也可以称之为业务产品。当然整个建设过程也是一个持续迭代、层层建设的过程。
1）工具化
工具化也适合大多数的公司，可以先用各种各样开源的工具支撑起研发、测试和运维的需求。不需要抵触工具化，因为有的时候我们的能力有限，完全抛弃工具并不现实，所以我们要做的其实是充分利用工具。
想要利用多种多样的工具，在选择的时候最好就选择比较大众的工具，太小众的最好不要用。因为我们要为后续的系统化和平台化做准备，不能自己给自己挖坑。
2）系统化
工具化是为了解决眼前的问题，而系统化是为了发展。我们要对工具做关联，同时也要注意关联的过程中不要忘记我们是在做产品，所以一定要依据产品的设计来做工具集成。
系统化的目的是打通各个工具的环节，而用大众化的工具支撑平台在这里就能凸显出它的意义了。
工具太小众，很可能出现问题但是你却无法解决。可能要集成的时候连接口都没有，使用小众工具，在系统化的道路上就处处是坑。
3）平台化
DevOps做到最后，还是要靠真技术。如果光靠工具进行组装，局限性就会很大。是时候该替换掉的中间件和工具组件就要替换掉，该自研的就要自研，一定不能被工具局限住，我们的最终目标是让每个环节都协作起来。
1）系统化
系统化做的是，打通工具集，为每个环境挑选主要的工具，以此来完成不同阶段的工具统一。
还是以Bug管理为例，
我们同时使用禅道、Bugzilla、JIRA不行吗？行！
JIRA一定比禅道好吗？禅道一定比Bugzilla好吗？不一定！
这里需要进行抉择，而这个抉择需要由DevOps平台建设方来制定。我们只有先统一好工具，才能把精力放在更有价值的地方。如果数据分散在不同的地方，下一步需要推进的时候要采集数据、改变用户习惯就会非常困难。
系统化需要同时考虑各个阶段工具之间的对接。松散在不同地方的工具是没有灵魂和凝聚力的，久而久之很可能还会被打散。所以我们要把工具打通，通过接口、文件、甚至是数据库层面，想尽一切办法让整个过程转起来，以完成系统化的转变。
2）平台化
平台化的过程中工具并不那么重要，重要的是信息流。因为这个时候工具组件已经成形，需要做的是通过替换或者自研去顶替已经被淘汰的工具。剩下的工作是过程优化，要让整个研发过程更加平台，各个环节之间都有联系，并通过平台沉淀的数据为我们提供价值。
我们建设DevOps平台的目的是什么？是为了保证质量，提升效率，价值反馈！DevOps平台建设到最后还是要发挥它最大的价值，只有整个研发过程在你手上可控，你才能更好地分析、找到研发过程的优化点，以此来改善过程。
四、软硬兼施，逐步落地
1）制定游戏规则
DevOps平台的建设过程，也是研发规范的制定过程。之前对大家来说玩法比较自由，但是现在上了平台就不能再随便乱跑了。
首先，平台制定了游戏规则，就需要在规则下进行研发，但很多规范需要宣贯，比如说：
分支策略问题：我们要给用户讲明白，这个分支的策略是怎样的策略？为什么这样做？有什么好处？应该怎么应用？
质量卡点要求：质量检查包括什么内容？分别会在什么时间点采集哪些质量指标数据？分析的时候依据又是什么？
安全校验规则：规则包括哪些？遇到问题要怎样处理、优化工程才能满足这些指定好的规则？
2）落实研发过程
落实研发流程也可以叫实操培训，和用户明确应该如何使用平台，谁应该干什么，每一个环境又有什么任务等等，这个落实和培训的流程是我们作为DevOps平台建设者的责任。
不像新闻类、电商类的APP，大家用一两次就能熟悉流程和操作，这种管理支撑类的平台有一定门槛，DevOps平台甚至要复杂得多。
所以要明白的是，我们自身有责任和义务告诉用户怎么使用平台，每个节点上他们应该做什么。
我们的义务明确了，那么用户的义务是不是也要跟着落实了呢？那当然不是我们去落实，而是领导帮忙去提点提点。
谁都想不受约束，都想自由地去干自己喜欢干的事情，但是我们要对项目负责，要对公司负责。我们承认这种改变会给用户带来成本，但是这个成本是必须的，不然等在平台发展到一定的规模之后再去做规定的事情就会产生更大的成本，到那个时候再后悔就晚了！
铁腕政策应该怎么做？
限期迁移，强制推广：注意，这项措施一定是等平台具有一定成熟度的时候再去做，还没有稳定的时候，不要盲目推进，不然就会丢失团队管理者的信任。假设大家都很积极地帮你去推进，最后你却掉链子，那么后面的迁移之路会越来越难；
规范化调整，偿还技术债：这是京东数科项目迁移的必经之路，之前存在的很多问题都要调整。举个最明显的例子，很多项目依赖快照发布上线，但是快照很多时候都不稳定，如果快照版本更新遇上发布上线，这就能体现出这个问题的严重性和普遍性了，所以对待这个问题决不能手软；
全面检查，做好质量管控：在项目迁移过来的时候，一定要对项目进行强制检查，不符合的地方一定要进行调整，并且在起点就控制好，这样才不至于越落地，标准越低；
用数据说话，纳入绩效考核：和绩效挂钩也是迫不得已的做法，在国企、事业单位用的最多，而互联网公司用的还比较少。但是这不失为一个比较好的措施，只是不到迫不得已还是不要强制纳入绩效，毕竟DevOps建设团队和研发团队都是一家人，一家亲。
最后还是要强调，树立榜样很重要。无论你的DevOps平台是非常好还是一般，都需要有试点团队的支持，我们筛选出具有代表性的项目团队并以此作为榜样。当然这个团队需要比较愿意配合并且乐意去接受和改变，对于这样的团队我们要重点照顾，甚至亲力亲为帮助他们完成项目迁移。
一旦你有了成功案例，故事就好讲了，去别的团队推广和迁移都会容易很多。无论是什么阶段，能有一个标杆样板，都可以起到由点及面，逐步落地的作用。
Q & A
Q1：怎么实现一键创建开发测试环境？
A：
建议首先标准化部署的方式，如部署路径，日志输出路径，启动用户等；
先满足一类工程的部署，比如先考虑Tomcat部署，然后再扩展到其他类别的部署；
先使用开源组件，如Jenkins，Ansible，通过接口调用来实现平台对接；
管理服务之间的依赖，可以一次性部署多个服务。
Q2：项目团队才用的gitlab，想问下如何从0开始搭建DevOps平台？
A：从0开始的话还是建议从开源软件开始，优先考虑代码托管、自动化构建、部署，gitlab+jenkins是最快的方式。
Q3：京东的mobile端如何做DevOps的？
A：移动端的DevOps还是比较复杂的，对于组件化和非组件化的工程，研发过程还是不同的，不过整体主阶段是类似的，都是从研发、测试、到灰度，然后到发版，涉及到的功能点会比较多。
比如安装包的加固和签名、渠道的管理、IOS的发版还会涉及到证书的管理，是一个比较复杂的过程，移动端持续集成的建设也是一个逐步建设的过程。
Q4：bug管理也是DevOps平台开发？
A：Bug的管理是为了持续集成的过程更完整，如果当前有其他更紧急的问题要处理，那么可以不考虑Bug管理。如果想让整个研发过程在DevOps平台上一站式解决，不仅是Bug，像代码扫描的缺陷，扫描规则、安全规则、测试用例、自动化测试脚本等等都应该是要考虑的范畴，总之，只要是能让研发团队更便捷的完成研发工作，都是我们要关注的内容。
Q5：最难缠不配合的部门是怎样的，如何解决他，有没有哪些业务是放弃接入？
A：我个人认为还是不要太过于纠结，有一些项目不是靠我们努力就可以接入的，偶尔也会有历史包袱过重，或者确实不适应平台的项目存在，可以考虑2/8原则。如果你为了以项目付出的努力值得你这样做，可以去努力，如果能帮助更多更有价值的项目，我建议可以先放一放。
Q6：Android+IOS如何在一起持续集成？
A：持续集成的过程是相同的，不同的是编译机的选择，打包的方式、研发过程、测试过程、发布过程大体还是相似的。对于不同的部分用不同的路线来处理，是可以在一起持续集成的，毕竟从产品经理的角度来看，提出的一个需求在Android端和IOS端都是要上线的，可以合并处理。
Q7：接口自动化测试依赖的数据该如何生成？尤其上游依赖环节比较多的情况下？
A：要达到单个服务的自动化测试数据自动生成的目标，对于依赖服务比较多的情况下，各个服务最好能够提供自己的联调环境。比如我是A服务的研发人员，我依赖B，最好让B能够提供一个联调环境，或者B的研发人员可以通过DevOps平台很快给你搭建B的服务，生成一个临时的联调环境，让B的研发负责测试数据。
让人员各司其职，对于复杂的系统是不可能靠一个服务的研发人员处理所有的测试数据的。
Q8：生产环境，做了哪些发布，灰度发布怎么做？
A：生产环境至少还是要准备两个，一个是预发，一个是生产。预发环境使用生产环境的数据、网络，但是流量入口是独立的，目的就是在新的功能要发布生产的时候，先发布到预发环境，然后通过特定的入口进行预发环境验证，没有问题再升级生产环境，否则对预发环境进行回滚。
灰度发布在移动端用的比较多，比如对某一特定区域的用户进行灰度测试，北京的用户可以升级客户端到最新版本，先看市场的反应，或者对某一个渠道的用户进行灰度测试，比如我们Android从360和华为商店上下载的版本就不同，达到部分灰度的效果。
Q9：多团队，多分支并行开发，到底怎么做？
A：这里涉及到分支策略的处理，多分支并行开发其实就是拉取多个分支进行不同功能的开发，也可以进行多分支并行测试，但是最终要上线时，只有一个分支能进入上线，上线完成后，会升级项目基线，然后其他分支要将基线Merge到当前分支重新进入测试上线流程。或者可以多分支并行开发，使用集成分支进行测试，然后一起上线，只要是在分支策略的约束下，能够保证基线稳定，过程如何处理都是可以灵活设计的。
Q10：规则检查用什么工具呢？
A：具体还要看检查什么规则，比如：
检查是否依赖快照包，可以通过maven的enforce插件完成；
检查是否有依赖包版本冲突，可以通过maven获取依赖树，然后进行对比；
检查是否符合分支策略要求，可以对接gitlab或者自研的代码托管平台，通过对比分支版本来完成。
Q11：持续集成平台生产平台和开发测试要分开吗？
A：服务端可能是分开的，但是对于用户来讲，作为一个平台来使用还是比较方便的，很多公司因为网络要求，开发环境、测试环境和生产环境是网络隔离的，我们可以在不同的网络环境下搭建不同的服务，这样在办公环境访问DevOps可以同时操作不同环境的构建部署，完成研发过程。
Q12：如果有很多服务 ，是应该给每个服务都设计一个pipeline 还是所有服务公用一个流水线？
A：个人建议还是每个服务都有自己的pipeline，甚至一个服务可以有多个pipeline，每个pipeline负责不同的功能，如提供代码扫描、自动执行自动化测试的，自动更新测试环境的，甚至还有发布部署的，在不同的时间点，在不同的情况下触发不同流水线的运行。
↓点这里可回看本期直播
阅读原文
230721
1、导入Mongo Monitor监控工具表结构（mongo_monitor…
上面提到： 在问题描述的架构图中我们可以看到，Click…
PMM不香吗？
如今看都很棒