阿里云鲍文乐：基于事件的自动化运维最佳实践

摘要：2022 年 7 月 25 日，云上自动化运维 CloudOps 系列沙龙_第二弹正式开启！阿里云弹性计算技术专家鲍文乐带来的主题分享是《基于事件的自动化运维最佳实践》，以下是他的演讲内容整理，本篇内容主要分为四个部分：

1.    为何事件如此重要
2.    让事件通知更有效
3.    事件驱动的运维架构
4.    云上托管事件运维

01 为何事件如此重要

系统事件代表了云资源状态的变化。以弹性计算的系统事件为例，上图代表弹性计算的系统事件来源。

为了给用户提供云服务器，需要底层的物理基础设置，以及中间的虚拟化服务。在虚拟化服务上，运行 Guest OS，最终给用户提供服务。

在运维类系统事件部分，阿里云负责运维物理基础设施和虚拟化服务。当计算、存储、网络组件出现故障，阿里云会发出运维类的系统事件。这些运维类的系统事件，要云厂商和用户通过协作，一起运维。

在资源状态变化类事件部分，不一定代表故障或者问题。但它是实现事件驱动架构的基础。

如上图所示，展示了部分典型的系统事件。

在非预期异常方面，实例宕机可能导致用户的服务中断。如果本地盘的实例发生宕机，阿里云无法替用户决定，是否将实例迁移，所以用户必须响应。

在计划内运维方面，最常见的是主动运维类事件。实例因系统维护计划重启。当计算、存储、网络等底层硬件出现问题，但没有严重到立刻宕机。

在这种情况下，阿里云检测之后，会给用户发送一个计划类运维事件。在一定时间内，如果用户不进行响应，阿里云会帮用户把这台机器迁移到一个健康的硬件上。

如果用户响应，可以在阿里云给出的的操作窗口里，选择一个对自己最有利的，对服务影响最小的时间点。提前迁移实例，从而规避计划重启。

在费用方面，如果实例到期停机，系统会在实例到期前三天，发出事件。用户需要规划自己的续费方式，比如自动续费。

在状态通知方面，实例生命周期状态变化代表，ECS 的实例管控状态发生变化。比如实例创建，实例启动，实例停机，实例释放等。

上图展现了云上事件运维，常见的几个形态。从下往上，自动化程度越来越高。阿里云推荐用户尽量做到事件运维的自动化。

第一层，用户被动的接收通知，登录控制台手工处理。
第二层，用户有一定处理事件的意识，主动订阅事件通知。
第三层，用户有一定的技术实力，建立了自己的自动化或半自动化的运维系统，通过事件驱动的架构，按需处理各种级别的事件消息。在处理时，通过调用云产品的 API 运维。
第四层，托管的自动化运维。用户完全把事件的运维逻辑，放到阿里云上，由阿里云托管运行。

02 让事件通知更有效

接下来，讲一讲如何让事件通知更精确。云监控提供所有云产品系统事件，统一的查询入口以及事件报警功能。

目前，已经有一百多种云产品，将自己的事件信息发送给云监控。包括云服务器、云数据库、容器服务等。

云监控在用户侧，提供两大类的服务：

第一类，用户可以主动查询。通过控制台查询系统事件，也可以通过 Open API 查询系统事件。

第二类，从系统往用户的事件通知。基于云监控事件的报警规则，订阅事件通知的功能。

云监控的通知渠道分两大类：

第一类，面向人工。包括电话、短信、邮件以及基于 Webhook 的工具，比如钉钉、飞书等等。

第二类，面向自动化运维程序或者运维系统。有消息队列、日志服务、函数计算、URL 回调等。基于软件库，可以实现事件的自动化处理。

上图是云监控事件的通用格式。一百多种云产品的系统事件，汇集到云监控之后，纳入统一的事件模型。

事件数据是 json 格式，外层是事件的公共属性，比如事件唯一的 ID，事件来源等，事件级别，事件名称，事件发生的时间、所在地域等等。

其中，content 字段代表事件的内容。它和具体某一类事件相关联。云产品的事件逻辑决定了，不同事件有不同的内容。

EventRule 是事件的筛选规则，按照事件的公共属性以及事件 content 对事件进行匹配。

Rule Targets 是事件通知的目标。其中，报警通知代表人工通知，包括电话、短信、邮件、钉钉、机器人等等。消息服务队列、函数计算、URL 回调、日志服务等等，供程序自动化消费使用。

