弹性计算技术公开课——CloudOps云上运维季目前已经圆满结束了，阿里云弹性计算技术专家王子龙和阿里云弹性计算技术专家樊超在本次课程中带来了题为《提升云上资源稳定性的两大利器：事件驱动体系构建&自诊断工具》的主题分享， 课程涵盖基于事件构建可观测体系、基于事件的云上运维、ECS事件驱动最佳实践、使用ECS遇到故障时的痛点分析、一眼排障ECS健康状态、一键定位ECS健康诊断等内容。
以下是本节课程的内容整理，供各位开发者学习：
大家好，我是来自阿里云弹性计算团队的王子龙,今天给大家讲一下如何构建 ECS 的事件驱动体系,如何基于 ECS 事件进行自动化运维，提升运维效率,从这四个方面给大家进行介绍。
1. 基于事件构建可观测体系
首先看一下如何基于事件构建可观测体系,先看一个真实案例。
某用户使用了突发性能实例，再进行大幅活动的时候，发现实例性能不符合业务预期，CPU 负载高，紧急进行了扩容，对大促活动造成了一些不好的影响，事后对该案例进行分析，可以看到，在问题可以发生时，如果能够提前感知对问题进行处理，就可以避免对业务的影响。
在使用 ECS 过程中会遇到很多突发问题。比如实例重启影响了正常业务使用，磁盘出现损坏，无法进行数据读写，创建实例后我们如何知道实例已经创建成功能够正常运行。针对这些问题，我们的共性思考就是能否提前感知问题，能否避免问题影响业务，是否能够知道问题产生的原因。针对问题，我们能做什么，如何处理从而对业务没有影响以及如何提升效率，比如使用 openai ati 的过程中，如何避免轮询更高效的感知 ati 的结果。
这里列出了使用 ECS 时可能会遇到的一些常见共性问题，在实例维度会遇到实例突然宕机，实例非预期重启，实例性能受损，实例欠费等问题，在磁盘方面会出现磁盘损坏，磁盘性能严重降低，如何换盘问题，从安全层面会遇到实例受 DDOS 攻击，是否存在潜在的安全违规问题，从业务操作层面启动实例，挂载网卡是异步的，怎么能够及时感知结果，创建快照时间比较久，如何知道快照什么时间创建完成。
接下来了解如何监测这些问题，这是公有云的完整架构数据图。通过对刚才列出的问题进行分类可以分为两部分，一部分是阿里云底层物理设备或者服务异常导致的问题，另一部分是客户使用资源的直接或者间接行为导致所产生的，而这些问题都会有对应的 ECS 事件，阿里云会把 ECS 实例出现到异常以及用户操作所导致的资源状态变化包装为不同类型的 ECS 事件，通过订阅 ECS 事件，可以监测当前实例的健康状态。
通过介绍 ECS 事件，了解事件和实例问题之间的关系。首先，不同的事件类型代表不同的问题。
比如磁盘不可用会对应坏盘事件，比如创建的快照。快照完成后就会有快照创建完成时间。目前 ECS 事件整体分为运维事件，用户事件，安全类事件，费用类事件。
每个大的分类一下都会有不同的事件类型对应不同的问题场景。比如都会有实例重启时间。非预期事件就是发生了重启通知用户，计划内运维事件就是未来某个事件会发生重启，用户可以修改重启时间规避问题。
对运维事件进行一下说明：运维事件分为非预期运维事件和计划内运维事件，非预期事件是指由于宿主底层软硬件突然出现故障，比如说硬件损坏，软件 Bug 等，导致其上的 ECS 突然变得不可用，计划类运维事件是阿里云计划对宿主级进行维护升级或阿里云发现底层物理机存在故障隐患，提前通知用户进行相关操作，同时我们根据受影响的程度划分了不同的事件等级，分为严重、警告、信息、三个级别。
如严重的等级，就表示这个事件需要被尽快处理，否则可能会导致实例无法使用，用户可以根据自己的诉求关注不同等级的事件。另外，事件会按照统一的标准进行定义，根据事件定义，我们能够一目了然的明白当前事件代表的含义，一般事件会包括资源类型。比如 instanse 代表实例，DISK 代表云盘。还会有事件起因说明该事件为何产生，还有对资源的影响，如宕机表示 ECS 实例会停止运行。
另外部分事件会有事件的状态，如 executing 代表事件正在执行中。另外，我们可以基于事件进行一些运维的操作。
下面看一下什么是基于事件观测实例的健康状态。
首先是实例产生事件后会通过阿里云的消息中心发送短信，邮件。在阿里云 ECS 控台可以查看实例下产生了哪些事件，也可以通过 open API 进行实践查询，这里可以只查询自己关注的事件。
同时我们也可以在云监控查看事件，在云监控的系统事件列表下可以根据不同的条件筛选不同的事件和查看，同时我们再用监控也可以配置自定义的报警规则，选择关注的事件，针对事件创建报警规则，投递到指定的渠道，目前支持多种投递渠道，同时我们还可以根据事件的属性进行事件过滤，实现更精确的观测。
2. 基于事件的云上运维
看一下如何基于事件进行运维，先看一个真实案例。
某个用户在业务高峰期实例发生了重启，影响了该时间段的业务。分析后发现，该实例的底层宿主机出现了故障。平台计划在未来某个时间段重启实例，通过迁移规避故障。而刚好该是时间为用户的业务高峰期，用户可以通过修改计划重启时间，避开业务高峰。但是用户忽略了这个通知。除了重启，我们还会遇到比如本地盘损坏，云盘残留安全问题，而这些问题都会有对应的事件，都可以基于事件运维提前规定，比如阿里云底层宿主机存在潜在的软硬件故障风险，需要重启。那此时 ECS 就会生成实例相关的计划内运维事件。
通过重启，重新部署等操作，可以提前规避底层的风险。同时我们还能指定重启的时间，避免重启对业务造成影响。比如本地盘出现损坏，会生成磁盘相关的事件。我们可以通过隔离坏盘，本地维修，磁盘恢复事件，来完成对受损的本地盘的处理。我们可以授权阿里云执行事件，也可以修改事件的执行时间，也可以通过系统去集成事件。
下面介绍一下基于事件进行运维的几种方式。
第一可以基于 ECS 控制台进行运维。我们可以在控制台试验列表选择关注的事件。如果事件太多，也可以通过一些过滤条件进行筛选。在事件列表会展示事件对应的实例，事件类型，事件的严重等级，事件状态。通过点击操作下方的按钮执行事件，不同事件对应的操作会有所不同，有的是重新部署，有的可以设置重启时间。具体的操作会根据实践类型而有所不同。
第二用户可以基于 ECS 事件 open API 进行运维。用户可以通过 open API 主动查询某个地域下全部实例或者某个实例的运维事件。
并且快速适配自己的业务系统进行自动化的对接。目前有三个新的 API。
一个是可以查询用户下某个地域内的沉没实例或者指定实例。第二个，就是我们对于外形中的状态的运维事件。用户可以去响应该事件，并授权阿里云执行默认的操作。第三我们可以修改某个地域下全部实例或者某个实例的运维策略比如说，修改运维的事件窗口，修改运维的维护动作。第三我们可以基于 EVENT BUS 平台进行系统的集成。我们会把 ECS 事件推到云监控，可以在 EVENT BUS 平台上订阅事件。
这里看一下基于 EVENT BREAK 示例。首先选择要订阅的事件来源。ECS 事件请选择阿里云官方事件源，然后选择需要订阅的事件类型，选择后会给出事件格式的示例。接下来呢，我们可以创建对应的事件，订阅的规则，选择合适的投递协议投递到我们的应用系统。目前支持了多种的投递协议，可以满足多样化的系统提升诉求。
3. ECS 事件驱动最佳实践
接下来看一下基于第三次事件驱动的最佳实践。这是云上某用户通过 EVENT bridge 订阅事件进行自动化运维的最佳实践。首先用户会在 EVENT bridge 创建实现规则，选择 HTTP 作为事件的投递协议。其次，用户会订阅关注的云产品产生的事件。EVENT bridge 也提成了阿里云很多云产品事件。当产品产生事件的时候会通过EVENT bridge 投递到用户自己的内部用户系统。
在用户系统中通过 KAFKA 进行内部的事件分发。事件会与内部的财务系统进行集成，实时感知费用变化情况，支持费用相关的业务。一些运维事件会按照优先级事件类型进行分类，分发给不同的运维人员进行处理。另外还有一些内部应用会集成事件，用来订阅资源状态变化。内部业务系统和应用程序通过实验驱动来集成阿里云的事件，方便运维人员通过事件进行自动化的运维。
这个是通过事件驱动解决轮询用户 OPEN API 体验差的最佳事件。用户会调用 ECS open API 操作 ECS 的资源。
但像启动实例，挂载网卡，创建镜像等操作是异步的，不能实时得到结果。此时用户就会调用查询类的 API，不断轮询资源的状态。但是轮询会遇到限流，并且会有很多无效的查询，不能实时感知结果。而通过事件驱动的方式，当有事件产生时， ECS 会把事件发布到 EVENT BUS 平台，如云监控，用户选择使用 MNS 协议，同时通过事件驱动的方式进行集成。
一方面更新内部业务系统的资源状态，解决资源状态更新不及时的问题。另一方面可以根据事件中的时间属性与内部运维系统提成统计整个操作的耗时。
通过事件驱动的方式，可以解决异步 Open API 轮询体验差，能够在第一时间感知业务操作结果，避免阻塞当前业务，同时事件驱动的方式编程更友好，相比 open API 更适合应用提成。
更多精彩内容，欢迎观看：
带你读《云上自动化运维宝典》——提升云上资源稳定性的两大利器：事件驱动体系构建&自诊断工具（2）：https://developer.aliyun.com/article/1405330
