04 | DevOps的衡量：你是否找到了DevOps的实施路线图？

精选留言(15)

• 

  陈斯佳

  老师，我有个具体问题。我们公司现在的Jenkins Jobs都是使用在github上的Groovy/pipeline file生成的。每次新增一个新项目/应用，就多一个if else或switch case语句，弄的很复杂又不好维护。针对这种应用程序多、环境多的情况，您有没有什么好的方式来进行配置管理呢？

  作者回复: 所以你们也在实践Jenkins的pipeline是吧，两个具体的建议给到你。
  第一，将job的配置代码化，也就是通过配置文件就能自动生成一个job，推荐你使用Openstack开源的Jenkins Job Builder工具，你在网上就能找到，使用起来非常方便。
  第二，对于每一个项目获应用，使用独立的Jenkinsfile进行管理，相当于彼此独立，毕竟你把他们揉在一起没有意义。
  当然你可能会问，那么大量重复的配置如何解决，其实这跟写代码模块化类似，我推荐你使用shares library来做一层抽象，把共同的东西提取出来进行复用哈。
  关于Jenkins 的任何问题，欢迎你随时给我说哈！

  2019-10-15

   4

   16
• 

  刘超 mingo

  全都是理论，大哥，能讲点实践什么不？有么有资料让我提前预习下？

  作者回复: 你好，目前就是基础理论篇呀😄 请问，你对具体哪方面的实践感兴趣呢，欢迎在留言区交流哈

  2019-10-15

   3

   5
• 

  Ops360

  在实施DevOps过程测试管理这个环节，如何有效的让测试和研发人员配合测试的一下工作，希望老师能分享单元测试和自动化测试方面的实施经验。在以前没有开展单元测试的研发团队，现在在原来的敏捷模式下给研发人员一项加新的工作内容，研发不愿意了，还有一些研发就没习惯单元测试，在测试人员实力不太强的团队，自动化测试应该从哪具体的小环节部分开始才合适？

  作者回复: 你好，你在留言中的两个字我觉得说的特别好，那就是习惯。我见过互联网公司单元测试完全推不下去的，也见过传统行业单元测试覆盖率能到达80%的，那么到底是人的能力问题，还是工具平台成熟度的问题呢？我觉得都不是，而是习惯的问题。
  至于如何推行单元测试，除了开发团队自我要求特别高的情况以外，我见过的成功路径，都是自上而下行政命令式的推动执行的。但是，有两个小技巧，第一就是明确分工，就单元测试而言，有这么几部分工作，试点工具和框架，制定指标，写单元测试，自动化执行和提取数据，报告展示，这些都要有明确的分工职责，一般来说，资深开发人员和测试专家都可以负责工具和框架试点，大多数情况下业界的通用工具都是可以满足需求的。第二就是明确目标，循序渐进，不要试图一下子全面铺开，在小团队试点跑通跑成熟了，再推行，同时数据指标要明确，否则没有目标谁也不知道要做成什么样子。其实，单纯追求全面的覆盖率并不是好的建议，还是要根据业务场景，务实的推行，比如核心模块，基础组件比较适合，这些相信整个团队在认真单元测试这件事情的价值的前提下，都是可以识别出来的哈。

  2019-10-18

  

   3
• 

  Geek_c991f2

  对于我们这些没有DEVOPS经验的工程师来说,理论还是抽象,想听下一个公司整个DEVOPS的实现流程,中间用到什么工具,哪些人员做了什么,先不用细化遇到什么问题,先有一个方向,老师,希望你能 看到我的恢复

  作者回复: 你好，感谢你的回复，关于DevOps实施的整个流程，也是我会在第6讲中介绍到的。
  其实，从我目前经历过的项目来看，大多数公司都是采用试点项目的方式来推进的，相当于一个改进的特区，从道法术器的角度来说，工具是最底层的，很多公司都有自己的工具链，单点能力也都足够强，所以最典型的DevOps平台就是持续交付流水线平台，通过这个平台串联软件交付的各个阶段，然后在具体的试点项目中进行落地，查漏补缺。
  另外，除了打磨工具链之外，研发数据的度量也是试点的重要方面，通过识别出适合自己公司的度量指标，然后结合工具平台提取数据，展现趋势，是量化DevOps目标和结果的最客观的手段，通过试点项目，在团队中对指标达成共识，有了改进的基线，那么接下来要做的，就是引入实践，来证明改进的效果。
  所以如果单纯来说用了哪些工具，我觉得比较容易泛泛而谈，就好比拿着锤子找钉子一样，而正确的姿势是，试点团队暴露出来的一些痛点，作为钉子，在打造好用的锤子，解决这个问题。
  当然，除了以上我说的这些，对于试点团队来说，人的因素也非常重要，通过观察人的行为，制定相应的流程和制度，这些在未来大规模推广，都大有裨益。

  2019-10-16

  

   1
