什么是DevOps
随着敏捷软件方法的广泛采用，以及IT基础设施即程序代码的管理方式的推广，DevOps也应运而生了。
DevOps 是通过人、流程和技术的有机整合，以协作、自动化、精益、度量和共享文化为指引，旨在建立一种可以快速交付价值并且具有持续改进能力的现代化 IT 组织。
什么是DevOps成熟度评估
随着技术的发展，越来越多的公司期望各种有用的方法论能够标准化，可量化。这样可以帮助决策者快速的知道我目前的水平，以及我未来发展的目标。
因此，随着DevOps被越来越多的推广，决策者们也期望知道自己公司或者团队的DevOps被量化之后长什么样子。于是DevOps成熟度评估模型便诞生了。
DevOps成熟度模型
在这些年的咨询生涯中，见过很多公司的成熟度模型。
这里给大家介绍几种吧。
常见DevOps成熟度模型
首先是信通院的，信通院把DevOps分成了3个模块，每个模块下面对应了一些纬度。如下：
- 敏捷开发管理
- 价值交付管理
- 敏捷过程管理
- 敏捷组织模式
- 持续交付
- 配置管理
- 构建与持续集成
- 测试管理
- 部署与发布管理
- 环境管理
- 数据管理
- 度量与反馈
- 技术运维
- 监控管理
- 事件与变更管理
- 运营配置管理
- 容量与成本管理
- 高可用管理
- 连续性管理
- 用户体验管理
再来看看某技术咨询公司的，他们把DevOps成熟度分为了6个纬度来进行评估。如下：
- 组织职能与能力
- 轻量级变更流程
- 自动化环境管理
- 持续部署与发布
- 运维监控与度量
- 架构解耦
同样是某咨询公司的，他们的DevOps成熟度模型的纬度又不一样了，他们把成熟度模型分为了8个纬度。如下：
- 发布组织与方法论
- 精益发布治理与过程
- 自动化软件发布
- 持续集成
- 持续部署
- 自动化运维
- 基础设施与云计算
- 平台与应用架构
另外一家科技公司，他们的DevOps成熟度模型的纬度也不一样，他们的分法如下：
- 持续集成
- 持续部署
- 轻量级变更流程
- 自动化环境管理
- 质量保证
- 运维监控与度量
- 可视化与可追溯
我总结的DevOps成熟度模型
凭借这些年的DevOps咨询经验，我总结了一套我认为更易用的能符合大部分公司情况的DevOps成熟度模型。结合了各家成熟度模型，做了一些调整和优化，以适用于大部分团队的DevOps成熟度评估。
他们也是8个纬度，如下：
- 组织与文化
- 敏捷开发
- CI/CD
- 质量与安全
- 可视化与自动化
- 版本与配置管理
- 运维监控与预警
- 持续度量与改进
组织与文化
DevOps不是一个软件产品，DevOps也不是一个工程师。DevOps需要文化与组织的变化，不仅是开发与运维之间的隔阂需要消失，IT与业务之间的隔阂也需要消失。
由于DevOps和敏捷一样，离不开组织的变革和支持，同时DevOps也是一种文化，因此综合了一下，把组织能支持DevOps的程度，与现阶段文化与DevOps的匹配程度，作为了这个纬度的关键。
敏捷开发
为什么要有这个纬度可能有些人会比较疑惑。因为Oleg Skrynnik在《DevOps精要》里面提到DevOps发展的其中一个前提是敏捷开发被广泛的采用。因此，敏捷做得好不好直接影响到DevOps做得好不好。他们是相辅相成的。
CI/CD
CI/CD即代表的是持续集成和持续部署。也可以理解为我们俗称的pipeline流水线。但它指代的不仅仅是工具，更是一种方法论。相对于集成与部署，更重要的是持续两个字。CI/CD占据了我们开发过程中的大部分阶段，从代码提交那一刻开始，到代码运行在生产环境，都是由CI/CD促成的。
质量与安全
这个纬度很多公司没有把它单独提出来，但我认为它是非常重要的。很多团队随着时间的推移，通常都会累积越来越多的技术债，最终也无法偿还。在兼顾交付的同时，质量与安全一定是我们长线能看到收益的纬度。因为质量与安全问题带来的隐形成本浪费，是很多团队和公司会忽略的。
可视化与自动化
IT工作内容很多是不可见的，因此可视化成了DevOps的重要指标。可视化的好处在于可以构建拉式系统，有助于识别低效环节，并且改善对剩余工作以及当前状态的了解。
很多团队以为有了流水线就是DevOps了，却不曾想依然有很多人工的工作。DevOps就是要规避人为的风险。因为人是会犯错的，而机器则不会。因此，自动化是非常重要的DevOps成熟度的考量纬度。
版本与配置管理
全面的版本控制能帮助团队在开发过程中获得收益，这些版本控制包括但不限于测试、脚本、环境、包、类库、文档、配置等。团队成员可以无风险的删除不需要的文件。
配置管理也是同样的原理和收益，配置与环境管理使得我们所有的变更都是受控的，系统可以被快速地重置到稳定状态。如果关键成员离开， 知识也不会遗失。
运维监控与预警
过去常常由一个独立的运维部门来负责所以线上运维的事情，这种情况在DevOps这里需要发生极大的变化了。运维的事情和开发合并到一起了，由一个团队共同负责了。这也是DevOps所强调的职责共担。同样对于运维的监控和预警也应该是对整个团队可见的。
持续度量与改进
DevOps已经越来越多的和效能关联上了。因此也出现了各种关于DevOps或者效能的度量。这些度量不是为了考核KPI，而是帮助团队持续改进的一种手段。DevOps提倡更频繁的直面问题，度量则是一种很好的方式帮助我们发现问题，并持续改进。
小结
可见，行业里没有一个统一的DevOps成熟度模型，各家都是按照各家的方法论在总结成熟度模型。
他们没有好坏，他们各有各的优点和侧重点。在不同的场景和不同的公司现状下，选择不同的成熟度模型能帮助我们更好的评估。
DevOps成熟度评级
关于级别的定义，行业里面普遍有两种，一种是4个级别，一种是5个级别。
我个人认为5个级别更合理，因为第1级其实就是零，并未尝试DevOps，第5级就是天花板，是以谷歌、微软、亚马逊等公司的领先DevOps团队为代表的天花板。
因此综合一下，级别定义如下：
- Regressive初始级 - 几乎没有尝试任何DevOps实践
- Basic基础级 - 做了一些DevOps实践，正在起步阶段
- Standard成熟级 - 能成熟运用各种DevOps实践
- Optimized优化级 - 不仅能运用各种DevOps实践，还能根据团队和组织情况进行优化改进
- Leading领先级 - 是行业里面DevOps的先行者、创新者、探索者、领导者
因此，把这个成熟度模型做成一张可量化的表则如下。
简单解释一下，表里的描述并不是全部，只是包含了一些关键例子和方向，使用者可以根据自己的情况调整和添加。其次，由于这些纬度很难量化，因此如果只是符合了部分描述，我们也认为没有做到。这样的好处是，我们不会因为评估为成熟级，而放弃了那些成熟级本应该达到而没有达到的描述。
举个例子，质量与安全纬度中，基础级做到了部分，同时成熟级也做到了部分，我们也认定只达到了基础级。
通过对这张表的打分，最后我们就能得到了一个例如下图的成熟度评估图：
总结
DevOps成熟度评估模型并不是指导你把DevOps做得更好的方法论，它只是用来评估目前的现状，以指导你未来还有哪些改进空间。
我做咨询的经历中，发现很多公司会把DevOps当作项目来做，要求团队在N个月内完成DevOps搭建和应用。但DevOps不应该以项目的方式进行，因为项目的方式意味着公司期望在有限的时间以及预算内获得特定的结果，然而DevOps其实是一场没有终点的马拉松比赛。
如果想知道如何把DevOps做得更好，推荐去看《DevOps精要》那本书，里面讲了DevOps的一些原则和关键实践，掌握这些东西才能持续把DevOps做好。
下回我也整理一篇文章来讲讲如何把DevOps持续做好。
