腾讯云颜松柏：详解DevOps成熟度模型与效能度量
本文由本人整理，发表在CSDN平台并署名【小雨青年】。
嘉宾 | 颜松柏 整理 | 小雨青年
出品 | CSDN云原生
云原生时代下，DevOps成为企业标配，从而量化必然成了刚需，成熟度模型与效能度量可以分别从两个方向评估DevOps程度，帮助企业不断进步。
2022年5月24日，在挪到线上举行的云原生系列Meetup·北京站上，腾讯云微服务专家架构师颜松柏分享了对DevOps成熟度模型与效能度量的理解和实践。
DevOps是通过人、流程和技术的有机整合，以协作、自动化、精益、度量和共享文化为指引，旨在建立一种可以快速交付价值并且具有持续改进能力的现代化IT组织。
DevOps是一个无限循环的闭环，它能够根据反馈不停地改进。CI即持续集成，CD即持续交付。
一、DevOps成熟度评估
随着DevOps被越来越多的推广，决策者们也期望知道自己公司或者团队的DevOps被量化之后长什么样子。于是DevOps成熟度评估模型便诞生了。
市场上存在多种DevOps成熟度评估模型，大多企业会针对自身特点来设计专属的成熟度评估模型。
DevOps成熟度模型
DevOps成熟度模型结合各类模型，做了一些调整和优化，适用于大部分团队的DevOps成熟度评估，主要从8个维度进行评估，分别是：
- 持续度量与改进
- 组织与文化
- 运维监控与预警
- 敏捷开发
- 版本与配置管理
- CI/CD
- 可视化与自动化
- 质量与安全
持续度量与改进：DevOps已经和效能关联上了，因此也出现了各种关于DevOps或者效能的度量。这些度量不是为了考核KPI，而是帮助团队持续改进的一种手段。DevOps提倡更频繁地直面问题，度量则是一种很好的方式帮助我们发现问题，并持续改进。
组织与文化：DevOps不是一个软件产品，也不是一个工程师。DevOps需要文化与组织的变化，不仅是开发与运维之间的隔阂需要消失，IT与业务之间的隔阂也需要消失。由于DevOps和敏捷一样，离不开组织的变革和支持，同时DevOps也是一种文化，所以综合一下，把组织能支持DevOps的程度，与现阶段文化和DevOps的匹配程度，作为这个维度的关键。
运维监控与预警：过去常常由一个独立的运维部门来负责所有线上运维的事情，有了DevOps后，这种情况发生了极大变化。运维的事情和开发合并到一起了，由一个团队共同负责了，这也是DevOps所强调的职责共担。同样，对于运维的监控和预警也应该是对整个团队可见的。
敏捷开发：为什么要有这个维度可能有些人会比较疑惑。因为Oleg Skrynnik在《DevOps精要》里面提到DevOps发展的其中一个前提是敏捷开发被广泛的采用，所以敏捷做得好不好直接影响到DevOps做得好不好，它们是相辅相成的。
版本与配置管理：全面的版本控制能帮助团队在开发过程中获得收益，这些版本控制包括但不限于测试、脚本、环境、包、类库、文档、配置等。团队成员可以无风险地删除不需要的文件。配置管理也是同样的原理和收益，配置与环境管理使得我们所有的变更都是受控的，系统可以被快速地重置到稳定状态。如果关键成员离开，知识也不会遗失。
CI/CD：CI/CD代表的是持续集成和持续部署。相对于集成与部署，更重要的是持续两个字。CI/CD占据了我们开发过程中的大部分阶段，从代码提交那一刻开始，到代码运行在生产环境，都是由CI/CD促成的。
质量与安全：这个维度很多公司没有把它单独提出来，但我认为它非常重要。很多团队随着时间的推移，通常都会累积越来越多的技术债，最终也无法偿还。在兼顾交付的同时，质量与安全一定是我们长线能看到收益的维度。因为质量与安全问题带来的隐形成本浪费，是很多团队和公司会忽略的。
可视化与自动化：IT工作内容很多是不可见的，因此可视化成了DevOps的重要指标。可视化的好处在于可以构建拉式系统，有助于识别低效环节，并且改善对剩余工作以及当前状态的了解。DevOps要规避人为的风险，因此，自动化是非常重要的DevOps成熟度的考量维度。
DevOps成熟度评级
DevOps成熟度评级分为五级：
- Regressive初始级：几乎没有尝试任何DevOps实践
- Basic基础级：做了一些DevOps实践，正在起步阶段
- Standard成熟级：能成熟运用各种DevOps实践
- Optimized优化级：不仅能运用各种DevOps实践，还能根据团队和组织情况 进行优化改进
- Leading领先级：是行业里面DevOps的先行者、创新者、探索者、领导者
因此，可以把这个成熟度模型做成一张可量化的表，如下所示。
DevOps成熟度评估图
通过8个维度配合5个评级，就可以得到DevOps成熟度评估图。它是一个雷达状的图谱，可以帮助企业了解DevOps成熟度的现状，企业能够直观了解哪些维度是需要改进的。
如下图中的案例所示，其持续度量和改进的维度评分只有2分，是亟待改进的部分。
二、DevOps效能度量
研发效能反映的是一家科技公司对市场环境的响应力有多高，它是一种基础能力，就好像人体做出反应有多快一样，这种基础能力的提升，会帮助人体在每一项任务上都做得更好。这是研发效能一直很受重视的原因。
DevOps效能度量指标
DevOps效能度量指标分为4个等级：
低效能 中等效能 高效能 精英效能
根据这4个等级，可以再划分2种度量指标：
- 结果指标
- 过程指标
通过等级和度量指标的划分，我们就可以把DevOps分成几个阶段，如下图所示。
横向为DevOps的三个阶段，分别是敏捷开发管理、持续交付、技术运维，纵向分为两个维度：交付效率、交付质量。 下图是详细的效能等级与指标的对应表，可以使用该表具体的数值对指标进行量化。
三、成熟度模型与效能模型的区别
前面已经给出成熟度模型和效能度量详细的指标数据图，那它们二者有什么区别呢？
成熟度模型是一次性评估，通过评估可以将团队或企业的现状可视化，以此明确短板及改进方向。
效能度量是持续、定期的度量，通过不间断的测试来量化得出哪些能力不足，并以此做出对应的改进措施。
日常使用中，我们更多地利用效能度量，因为它涉及的很多指标能切实帮助我们改进DevOps中的不足。
综上，成熟度模型在企业首次评估DevOps时提供了可视化的现状，在企业后续发展中，效能度量通过不断度量，用更丰富的指标完善企业的DevOps。