• 

  delly

  我觉得cmmi，itil和devops所解决的问题不一样，因为他们出现时整个软件行业的背景都不一样。比如运维团队再没有一个合适的框架之前，自己摸索，碰到问题只会自乱阵脚，有itil做指导，把一切都看作服务，服务交付的度量也有了，成功率也高了。而现在在成功率高的基础上，还要加快效率，所以devops这个理念就有了，慢慢交付不行，要持续交付。但老框架也会一直结合行业的变化对自身的内容做适当的增减，也慢慢的可以同时兼顾解决更多的问题。
  
  我觉得老师讲的方法特别好，企业不是用了一个框架就不用别的，而是需要根据自己的发展阶段的不同，从不同的框架中汲取需要的东西。一步到位基本不可能，就是要不断的对标框架提到的理想状态，再看看自己的现状和关键需求，结合团队的能力和接受度，制定属于自己的一套解决方案。老问题解决新问题诞生，往复循环即可。
  比如服务团队建立初期可能要多看看itil的东西，流程制订好，先保证成功，再通过devops相关的框架解决交付效率的问题，慢慢来。

  作者回复: 你好，我非常赞同你的留言，其实公司里面一直在纠结一件事情，所谓业界最佳实践是否适用于企业自身，如果没有最佳实践漫无目的找不到方向，也不好统一大家认知，但是所有最佳实践也不能照单全收。所以最终还是需要相对有经验的人，带着最佳实践和公司业务团队的理解，去摸索出属于公司自己的最佳实践，这种循序渐进的方式才是DevOps应用的节奏吧。

  2019-10-16

  

   1
• 

  leslie

  不知道这种理解是否有道理：其实现在的DevOps一定程度可以理解为软件研发过程中的ERP。
      前天借着算法训练营开班的机会拜会了北京DB圈子里的同行；其实随着现在DB和OPS承担的服务器增长越来越恐怖，流程化、结构化反而成为现在软件开发过程中的问题。
       软件的任何问题都是运维。。。DevOps其实一定程度就是就是软件内部开发和运维的透明度，从而更好的解决软件研发与维护中的沟通和协作的问题。

  作者回复: 这个比喻很有趣，实际上，运维的标准化程度要远远高于开发和测试，在加上运维工作本身就要求要紧的作风，所以在DevOps领域运维跑在前面也并不意外。那么下一步就是向前和向后拓展，向前拓展开发，向后拓展运营。

  2019-10-15

  

   1
• 

  zy86

  老师我们现在自己内部团队实现了一个devops平台。集合opneldap,gitlab,jenkins,nexux,sonarqube,denpencycheck等实现了一个devops管理平台。但是公司内部的项目组并不想用我们的。部分项目组使用的是jrs结合jenkins他们觉得已经很舒服了。尴尬

  作者回复: 是的，所以我经常说Jenkins是公司内部平台建设的最大竞争对手，因为他太通用了，也足够满足大多数的需求。
  对于这种情况，我觉得还是要找到切入点，比如你列举的工具链里面，有哪些是现在不具备的，从使用效益和安全合规两个角度，再加上数据收集的角度出发，是不是能更好的解决用户的问题。
  我给你举一个例子，之前有个团队也是自己搭建Jenkins，不愿意用公司统一的工具，OK这没问题。后来他们发现，他们自己维护的资源环境特别不稳定，也不满足https合规要求，所以就主动联系我们是否可以托管环境，那从这个角度切入，他们发现使用公司平台也没什么不同，甚至更加简单了，所以，就主动提出能不能接入进来。你看，如果你的产品，用户不爱用，那就得想想这个产品带给用户的价值到底是什么，这也是产品设计能力圈的一部分。

  2019-12-03

  

  
