DevOps成熟度评估模型
什么是DevOps
随着敏捷软件方法得到广泛应用的同时，在推动IT基础设施作为代码库管理的基础架构的过程中（通过促进作为代码库管理的基础架构），DevOps随之应运而生。
DevOps 是通过将人、流程和技术进行有机整合来实现协作、自动化以及提高效率的现代IT组织体系；该方法以促进协作、实现自动化以及量化评估为基础，并融合共同的文化价值观；其目标是致力于构建一个既能快速产生价值又具备持续优化能力的现代化IT组织。
什么是DevOps成熟度评估
随着技术的发展趋势使得越来越多的企业要求标准化的方法论工具便于量化分析。这将有助于决策者迅速掌握当前的能力水平以及未来发展的具体方向。
基于此，在DevOps逐渐普及的情况下，在公司或团队实施量化后的情况之下（即实施量化的具体情况之下），决策者们希望了解其效果以及该评估模型如何出现（即该模型是如何产生的）。从而导致了DevOps成熟度评估模型的诞生
DevOps成熟度模型
在这些年的咨询生涯中，见过很多公司的成熟度模型。
这里给大家介绍几种吧。
常见DevOps成熟度模型
主要是由信通院主导的组织机构，在其框架下将DevOps技术划分为了三个主要模块，并为每个模块均涵盖了若干维度的技术要点
以下是对输入文本的改写版本
进一步了解某技术咨询公司的情况吧？该咨询公司则将其DevOps成熟度划分为六个维度作为评估依据。
- 组织职责与核心能力
- 简洁变更流程
- 自动化环境管控
- 持续部署发布系统
- 运维监控及性能度量
- 架构解耦技术
同样是该咨询公司；他们对DevOps成熟度模型的维度进行了更新；这次更新将模型划分为8个维度。
- 发布组织与方法论
- 精益发布治理与过程
- 自动化软件发布
- 持续集成
- 持续部署
- 自动化运维
- 基础设施与云计算
- 平台与应用架构
另外一家科技公司，在其DevOps成熟度模型中所涉及的维度有所区别；他们将该模型划分为不同的类别。
- 持续集成实践
- 持续部署流程
- 轻量级变更处理流程
- 自动化环境管理方案
- 质量控制措施
- 运维监控与性能度量机制
- 可视化分析系统及追溯机制
我总结的DevOps成熟度模型
基于多年的DevOps咨询服务积累, 我归纳出一套经验证且易于使用的适用于大多数企业的DevOps成熟度评价体系. 在吸收业内主流的各种成熟的度量体系的基础上, 进行了必要的改进和完善, 旨在满足各类团队对全面且实用的DevOps评估需求.
他们也是8个纬度，如下：
- 组织结构与发展
- 快速响应型开发流程设计框架
- 高效迭代集成管理体系（CI/CD）
- 产品质量保障体系构建方案
- 数据可视化技术辅助工具开发计划
- 软件版本控制及配置管理工具集成方案
- 运维监控系统及预警机制优化策略
- 持续集成度量指标及持续改进计划制定方案
组织与文化
它既不是单一的软件产物也不是专业人员。实现DevOps转型涉及组织文化的重塑，在消除开发运维间的鸿沟的同时还需要打破IT部门与业务部门之间的隔阂。
因为DevOps与敏捷性质相同，在促进组织变革与提供支持方面具有重要性。同时，在某种程度上来说也是一种文化传统。综合考虑后将其作为衡量该维度的关键因素。
敏捷开发
人们可能会对此感到困惑：为什么要引入这一维度？由Oleg Skrynnik在《DevOps精要》一书中指出，在DevOps的发展过程中，默认情况下敏捷开发被广泛采用作为一个前提条件。因此, 敏捷开发的成功与否直接关系到整个 DevOps 项目的成功与否. 两者之间相互依存, 相互促进.
CI/CD
CI/CD本质上指的是持续集成和持续部署这一概念。它也被我们通俗地称为pipeline流水线。然而，在技术术语中，它不仅指代工具本身，更是一种方法论。相较于集成与部署而言，持续性的概念更为关键。在软件开发流程中占据主导地位的是CI/CD系统：从代码提交那一刻起（即代码进入版本控制系统），一直到该代码在生产环境中稳定运行都是由CI/CD系统所推动完成的。这种方法不仅提升了开发效率，并且显著减少了人为错误的发生概率
质量与安全
这个维度通常未被独立识别出来。然而我认为这是一个不容忽视的关键因素。随着时间的推移, 很多团队会逐渐积累越来越多的技术债务, 最终无法彻底解决这些问题. 在注重交付的同时, 质量与安全一定是那些能够长期带来收益的关键维度. 因为质量与安全问题所带来的潜在成本损失往往会被人忽视, 这种现象往往会导致资源过度投入技术优化而忽略更为基础的安全保障.
可视化与自动化
IT领域的许多工作内容是看不见的，并因此导致了可视化的重要性地位的确立。这意味着可以说可视化已成为DevOps中的一个重要指标。通过构建拉式系统能够实现发现效率低下之处的目标，并且这种改进还能够进一步提升对剩余任务和当前状况的认知程度。
认为拥有流水线即可完成 DevOps 的全过程。但事实上仍然存在大量的人工工作环节。因此, DevOps 的核心目标则是尽量减少由于人类不可避免地会犯错所带来的风险, 而 machine 则完全不会犯错, 这使得 automation 成为了衡量一个 DevOps 是否成熟的非常重要的指标。
版本与配置管理
系统化的版本管理方案将有助于团队在开发过程中带来便利。这些版本管理措施涵盖测试用例、脚本文件、运行环境配置以及相关的包组件等。因此建议项目成员在处理无关文件时应采取谨慎态度。
同样遵循着一致的方法论并带来显著的好处，在涉及配置与环境管理的过程中，在变更操作上能够实现全方面的控制；确保系统能够迅速恢复至稳定状态；组织中的关键成员离职时也不会导致知识流失
运维监控与预警
过去通常由一个独立负责的运维团队单独承担线上运维的任务，在DevOps环境下这种状况需要发生根本性的转变。将运行维护工作与开发整合在一起后由同一团队共同完成这也是DevOps所推崇的核心理念之一。同样地，在监控与预警方面也需要整个团队具备统一的能力
持续度量与改进
DevOps已经越来越紧密地与效能相关联了。因此也出现了多种关于DevOps或者效能的度量指标。这些指标并非用于评估关键绩效指标（KPI），而是作为一种促进团队持续改进的有效工具。在应用这些度量时能够及时发现问题并推动持续改进的同时，在应用Degree of DevOps (DOD)时能够及时发现问题并推动持续改进。
小结
目前行业内尚未形成一个统一的DevOps成熟度模型，各个组织依据自身的开发和运维方法论构建自己的成熟度模型
他们既没有优劣之分，在每个个体中也都有其独特的优势与特点。根据具体情况以及公司的运营状况，在不同的情景下采用合适的成熟度模型能够更加有效地完成评估工作。
DevOps成熟度评级
关于级别的定义，行业里面普遍有两种，一种是4个级别，一种是5个级别。
我认为设置为五个级别更为合理。具体而言，第1级别实际上就是零，并没有进行过任何DevOps实践；而第五级别则是极限状态，在此层次上发挥顶级水平的仅能以像谷歌、微软、亚马逊等公司这样的顶尖DevOps团队为例。
因此综合一下，级别定义如下：
- Regressive初始级- 几乎没涉及任何DevOps实践
- Basic基础级- 开始接触一些DevOps实践
- Standard成熟级- 熟练地应用各种DevOps实践
- Optimized优化级- 经过优化版本的应用，并能根据团队情况改进
- Leading领先级- 在DevOps领域处于领先位置
因此，把这个成熟度模型做成一张可量化的表则如下。
简要说明一下，在表中所列的内容并非全面列举所有可能的情况与方向，在实际应用中应根据具体情况做出相应的调整与补充。值得注意的是由于这些维度难以量化评估因此如果只满足了部分指标或要求我们也认为未能完全达到预期目标这样的设计优势在于它既不会因为评估结果定性为成熟级就放弃那些本应在成熟级阶段应达到的目标。
举例来说，在质量与安全维度中，在基础层级的部分内容得到了实现，在成熟层级的部分内容也得到了实现，并且我们的评估结果表明仅实现了基础层级。
对这张表格进行了评分后,从而能够获得一个具体表现为下图所示的一个成熟度评估图表
总结
DevOps成熟度评估模型并非不作为提升DevOps质量的方法论；它主要用于评估当前状况，并帮助你识别未来的改进方向。
在我参与咨询的过程中发现，在企业中存在大量将DevOps仅仅视为一个项目的现象：即要求组织在规定时间内完成DevOps架构的构建与部署工作；然而这种方法并不适宜推广：因为采用项目模式意味着企业在限定的时间与预算内追求特定成果；而实际上DevOps应该被视为一项持续改进、不断迭代的战略工程；它强调的是长期价值创造而非短期目标达成；就像一场永无止境的马拉松比赛：只有坚持投入持续关注与改进才能实现真正的成功
如果想深入了解如何提升DevOps的效率与质量，则可以参考《 DevOps 精要 》这本书。其中提到了一些核心原则以及关键的实践方法。通过掌握这些原则和实践技巧, 才能持续有效地实施和发展 DevOps 工作。
下回我也整理一篇文章来讲讲如何把DevOps持续做好。