弹性计算技术公开课——CloudOps云上运维季圆满结束了，阿里云弹性计算技术专家郑大禹在本次系列课程中带来了主题为《使用OOS进行云上自动化运维》的课程分享，课程内容涵盖云上资源运维面临的挑战、OOS 自动化运维能力揭秘、使用 OOS 云上 CloudOps 实践等方向。
以下是他的课程内容整理，供各位开发者学习：
一、云上资源运维面临的挑战
云上资源有如下特点，首先是规模大，用户不需要建立自己的基础设施，可以理论上无限的购买所需要的云资源。另外，由于云上资源的弹性，用户可以根据自身的需求，随时随地的获取所需的云资源。这些都造成云上资源会比自建的基础设施规模更大。其次就是云上资源种类多。除了传统的计算，存储，网络资源外，云上提供了更多样化的服务。例如数据库，消息队列、人工智能 ai、物联网等多种类型的资源。
用户可以根据自身的需求购买相应的资源，省去了自身搭建的繁琐流程。由云上提供了各种类型的云服务，使得用户能专注于开发业务自身的逻辑。越来越多的技术架构下沉到云资源层。这一方面让用户无需关注基础设施的维护与管理，同时也使得云上资源的场景变得更加复杂。
正是由于云上资源的这些特点，资源的运维在效率，成本，安全等方面也面临着相应的挑战。
1、云资源规模快速增长
首先，云资源规模在快速的增长。云资源规模会随着业务的发展快速增长，企业需要管理更多的与计算，存储，网络等资源，这将大大增加运维的复杂性，需要企业投入更多的时间和人力资源来管理监控这些资源。企业需要建立有效的运维流程和工具，以提高资源的运维效率和可靠性。
下面以某云账号下的云资源规模为例，在开始的阶段，业务处于启动期，只需要几台 ECS 实例部署 web 服务就可以满足需求。时期云资源的增长比较平稳。采用一些手动运维的方式或者简单运维脚本的方式就能完成这些少量资源的管理。但是随着业务的发展，提供的服务更多，包括 API 大数据服务，资源规模呈指数限制增长。如果采取和之前相同的运维方式需要的人力也在积极增长。这时如何通过自动化的方式将之前少量资源下的运维经验批量复制到大致大量资源上，从而提高运维效率是一个挑战。
2、云资源成本也在快速的增长
云资源成本随着资源规模相应增长，企业需要进行有效的成本管理和优化，包括分析和监控资源的使用情况，采用适当的成本节约测试，比如节省停机模式，临时带宽升级等。与此同时，如何自动文化的将这些成本优化、运维措施应用起来，也成为了一个挑战。
在某云账号下的云资源成本为例，在开始的阶段企业仅引入了少量的 ecs 云资源，通过一些应用，一些成本优化的最佳实践方式能够降低云资源的整体成本。但随着业务的发展，引入了更多比如 ecs 资源或者其他云资源，包括例如数据库，消息队列等，需要对新引入的资源持续的进行成本优化。可以看到云资源的成本呈现了波动上涨的趋势。这时如何通过提升云资源的利用率，降低成本，自然也成为了另一个挑战。同时，如何通过将之前成本优化的经验自动推广到新引入的资源上，避免人工优化，也是一个关键点。
3、安全合规问题日益重要
云上的安全合规问题包括数据泄露，滥用服务系统漏洞、帐号劫持，拒绝服务攻击，不安全应用接口等。其实针对这些安全合规问题，云上已经有了不少的最佳事件。
比如随着云资源规模的增长，企业需要定期进行系统漏洞的管理，更新和升级系统的补丁、修复已知的安全漏洞。针对一些公司或者行业的合规要求，企业需要定期对云资源进行合规性检查，修复不合规的资源。
例如，某些行业对可靠性要求高，需要进行多可用区，甚至跨地域的容灾，企业就需要根据合规要求，对相应的云资源进行检查。如果资源不满足容灾要求还有进行相应的修正。整个过程耗时耗力，如何对部分安全合规要求进行自动的检查，并对不合规的资源进行自动修正，又成为了云上运维的又一挑战。
4、CloudOps 最佳实践如何落地
虽然云上绝大部分的运维操作已经封装成了 open api，但是这些最佳实践的场景往往不是简单的一个 api 的调用，或简单的云上云操作。它是一系列运维操作的组合,如何将众多的最佳实践自动化的应用到云资源上这将成为一个命题,OOS 运维编排服务正式提供了这样一种任务编排能力的平台。
二、OOS 自动化运维能力揭秘
简单介绍一下 OOS 服务，运维编排服务简称 OOS，是全面免费的云上自动化任务编排平台提供了自动化任务的管理和执行,作为平台提供了一系列自动化和半自动化的平台能力实，践基础设施运维及代码的 cloud office as Code 的理念。
首先在自动化能力方面， OOS 提供了批量操作，跨地域操作条件控制，并发控制等能力使得运维任务能够在多地域大批量资源等复杂场景下，高效稳定的运行。其次，OOS 也支持审批，暂停等半自动化功能。
例如对一些重要的运维操作，有些情况下会需要相关的或需要关键人员的审批通过才能执行,这是可以在 OOS 任务流程中加入审批步骤，通知相关人员进行审批,审批之后再自动执行。另外，对于一些无法自动化的步骤 OOS 也支持暂停操作,有相关的人员人工确认后再执行自动化操作,那么 OOS 还支持多种的触发类型，包括立即操作，定时操作，靠近触发操作事件驱动操作。
比如，如果我想现在立刻执行某个命令，就可以采用一级操作,这也是默认的方式。然后如果想明天晚上 8 点执行命令或者是每天晚上 8 点执行命令,这种周期性的操作或者延迟操作可以采用定时操作,如果我想针对一些云监控的告警条件。比如当 CPU 使用量高于 80%的时候，进行一些清理的操作，或者是当磁盘到使用量高于 80%的时候删掉一些不必要的文件,这时可以使用告警触发操作事件驱动操作，是结合我们云监控的事件，以 ECS 事件为例。
当在 ECS 启动的时候来进行一些初始化的操作,这时可以采用事件操作，OOS 是在这些能力的基础上提供了托管服务稳定，可靠，无需用户在 ECS 或者产品中进行安装配置,OOS 支持编排 70 多种常用阿里产品，提供 200 多运维任务场景，公共模板开箱即用,此外， OOS 所有的运维操作都可以在 action trio 中审计保障用户的审计需求。
基于上述的平台能力 OOS 构建了强大的 api 编排能力，以启动 ECS 实例并安装软件为例，在我们常用的运维方式需要先通过 start instance 启动示例。因为 star instance 集中实例是一个异步的过程，所以必须要等实例是运行中的状态才能在后续进行安装软件的操作。所以需要通过不停的 describe instance 来检查实例的系统状态。然后直到实例的状态是运行中,此时再通过 come on 的运行命令的 API 进行安装软件的命令。安装命令过程也是一个异步过程。所以我们需要通过不停的轮询来等待命令执行完成。在命令执行完成之后还需要通过一个 api described invocation result 来查询命令的结果输出，来确定命令是否按照我们期望来执行。
在 OOS 的任务流程中，将第一部分启动实例以及等待实例启动过程的分装成一个云产品动作，就是 ACS，ECS，StartInstance 在过程中，它既完成了启动成立的过程。同时它会等待实例已经是运行中，当动作完成状态，可以立即来进行运行命令的操作，无需再等待。然后同时进行安装命令动作，并等待命令执行完成，最终把结果输出。当这两个动作完全执行完成之后，现在的结果就会输出到任务的输出中,这样就能够一眼的看到命令是否按预期来执行，不用来维护复杂的流程。
平台能力和 api 编排能力的基础上后来是构建出了丰富的运维场景。包括常用运维任务、批量操作实例、批量管理软件、定时开关机、带宽临时升级、创建和更新镜像、清理磁盘,这些常用运维任务都是我们在收集用户的使用场景的基础上，抽象出来最常用的,这些通用的运维任务，把它提取出来，放在 OOS 的控制台。
同时，对这些操作的流程进行一些优化。另外， OOS 在提供这些基础能力的基础之上，还提供一些辅助场景的能力，包括软件包管理，参数管理，配置清单，补丁管理。软件包管理是在实例中安装阿里云 agient 或者软件包管理工具可管理的软件。
同时软件包还支持企业将自己的软件上传到 OOS 上,通过软件包进行版本管理来安装到对应的 ecs 实例,参数管理提供对参数的存储管理服务,支持文本数据和加密数据两种格式.加密数据这边采用了 MS 来保障加密的安全。配置清单是能够获取云服务器的 OOS 内部的一些信息,这些信息无法通过API来获取。
例如系统内软件包的安装的信息,另外还有系统中文件的一些信息，包括文件的大小，文件的更新时间。这些也都是无法通过 API 获取。所以这些信息我们是可以通过配置清单来获取，很自然的场景以刚才软件安装的信息为例，我们可以通过筛选一些未安装软件的实例，或者是安装的是软件的低版本的示例进行更新，把软件更新到最新的一个版本.
补丁管理是会对 ECS 实例的补丁系统补丁进行扫描或安装。
用户可以根据自己的需要灵活的设置补丁的扫描安装条件。比如在安装中只安装某个操作系统版本的补丁,比如只安装 windows2022 的操作系统，专门的补丁或者只安装中高危补丁,这样能够满足用户自定义的安装需求。
三、使用 OOS 云上 CloudOps 实践
1、高效运维：批量操作 ECS 场景
首先，我们将最常用的 ecs 操作抽象为批量操作 ECS 实例场景。其中包括启动实例，停止实例，重启实例，在实例中下载文件，续费以及更改续费类型，导出实例属性，修改实例属性，执行命令，更换系统盘，添加实例角色以及删除示例角色等功能。
对于批量操作 ECS 实例的场景，实例的选择方式也是多种多样的，例如可以选择账号下的全部实例，对于一些选择实例数量比较少的情况，可以选择手动选择对应的实例。实例数量比较多，并且又不是全部实例的情况下，这时手动选择比较麻烦，我们可以在 csv 中维护实例。通过上传 csv 文件的方式来选择大批量的实例。实例在 csv 中最多可以支持到 5000 个实例，可以满足绝大部分的场景。
如果用户的资源是通过标签或者资源组的方式来管理的。比如 it 部门的所有资源都打了对应的标签，或者是都是归属于 it 部门的资源组。此时可以通过指定标签或者资源组的方式来筛选实例，最后是配置清单功能，比如我通过配置清单中的信息筛选，没有安装某一个软件的实例，或者是说某个文件的更改日期在某个时间点之前的所有实例，这样是能够支持各种丰富的实例筛选的方式。
另外， OOS 还提供强大的速率控制的功能，支持频发控制和批次控制两种形式。比如有 100 台 ECS 实例，将并发度设置为 10，就能保证每次同时操作的有 10 个实例。当其中的一个实例操作完成之后，才会有下一个实例进来进行操作来，弥补他空间，保证同时一直有 10 个实例来进行操作，而批次控制是要保证这一批完成之后才会有下一批来进来。比如就是每一批有 10 个实例，即调第一批的 10 个实例都执行完成才会是第二批的 10 个实例才会进来，这是并发控制和批次控制之间的不同点。
同时， OOS 还提供了强大的失败暂停功能，如果设置了失败暂停模式的话，在批次中，如果某一个实例失败，它就会暂停在失败的实例处，可以根据需要选择是从事跳过或者取消。
一般来说，对于临时的错误或者因为资源的依赖没有准备好而产生的错误，再检查之后手动来修正这些依赖之后进行重试就能成功。如果是一些不重要的操作和一些不影响结果的可忽略的操作可以选择跳过。此时它失败的实例就不会继续执行，但是会继续执行剩下的所有实例。如果是一个比较关键的操作，不能忽略，此时可以选择取消。这样他就不会再执行下面的所有实例了。
2、高效运维：ECS 应用滚动升级
第二个场景是 ECS 应用的滚动升级，OOS 通过将 SLb ECS 云助手的原子能力包装为任务场景的云产品动作，辅加 OOS 的自动分批并发控制、错误暂停、重试继续等控制功能，完成 ECS 应用滚动升级的场景。在该过程中服务要保证一直在线，所以在应用升级的过程中不能一下把所有的 ECX 实例都升级了,需要进行分批的滚动升级，这样能够保证在任何时间点上都至少有一部分应用在提供服务。此时 OOS 就能够利用自己强大的分批能力。
以该场景为例，oos 将所有的 ECS 实例分为三批，每一次只处理一批的 ECS 实例。在处理一批的过程中首先将 ecs 实例重复在均衡中卸载，即将这几个实例的权重设为 0。这几个实例就不会提供服务。但是其他的剩余的实例仍然提供服务，保证服务并没有下线，然后卸载之后通过更新镜像 ECS 镜像或执行命令脚本的方式来更新 ECS 应用,在更新完成之后，再将更新后的 ECS 服务挂载到负载均衡器上,对外提供服务。
其次如果这一批次中有有执行失败的实例的时候可以根据需求选择是重试还是回滚操作来保证服务一直是稳定的。当一批次更新完了之后，会挂载到一些会 SLb 上对外提供服务。此时再开始筛出第二批，对第二批 ECS 实例进行滚动升级操作。然后第二批同样的操作滚动升级完再进行第三批的操作。直到所有的 ecs 都更新为最新版本的应用。此时滚动升级结束，这样就利用了 OOS 的强大的分批以及任务编排的能力来提升 ECS 应用发布效率。
3、高效运维：使用参数仓库管理基础设施配置
以两个场景为例，根据要求系统管理员需要定期的更新基础镜像的安全补丁。因为会涉及到一些安全漏洞的情况。所以它需要定期的来更新安全补丁。用户在将这些镜下应用到自己的系统中来创建这些资源。但是在传统的场景用户更新镜像需要同时更新所有的 rOS 模板，同时将旧镜像替换为新镜像。而使用参数仓库之后，用户只需要在所有的模板中引用参数仓库中的对应的参数，更新完镜像之后，只需要把镜像 ID 更新到对应的参数中。
接下来集中的来管理这些镜像 Id，就可以迅速将所有的模板都更新为最新的镜像，这样就避免了用户手动更新所有模板的复杂度，因为所有的模板有时候会更新的不一致、遗漏。
另一个场景是对于加密参数，应用管理员可能会近期的来轮转 ECS 和 rds 的密码，这些密码会使用在多种场景上。比如去更新云资源的密码 ECS 和 rds。然后比如一些 rds 的数据库的密码我们在应用中获取密码配置来连接数据库。在一些运维操作这种过程中也会使用密码。然后如果是这种传统的方式同样，在更新密码之后，应用管理员会对多个地方的代码以及配置进行更新。这样就会造成如果有遗漏，造成事故故障。
然后使用 OOS 加密参数管理密码之后，应用管理员只需要将对应的密码放进加密参数中。比如我们可以将测试环境和生产环境的密码做一个区分。然后对应的云资源的操作，运维操作中或者是应用操作中会根据密码的名字来获取对应的密码。这样能够保证不需要用户来去更新散落在各个地方的资源的密码，提高了运维效率。
4、成本优化：自动化云资源成本优化
OOS 实现的另一个场景就是自动的资源成本优化。用户的资源利用率往往是每日呈现周期性波动的。比如一些办公的服务，它的使用高峰是早上 8 点到晚上 6 点，晚上 6 点下班之后，他的使用承载度会降一个较低的水平。而一些游戏或者娱乐应用的周期可能正好和办公服务相反。高峰期是在下班后以及周末。此时通过总结这样的经验就为自动化的成本优化提供了相应的理论基础。以计算和网络资源为例的两个场景，就是图片的两个场景。
场景一，计算资源。用户的痛点是它的机器周期性的空前造成了成本浪费。首先，用户的机器负载高峰是从早上 8 点到晚上 12 点。晚上 12 点到第二天早上的 8 点，其实是一个低封期，用户在预估的时候，是按高峰期的计算资源来预估的。如果按低峰期的资源来预估，高峰期就会造成资源不足，造成应用拒绝服务，从而造成故障。但是，按高峰期的计算资源来预估，就会造成低峰期资源计算浪费。
Ecs 提供一个节省停机模式，通过节省停机模式，就可以在停机的时间段内对计算资源不进行收费。但是，用户通过节省平均模式来操作开关机需要自己来编写脚本，完成自动化，也较为复杂。所以 OOS 提供了一整套的解决方案，通过定时配置高峰期自动开机，低峰期自动关机来达成成本优化的目的。在早上 8 点，oos 将触发开机操作，到晚上 12 点，再触发关机操作。此时一部分闲置的计算资源，就被回收，从而降低成本。到第二天的高峰来临之前，早上 8 点再次自行开机操作，然后再到晚上 12 点进行关机，周而复始的来进行自动化的成本优化。
场景二是网络资源的优化。网络资源其实也是存在使用也是存在高峰和低谷的。早上 11 点到下午 13 点的是一个带宽使用的高峰期。此时明显比其他时间段所处的网络使用的水平要高。其他时间是一个低峰期。这样，如果是按低峰期设置固定带宽，会造成高峰期的使用的时候带宽被打满，从而无法提供服务，造成一些故障。如果要都是按高峰期来预估固定带宽的，会造成低峰期的带宽会有极大的浪费。如果使用一些大量的带宽，成本较高，因为高峰期很短。此时用户希望可以仅在高峰期临时的升级带宽。
ECS 提供临时升级带宽的功能。用户可以指定在某个时间段升级带宽到多少以及持续多长时间。因为带宽是一个比较固定的周期性波动，用户希望能够定时的来做操作。所以 OOS 也提供了定时的带宽，也是升级的方案来节约费用，在用户预设的时间短，比如 11 点的时候把带宽升级的到较高的水平，然后持续两个小时。
在用户的低峰期，再把带宽降下来，在该基础上，可以更进一步做操作。如果比如用户对高峰期的来临的时间估计并不是十分准确的时候，可以采用云监控告警触发的方式来进行临时带宽升级，比如带宽使用率超过百分之七十以上的，预测带宽即将迎来使用高峰，此时将临时带宽升上去，等高峰期一过，临时带宽会再降下来，通过这样的操作，能够做一些并不是那么有周期性规律的，资源的使用率能够进行一些优化。
5、安全合规：系统补丁扫描和修复
OOS 在安全合规的场景也有很多最佳实践，其中一个最佳实践就是提供的补丁管理功能：能够支持系统补丁的扫描和修复，达到 ECS 实例的自动的固定修复。
首先补丁管理在每种操作系统提供了一个开箱即用的默认固定极限，让 80%以上的用户无需配置，对补丁管理达到一个开箱即用的效果。针对那些对安装补丁有特殊要求的用户，OOS 也提供可以不使用默认的固定极限，而使用自定义的不定极限，可以对这些操作系统级别补丁的类型、级别、发布时间做一些自己的过滤和筛选。比如，用户对稳定性要求比较高，可能就只会安装安全性操作系统和安全相关的补丁，然后危险级别是高的一些比如 enhancement 这种优化的补丁，或者是低维的补丁就不会安装。
同时用户也可以对发布时间有要求，是安装发布之后一周以上的比较稳定的。因为有些补丁发布出来被测出来有问题会再回收。此时在补丁发布之后立即安装会带来一些隐患。当补丁发布经过比较长时间的测试之后，它的稳定性其实是有一定的保障的。
另外，补丁管理也像 OOS 的一些基础能力，支持多种的实例的选择方式。通过这种手动选择标签和资源组选择，配置清单选择，补丁管理是都支持的，针对这种场景比如在资源里，用户可能有测试环境的资源以及生产环境的资源。
两种资源可能需要不同的配置和测试。因为它的稳定性可能要求不是很高。所以我们可以每天都对它进行升级。一但有合适的补丁就立刻安装。生产环境对资源稳定性要求会更高一些，所以需要定期的每周来做。这些都可以通过选择实例的方式来达到这样的效果。另外，补丁管理还支持多种的修复方式，支持仅扫描。即只是扫描出来哪些安装了固定，哪些需要安装的补丁，但是并没有真的安装。先查看一下当前实例里面的具体的补丁安装情况。
另外，就是扫描并安装，此时它不仅会扫描补丁，并且会把复合不定极限的系统补丁的安装上。对于比较关键的补丁 windows 补丁或者是 Linux 以及内核的补丁的。有的情况下，它还需要重启实例才生效。用户可以说我安装之后，根据需要先不重启实例。此时补丁已经被安装了，但是并没有生效。然后用户可以预约一个比较合适的时间，一个运维窗口再来重启示例，让补丁生效或者是在固定安装之后立即重启实例，让它生效。这都可以在补丁管理里面进行设置。
补丁管理也支持灵活的处罚方式，比如立即修复或者是预约一个时间周期性的修复。补丁管理附带了目前多种的服务器的操作系统，包括 linux， windows 支持 9 种常见的操作系统。除了 windows server 外，还支持 8 种 linux 等于服务器的。它的几个版本包括 Alibaba Cloud、Anolis 、CentOS 、RHEL 、Debian 、Ubuntu 、Alma Linux 、Rocky Linux 。
用户通过补丁管理的功能可以一下来制定说修复一批的 ecs 实例里面可以包括 Linux 实例和 windows 实例，然后补丁管理的安装脚本会去根据实例里面的操作系统的类型拉取对应的补丁。比如 Alibaba Cloud 就会拿去对应的在补丁期限。如果是 windows 的补丁实例，会拉取对应的 windows 的补丁机械来进行补丁的安装以及扫描的配置。
6、安全合规：结合配置审计安全合规自动修复
另外配置审计是一项资源审计服务，确保资源持续性合规。可以结合 OOS 进行自动化合规修复是一项资原生计的服务。配置审计服务可以发现不合规的资源。通过配置审计服务对各种云资源进行审计，可以根据预设的这些规则，检查云资源的配置是否符合安全实践的最佳实践以及合规性要求。对于每一个审计的规则，用户可以配置 OOS 的自动修复的方案。因为在默认的情况下，配置审计是会检测出你有哪些资源不合规需要你来手动的进行修复。通过 OOS 自动修复的方案，就可以避免手动修复的方式。用户可以在配置审计检查出资源不合规的时候立刻触发自动修复。
以图中为例，这是一个云资源标签的一个创新。大家可以看到云资源上。其实我们打的是三类标签，一类是地区的标签，一类是部门的标签，即信息部一类是环境的标签，比如测试环境，生产环境。大家可以看到 ECS OOS 以及 VPC 上的每个资源都打了不同的标签，配置审计这边是可以配置一些合规的规则的要求。
比如今天配了一个规则，就是必须存在一个指定的标签部门。因为公司内会根据部门来进行成本的分账。如果你没有打部门的标签，我在分账的时候就不会把你算到部门里面。这样就会造成分账的不准确，没法把所有的成本都分划到各个部门里面做。所以配置审计就会对所有的资源进行检测，发现有一些资源没有打部门的标签。此时他会把这些资源记录下来。通过 OOS 触发自动修复的方式，根据预先设定的规则，对不合规的资源打指定的标签，修复资源上的标签。同时， ecs 就所有的资源上都打上部门相关的标签，这样能够保证分账的合理以及准确。
四、总结
云上其实提供了各种各样的最佳实践，包括资源运维的效率、资源成本以及资源安全的安全合规方面的最佳时间，OOS 的平台通过自身强大的任务编排能力以及添加的辅助运维能力能够多方面实现云上最佳实践自动化。用户基于 OOS，任务编排平台以及云上每个产品的最佳实践可以打造自己专属的自动化运维平台。OOS 最后的发展方向是打造构建自己的平台能力，通过降低使用门槛，支持更多的云资源，将最佳实践能够自动的应用到更多的云资源的场景中。然后用户在基于 OOS 平台之上的能够更方便，更高效的来构建自己的自动化运维平台。
原文链接
本文为阿里云原创内容，未经允许不得转载。
