序言
云计算行业已经有十多年的发展了，话题早已从“要不要上云”转向“如何用好云”。“要不要”其实是一个决策性的话题，直到决策出来一个结果了，话题就算结束了，而“如何用好云”却是一个持续性的话题。
一般来说，在规划阶段开始，企业就会开始思考“如何用好云”，这个话题会伴随用云的整个过程。如果简单地从工作类型划分，除了业务代码的研发（Dev），其他的部分都可以称为运维（Ops），包含资源创建（环境部署）、应用部署、资源管理、资源监控、报警和故障排查等工作。
笔者从事云计算工作超过五年时间，参与开发过多款云产品，可以说既是云计算产品的消费者，也是云计算产品的生产者。在这里，笔者谈一谈对云上 DevOps 能力体系的多年思考和总结，希望对准备上云或是已经上云的运维人员有所帮助。
自动化运维等级金字塔
首先，从运维自动化等级和程度来看，DevOps 其实是一种非常高级的自动化，不仅自动化程度比较高，而且对于自动化的完成方式有着非常严格的定义。关于运维自动化与 DevOps 的关系，其实可以非常好地参考汽车自动驾驶技术分级标准，笔者做了个对比图，如图1。
图1：自动化运维等级金字塔
如图1，对应自动化驾驶的 6 个 Level，笔者将自动化运维分为了 5 个等级，分别是手动运维、半手工/半自动化运维、高度自动化、标准化运维和 AIOps。其中，运维自动化 L2 对应了自动驾驶的 Level 1 和 2。为了方便说明和对比这 5 个自动化运维等级，笔者做了详细说明，大家可以参考如下的表格。
表1：自动化驾驶等级与自动化运维等级对比参考
- Level 1：手动运维。一些技术能力一般的企业，在上云初期运维工作主要是纯手动，只能依赖云服务商提供的控制台进行操作。
- Level 2：半手工/半自动化运维。运维自动化工作比例还不超过30%。运维人员可以通过命令行（CLI）完成部分运维工作。
- Level 3：高度自动化，运维自动化程度可达到 50%。企业运维人员会使用云平台的SDK调用API进行日常运维工作，同时自行开发运维系统，但运维系统通常无定制化和平台能力，同时和内部系统是紧耦合的。
- Level 4：标准化自动化，运维自动化程度超过 90%。企业的运维系统已具备平台化、模版化和代码化的能力，可根据自身的运维需求定制化开发系统。与此同时，运维人员已具备使用具备模板化的产品来实现运维工作的标准化和自动化。
- Level 5：AIOps，即智能运维，运维自动化程度达 100%。这个阶段不再需要值班人员，生产力完全解放。这是当前很多大型互联网企业的运维目标，也是头部企业重点投入的方向。
DevOps 是自动化运维的进阶模式
模板化是最 DevOps 的自动化方式
这里，笔者想着重谈一下 Level 3-高度自动化运维与Level 4-标准化自动化运维的区别。大多数自研的运维系统是在 Level3 类型，例如在内部运维系统上开发了一个功能，可以立即创建 10 台云服务器，下次需要创建其他资源时，如创建 3 个消息队列，还是需要额外再开发创建消息队列功能。所以，Level 3 -高度自动化运维可以理解为是一个聚焦具体场景的单一“系统”。
而 Level 4 -标准化自动化运维更具备普遍性，完成了更高一级的抽象。当前，大多数的云平台都提供了自动化部署相关产品，如 AWS CloudFormation、阿里云的资源编排工具ROS等，所以Level 4标准化自动化运维系统其实是一个平台型的产品。
使用 Level 4 阶段的产品创建资源只需要创建一个模板，当需要创建新资源时，只需要套用模板即可，无需额外开发。多提一句，这里说的模板通常是 YAML 或是 JSON 文件，最近业界又开始将这类 YAML 和 JSON 代码化，面对资源的代码方式，思路和模板还是一致的，对于 DevOps 先锋者建议可以关注下 AWS CDK 和 Pulumi 类的产品。
实现模板化后，即可以将模板的管理方式和代码一致，使用 Git 等版本控制软件管理起来，使得模板的修改和发布过程可以享受类似代码一样的福利——评审、构建和持续发布，这就是最 DevOps 的自动化方式。
模板化或代码化是AIOps基础
AIOps（智能运维）可能是我们所有人的目标，不过理想和现实的差距还是存在的。现阶段的 AIOps 只在少数的特定场景下才有，比如弹性扩容场景下，可以对历史扩容数据学习后进行预扩容，或用AI的方式来检测某个指标是否异常等，所以 AIOps 还远没有达到完全自动化的程度。建议在特定场景里可进行 AIOps 的调研，在方向上对 AIOps 保持关注即可。
即便如此，笔者还是愿意表达自己的观点，模板化或代码化自动化运维（即 Level 4），应该会是 AIOps 的基础，因为只有所有运维工作都可以被自动化、所有自动化工作都非常规范和标准时，AI 才有机会进行学习，AIOps 才可能成为现实。
DevOps 基础核心—— CI/CD，基础设施即代码
通常，云上自动化运维系统的第一步是环境部署，这是基础同时也是非常重要的一步。一旦部署完成，后续想要再去修改代价会非常大。尤其是上线以后，会是一个环境迁移的工程量了，所以环境部署是最先需要开始设计的。
图2：CI/CD 流水线
CI/CD 流水线的系统运行环境
以实际项目中运用 DevOps 模式的例子——CI/CD 流水线应用“基础设施即代码”的实践为例，看一下自动化部署的整个流程。
图3：自动化部署流程
通常流水线的源头是从 Git 开始的，所以也有人将这种模式称之为 GitOps，显然这里的 Git 也可以替换成其他的版本控制系统，如 SVN 等，因为思路是一样的，所以本文依旧称之为 DevOps。
相信大家对 CI/CD 流水线都很熟悉了，如图 3，这里的流水线不仅包括了业务代码 Repo，还包括了 DevOps Repo，那么 DevOps Repo 应该用来存什么内容呢？这里重点强调的是系统所依赖的运行环境的配置，这里的运行环境通常也叫“基础设施”，即包括了云服务器、网络、数据库、负载均衡和中间件等业务应用所依赖的系统环境，目录可参考图 4。
图4：系统环境目录
在图 4 中，environment.yml 是一个环境所需要的完整模板，modules 里是各个资源模块，分别是云服务器、数据库、负载均衡和 VPC 网络，这里只包含了最最基本的云资源，对于有经验的 DevOps 工程师还可以增加更多的资源，如消息队列、kafka 等中间件，NoSQL 类型的数据库以及监控和报警规则。
环境的配置信息可以存储在流水线上，这样在部署时可以先部署环境、后部署业务。那部署环境时，可以根据实际情况选择创建一个新环境或是更新环境。一个环境配置通常包含以下信息：
- 环境类型：如日常测试环境、预发环境和生产环境。
- 环境地域：如杭州、北京和上海等。
- 环境其他参数：如账号、AccessKey/Token 和角色等。
- 资源相关配置：如服务器数量、域名等。
云上标准化部署三大能力
云上环境与传统数据中心的环境最大的区别是，云上的一切服务是以 API 为核心，资源的创建、修改和删除等所有操作都可以通过 API 来完成，因此云上部署是天然的规范化，从而提高了云上的部署效率，即实现了高效而统一的标准化部署。其中，典型的需重复部署的场景有以下四类：
- 环境部署，如日常测试环境、预发环境和生产环境，只需要构建一个部署，即可以通过新增 stage 的方式达到重复部署。通常由日常环境开始，然后重复到预发和生产环境。
- 多地域部署，如先部署在杭州、然后再部署到北京和上海等其他地域，可以快速地重复部署。一般只需要在流水线上新增一个新地域 stage，添加配置参数即可实现一键部署。
- 集群部署，如先部署了几个集群，再重复部署多个集群，同样也可以快速地重复部署。可以通过在流水线上新增一个新集群 stage，添加配置参数即可实现一键部署。
- 容灾环境部署，如先部署了一个主要的生产环境，再部署一个容灾环境时，采取集群部署的同样方式来实现。
通常，云上高效而标准化部署具备三大能力——消除环境差异、环境的快速复制能力和环境的重建能力。
-
消除环境差异，实现环境一致性。环境的微小差异即可带来业务上非常大的差异，而且排查起来非常困难，比起代码的 Debug 要费时费力许多，毕竟大部分的代码逻辑可以在本地复现和 Debug，但是环境造成的差异则非常繁琐，需要进行非常细致的排查才能找到问题的症结所在。而云上标准化部署能够消除环境差异，实现环境的一致性，大大地简化了运维工作。
-
一键部署，快速复制能力。从日常环境到生产环境，从 A 地域到 B 地域，从单集群到多个集群，无一不需要高效的复制能力，而环境的复制能力是其中的第一步，且是最为关键的一步。标准化部署能将原来的数天工作量缩短为几个小时，甚至一键部署的能力，可以说极大地提升了运维效率。
-
重建的能力。很多环境问题是问题历史悠久造成的，各种不规范、不标准的操作日积月累最终导致环境混乱。因此，对于日常测试环境来说，定期地推倒重建是非常有必要的，理由类似自动化测试，越干净的环境越能验证、复现和 Debug 业务问题。因此，当一个测试环境有问题时，应该可以做到随时释放并能够一键重建。
所以，如果在项目规划阶段就考虑到自动化部署能力，那么后续的部署无疑会平滑许多。然而，对于已经存在的项目是否也可以使用这个模式呢？答案是肯定的，这要求对应的服务有能力将已有的云资源转化成部署模板的能力，然后再根据修改这个模板以便可以重复使用。
完整 DevOps 体系应具备哪些能力？
如果说，100% 自动化是 DevOps 理想中的形态，那么任何环节的缺失都可能成为实践 DevOps 的障碍。通常，按照运维工作的流程来看，DevOps 往往会包括八个环节：计划、编码、构建、测试、发布、运维、监控，然后重新回到计划，开始新一轮迭。
图5：阿里云 ECS DevOps
值得重点强调的是，利用上述部署模板的方式，也是可以包括监控、报警等设置。因为一切皆是云产品、一切云产品都提供 API 缘故，因此才成就了部署模板是可以做到统一集中的。
笔者所在的阿里云，DevOps 体系不仅环境部署实现了模板化，连运维编排也可以模板化的，即自动化运维（阿里云提供运维编排工具 OOS），业界也把这种模式叫做 Ops as Code，Automation as Code 或是 Runbook as Code 了。因为产品的设计原则和思想和部署模板一致，所以不再赘述其详细步骤。
作为云计算产品的生产者，笔者同时也从一个云资源的全生命周期梳理了一个 DevOps 的闭环，如图 5。这张图笔者在 2020 云栖大会的分享中也做了阐述，可以用“四环图”来称呼它。
图6：资源生命周期四环图
一环：最核心的云资源，有服务器类资源，虚拟机服务器和裸金属，也可以包括容器实例。
二环：云服务器的生命周期的六个阶段：创建、镜像、补丁升级、诊断修复、监控和运维和实例配置。
三环：云服务器全生命周期的六个阶段，可以利用不同的工具可以提升效率。如实例的监控和运维，除了有云厂商提供的监控产品外，还有很多第三方的监控产品。运维方面，建议使用自动化运维类产品，如运维编排 OOS，可以把最常用的运维任务模板化，从而提供运维的规范性，减少因为人肉执行的失误，避免让运维背锅。
四环：除了使用云平台工具之外，还可以利用第三方的工具，如 Terraform、Ansible 等。另外，很多工具都不约而同地选择了模版的方式， 如 YAML、JSON、Hashicorp 自定义的 HCL 等。基于模板，可以构建一个生态，方便外部的参与者共同贡献内容，不仅丰富了 DevOps 的世界，最终达到了更高的 DevOps 效率。
图5不仅包含了阿里云的 DevOps 工具，也包括了业界较为流行的运维工具，它们的设计思想都是类似的，因此在工具的采用上可以根据实际需要分别采用。一般来说，如果使用的是单一云平台的云资源时，使用云平台一方的产品有着最一致的体验，集成度也最高，成本也是相对最少的。
这里，笔者还想简单提一下容器 DevOps 和云服务器 DevOps 的区别。当前，K8S 已经是容器编排（管控）领域的事实标准了，几乎所有的云服务商也都实现了各类托管 K8S 产品，甚至局部的 Serverless K8S。
很多云服务器的使用者对于 K8S 是心向往之，却又因为各种原因需要继续使用云服务器。笔者曾经这样评价过 K8S，“K8S 本身并不是什么技术上的重大创新，更多的是把 DevOps 里面的很多最佳实践产品化了”——这一说法也得到了部分容器专家的认同。
表2：容器管控（K8s）Vs 云服务器 DevOps
DevOps 落地的阻碍：如何和财务流程实现平衡
事实上，DevOps 并不是一个新鲜的概念，但是真正做到 DevOps 的企业少之又少，背后的原因是多种多样的。以笔者多年的经验看来，其中最大的两个因素：一个是财务，二是运维开发人员的习惯。
财务人员是典型的计划式模式，需先预估、再采购，这里最大的挑战在于没人能够精准地预测明天的事情，所以最终的结果要么是预估多了，要么就是预估少了，预估多了下一次的预估必定要收紧，预估少了再放松，然后循环重复这个过程。
财务上的限制对于 DevOps 的发展有时是致命的，这种“计划式”的模式直接影响到了云上资源的创建和释放模式，财务上喜欢“包年包月”，因为看起来比较划算，而 DevOps 运维开发人员则偏向于“按需分配，弹性伸缩”。
所以，笔者最后想呼吁各位财务专家多考虑下，给予技术架构上在预算上一定的灵活性，可以非常有效地帮助并促进业务高速发展。
作者介绍
吴君印，阿里云智能弹性计算 ECS 资深技术专家，负责部分 ECS 新产品、可信计算实例的架构，并全面负责阿里云智能 OnECS、OnAliyun 产品的技术研发和运维架构工作。拥有丰富的云计算行业的经验，致力于打造以 ECS 为中心的自动化和 DevOps 一体化的管理和运维体验。