一旦出现符合匹配事件报警规则的事件，云监控会把事件路由给相应的 Target。如果选择多个 Target，每个 Target 都会收到通知。

为了让事件通知更有效，阿里云通过使用标签，对资源进行分组，让报警规则的粒度更小。然后，通过动态标签规则，创建云监控的应用分组。

于是云监控的应用分组和标签，产生了一对一的关系。用户也可以在应用管理系统，通过导入标签，创建应用分组。应用管理会自动配置云监控的应用分组。

然后，基于分组创建报警规则。首先，按照不同的角色，不同的职责，创建不同的联系人分组。接下来，按照事件的严重程度和接收人，划分多个报警规则。

除此之外，用户可以利用云监控的筛选能力，做细粒度筛选。在一个事件里可能有实例创建，释放，启动、停止等多种状态。用户可以通过关键词过滤或者是 SQLFilter，精确地筛选一类事件里的某一类状态。

在选择通知方式方面，用户按照事件的级别，选择不同的通知方式。避免事件通知沦为垃圾短信和垃圾邮件，推荐钉钉群报警。

事件规则细化之后，创建事件报警模板。把模板应用到 N 个分组上。从而实现了报警规则的批量复制，减轻维护压力。 

03 事件驱动的运维架构

基于 OpenAPI 轮询资源状态获取状态变更实时性较低，有大量冗余请求，系统消耗高，有限流的风险，并且依赖多个云产品 API，进一步增加了复杂性。阿里云通过改造事件驱动架构，提高了实时性和稳定性，降低了系统消耗。

某客户原先通过轮询云产品的 API，获取事件信息，存储到运维系统。运维团队把事件推送到运维门户上，由各个业务系统负责响应事件。业务系统不直接上阿里云控制台。

由于它使用了多个云产品，运维系统里有 N 段轮询代码，实时性也不好。

将系统改造成事件驱动架构。系统在初始化阶段，在云监控设置了事件报警规则。云产品发布了事件之后，云监控检测到事件匹配，把这个事件推送到指定客户的消息队列里。客户的运维系统从消息队列里，拉取事件消息，存储之后，推送给运维门户。

通过上述操作，简化了代码逻辑，降低了资源消耗，提高了实时性和稳定性。

在弹性伸缩方面，当实例释放之后，ECS 管控会发布一个实例状态的变更事件。云监控根据规则，路由给弹性伸缩消息队列。然后，弹性伸缩消费事件消息获取实例信息。弹性伸缩将实例从伸缩组移除，根据伸缩规则，进行下一步操作。 

04 云上托管事件运维

运维编排 OOS 系统，能够自动化管理和执行运维任务。相比传统的纯手工运维或脚本运维，门槛低、规范安全、效率高、易维护、免费。

在运维编排里，提供了事件运维功能。首先，设定事件规则，限定资源范围。然后，选择事件触发之后执行的运维模板，设定模板参数。

阿里云提供的抢占式实例，是一个比较便宜的实例。购买抢占式实例之后，会有一个小时的保护期。一小时后，实例随时有可能被释放回收。在回收前的五分钟，抢占式实例会发布一个实例中断通知。

通过 OOS 事件运维，在实例被回收之前，摘掉所有与之关联的负载均衡，实现不影响业务的优雅下线。

在运维模板里，一共分了五个步骤。

第一，eventTrigger。即监控抢占式实例的释放事件。
第二，describeSLB。即查询释放的抢占实例所在负载均衡 ID。
第三，setBackendServers。即将释放的实例在负载均衡上的权重设置为 0。
第四，waitConnectionExpire。即等待已经建立的网络连接断开。
第五，removeBackendServers，即将释放的实例从负载均衡后端服务器列表上移除。

Q&A 环节，用户问答

Q1 资源编排 ROS 和 OOS 有打通的最佳实践案例吗？

答：打通没有问题。ROS 将 OOS 模板和执行定义为资源，支持执行 OOS 模板。因为 OOS 通过 API 编排，所以 OOS 里可以调用 ROS 的 API，从而创建一个资源栈。

Q2 OOS 运维编排的模板必须自己配置吗？

答：不是。编排提供了一些常见的运维场景，可以在控制台操作，点击配置即可。

Q3 突发性能实例的性能受限怎么办?

答：服务可能受损，需要检查突发性能实例的使用是否符合预期。可以考虑对实例升配或者更换成非突发性能实例。