一、保障业务系统的可靠性

在云原生时代，如K8S、微服务、异地多活等技术架构，都在为解决这一问题提供着各自的方案。要真正保障业务系统的可靠性，需要从第一性原理出发，对业务系统的可靠性进行拆分。

1.业务可靠性的三个阶段

第一阶段是事前预防阶段，旨在避免故障和异常的发生；第二阶段是事中处理阶段，即在故障真正出现时，如何迅速发现、定位并恢复；以及事后跟进阶段，即发现异常隐患后，如何跟进修复，并持续保障，避免同类问题再次发生。

2.三个环节的提升方向

首先，如何规避故障隐患。这需要我们更早、更及时地发现业务服务中存在的隐患，并探索有效的隐患规避方式。

其次，与云上更多的自动化能力相关。如何借助云上更全面、更自动化的工具来进行故障恢复。

最后，阿里云将提供持续的数据监测，确保用户的服务在持续、可靠的使用中。

 

二、云上业务系统可靠性的困难和挑战

阿里云在构建整体产品功能时，已经提供了丰富的云上运维能力，如云监控的监控告警、异常诊断、弹性伸缩等，不仅解决了成本问题，还能有效帮助业务规避风险。同时还提供了自动化的运维编排服务。然而这些能力的更好执行，依赖于我们能否更好、更实时、更准确地监测业务情况，避免过多的噪声干扰，从而给出正确的判断。

 

三、ECS视角：用户业务稳定运行的痛点

ECS作为基础设施层的重要组成内容，一方面提供了ECS侧的实力能力及物理基础设施运行情况的信息，这些信息均可免费获取。另一方面，在整个基础底座中，用户操作系统层面的信息，如运行数据、内核进程的使用量等，对业务有着重大影响。特别是在操作系统内核层面，对于一般用户而言，具有较高的门槛，因为操作系统相对复杂，用户难以快速在操作系统中做出问题判断。基于最原始的责任边界，阿里云主要负责底座的稳定，而在用户责任方面，致力于提供更方便、更灵活的工具，以减少异常发生。

1. ECS实例稳定性问题

要确认责任边界，即判断是ECS底层问题还是用户代码侧异常，这完全决定了不同的排查方向及需要查看的信息，因此需要快速定界并更快地发现问题。

2. 实例性能问题

用户在购买阿里云实例时，每个实例都有一定的规格，代表其能提供的CPU、内存以及存储、网络性能能力。如何更直观地识别这些能力，让用户了解自身业务是否与实例规格匹配，或存在哪些方面的性能不匹配，都会极大影响业务的可靠性。

 

四、即将发布ECS Lens:ECS可观测能力全面升级

ECS Lens即将在10月份发布。本质上它是基于阿里巴巴Cloudless洞察框架和ECS原有可观测性能力打造的，旨在全面提升云上业务的洞察能力、提升字符。Cloudless洞察框架提供了统一的数据接入、通用场景的可观测能力，如成本、访问、安全等场景，都能做到快速定义。同时它支持更多灵活数据的订阅，方便用户基于ECS实例的数据做更全面的可观测性分析。基于ECS原有的可观测能力进行升级，以支持用户更多不同的应用场景。本质上提供的稳定性能力能解决分钟级的异常发现，并借助原有的ECS系统事件，达到85%以上的隐患异常提前识别。针对实例性能问题，可以做到一键诊断，快速发现。

 

五、ECS Lens产品的全景图

ECS Lens是阿里云可观测体系下的一部分，分为整体可观测体系的爱视层、应用层以及用户业务层。在ECS这一侧，更多聚焦于ECS层，由于有一定的运维编排能力，便称之为ECS+层。

在整个能力体系上，首先由CIPO（Cloud Infrastructure Performance Observer，云基础设施性能观测器）基础底座提供整体的计算、存储核心指标的采集。接着，通过云监控会做用户操作系统内的指标采集，方便用户更好地识别当前实例的运行状态。基于CIPU底座和云监控的采集，会依托整体数据智能算法平台，提供更多的计划运维事件、性能风险事件以及实例状态变更的识别，确保整个全周期及各个异常状态点都能进行自动化的运维定义。

再到上一层，还有两块诊断分析的能力。一是实例健康诊断，对于常见问题，可以用实例健康诊断快速排查当前实例的异常。二是新增加的实力性能分析，帮助用户更好地使用实例规格，用好规则。

整体而言，提供了一个丰富的ECS系统监测指标、领先的异常感知能力，并能与云上可观测体系及ECS相关的应用能力相结合，整体保障用户实现端到端的可观测方案。

 

六、新增的功能

