04 DevOps的衡量:你是否找到了DevOps的实施路线图?
你好,我是石雪峰。今天我们来聊聊DevOps的实施路线图。
商业领域有一本特别经典的书,叫作《跨越鸿沟》,这本书中提出了一个“技术采纳生命周期定律”,对高科技行业来说,它的地位堪比摩尔定律。
简单来说,这个定律描述了一项新技术从诞生到普及要经历的5个阶段,这5个阶段分别对应一类特殊人群,即创新者、早期使用者、早期大众、晚期大众和落后者。这个定律表明,技术的发展不是线性的,需要经历一段蛰伏期,才能最终跨越鸿沟为大众所接受,成为业界主流。
当然,DevOps这项所谓的新技术,在企业内部的落地也注定不是一帆风顺的。那么在这种情况下,你是否找到了DevOps的实施路线图呢?
从2017年第一届DevOpsDays大会中国站举办以来,DevOps正式在国内驶入了发展的快车道。从一门鲜为人知的新技术思想,到现在在各个行业的蓬勃发展,各种思想和实践的激烈碰撞,DevOps的理念和价值可谓是深入人心。
这样看来,DevOps已经成功地跨越了技术发展的鸿沟,从早期使用者阶段进入了早期大众的阶段,而这也意味着越来越多的公司开始尝试DevOps。
在2017年底,Forrester的一组调查数据显示,将近50%的受访公司表示已经引入并正在实施DevOps,30%的公司表示有意向和计划来开启这项工作,而对DevOps完全不感兴趣的仅占1%。可以说,2018年就是企业落地DevOps的元年。
但是,就像你要去往一个未知的目的地时,需要导航帮你规划路径、实时定位,并在出现意外情况时及时提示你是否要重新规划路径一样,企业在实施DevOps的过程中,其实也面临着相似的问题。企业自身难以清晰定位DevOps的现状,客观评估DevOps相关的能力水平,识别当前所面临的最大瓶颈以及实施DevOps的阶段性成果预期……
回顾整个IT行业的发展历程,新思想和新技术的发展,总是同标准化的模型和框架相伴相生的。
我认为,任何技术的成熟,都是以模型和框架的稳定为标志的。因为当技术跨越初期的鸿沟,面对的是广大受众,如果没有一套模型和框架来帮助大众快速跟上节奏,找准方向,是很难大规模推广并健康发展的。
比如,软件开发领域的CMMI模型(软件能力成熟度模型)、运维行业的ITIL模型等,在各自的领域都久负盛名,甚至一度被各个领域的从业者奉为圭臬和行为准则,成为衡量能力高低的标尺。
我曾经在国内某大型通讯设备公司参与过CMMI评级项目。当时,就算业务压力再大,只要是关于通过评级的事情,所有部门都会高优先级支持。由此可见,整个公司都非常重视这个认证评级项目。
那么问题来了,在DevOps这项新思想和新技术不断走向成熟的过程中,是否也有类似的模型和框架,能够指导企业内部的DevOps转型落地工作呢?
答案是有的,而且有很多。只要你去谷歌上搜一下DevOps框架、模型等关键词,就能看到非常多的结果。尤其是国外的一些知名公司,比如Atlassian、CloudBees、CA等,基本上都有一套自己的模型和框架,来帮助企业识别当前的DevOps能力水平并加以改进。
我之前参与过工信部旗下的中国信息通讯研究院牵头制定的一套DevOps能力成熟度模型。这套模型覆盖了软件交付的方方面面,包括敏捷开发管理、持续交付和技术运营三大部分,同时,也有与应用架构设计、安全和组织结构对应的内容。
不仅如此,对于开发DevOps工具的企业来说,系统和工具模型更加偏向于平台能力,稍加整理就可以作为平台需求输入到开发团队中。目前已经有不少公司在参考这套模型进行DevOps实践。下图展示了这个模型的整体框架,如果你正在企业内部推进DevOps落地的话,可以参考一下。
步骤与原则
业界有这么多模型和框架,是不是随便找一个,直接照着做就行了呢?当然不是。
毕竟,每家企业所处的行业现状、竞争压力、市场竞争态势都不尽相同,组织架构、战略目标、研发能力、资源投入等方面也千差万别,很难有一条标准的路径,让大家齐步走。比如,同样是金融企业,让万人规模的大银行和百人规模的城商行同台竞技,本身就有点强人所难。
所以,在实际参考模型和框架的时候,我认为应该尽量遵循以下步骤和原则:
1.识别差距
从“道法术器”的角度来说,DevOps的成熟度模型和框架处于“法”这个层面,也就是一整套实施DevOps的方法论,相当于是一幅战略地图,最重要的就是对DevOps实施所涉及到的领域和能力图谱建立全面的认知。
通过和模型、框架进行对标,可以快速识别出企业当前存在的短板和差距,并建立企业当前的能力状态基线,用于对比改进后所取得的效果。
2.锚定目标
数字化转型的核心在于优化软件交付效率。通过对标模型框架,企业需要明确什么是影响软件交付效率进一步提升的最大瓶颈,当前存在的最大痛点是什么,哪些能力的改善有助于企业达成预定的目标……同时,要根据企业的现状,甄别对标的差距结果,识别出哪些是真实有效的,哪些可以通过平台能力快速补齐。
比如,对于一家提供CRM软件的公司来说,容器化部署虽然在环境管理、部署发布等领域有非常多的优势,但并非当前的核心瓶颈和亟需解决的问题,那么就不应该纳入近期的改进列表中。
通过现状分析,企业可以把有限的资源聚焦在那些高优先级的任务上,识别出改进目标和改进后要达到的预期效果。这些效果需要尽量客观和可量化,比如缩短50%的环境准备时长。
3.关注能力
模型和框架是能力和实践的集合,也就是道法术器的“术”这个层面,所以在应用模型的过程中,核心的关注点应该在能力本身,而不是单纯地比较数字和结果。
比如,亚马逊每天23000次部署的案例经常会被拿来举例子。这个数字的确相当惊人,但反过来想想,所有企业都需要达到这么高的部署频率吗?举个例子,一个客户端应用可以在几分钟内构建完成,但同样是构建,对于大型系统软件来说可能需要几个小时,那么到底多长时间才算达标呢?
我们不能只关注这些明星企业所达到的成就,而忽略了自身的需求。所以,正确的做法是根据锚定的目标识别所需要的能力,再导入与能力相匹配的实践,不断强化实践,从而使能力本身得到提升。
4.持续改进
模型和框架本身也不是一成不变的,也需要像DevOps一样不断迭代更新,以适应更高的软件交付需要。另外,从今年的DevOps状态报告就可以看出,达到精英级别的比例从2018年的7%快速提升到2019年的20%,也就是说,行业整体的能力也在不断提升,这就对企业的软件交付能力提出了更高的要求。
好了,以上这些就是我总结的企业应用DevOps能力模型和框架的步骤和原则。DevOps作为一个系统性工程,同样需要与之配套的立体化实施方法,只有将方法、实践和工具结合起来,全方位推进,才有可能获得成效。
为了帮助你更好地理解DevOps实施的过程,我贴了一幅经典的部署引力图。
可以看出,当软件发布的频率从100天1次进化到1天100次的时候,分支策略、测试能力、软件架构、发布策略、基础设施能力,以及数据库能力都要进行相应的改动。比如分支策略要从长线分支变成基于特性的主干开发模式,而架构也要从大的单体应用,不断解耦和服务化。在实际应用中,企业涉及的领域甚至更多,因为这些仅仅是技术层面的问题,而组织文化方面也不可或缺。
实践案例
最后,我再跟你分享一个我之前参与改进的一个客户的案例。
刚开始跟这个客户交流的时候,他千头万绪,抓不准重点,甚至由于组织严格划分职责边界,基本上每讲到一块内容,他就要拉相应的人过来聊,在许多人都聊完之后,项目的全貌才被拼凑出来。我相信这并不是个例,很多公司其实都是如此。
于是,我们引入了能力成熟度模型,并基于模型对企业现有的能力水平进行了一次全盘梳理,并初步识别出了100多个问题点和40多个差距项。下面这张图就是汇总的大盘图,当然,部分数据进行了处理。
接下来,针对识别出来的这些差距点,我逐项跟企业进行了沟通,重点在于锚定一期的改进目标和具体工作事项。在沟通过程中,我发现由于企业所处行业的特殊性,或者客观条件不具备,有些内容并非优先改进事项,于是将改进事项缩减为30个,并识别出这些改进事项的相互依赖和预期目标。比如,这个企业之前初始化一套环境需要2周左右的时间,为了加快整体交付能力,我们将改进目标定到1周以内完成。
好啦,有了改进目标和预期效果之后,就要分析哪些关键能力制约了交付效率的提升。还拿刚才那个例子来说,核心问题在于环境的初始化过程复杂以及审批流程冗长。其中,原有的初始化过程是研发整理一份部署需求文档,来说明应用所依赖的环境和版本信息,并且这个需求还被整合到一个40多页的文档中。运维团队根据这个文档部署,每次都很不顺利,因为软件功能迭代所依赖的环境也在不断更新,但文档写出来就再也没人维护了。所以,很多人说文档即过时,就是这个道理。
识别出核心能力在于自动化环境管理之后,团队决定引入基础设施即代码的实践来解决这个问题。关于具体的技术细节,我会在后面的内容中展开,这里你只需要知道,通过将写在文档中的环境配置说明,转变成配置化的信息,并维护在专门的版本控制系统中,从而使得基础环境的初始化可以在分钟级完成。
当然,审批环境的优化属于非技术问题,而是流程和组织方面的问题。当大家认识到这些审批在一定程度上制约了发布频率的提升,就主动改进了现有流程。针对不同的环境进行不同级别的审批,使得单次审批可以在当天完成。
这样优化下来,环境准备的时长大大缩短,从当初的2周缩短到了2天,改进效果非常明显。接下来,团队又识别出新的差距,锚定新的目标和预期效果,并且有针对性地补齐能力建设,走上了持续改进的阶段。
由此可以看出,DevOps的能力实践和能力框架模型相辅相成:能力实践定义了企业落地DevOps的路线图和主要建设顺序,能力模型可以指导支撑方法的各类实践的落地建设;能力实践时刻跟随企业价值交付的导向,而能力模型的积累和沉淀,能够让企业游刃有余地面对未来的各种挑战。
至于ITIL和CMMI,这些过往的框架体系自身也在跟随DevOps的大潮在持续演进,比如以流程合规为代表的ITIL最近推出了第4个版本。我们引用一下ITIL V4的指导原则,包括:关注价值、关注现状、交互式流程和反馈、协作和可视化、自动化和持续优化、极简原则和关注实践。
看起来是不是有点DevOps的味道呢?需要注意的是,DevOps不会彻底颠覆ITIL,只会在保证合规的前提下,尽可能地优化现有流程,将流动、反馈和持续学习改进的方法注入ITIL之中,从全局视角持续优化企业的价值交付流程。
总结
总结一下,今天我给你介绍了新技术和新思想的发展需要面对的鸿沟,而能力模型和框架是技术和思想走向成熟的标志,对于DevOps而言,也是如此。在面对诸多模型和框架的时候,企业需要立足自身,识别差异,锚定目标,关注能力,并持续改善软件的开发交付效率。DevOps的实施需要立体化的实施框架,通过模型、方法、能力和实践的相互作用,实现全方位的能力提升。
到此为止,我们整体介绍了DevOps的基本概念、核心价值、实施方法和路线图,帮助你建立了一套有关DevOps的宏观概念。接下来我们就会开始深入细节,尤其是针对每一项核心实践,我会介绍其背后的理念、实施步骤,以及所依赖的能力模型,手把手地帮助你真正落地DevOps。
思考题
最后,给你留一道思考题:关于CMMI、ITIL和DevOps,你觉得它们之间的关系是怎样的呢?企业该如何兼顾多套模型框架呢?
欢迎在留言区写下你的思考和答案,我们一起讨论,共同学习进步。如果你觉得这篇文章对你有所帮助,欢迎你把文章分享给你的朋友。
- 陈斯佳 👍(37) 💬(6)
老师,我有个具体问题。我们公司现在的Jenkins Jobs都是使用在github上的Groovy/pipeline file生成的。每次新增一个新项目/应用,就多一个if else或switch case语句,弄的很复杂又不好维护。针对这种应用程序多、环境多的情况,您有没有什么好的方式来进行配置管理呢?
2019-10-15 - 柯基道格 👍(8) 💬(2)
对于CMMI,TMMI个人理解是以传统瀑布为基础发展及改进的研发模型,对于公司组织架构是传统职能部门的工作模式下更为实用。 ITIL是大于研发模型,个人感觉是ITIL>CMMI,其还会有涉及公司管理各种方方面面,是用于公司整体的运转。 DEVOPS是传统职能部门在能够突破其部门的壁垒的情况下,发展出来的模式,是敏捷化理念下应孕而生的。 三种模式不存在谁好谁坏,关键还是看公司是怎么运转,例如:我们公司就是国企下的全资子公司,国企的气息浓厚,因此对于我们来说 部门壁垒也是劳不可破的,因此我为认CMMI在我们这里会比DEVOPS更为有用。但这就是意味着DEVOPS是否无法推荐。个人认为也不是,DEVOPS在有部门壁垒的公司,不能纵向从需求-》开发-》运营的推广。 而是得纵向宣传理念,横向推广实践,在DEVOPS的理念下,为每个部门服务,让他们吃到甜头,让上层看到价值,才会有突破部门壁垒的纵向实战的尝试吧。
2020-02-16 - Ops360 👍(7) 💬(1)
在实施DevOps过程测试管理这个环节,如何有效的让测试和研发人员配合测试的一下工作,希望老师能分享单元测试和自动化测试方面的实施经验。在以前没有开展单元测试的研发团队,现在在原来的敏捷模式下给研发人员一项加新的工作内容,研发不愿意了,还有一些研发就没习惯单元测试,在测试人员实力不太强的团队,自动化测试应该从哪具体的小环节部分开始才合适?
2019-10-18 - delly 👍(6) 💬(1)
我觉得cmmi,itil和devops所解决的问题不一样,因为他们出现时整个软件行业的背景都不一样。比如运维团队再没有一个合适的框架之前,自己摸索,碰到问题只会自乱阵脚,有itil做指导,把一切都看作服务,服务交付的度量也有了,成功率也高了。而现在在成功率高的基础上,还要加快效率,所以devops这个理念就有了,慢慢交付不行,要持续交付。但老框架也会一直结合行业的变化对自身的内容做适当的增减,也慢慢的可以同时兼顾解决更多的问题。 我觉得老师讲的方法特别好,企业不是用了一个框架就不用别的,而是需要根据自己的发展阶段的不同,从不同的框架中汲取需要的东西。一步到位基本不可能,就是要不断的对标框架提到的理想状态,再看看自己的现状和关键需求,结合团队的能力和接受度,制定属于自己的一套解决方案。老问题解决新问题诞生,往复循环即可。 比如服务团队建立初期可能要多看看itil的东西,流程制订好,先保证成功,再通过devops相关的框架解决交付效率的问题,慢慢来。
2019-10-16 - mingo 👍(6) 💬(4)
全都是理论,大哥,能讲点实践什么不?有么有资料让我提前预习下?
2019-10-15 - Frank 👍(3) 💬(1)
想请问下老师,我们公司主要做的是内部系统,相对而言系统的架构相对都比较简单,有的项目可能都是单节点的服务,个人感觉devops的实施很大依赖于产品或者项目的本生,项目或者产品本生就很"小",感觉devops也很难做大,所以工作中在做一些devops的实践中也有很大的困惑,请问老师有什么看法
2019-10-21 - leslie 👍(2) 💬(1)
不知道这种理解是否有道理:其实现在的DevOps一定程度可以理解为软件研发过程中的ERP。 前天借着算法训练营开班的机会拜会了北京DB圈子里的同行;其实随着现在DB和OPS承担的服务器增长越来越恐怖,流程化、结构化反而成为现在软件开发过程中的问题。 软件的任何问题都是运维。。。DevOps其实一定程度就是就是软件内部开发和运维的透明度,从而更好的解决软件研发与维护中的沟通和协作的问题。
2019-10-15 - Geek_c991f2 👍(1) 💬(1)
对于我们这些没有DEVOPS经验的工程师来说,理论还是抽象,想听下一个公司整个DEVOPS的实现流程,中间用到什么工具,哪些人员做了什么,先不用细化遇到什么问题,先有一个方向,老师,希望你能 看到我的恢复
2019-10-16 - 镜花水月 👍(0) 💬(1)
一个没做过开发的童鞋涉猎Devops好像不太适合 感觉技术时间和方法很多,自己都不懂,肯定没法组织和引导大家开干。
2020-01-31 - 陈磊@Criss 👍(0) 💬(1)
以为devops的衡量是如何衡量devops各个环节的指标
2020-01-14 - zy86 👍(0) 💬(1)
老师我们现在自己内部团队实现了一个devops平台。集合opneldap,gitlab,jenkins,nexux,sonarqube,denpencycheck等实现了一个devops管理平台。但是公司内部的项目组并不想用我们的。部分项目组使用的是jrs结合jenkins他们觉得已经很舒服了。尴尬
2019-12-03 - 张瑞霞 👍(0) 💬(4)
老师能加下你微信吗,有一些具体的问题想问下。
2019-11-21 - sugar 👍(0) 💬(1)
看了这几章,终于有了点眉目,窥到了DevOps的一些斑点
2019-10-16 - Bryan Bai 👍(0) 💬(2)
您这个DevOps成熟度模型挺有意思,有没有完整版参考?
2019-10-16 - 陈文涛 👍(0) 💬(3)
看来大家的留言,感觉作者应该开一堂课,京东在devops的实际落地,使用了哪些工具,各个岗位和环节是怎么衔接的。。。。。。:)
2019-10-15