关于javascript:一文读懂云上DevOps能力体系

9次阅读

共计 5618 个字符，预计需要花费 15 分钟才能阅读完成。

简介：阿里云 ECS 自动化运维套件架构师，深度拆解云上运维能力体系建设：自动化运维等级金字塔、自动化运维的进阶模式、DevOps 的根底外围、云上标准化部署三大能力……

云计算行业曾经有十多年的倒退了，话题早已从“要不要上云”转向“如何用好云”。“要不要”其实是一个决策性的话题，直到决策进去一个后果了，话题就算完结了。而“如何用好云”却是一个持续性的话题。

一般来说，在布局阶段开始，企业就会开始思考“如何用好云”，这个话题会随同用云的整个过程。如果简略地从工作类型划分，除了业务代码的研发（Dev），其余的局部都能够称为运维（Ops），蕴含资源创立（环境部署）、利用部署、资源管理、资源监控、报警、故障排查等工作。

笔者从事云计算工作超过五年工夫，参加开发过多款云产品，能够说既是云计算产品的消费者，也是云计算产品的生产者。在这里，笔者谈一谈对云上 DevOps 能力体系的多年思考和总结，心愿对筹备上云或是曾经上云的运维人员有所帮忙。

从运维自动化等级和水平来看，DevOps 其实是一种十分高级的自动化，不仅自动化水平比拟高，而且对于自动化的实现形式有着十分严格的定义。对于运维自动化与 DevOps 的关系，其实能够十分好地参考汽车主动驾驶技术分级规范，笔者做了个比照图，如图 1。

图 1: 自动化运维等级金字塔

如图 1，自动化运维可分为 5 个等级，别离是手动运维、半手工 / 半自动化运维、高度自动化、标准化运维和 AIOps，别离对应自动化驾驶的 6 个 Level，其中运维自动化 L2 对应了主动驾驶的 Level 1 和 2。为了不便阐明和比照这 5 个自动化运维等级，请参考如下的表格。

表 1: 自动化驾驶等级与自动化运维等级比照参考

Level 1：手动运维。一些技术能力个别的企业，在上云初期运维工作次要是纯手动，只能依赖云服务商提供的控制台进行操作。
Level 2：半手工 / 半自动化运维，运维自动化工作比例还不超过 30%。运维人员能够通过命令行（CLI）实现局部运维工作。
Level 3：高度自动化，运维自动化水平可达到 50%。企业运维人员会应用云平台的 SDK 调用 API 进行日常运维工作，同时自行开发运维零碎，但运维零碎通常无定制化和平台能力，和外部零碎紧耦合。
Level 4：标准化自动化，运维自动化水平超过 90%。企业的运维零碎已具备平台化、模版化和代码化的能力，可依据本身的运维需要定制化开发零碎。与此同时，运维人员已具备应用具备模板化的产品来实现运维工作的标准化和自动化。
Level 5：AIOps，即智能运维，运维自动化水平达 100%。不再须要值班人员，生产力齐全解放。这是以后很多大型互联网企业的运维指标，也是头部企业重点投入的方向。

2.1 模板化是最 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 的自动化形式。

2.2 模板化或代码化是 AIOps 根底

AIOps（智能运维）可能是咱们所有人的指标，不过现实和事实的差距还是存在的。现阶段的 AIOps 只在多数的特定场景下才有，比方弹性扩容场景下，能够对历史扩容数据进行学习后进行预扩容，或用 AI 的形式来检测某个指标是否异样等，所以 AIOps 还远没有达到齐全自动化的水平。倡议在特定场景里可进行 AIOps 的调研，在方向上对 AIOps 放弃关注即可。

即便如此，笔者还是违心表白本人的观点，模板化或代码化自动化运维（即 Level 4），应该会是 AIOps 的根底，因为只有所有运维工作都能够被自动化、所有自动化工作都十分标准和规范时，AI 才有机会进行学习，AIOps 才可能成为事实。