1.实力状态检查指标

实力状态检查指标旨在解决如何识别实力是否有异常，以及异常诱因是来自阿里云侧还是用户应用侧的问题。参考AWS的做法，开发了state check功能，一方面提供宿主机状态检查，另一方面提供应用侧状态检查，能够在分钟级内判断是否是阿里云侧的异常导致实力不可用。在异常识别能力方面，原先是提供了操作系统错误事件来帮助用户感知异常，但该功能需要用户应用持续3分钟以上不可用才会触发事件。为了减少误判，则设置这三分钟。然而这不利于实时的应用自动化监控。为了解决这一问题，我们新增了状态检查功能，以实现更实时的异常检测和更自动化的集成。

2.关于实力性能方面的能力提升

原先已经提供了ECS实例的如网络带宽、CPU利用率以及存储IOPS等用量指标，但对于用量指标，用户往往难以直接使用。例如，同样的实力，CPU利用率10%和50%对于业务的判断并不相同。对于比如Freddy的实力可能10%，已经达到了上限，但是对于四合的实力，它的50%的用量可能也只是一个刚刚好的、正常的状态。这样的话会基于实力上限做一个水位，这样就可以聚焦到百分比的逻辑，当应用达到80%以上的CPU利用率时，显然已处于不健康状态，用户可设置告警和通知。

3.性能风险事件功能

当实力在运行过程中某一项性能指标达到100%时，会记录性能风险事件，方便用户回溯历史运行状态。整体而言是从用量指标出发，推出了更多性能水位指标和性能风险事件，确保用户能快速查看当前实力的性能状态是否健康。此外还会提供一个性能分析页面，告知用户当前存在的性能风险及其来源，并增加规格推荐等逻辑，帮助用户更好地利用实际性能。

4.自动化恢复能力

通过指标和事件，定义了许多风险场景，并探索如何与更强大的自动化能力相结合。目前主要提供基于ECS系统事件的自愈能力，ECS系统事件更多聚焦底层ECS宿主机异常问题，它能够和ECS的维护属性相结合，比如在遇到故障之后，是要做重启还是停机的简单操作，能够闭环ECS测的问题，并通过实力重启等简单操作实现业务自愈。但对于一般的用户来说，一般的业务可能承受不起停机风险，所以会更加的倾向基于OS实现自身业务的自愈能力，比如针对业务咨询，可以在故障发生之前，做好业务切流以及数据的备份，保证故障规避条件下无损恢复业务，从而持续的保证线上业务的可运行性。

 

七、两个场景

一是公网带宽自适应调节，基于公网带宽利用率水位 ，当水位到达90%自动申请临时带宽升级，保证公网始终属于利用率比较合理的状态，避免延时过高导致上游应用出错；二是实例重部署，主要是来自于AI推理的算法，它需要用到很多的本地盘数据，但是在本地盘的数据发生损坏后，需要做实力的重置，但重置后，它本身的信用盘的数据仍然存在，这会导致它的实力在节点发现的时候出现异常，那么最好的方式是基于实力重置的逻辑保证全新的实力重新加到业绩群里来实现实力的恢复。

 

八、案例

1.关于OS自动重启及CPU利用率的异常

在日常的代码和发布环节中，很容易出现一些操作是应用侧的发布错误导致业务锁死，使整个实力的CPU狂飙，从而不可用。在这个情况下，建议用户配置告警与事件运维，比如当整个实力处于5分钟以上的CPU百分百的打满，本质上对于上游业务，除了一些离线业务作业外，在线业务基本上在这个阶段是处于不可服务的状态，则需要借助OS的能力告警与事件运维，定义具体的CPU的指标，把待关联的在线业务实际关联进来，并选择一个批量重启的模板。如果可以再定义比如恢复时长和调整内容。实现通化运维的能力这一业务，通化运维的能力会帮助我们做业务兜底，避免线上的业务持续跑满，从而百分百完全不可服务，是因为没有及时做治愈。

2.公网带宽

首先，公网带宽的费用都是比较贵的，对于一般的用户，更多的是基于包年包月固定带宽的方式来选择，但是为了偶发的一些大促或为了一些突发的业务高峰，会做一些临时概况的升级，通过这个方式可以既有效又省时省力的解决这一类的问题。

 

九、总结

ECS、MAS的目标是助力用户，尽享ECS的卓越性能和稳定性，全面增强ECS性能和稳定性的异常识别，结合智能化实现端到端的盈利，今天主要介绍的是稳定性性能以及自动化关联的关系，但是像降本以及其他的安全类的问题，在后续的产品研究中也会逐步的丰富和建设。