更多精彩内容，欢迎观看：
带你读《云上自动化运维宝典》——如何使用OOS有效进行云上自动化运维（1）：https://developer.aliyun.com/article/1405369
3. 使用 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 就所有的资源上都打上部门相关的标签，这样能够保证分账的合理以及准确。
4. 总结
云上其实提供了各种各样的最佳实践，包括资源运维的效率、资源成本以及资源安全的安全合规方面的最佳时间，OOS 的平台通过自身强大的任务编排能力以及添加的辅助运维能力能够多方面实现云上最佳实践自动化。用户基于 OOS，任务编排平台以及云上每个产品的最佳实践可以打造自己专属的自动化运维平台。
OOS 最后的发展方向是打造构建自己的平台能力，通过降低使用门槛，支持更多的云资源，将最佳实践能够自动的应用到更多的云资源的场景中。然后用户在基于 OOS 平台之上的能够更方便，更高效的来构建自己的自动化运维平台。
这就是今天课程的主要内容，大家如果对 OOS 产品或者 OOS 的一个最佳实践感兴趣可以扫码了解我们官方文档以及知识，和我们进行沟通。
