来自阿里云弹性计算团队的王子龙，从如何构建 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 更适合应用提成。
4. 总结
最后针对今天所讲的内容进行一个总结，先给大家演示一下刚才讲的内容，首先在阿里云的官方文档可以看到，关于 ECS 事件的一个详细介绍，这里列出了不同的事件类型，同时在事件介绍里面包括事件的说明以及事件的影响，同时还会给针对这个事件给到用户的一些处理建议。
第二是关于 open API 在 ECS open API 的官方文档中有一个模块式系统事件，大家可以在系统事件这部分查看关于事件的 open API。比如 describe instance history events 是查询我们事例下所产生的历史的事件，这里会有关于 API 的详细说明。
同时我们还可以对这个 open API 进行调试，可以查看自己实例下有哪些事件。其次看一下 ECS 事件的控制台。在 ECS 事件控制台。我们可以查看到实例下所产生的事件，以本地盘受损事件为例，可以看到出现了一个坏盘事件，那针对这个坏盘事件可以看到当前这个事件的处理进度，以及我们还有后续的可以做的一些操作：比如修复磁盘，重新部署。
了解一下云监控，它可以去查看事件订阅事件。在云监控的系统监控部分可以查看事件。
我们可以查看以实例状态变化实验为例，我们可以看到当前这个实例所产生的实例状态变化事件。同时我们还可以基于事件创建我们对应的报警规则。比如我们可以定义自己的报警名称，选择产品类型，这里我们选择 ECS，可以选择事件的类型，比如异常类的实例还是状态通知类的事件；可以选择事件的等级，这里选择严重；选择事件的名称；那可以选择实例状态变化；同时我们还可以根据关键词去过滤事件。因为可能不是所有的事件我们都关注，最后可以选择我们通知的方式，可以选择报警通知，那就会发送对应的短信邮件，同时我们可以还发到对应的钉钉之类的。这里还提供消息队列、函数计算、U2 回调。
下面介绍一下 EVENT BRIDGE，我们可以查看发生的事件，还是以刚才的实例状态变化为例，那我们可以看到产生了很多的实例状态变化事件，同时我们还可以像云监控一样创建对应的规则去订阅事件，把事件投递到我们的目标端，这里创建一个进行演示。
比如输入规则名称，叫 test。事件源选择 ECS 事件源，事件类型选择实例状态变换，下一步选择投递的目标端，这里支持丰富的一些目标端，有钉钉、函数计算等，这里投递目标会比云监控更多。
大家可以根据自己的需求选择。展示一下在事件产生之后，可以在云监控和 EVENT bridge 去查看的一个过程，选择一个实例。比如重启这个实例，重启之后，我们就能会收到一个实例状态变化的事件，看一下是否查看到，从事件查看查询该事例下所产生的事件，修改一下这个时间选择，大家可以看到产生了一个实例状态变化事件，同时，在 EVENT bridge 里面也是同理。在事件的详情里面可以查看具体的一些事件的属性。
ECS 提供了丰富的事件。我们可以从多维度去衡量资源的稳定性主要呢，是有非预期的事件。计划内运维事件，安全费用类事件，资源状态变化事件。同时基于这些事件，我们可以构建可观测的体系。
第一我们可以基于事件配置短信，邮件报警，第二，我们可以在控制台和 open API 查询事件，第三我们可以配置自定义的监控，可以选择监控的渠道，同时基于ECS 事件还可以进行自动化的运维。第一我们可以通过控制台去响应事件，实现对资源的运维，第二可以通过 open API 去查询事件执行对应的运维动作，第三我们可以通过 EVENT bridge 云监控集成事件，进行系统化运维。
5. 使用 ECS 遇到故障时的痛点
大家好，我是来自阿里云弹性计算的樊超，今天主要介绍的是 ECS 自诊断工具，今天主要讲的是分为四个部分内容。
第一部分使用 ECS 遇到故障时的痛点，简单介绍使用 ECS 时的典型问题以及针对这些问题如何选择自主解决工具。第二部分一眼排障 ECS 健康状态,主要是帮大家介绍一个能够快速知道 ECS 当前是否有问题的工具。第三部分，一键定位 ECS 健康诊断,ECS 健康诊断能够详细的定位 ECS 当前的故障,并且根据当前的故障给出一定的修复建议，第四部分进行总结。
我们在使用 ECS 的过程中会遇到各种各样的问题，这里罗列了一些我们收集到的典型问题，
比如实例无法连接这些问题,可能是由实例配置异常,实例状态异常,实例网络不通或者运营商黑洞等各种各样的问题导致的，例如实例性的问题， CPU 负载高，磁盘 iops 高，网络丢包率高，实例性能受损等问题，实例操作问题，比如实例启动失败，实例登录失败，实例升降配失败以及实例续费失败等各种各样的操作问题。比如实例配额不足，我们会遇到各种各样因为配额达到上限而导致的配额操作问题。
当遇到这些问题时，我们脑海中自然而然的会有三个问题。
第一 ECS 是否有问题，还是当前我业务故障。第二，ECS 有什么样的问题到底发生了什么事情。第三， ECS 如何处理，如何处理这些已经定位的故障来恢复 ECS，从而恢复我的业务。
所以在遇到 ECS 故障时，我们可以选择不同的自主排查工具。
ECS 是否有问题，我们可以使用实例健康状态一眼能够看出来当前ECS 是否故障。当我们想知道 ECS 有什么问题，以及ECS 当前的问题该如何处理时，我们可以选择实例健康诊断来对 ECS 进行定位，从而得到具体的恢复建议和修复办法。
相比较于传统的走工单的流程去解决问题。自主排查能够更快解决 ECS 的问题。
在传统工单流程中，流程步骤多，周期长，享用慢，无法自主解决。只能等被动的等工单回复。而采用自主排查工具周期短，响应快，能够自主解决问题。通过使用自主排查工具，能够快速的获得当前 ECS 实例问题的详细报告以及根据报告快速的恢复 ECS。因此，我们强烈建议用户能够使用自主排查工具，对 ECS 进行故障定位和问题的修复。
6. 一眼排障 ECS 健康状态
第二部分一眼排障 ECS 健康状态，使用健康状态功能能够一眼确定当前 e cs 的是否有故障。
实例健康状态表示的是实例。操作系统的运行状态。通过实例健康状态可以快速确定 ECS 实例是否真正可用。用实例健康状态能够直接看到 e cs 当前的真正情况是什么。它是否故障以及是否真正在运行这里我们举了两个控制台的例子。在图一，我们可以明确的看到实例健康状态一栏三个实例都是正常的，代表当前 ECS 没有任何故障。
图二可以看到在状态这一栏里两个实例都出现了性能下降或实例受损。通过黄色的窗口可以明确的可以看出。第三个实例，因为已经停止，所以健康状态已经不适用。
通过这两个图，我们可以一眼确定当前 6 个实例的是什么样子。它当前是否有故障，运行状态是否 ok。
健康状态呢是一种定义。它包括 5 个值。在这里我们先简单的介绍这 5 个值的含义是什么以及用在什么样的场景下。
Initializing 初始化中实例状态，初始化中代表实例正处在初始化阶段。也就是实例在管控状态中已经运行中。但是在真正的情况下，它的操作系统还没有启动，也就是它还没有进入用户态，像挂盘 SS 是登录等操作都会失败，Impaired 性能受损或性能降级，这代表实例已经受到了损伤，它的健康已经受损。
当前的实例因为底层故障或该 SOS 问题已经不再正常。所以当用户遇到业务问题时，可以看看当前实例是不是处在impaired 的状态。如果当前处在 impaired 状态，说明 ECS 已经故障。
OK 正常，代表实例也完全正常，实例的操作系统正常运行没有任何问题。Insufficient data，数据不足，当实例处在停止中或者已经停止，健康状态已经没有意义。Not applicable，不适用代表当前实例已经被删除。一般情况下，用户不会看到该状态。健康状态是在 5 个状态值之前不断轮询的状态机。
我们从创建到删除实例分别介绍这 5 种之间的转化情况。实例在初步建设中处在 creating，说明实例正在创建中。创建完之后实例会处在 stop 的状态，那么此时健康状态是红色的。InSufficent Data 代表当前不适用。当实例开始运行，同时健康状态会进入到 Initializing。初始化中，代表当前实例正在运行，但是它的操作系统还在自检中，还没有进入用户态。
当操作系统进入用户状态，该 SOS 完全启动成功后，它会处在 OK 状态。也就是说，当前实例完全正常。当一个处在 OK 正常的实例遇到了各种各样的问题时，它会转变到 impaired 的状态。代表当前实例已经受损或性能下降。当这些故障和问题已经结束，实例恢复正常时，它会转回 OK 状态，最终这个实例会被停止，然后它会恢复到以 InSufficent Data 状态，最终又被删除。那么就会变成 Not applicable，实例已经完全结束了它的生命周期。用户可以在多种入口查看ECS 健康状态。除了 open API 接口，我们在控制台的两个入口处也可以看到 ECS 控制台的实例列表。
在这个列表页，我们可以清楚的看到，处在运行中的实例，它是正常还是受损中。然后下面图是我们在 ECS 控制台的实例详情页的右上角。
正常，实例健康状态是一个红色对号的图标。初始化中是一个实例正在刷新的图标。性能受损或性能降级状态，实例是一个红色的叉。数据不足，也就是实例处在 stop 或 stopping 状态时，它是一个黄色的叹号。
7. 一键定位 – ECS 健康诊断
第一部分，一键定位 ECS 健康诊断。首先，我们先举一个例子，利用健康诊断定位 ssh 无法连接问题，当用户通过 SSH 连接 0.129 这台 ECS时发现无法通过 ssh 登录。SSh 命令报错。
于是第二步，用户通过 ECS 控制台的实例问题排查页面对 ECS 实例发起了远程无法连接问题的健康诊断。
第三步，用户通过健康诊断得到了健康诊断报告,在健康诊断报告中，它可以明确的看到健康诊断对实例的 SSH 服务状态进行了诊断,该诊断结果表明，想登录的 ECS 的ssh 服务没有启动，并且在详细说明中有诊断修复方案的超链接。
第四步，用户通过该超链接获取了如何解决该问题的解决方案。通过该方案，用户可以主动的人工去修复该问题，从而解决问题。在这个 case 中，我们演示了一个用户从发现问题到发起，诊断，获取诊断报告。最后通过诊断报告中的解决方案，人工修复了该问题的完整过程。
使用健康诊断，快速定位 ECS 具体问题实例。
健康诊断功能可以对实例的系统状态，网络状态，磁盘状态等进行全方位的诊断，可以帮助用户了解实例的运行状态，及时发现并解决常见问题。这个图就是一个用户在进行实例健康诊断之后的诊断报告。我们可以看出，该实例通过诊断并没有发现任何问题。而且通过该图，可以看见该诊断对实例的多个方面进行了全方位的诊断结果。
实例健康诊断能够诊断很多常见的实例健康问题。
这些问题包括实例性能问题，诊断 ECS 实例， CPU 负载高，内存负载高，带宽负载高，磁盘 bps iops 高或者实例性能受损等。实例无法连接或启动异常，诊断 VNC 无法远程连接、SSH 无法连接、实例处于运行状态，实例操作系统无法启动等问题。网络问题诊断，诊断ECS 实例的网络性能受损，或者 ping 不通等问题。实例操作未生效，诊断 ECS 实例的变更操作未生效问题，例如云盘扩容实际未生效。资源配额不足的问题，能够诊断ECS 实例的各种配额是否达到了上限。有哪些达到了上限。
费用类问题，诊断 ECS 实例购买、退款、续费、升降配、转换计费方式等问题。安全风险检测，诊断 ECS 实例是否存在安全风险。例如系统漏洞，安全告警，恶意进程等。实例费用及安全行为审计，对 ECS 实例状态，实例费用，安全组等相关的操作进行审计追溯。用户可以拿到该实例的历史行为记录，从而对该实例的历史操作进行审计和问题追查。
介绍一下诊断报告的详细组成部分。
诊断报告由三个部分组成。
第一个是诊断指标。诊断指标是健康诊断的核心功能，一个诊断指标指明了该实例的一个具体的检查点，比如说 CPU 利用率，诊断结果条目，对诊断指标进行检查，返回的是诊断结果条目，一个诊断指标对应着多个诊断结果条目，诊断结构条目按照严重等级分为 Info、Warn、Critical。Critical 类型的诊断结果条目是已经影响到实例的正常运行，强烈建议用户进行修复。
强调一个特殊点，因为一个诊断指标对应的实际故障问题多种多样，有一些可能我们还没有覆盖的实际问题，所以当诊断结果条目没有异常时并不意味着该诊断指标在实际中不存在问题。诊断指标集合，一组诊断指标的集合，可以一次性对诊断指标里的所有指标进行诊断。
也就是说，诊断指标集合是发起健康诊断的起点，用户可以自定义诊断指标集合，比如说只关心网络的用户，可以把网络相关的诊断指标自定义为一个诊断集合，在发起健康诊断时只对该网络相关的诊断指标集合进行诊断，只诊断这些指定的诊断指标。又比如说一些用户可能只关心费用类问题，他可以把费用类的诊断指标组成一个诊断指标集合。每次诊断只发起该诊断指标集合的诊断，从而只得到关于费用的诊断结果，右图是各个诊断按指标概念所对应的内容。
诊断指标分类，在诊断报告里，为了方便用户查看和排查问题，我们先预定义的将诊断指标进行了分类。
这些分类只显示在诊断报告中与诊断指标集合无关。现在我们支持 8 大类诊断指标，集合，包括计算服务健康诊断，网络服务健康诊断，存储服务健康诊断，实例配置管理诊断，安全控制诊断，费用类诊断以及 Linux 或 windows 的实例操作系统内的相关本配置诊断，以及用户的行为回复。
重点介绍一下 Linux 和 windows 的实例操作系统内相关诊断。我们不仅能够诊断云操作系统的底座问题，我们还能帮助用户进行用户 guest os 内相关配置和行为的检查。当用户授权以后，我们可以帮用户进行windows 或 Linux 操作系统内各种配置状态和服务的检查，从而帮助用户定位内部的问题。
健康诊断入口。
第一个入口是在 e cs 控制台自主问题排查页面。用户可以在自主排查中通过预定义好的问题，选择合适的场景，发起健康诊断，从而获取诊断报告。第二个入口是 ECS 控制台工单在线服务，在线，入口在用户发起在线诊断后，机器人和可以根据用户的问题也建议用户是否走健康诊断。
用户点击健康诊断，入口就可以发起健康诊断，从而获取详细的 e cs 诊断结果。第三个入口是 ECS 控制台提交工单入口。在提交工单中，用户选择了云服务器，ECS 产品就会给用户提供很多的 ECS 排查工具。而这些排查工具底层使用的就是实例健康诊断工具。它这里只是帮用户根据场景做了预定义的诊断集。每一个具体的工具问题对应了不同的诊断集。以上我们介绍了两种自助排查的工具。
介绍一下 ECS 故障自主排查的最佳流程。
当业务用户的业务报警，用户怀疑 ECS 出了问题时可以首先检查健康状态。如果健康状态当前是 impaired 的状态。那么说明 ECS 的实例有问题，那么它可以进一步发起健康诊断定位 ECS 的具体问题。通过诊断报告中的异常诊断结果条目，它可以看到 ECS 的问题是什么，并通过健康诊断结果条目中的修复建议进行 ECS 的恢复。
另外一个场景是当用户想知道历史的业务故障时，它可以对 ECS 发起历史的健康诊断，健康诊断本身支持 30 天内的 ECS 历史故障排查。通过历史健康诊断，用户可以检查在某个指定的时间段内 ECS 事例是否发生过故障。
8. 总结
通过以上我们介绍了当用户遇到各种各样的故障，例如实例无法连接实例性能问题，实例操作问题，实例配额不足时，可以通过一眼排障健康状态来一眼确定 ECS 当前是否受损，当确定 ECS 是否受损过后，它可以通过一键定位健康诊断来直接对实例发起健康诊断。按根据指定的诊断及指标集合，进行 ECS 诊断，来明确 ECS 是否有相关的问题，诊断报告确定了该问题时，可以根据诊断报告中的修复文档进行人工修复，从而恢复 ECS。
