什么是 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 团队为代表的天花板。

因而综合一下，级别定义如下：

1. Regressive 初始级 – 简直没有尝试任何 DevOps 实际
2. Basic 根底级 – 做了一些 DevOps 实际，正在起步阶段
3. Standard 成熟级 – 能成熟使用各种 DevOps 实际
4. Optimized 优化级 – 不仅能使用各种 DevOps 实际，还能依据团队和组织状况进行优化改良
5. Leading 当先级 – 是行业外面 DevOps 的先行者、创新者、探索者、领导者

因而，把这个成熟度模型做成一张可量化的表则如下。

简略解释一下，表里的形容并不是全副，只是蕴含了一些要害例子和方向，使用者能够依据本人的状况调整和增加。其次，因为这些纬度很难量化，因而如果只是合乎了局部形容，咱们也认为没有做到。这样的益处是，咱们不会因为评估为成熟级，而放弃了那些成熟级本应该达到而没有达到的形容。

举个例子，品质与平安纬度中，根底级做到了局部，同时成熟级也做到了局部，咱们也认定只达到了根底级。

通过对这张表的打分，最初咱们就能失去了一个例如下图的成熟度评估图：

总结

DevOps 成熟度评估模型并不是领导你把 DevOps 做得更好的方法论，它只是用来评估目前的现状，以领导你将来还有哪些改良空间。

我做征询的经验中，发现很多公司会把 DevOps 当作我的项目来做，要求团队在 N 个月内实现 DevOps 搭建和利用。但 DevOps 不应该以我的项目的形式进行，因为我的项目的形式意味着公司冀望在无限的工夫以及预算内取得特定的后果，然而 DevOps 其实是一场没有起点的马拉松较量。

如果想晓得如何把 DevOps 做得更好，举荐去看《DevOps 精要》那本书，外面讲了 DevOps 的一些准则和要害实际，把握这些货色能力继续把 DevOps 做好。

下回我也整顿一篇文章来讲讲如何把 DevOps 继续做好。