通常，云上自动化运维零碎的第一步是环境部署，这是根底同时十分重要的一步。一旦部署实现，后续想要再去批改代价会十分大。尤其是上线当前，会是一个环境迁徙的工程量了，所以环境部署是最先须要开始设计的。

图 2：CI/CD 流水线的零碎运行环境

3.1 CI/CD 流水线的零碎运行环境

以理论我的项目中使用 DevOps 模式的例子——CI/CD 流水线利用“基础设施即代码”的实际为例，看一下自动化部署的整个流程。

图 3：CI/CD 流水线

通常流水线的源头是从 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 和角色等。
资源相干配置：如服务器数量、域名等。

3.2 云上标准化部署三大能力

云上环境与传统数据中心的环境最大的区别是，云上的所有服务是以 API 为外围，资源的创立、批改和删除等所有操作都能够通过 API 来实现，因而云上部署是人造的规范化，从而进步了云上的部署效率，即实现了高效而对立的标准化部署。其中，典型的需反复部署的场景有以下四类：

环境部署，如日常测试环境、预发环境和生产环境，只须要构建一个部署，即能够通过新增 stage 的形式达到反复部署。通常由日常环境开始，而后反复到预发和生产环境。
多地区部署，如先部署在杭州、后需部署到北京和上海等其余地区，能够疾速地反复部署。个别只须要在流水线上新增一个新地区 stage，增加配置参数即可实现一键部署。
集群部署，如先部署了几个集群，再反复部署多个集群，同样也能够疾速地反复部署。能够通过在流水线上新增一个新集群 stage，增加配置参数即可实现一键部署。
容灾环境部署，如先部署了一个次要的生产环境，后须要部署一个容灾环境时，采取集群部署的同样形式来实现。

通常，云上高效而标准化部署具备三大能力——打消环境差别、环境的疾速复制能力和环境的重建能力。
• 打消环境差别，实现环境一致性。环境的渺小差别即可带来业务上十分大的差别，而且排查起来十分艰难，比起代码的 Debug 要费时费力许多，毕竟大部分的代码逻辑能够在本地复现和 Debug，然而环境造成的差别则十分繁琐，须要进行十分粗疏的排查能力找到问题的症结所在。而云上标准化部署可能打消环境差别，实现环境的一致性，大大地简化了运维工作。

• 一键部署，疾速复制能力。从日常环境到生产环境，从 A 地区到 B 地区，从单集群到多个集群，无一不须要高效的复制能力，而环境的复制能力是其中的第一步，且是最为要害的一步。标准化部署能将原来的数天工作量缩短为几个小时，甚至一键部署的能力，能够说极大地晋升了运维效率。

• 重建的能力。很多环境问题是问题历史悠久造成的，各种不标准、不规范的操作与日俱增最终导致环境凌乱。因而，对于日常测试环境来说，定期地推倒重建是十分有必要的，理由相似自动化测试，越洁净的环境越能验证、复现和 Debug 业务问题。因而，当一个测试环境有问题时，应该能够做到随时开释并可能一键重建。

所以，如果在我的项目布局阶段就思考到自动化部署能力，那么后续的部署无疑会平滑许多。然而，对于曾经存在的我的项目是否也能够应用这个模式呢？答案是必定的，这要求对应的服务有能力将已有的云资源转化成部署模板的能力，而后再依据批改这个模板以便能够重复使用。

如果说，100% 自动化是 DevOps 现实中的状态，那么任何环节的缺失都可能成为实际 DevOps 的阻碍。通常，依照运维工作的流程来看，DevOps 往往会包含八个环节：打算、编码、构建、测试、公布、运维、监控，而后从新回到打算，开始新一轮迭代。

图 5：DevOps 流程图

值得重点强调的是，利用上述部署模板的形式，也是能够包含监控、报警等设置。因为所有皆是云产品、所有云产品都提供 API 缘故，因而才成就了部署模板是能够做到对立集中的。

