DevOps 实战笔记
石雪峰
京东商城工程效率专家
37393 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 41 讲
DevOps 实战笔记
15
15
1.0x
00:00/00:00
登录|注册

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

思考题
总结
实践案例
步骤与原则
DevOps能力成熟度模型
模型和框架的重要性
DevOps的实施现状
DevOps的发展历程
技术采纳生命周期定律
DevOps的实施路线图

该思维导图由 AI 生成,仅供参考

你好,我是石雪峰。今天我们来聊聊 DevOps 的实施路线图。
商业领域有一本特别经典的书,叫作《跨越鸿沟》,这本书中提出了一个“技术采纳生命周期定律”,对高科技行业来说,它的地位堪比摩尔定律。
简单来说,这个定律描述了一项新技术从诞生到普及要经历的 5 个阶段,这 5 个阶段分别对应一类特殊人群,即创新者、早期使用者、早期大众、晚期大众和落后者。这个定律表明,技术的发展不是线性的,需要经历一段蛰伏期,才能最终跨越鸿沟为大众所接受,成为业界主流。
当然,DevOps 这项所谓的新技术,在企业内部的落地也注定不是一帆风顺的。那么在这种情况下,你是否找到了 DevOps 的实施路线图呢?
从 2017 年第一届 DevOpsDays 大会中国站举办以来,DevOps 正式在国内驶入了发展的快车道。从一门鲜为人知的新技术思想,到现在在各个行业的蓬勃发展,各种思想和实践的激烈碰撞,DevOps 的理念和价值可谓是深入人心。
这样看来,DevOps 已经成功地跨越了技术发展的鸿沟,从早期使用者阶段进入了早期大众的阶段,而这也意味着越来越多的公司开始尝试 DevOps。
在 2017 年底,Forrester 的一组调查数据显示,将近 50% 的受访公司表示已经引入并正在实施 DevOps,30% 的公司表示有意向和计划来开启这项工作,而对 DevOps 完全不感兴趣的仅占 1%。可以说,2018 年就是企业落地 DevOps 的元年。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
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-15
    6
    37
  • 柯基道格
    对于CMMI,TMMI个人理解是以传统瀑布为基础发展及改进的研发模型,对于公司组织架构是传统职能部门的工作模式下更为实用。 ITIL是大于研发模型,个人感觉是ITIL>CMMI,其还会有涉及公司管理各种方方面面,是用于公司整体的运转。 DEVOPS是传统职能部门在能够突破其部门的壁垒的情况下,发展出来的模式,是敏捷化理念下应孕而生的。 三种模式不存在谁好谁坏,关键还是看公司是怎么运转,例如:我们公司就是国企下的全资子公司,国企的气息浓厚,因此对于我们来说 部门壁垒也是劳不可破的,因此我为认CMMI在我们这里会比DEVOPS更为有用。但这就是意味着DEVOPS是否无法推荐。个人认为也不是,DEVOPS在有部门壁垒的公司,不能纵向从需求-》开发-》运营的推广。 而是得纵向宣传理念,横向推广实践,在DEVOPS的理念下,为每个部门服务,让他们吃到甜头,让上层看到价值,才会有突破部门壁垒的纵向实战的尝试吧。

    作者回复: 我跟传统企业打交道也不少,我倒觉得,预期内部突破,不如外部突破,适当的看看同行业里面的其他公司的做法,请一些外部的培训讲师,其实外部的人说的话有时候反而更容易被领导接受,如果有些横向的业界竞争就更好了,这种带动效应远比内部一个人推来的快速有效。

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

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

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

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

    2019-10-16
    6
  • mingo
    全都是理论,大哥,能讲点实践什么不?有么有资料让我提前预习下?

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

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

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

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

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

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

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

    2019-10-16
    1
  • 镜花水月
    一个没做过开发的童鞋涉猎Devops好像不太适合 感觉技术时间和方法很多,自己都不懂,肯定没法组织和引导大家开干。

    作者回复: 没有做过开发固然有一些约束,到绝对不是制约因素,IT行业技术的更新换代非常快速,五年前做过开发的同学,今天就有点跟不上节奏了。在我看来,如果想组织和引导DevOps,首先自己对这块要有充分的认知,着眼点在链路上,而不是单点,有可能的话加入到过程改进项目中,让问题自己浮现出来,然后引入工具和实践解决它。 其实坦率的说,很多公司的研发效率水平还停留在杀鸡焉用牛刀的层面,所以了解基本的持续交付里面就足矣推动改进了哈,加油

    2020-01-31
  • 陈磊@Criss
    以为devops的衡量是如何衡量devops各个环节的指标

    作者回复: 你好,关于度量的部分,你可以参考正向度量部分哈

    2020-01-14
收起评论
显示
设置
留言
28
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部