• 

  张瑞霞

  老师能加下你微信吗，有一些具体的问题想问下。

  作者回复: 你好，我的微信号是 cendrier

  2019-11-21

  

  
• 

  Frank

  想请问下老师，我们公司主要做的是内部系统，相对而言系统的架构相对都比较简单，有的项目可能都是单节点的服务，个人感觉devops的实施很大依赖于产品或者项目的本生，项目或者产品本生就很"小"，感觉devops也很难做大，所以工作中在做一些devops的实践中也有很大的困惑，请问老师有什么看法

  作者回复: 你好，无论系统大小只要是对软件交付的效率提升有诉求，其实都可以尝试DevOps模式，小团队更加灵活，职责边界没有固化，甚至有很多空白等待填补，相比大公司来说有自己的优势，更有可能培养所谓的全栈工程师，等以后如果去了大公司，这种经历将会是一种不可取代的优势。
  我理解你的问题有两方面，一个是有没有必要做DevOps，这个上面也说到了。第二个是要做到什么程度，技术的发展是为了解决问题的，比如微服务很热，但是难道说单点服务就没有存在的意义了吗？显然不是，关键还是看服务本身的场景。我觉得可以目光可以稍微放长一些，小系统如果做得好也有变大的一天，而在小系统上的实践积累也会成为将来大系统大平台的基础。
  总之，我认为DevOps的理念和身体力行的实践，于公于私，都是值得去做的。

  2019-10-21

  

  
• 

  sugar

  看了这几章，终于有了点眉目，窥到了DevOps的一些斑点
  

  作者回复: 你好，感谢你的留言，那么接下来，我们就要开始实践部分啦，也欢迎你提出你的问题，我们一起交流学习。

  2019-10-16

  

  
• 

  Bryan Bai

  您这个DevOps成熟度模型挺有意思，有没有完整版参考？

  作者回复: 你好，这个模型是业界公开的，任何人都可以看，你可以网上搜一下就能找到哈

  2019-10-16

  

  
• 

  陈文涛

  看来大家的留言，感觉作者应该开一堂课，京东在devops的实际落地，使用了哪些工具，各个岗位和环节是怎么衔接的。。。。。。：）

  作者回复: 哈哈，像京东这种公司的工具都是自己开发的，并不具备太多参考性哈，大公司都有这种习惯，什么都要自己做才行😄

  2019-10-15

   2

  
• 

  Robert小七

  目前的工作是给一些金融行业的客户做devops咨询，帮助企业改进研发效能！希望和老师一起共同探讨devops的落地实施！

  作者回复: 你好，看来是半个同行，不知道你在指导企业转型的过程中是否也有一套模型框架呢。是否也有一些新法可以拿来讨论的呢？期待你的更多回复哈

  2019-10-15

   1

  
• 

  风过留痕

  希望老师在今后的分享中能够更加细致的讲解原理和结合实际情况的实践，期待您的下一讲。

  作者回复: 你好，感谢你的回复，收到你的反馈。我也提个小小的期望，短短的10几分钟的课程难以面面俱到，希望你能提出你遇到的实际问题和思考，我们可以在留言区跟大家一起交流讨论，营造一种共同学习的氛围哈！

  2019-10-15

  

  
• 

  天天向上

  问题点的详细清单能给下吗？

  作者回复: 你好，你是指案例中的问题列表吗，其实这些都是针对具体公司给出来的，可能没有普遍意义。比如，将构建脚本纳入版本控制系统，增加平均故障修复时间的统计，这些都是在对标之后给出来的改进建议哈。

  2019-10-15

  

  