04 | DevOps的衡量：你是否找到了DevOps的实施路线图？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
DevOps的实施路线图是企业在实施DevOps过程中面临的挑战。文章介绍了DevOps的发展历程和在企业内部的落地情况。随着DevOps在中国的快速发展，越来越多的公司开始尝试DevOps，并且已经有一些公司制定了自己的DevOps能力成熟度模型来指导企业内部的DevOps转型落地工作。作者还提到了一套由中国信息通讯研究院牵头制定的DevOps能力成熟度模型，该模型覆盖了软件交付的各个方面，包括敏捷开发管理、持续交付和技术运营等内容。对于开发DevOps工具的企业来说，系统和工具模型更加偏向于平台能力。文章指出，随着DevOps的发展，模型和框架的稳定将成为其成熟的标志，而这些模型和框架将帮助企业快速跟上节奏，找准方向，推动DevOps的大规模推广和健康发展。 文章提出了企业应用DevOps能力模型和框架的步骤和原则，包括识别差距、锚定目标、关注能力和持续改进。通过实践案例的分享，强调了DevOps的能力实践和能力框架模型相辅相成，能够指导企业落地DevOps的路线图和主要建设顺序，同时让企业能够游刃有余地面对未来的各种挑战。此外，文章还提到了ITIL和CMMI等框架体系在持续演进，将流动、反馈和持续学习改进的方法注入其中，从全局视角持续优化企业的价值交付流程。 总的来说，本文通过介绍DevOps的发展历程、企业内部的落地情况以及能力成熟度模型的应用，为读者提供了对DevOps实施路线图的深入了解和应用指导。同时，通过实践案例的分享和对其他框架体系的讨论，展示了DevOps在持续演进中的重要性和影响力。
《DevOps 实战笔记》，新⼈⾸单¥59
全部留言(28)
- 最新
- 精选
陈斯佳老师，我有个具体问题。我们公司现在的Jenkins Jobs都是使用在github上的Groovy/pipeline file生成的。每次新增一个新项目/应用，就多一个if else或switch case语句，弄的很复杂又不好维护。针对这种应用程序多、环境多的情况，您有没有什么好的方式来进行配置管理呢？作者回复: 所以你们也在实践Jenkins的pipeline是吧，两个具体的建议给到你。 第一，将job的配置代码化，也就是通过配置文件就能自动生成一个job，推荐你使用Openstack开源的Jenkins Job Builder工具，你在网上就能找到，使用起来非常方便。 第二，对于每一个项目获应用，使用独立的Jenkinsfile进行管理，相当于彼此独立，毕竟你把他们揉在一起没有意义。 当然你可能会问，那么大量重复的配置如何解决，其实这跟写代码模块化类似，我推荐你使用shares library来做一层抽象，把共同的东西提取出来进行复用哈。 关于Jenkins 的任何问题，欢迎你随时给我说哈！
2019-10-15637
柯基道格对于CMMI，TMMI个人理解是以传统瀑布为基础发展及改进的研发模型，对于公司组织架构是传统职能部门的工作模式下更为实用。 ITIL是大于研发模型，个人感觉是ITIL>CMMI，其还会有涉及公司管理各种方方面面，是用于公司整体的运转。 DEVOPS是传统职能部门在能够突破其部门的壁垒的情况下，发展出来的模式，是敏捷化理念下应孕而生的。 三种模式不存在谁好谁坏，关键还是看公司是怎么运转，例如：我们公司就是国企下的全资子公司，国企的气息浓厚，因此对于我们来说 部门壁垒也是劳不可破的，因此我为认CMMI在我们这里会比DEVOPS更为有用。但这就是意味着DEVOPS是否无法推荐。个人认为也不是，DEVOPS在有部门壁垒的公司，不能纵向从需求-》开发-》运营的推广。 而是得纵向宣传理念，横向推广实践，在DEVOPS的理念下，为每个部门服务，让他们吃到甜头，让上层看到价值，才会有突破部门壁垒的纵向实战的尝试吧。作者回复: 我跟传统企业打交道也不少，我倒觉得，预期内部突破，不如外部突破，适当的看看同行业里面的其他公司的做法，请一些外部的培训讲师，其实外部的人说的话有时候反而更容易被领导接受，如果有些横向的业界竞争就更好了，这种带动效应远比内部一个人推来的快速有效。
2020-02-1628
Ops360在实施DevOps过程测试管理这个环节，如何有效的让测试和研发人员配合测试的一下工作，希望老师能分享单元测试和自动化测试方面的实施经验。在以前没有开展单元测试的研发团队，现在在原来的敏捷模式下给研发人员一项加新的工作内容，研发不愿意了，还有一些研发就没习惯单元测试，在测试人员实力不太强的团队，自动化测试应该从哪具体的小环节部分开始才合适？作者回复: 你好，你在留言中的两个字我觉得说的特别好，那就是习惯。我见过互联网公司单元测试完全推不下去的，也见过传统行业单元测试覆盖率能到达80%的，那么到底是人的能力问题，还是工具平台成熟度的问题呢？我觉得都不是，而是习惯的问题。 至于如何推行单元测试，除了开发团队自我要求特别高的情况以外，我见过的成功路径，都是自上而下行政命令式的推动执行的。但是，有两个小技巧，第一就是明确分工，就单元测试而言，有这么几部分工作，试点工具和框架，制定指标，写单元测试，自动化执行和提取数据，报告展示，这些都要有明确的分工职责，一般来说，资深开发人员和测试专家都可以负责工具和框架试点，大多数情况下业界的通用工具都是可以满足需求的。第二就是明确目标，循序渐进，不要试图一下子全面铺开，在小团队试点跑通跑成熟了，再推行，同时数据指标要明确，否则没有目标谁也不知道要做成什么样子。其实，单纯追求全面的覆盖率并不是好的建议，还是要根据业务场景，务实的推行，比如核心模块，基础组件比较适合，这些相信整个团队在认真单元测试这件事情的价值的前提下，都是可以识别出来的哈。
2019-10-187- delly我觉得cmmi，itil和devops所解决的问题不一样，因为他们出现时整个软件行业的背景都不一样。比如运维团队再没有一个合适的框架之前，自己摸索，碰到问题只会自乱阵脚，有itil做指导，把一切都看作服务，服务交付的度量也有了，成功率也高了。而现在在成功率高的基础上，还要加快效率，所以devops这个理念就有了，慢慢交付不行，要持续交付。但老框架也会一直结合行业的变化对自身的内容做适当的增减，也慢慢的可以同时兼顾解决更多的问题。 我觉得老师讲的方法特别好，企业不是用了一个框架就不用别的，而是需要根据自己的发展阶段的不同，从不同的框架中汲取需要的东西。一步到位基本不可能，就是要不断的对标框架提到的理想状态，再看看自己的现状和关键需求，结合团队的能力和接受度，制定属于自己的一套解决方案。老问题解决新问题诞生，往复循环即可。 比如服务团队建立初期可能要多看看itil的东西，流程制订好，先保证成功，再通过devops相关的框架解决交付效率的问题，慢慢来。
作者回复: 你好，我非常赞同你的留言，其实公司里面一直在纠结一件事情，所谓业界最佳实践是否适用于企业自身，如果没有最佳实践漫无目的找不到方向，也不好统一大家认知，但是所有最佳实践也不能照单全收。所以最终还是需要相对有经验的人，带着最佳实践和公司业务团队的理解，去摸索出属于公司自己的最佳实践，这种循序渐进的方式才是DevOps应用的节奏吧。
2019-10-166 
mingo全都是理论，大哥，能讲点实践什么不？有么有资料让我提前预习下？作者回复: 你好，目前就是基础理论篇呀😄 请问，你对具体哪方面的实践感兴趣呢，欢迎在留言区交流哈
2019-10-1546
Frank想请问下老师，我们公司主要做的是内部系统，相对而言系统的架构相对都比较简单，有的项目可能都是单节点的服务，个人感觉devops的实施很大依赖于产品或者项目的本生，项目或者产品本生就很"小"，感觉devops也很难做大，所以工作中在做一些devops的实践中也有很大的困惑，请问老师有什么看法作者回复: 你好，无论系统大小只要是对软件交付的效率提升有诉求，其实都可以尝试DevOps模式，小团队更加灵活，职责边界没有固化，甚至有很多空白等待填补，相比大公司来说有自己的优势，更有可能培养所谓的全栈工程师，等以后如果去了大公司，这种经历将会是一种不可取代的优势。 我理解你的问题有两方面，一个是有没有必要做DevOps，这个上面也说到了。第二个是要做到什么程度，技术的发展是为了解决问题的，比如微服务很热，但是难道说单点服务就没有存在的意义了吗？显然不是，关键还是看服务本身的场景。我觉得可以目光可以稍微放长一些，小系统如果做得好也有变大的一天，而在小系统上的实践积累也会成为将来大系统大平台的基础。 总之，我认为DevOps的理念和身体力行的实践，于公于私，都是值得去做的。
2019-10-213
leslie不知道这种理解是否有道理：其实现在的DevOps一定程度可以理解为软件研发过程中的ERP。 前天借着算法训练营开班的机会拜会了北京DB圈子里的同行；其实随着现在DB和OPS承担的服务器增长越来越恐怖，流程化、结构化反而成为现在软件开发过程中的问题。 软件的任何问题都是运维。。。DevOps其实一定程度就是就是软件内部开发和运维的透明度，从而更好的解决软件研发与维护中的沟通和协作的问题。作者回复: 这个比喻很有趣，实际上，运维的标准化程度要远远高于开发和测试，在加上运维工作本身就要求要紧的作风，所以在DevOps领域运维跑在前面也并不意外。那么下一步就是向前和向后拓展，向前拓展开发，向后拓展运营。
2019-10-152- Geek_c991f2对于我们这些没有DEVOPS经验的工程师来说,理论还是抽象,想听下一个公司整个DEVOPS的实现流程,中间用到什么工具,哪些人员做了什么,先不用细化遇到什么问题,先有一个方向,老师,希望你能 看到我的恢复
作者回复: 你好，感谢你的回复，关于DevOps实施的整个流程，也是我会在第6讲中介绍到的。 其实，从我目前经历过的项目来看，大多数公司都是采用试点项目的方式来推进的，相当于一个改进的特区，从道法术器的角度来说，工具是最底层的，很多公司都有自己的工具链，单点能力也都足够强，所以最典型的DevOps平台就是持续交付流水线平台，通过这个平台串联软件交付的各个阶段，然后在具体的试点项目中进行落地，查漏补缺。 另外，除了打磨工具链之外，研发数据的度量也是试点的重要方面，通过识别出适合自己公司的度量指标，然后结合工具平台提取数据，展现趋势，是量化DevOps目标和结果的最客观的手段，通过试点项目，在团队中对指标达成共识，有了改进的基线，那么接下来要做的，就是引入实践，来证明改进的效果。 所以如果单纯来说用了哪些工具，我觉得比较容易泛泛而谈，就好比拿着锤子找钉子一样，而正确的姿势是，试点团队暴露出来的一些痛点，作为钉子，在打造好用的锤子，解决这个问题。 当然，除了以上我说的这些，对于试点团队来说，人的因素也非常重要，通过观察人的行为，制定相应的流程和制度，这些在未来大规模推广，都大有裨益。
2019-10-161 
镜花水月一个没做过开发的童鞋涉猎Devops好像不太适合 感觉技术时间和方法很多，自己都不懂，肯定没法组织和引导大家开干。作者回复: 没有做过开发固然有一些约束，到绝对不是制约因素，IT行业技术的更新换代非常快速，五年前做过开发的同学，今天就有点跟不上节奏了。在我看来，如果想组织和引导DevOps，首先自己对这块要有充分的认知，着眼点在链路上，而不是单点，有可能的话加入到过程改进项目中，让问题自己浮现出来，然后引入工具和实践解决它。 其实坦率的说，很多公司的研发效率水平还停留在杀鸡焉用牛刀的层面，所以了解基本的持续交付里面就足矣推动改进了哈，加油
2020-01-31
陈磊@Criss以为devops的衡量是如何衡量devops各个环节的指标作者回复: 你好，关于度量的部分，你可以参考正向度量部分哈
2020-01-14
