摘要：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突发性能实例的性能受限怎么办?
答：服务可能受损，需要检查突发性能实例的使用是否符合预期。可以考虑对实例升配或者更换成非突发性能实例。
