云监控发布新feature，打通事件中心和函数服务，可以实现秒级故障恢复。
试想这样一个场景：
当ecs宕机时，在几秒内实现eip自动迁移至另一个健康的ecs实例，快速故障恢复，避免损失。
如何做到？
云监控之前推出了事件中心，定位于，将阿里云上发生的对用户有影响的事件，集中起来，统一展示，统一管理；同时，__可以实现在云产品异常事件发生的第一时间，对用户广播通知，同时打通了事件与函数服务，在事件发生时触发函数计算的执行，快速实现诸如eip迁移，slb带宽扩容，slb摘掉故障服务器等操作，以实现故障的快速恢复__。
架构示意图
在这个架构中，云产品提供各类事件，使得整个场景能够有米下锅；云监控在这个链路中，起到了枢纽的作用，有效串联了各云产品的事件和函数计算，再通过函数计算串联到各云产品的管控API，使云产品之间可以有效的联动。
故障发生>云产品事件>云监控广播>触发函数计算>云产品管控api>故障恢复
关键组件：云产品异常事件和运维Api
ecs作为先锋产品，率先开放了12个对于用户极其重要的运维事件，使得基于事件的自动故障恢复可行。8月份，ecs还将继续开放更多的事件。
- ECS目前开放的系统事件
| 事件名称 | 事件含义 | 状态 | 事件等级 |
|---|---|---|---|
| Instance:InstanceFailure.Reboot | 因实例错误实例重启开始 | Executing | CRITICAL |
| Instance:InstanceFailure.Reboot | 因实例错误实例重启结束 | Executed | CRITICAL |
| Instance:SystemFailure.Reboot | 因系统错误实例重启开始 | Executing | CRITICAL |
| Instance:SystemFailure.Reboot | 因系统错误实例重启结束 | Executed | CRITICAL |
| Instance:SystemMaintenance.Reboot | 因系统维护实例计划重启 | Scheduled | CRITICAL |
| Instance:SystemMaintenance.Reboot | 因系统维护实例计划重启已规避 | Avoided | CRITICAL |
| Instance:SystemMaintenance.Reboot | 因系统维护实例计划重启执行中 | Executing | CRITICAL |
| Instance:SystemMaintenance.Reboot | 因系统维护实例计划重启已完成 | Executed | CRITICAL |
| Instance:SystemMaintenance.Reboot | 因系统维护实例计划重启已取消 | Canceled | CRITICAL |
| Instance:SystemMaintenance.Reboot | 因系统维护实例计划重启已失败 | Failed | CRITICAL |
| Disk:Stalled | 磁盘性能受到严重影响开始 | Executing | CRITICAL |
| Disk:Stalled | 磁盘性能受到严重影响结束 | Executed | CRITICAL |
更多事件详情：https://help.aliyun.com/document_detail/66940.html
关键组件：云监控
云监控是阿里云的核心基础服务之一，服务了近百万企业用户。
云监控产品的核心目标是，帮助企业用户提升服务可用率。降低MTTR-平均故障时间。
关键组件：函数计算
阿里云函数计算（Function Compute）是一个事件驱动的全托管计算服务。通过函数计算，您无需管理服务器等基础设施，只需编写代码并上传。函数计算会为您准备好计算资源，以弹性、可靠的方式运行您的代码。更棒的是，您只需要为代码实际运行消耗的资源付费 - 代码未运行则不产生费用。
关于可用率
可用率的定义（百度百科）：
计算机有效性的表示，它是在一段相当长的时间内， 计算机的可用时间与故障时间，维修时间及可用时间总和比。
简单理解就是：MTTR(平均故障恢复时间)/MTBF(平均故障间隔)的比值。
如何有效提升可用率
如上所示，提升可用率，一是降低MTTR，二是提升MTBF。降低MTBF和提升MTTR的效果一样，但是代价却很不一样。尤其是在云时代，单点的错误非常常见，故障难以避免。一方面用户需要自己设计高可用架构，提供适当的容错，另一方面，也需要快速的故障发现和快速的故障恢复。
如何降低MTTR
1，及时的发现故障，并广播通知
2，在可控范围内，快速的自动化的恢复故障，
通过事件中心的广播，快速发现故障，并广播给用户
云监控作为阿里云的基础服务，推出了事件中心。 产品定位于，将阿里云上发生的对用户有影响的事件，集中起来，统一展示，统一管理，让用户可以方便的了解这些事件，这些事件通常都是对用户有比较严重影响的事件，比如：ecs宕机，hang机，rds主备切换，slb证书过期，slb丢包等。事件发生后，可以在秒级内对外广播通知。让用户及时的了解故障发生，以便作出迅速反应。
故障自动恢复的风险和可行性
自动化的故障恢复通常伴随着相当高的风险，要非常谨慎；但是，通常大部分的故障都有相似性，符合28原则，80%的故障是由于20%的常原因导致， 对于这20%的高度一致的故障，迅速采集自动化的恢复措施，将有助于帮助用户快速的恢复故障。
当然，自定义的可编程的故障恢复将有助于用户定义自己的healing action。基于阿里云的函数计算服务，可以轻松实现这一灵活性。同时，函数计算服务，也会提供诸多标准化的模板，比如，slb带宽调整，eip迁移等，用户只要套用，轻点几下鼠标，即可以轻松实现。完成以下场景的自动化运维：ecs宕机时，几秒内完成eip迁移到另一台ecs；在业务高峰时，迅速的调整带宽，以适应业务的需求。
以上场景，基于'云产品事件>云监控>函数计算'这个链路，可以秒级的完成，从而快速的恢复故障，从而提升用户服务的可用率。
事件中心效果图
说了半天，看一下事件中心的真面目
未来规划：
未来，不只是系统事件，业务自己的异常事件， 也可以支持触发函数计算，这将大大拓展函数服务的价值边界，带
来更多的可能性。
这一切，都是为了更好的可用性。
注：该功能已经灰度上线，感兴趣的同学，可以申请公测。钉钉扫描二维码：
<div id="8ozdzz" data-type="image" data-display="block" data-align="left" data-src="https://cdn.nlark.com/lark/0/2018/png/32463/1533527800957-d1aef80d-c9e1-4827-9bd6-f2da75636724.png" data-width="273">
<img src="https://cdn.nlark.com/lark/0/2018/png/32463/1533527800957-d1aef80d-c9e1-4827-9bd6-f2da75636724.png" width="273" />
</div>
