Skip to main content

腾讯云颜松柏:详解DevOps成熟度模型与效能度量

本文由本人整理,发表在CSDN平台并署名【小雨青年】。

发布地址:https://mp.weixin.qq.com/s?__biz=Mzg2ODEzOTA0OA==&mid=2247487105&idx=1&sn=0fb55a59efe5e59f85da491cc497a921&chksm=ceb1a7c6f9c62ed09b54f7c414869f7de4a8afc4b7855b9837bb313abed899f58cbe0cccceb2&token=1516426127&lang=zh_CN#rd

嘉宾 | 颜松柏 整理 | 小雨青年

出品 | 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。