DevOps实战笔记 — 04.DevOps的衡量： 你是否找到了DevOps的实施路线图？

04 | 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的实施需要立体化的实施框架， 通过模型、 方法、 能力和实践的相互作用， 实现全方位的能力提升。

思考题

　　最后， 给你留一道思考题： 关于CMMI、 ITIL和DevOps， 你觉得它们之间的关系是怎样的呢？ 企业该如何兼顾多套模型框架呢？

 

答： CMMI ： Capability Maturity Model Integration ，即能力成熟度模型集成。

　　ITIL： Information Technology Infrastructure Library ， 即信息技术基础架构库。