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