笔者所在的阿里云，DevOps 体系不仅环境部署实现了模板化，连运维编排也能够模板化的，即自动化运维（阿里云提供运维编排工具 OOS），业界也把这种模式叫做 Ops as Code、Automation as Code 或是 Runbook as Code 了。因为产品的设计准则和思维和部署模板统一，所以不再赘述其具体步骤。

作为云计算产品的生产者，笔者同时也从一个云资源的全生命周期梳理了一个 DevOps 的闭环，如图 5。这张图笔者在往年 2020 云栖大会的分享中也做了论述，相熟北京的敌人喜爱用“四环图”来称说它。

图 6: 云资源生命周期四环图

一环：最外围的云资源，有服务器类资源，虚拟机服务器和裸金属，也能够包含容器实例。
二环：云服务器的生命周期的六个阶段：创立、镜像、补丁降级、诊断修复、监控和运维和实例配置。
三环：云服务器全生命周期的六个阶段，能够利用不同的工具能够晋升效率。如实例的监控和运维，除了有云厂商提供的监控产品外，还有很多第三方的监控产品。运维方面，倡议应用自动化运维类产品，如运维编排 OOS，能够把最罕用的运维工作模板化，从而提供运维的规范性，缩小因为人肉执行的失误，防止让运维背锅。
最近，咱们曾经将三环的这一整套“ECS 自动化运维套件”正式对外公布，帮忙企业实现从 IT 架构的布局、迁徙、部署、弹性扩缩容，到日常治理全生命周期的自动化运维。利用这套工具，每一家云上的企业都能够低成本构建属于本人的自动化运维体系。

四环：除了应用云平台工具之外，还能够利用第三方的工具，如 Terraform、Ansible 等。另外，很多工具都不谋而合地抉择了模版的形式，如 YAML、JSON、Hashicorp 自定义的 HCL 等。基于模板，能够构建一个生态，不便内部的参与者独特奉献内容，不仅丰盛了 DevOps 的世界，最终达到了更高的 DevOps 效率。

图 6 不仅蕴含了阿里云的 DevOps 工具，也包含了业界较为风行的运维工具，它们的设计思维都是相似的，因而在工具的采纳上能够依据理论须要别离采纳。一般来说，如果应用的是繁多云平台的云资源时，应用云平台一方的产品有着最统一的体验，集成度也最高，老本也是绝对起码的。

这里，笔者还想简略提一下容器 DevOps 和云服务器 DevOps 的区别。以后，K8S 曾经是容器编排（管控）畛域的事实标准了，简直所有的云服务商也都实现了各类托管 K8S 产品，甚至部分的 Serverless K8S。

很多云服务器的使用者对于 K8S 是心向往之，却又因为各种起因须要持续应用云服务器。笔者已经这样评估过 K8S，“K8S 自身并不是什么技术上的重大翻新，更多的是把 DevOps 外面的很多最佳实际产品化了”——这一说法也失去了局部容器专家的认同。

事实上，DevOps 并不是一个陈腐的概念，然而真正做到 DevOps 的企业少之又少，背地的起因是多种多样的。以笔者多年的教训看来，其中最大的两个因素：一个是财务，二是运维开发人员的习惯。
财务人员是典型的打算式模式，需先预估、再洽购，这里最大的挑战在于没人可能精准地预测今天的事件，所以最终的后果要么是预估多了，要么就是预估少了，预估多了下一次的预估必然要收紧，预估少了再放松，而后循环反复这个过程。

财务上的限度对于 DevOps 的倒退有时是致命的，这种“打算式”的模式间接影响到了云上资源的创立和开释模式，财务上喜爱“包年包月”，因为看起来比拟划算，而 DevOps 运维开发人员则偏差于“按需分配，弹性伸缩”。

所以，笔者最初想呐喊各位财务专家多思考下，给予技术架构上在估算上肯定的灵活性，能够十分无效地帮忙并促成业务高速倒退。

作者：吴君印
原文链接
本文为阿里云原创内容，未经容许不得转载

正文完