简介： DevOps 能力反映的是技术研发响应业务变化的能力。随着组织规模的增加和业务复杂性增长，DevOps 能力会变得越来越重要。持续提升 DevOps 的能力成为技术研发的共同挑战。
编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》，前往：https://developer.aliyun.com/topic/devops，下载完整版电子书，了解阿里十年DevOps实践经验。
DevOps 能力反映的是技术研发响应业务变化的能力。随着组织规模的增加和业务复杂性增长，DevOps 能力会变得越来越重要。持续提升 DevOps 的能力成为技术研发的共同挑战。
为了给组织的 DevOps 能力提升指明方向，并规划清晰的路径。我们定义了 DevOps 能力成熟度模型，它提供两个价值：1）知道我们今天在哪里；2）如何规划提升路径。
我们将 DevOps 的实施，分解为 4 大类，10 个能力，分别是：
基础能力：包括系统的服务化水平和基础设施水平两块，它是研发和交付的基础。其中，服务化水平跟应用架构紧密关联，最理想的情况是无服务化架构，比较低级的状况是整个系统耦合在一起的巨石架构；基础设施水平体现为研发对基础设施所需要的关注度，需要的关注度越高，研发花在基础设施上的成本越高，效率越低，而且稳定性反而难以保障。
交付能力：包括工具化水平、测试自动化水平和部署发布水平三大块，它是工程能力水平的主要体现。其中，工具化水平指的是研发全流程中涉及到的各类工具的整体水平，包括单点能力（如项目协作工具、构建工具、依赖管理工具、环境管理工具等）和协同能力（如需求与发布的系统、缺陷与测试的打通等）；测试自动化水平指测试的反馈效率和自动化程度，测试自动化是工程能力的重要组成部分，也是提升部署发布能力的基础；部署发布水平是指把制品上线到生产环境并提供服务的能力，包括发布的自动化程度、稳定性（如平滑的灰度发布）和适应性（即面向不同情况的处理能力及出现问题后的自愈能力）。好的交付应该是持续、快速、高质量和低风险的。
运维能力：包括系统的可观测性、应用的运维水平和基础设施的运维水平，是系统运行时弹性和韧性水平的体现。其中，可观测性是运维能力中最重要的一环，主要体现在能否站在系统的角度看到全局的运行情况以及其中的问题，通常体现在监控水平和链路分析及问题定位能力上；应用运维是指对应用进行的运维操作，包括配置项的修改、调整应用运行时参数、对应用进行调整如扩缩容等；基础设施运维是指对系统的基础设施部分的运维操作，包括虚拟机、容器平台、基础服务（如域名、配置中心等），这是整个系统的基础部分。最好的运维就是自运维。
协同能力：包括业务和技术间的协同，以及开发与运维的协同能力，它是整体协同和业务响应能力的体现。其中，开发和运维协同是为了交付过程更加顺畅和高效，以提高技术的响应速度，同时保障系统运行的弹性和韧性；技术和业务协同是为了让从业务到技术的价值传递和交付更加精准、高效，反馈更加即时，以提高业务发展和创新的效率和效果。
成熟度模型
基于这 4 大类 10 个能力，我们给出了一个包含 5 个级别的成熟度模型，从 L0 到 L4 成熟度依次递增。
| 分类 | 能力 | L0 | L1 | L2 | L3 | L4 |
| 基础能力 | 服务化水平 | 低（单体或刚开始进行服务化） | 中（基于特定框架下的业务开发） | 中（基于特定框架下的业务开发） | 高（仅关注业务开发，语言相关） | 高（仅关注业务开发，语言无关） |
| 基础设施关注度 | 高（非云原生基础设施） | 高（非云原生基础设施） | 中（云原生基础设施） | 较低（主要serverless） | 低（完全serverless） | |
| 交付能力 | 工具化水平 | 低（无DevOps工具链） | 中（部分、孤岛式的工具） | 较高（持续交付工具链） | 较高（持续交付工具链） | 高（端到端devops工具链） |
| 测试自动化水平 | 低（无自动化，反馈时间长） | 低（无自动化，反馈时间长） | 中（部分自动化） | 较高（主要自动化） | 高（完全自动化） | |
| 部署发布能力 | 低（手工发布） | 较低（自动化工具发布） | 中（自动化声明式发布） | 较高（自动化声明式发布，有干预的灰度能力） | 高（自动化声明式发布，自动灰度能力） | |
| 运维能力 | 可观测性 | 低（只能观测散点式的基础资源） | 较低（散点式的基础资源和服务接口可观测） | 中（服务整体能力可观测） | 高（全景业务能力和服务能力可观测可追溯） | 高（全景业务能力和服务能力可观测可追溯） |
| 应用运维能力 | 低（人工运维） | 较低（自动化工具运维） | 中（声明式运维） | 中（声明式运维） | 高（服务自运维） | |
| 基础设施运维能力 | 低（单点、人工运维） | 较低（单点、自动化工具运维） | 中（集群、自动化工具运维） | 中（集群、自动化工具运维） | 高（集群、自运维） | |
| 协同能力 | 开发、运维协同能力 | 低（开发、运维分离 批量部署、独立运维） | 较低（开发、运维协作部署，加大部署频次） | 中（开发自主部署 开发协助应用运维） | 较高（开发团队持续交付 开发、运维团队融合） | 高（开发团队持续交付、自运维） |
| 业务、技术协同能力 | 低（业务与技术相互独立、抛接需求、很少同步） | 较低（业务与技术定期同步，批量开发、部署、发布） | 中（以业务需求为单位持续开发、部署、发布） | 中（以业务需求为单位持续开发、部署、发布） | 高（业务需求的快速响应和交付，业务需求的即时反馈、调整闭环） |
L0：手工批量交付、手工运维，这是零能力的 DevOps 阶段，其服务能力完全取决于开发者个人，业务交付质量普遍不高，随着业务的发展和团队规模的变大会遇到各类问题，通常会首先寻求工具的帮助。
L1：手工为主、工具辅助的批量交付和运维，这个阶段开始引入自动化工具来辅助进行运维、发布等工作，通常已经有了服务化的基础，基础设施已经部分上云，并通过引入开源工具或自建搭建了一些完成特定诉求的工具，但这些工具往往还是孤岛，没有联系起来，业务、开发、运维间采用定期同步的方式，需求的交付还是批量式的。
L2：基于业务需求的部分自动化的交付运维，这个阶段能基于业务需求进行持续发布，已经采用了声明式运维，通常已经使用云原生的基础设施，并且使用云上的资源管理服务状态，大部分工具链已经能串联起来，实现一定程度的持续交付，服务开始具有中间件级别的抽象和治理能力，但一般还无法做到自运维，回滚等操作还需要依赖人来判断和处理。
L3：基于业务需求的端到端自动化交付和有限制的自运维，这个阶段的业务需求交付频率和交付质量有了明显提高，服务化水平已经相当高，针对特定的技术栈可以做到大部分情况下关注业务开发，主要服务以serverless 方式发布运行。发布过程可以做到自动化和声明式，只在灰度处理上需要少量的干预，服务已经可以做到大部分情况下的自运维和自治理。
L4：业务需求的端到端持续交付和调整闭环、完全自运维，这个阶段开发者只需关注业务开发，且业务需求能够做到快速的交付和调整，服务化水平与技术栈解耦，做到完全 serverless 化。整个交付过程完全自动化，服务能够完全自治理。这个阶段是我们追求的目标。
原文链接
本文为阿里云原创内容，未经允许不得转载。
