演讲嘉宾简介：滕圣波（云普），阿里云高级技术专家，2018年5月加入阿里云，作为架构师搭建了ECS的事件体系，同时也是阿里云的官方自动化运维平台-运维编排服务的主架构师之一，目前负责ECS智能自治服务、云桌面等领域。在加入阿里云之前，是VMware中国研发中心终端用户计算部门的架构师，拥有北京邮电大学计算机专业的硕士和学士学位。

以下内容根据演讲视频以及PPT整理而成。观看回放
更多课程请进入“玩转ECS详情页”了解

本次分享主要围绕以下四个方面：

一、ECS自助服务概要
二、智能诊断
三、自动化修复
四、自助服务背后的AI与数据能力

自助服务水平的高低是云厂商的核心竞争力，阿里云经过过去几年的积累，已经有了非常高效的自助服务能力。今天就将这些能力透露给最终用户。本次分享由阿里云高级技术专家滕圣波（云普）为大家介绍ECS自助服务，解析ECS自助服务主要包含哪些方面的自助服务，并从诊断和修复两个方面为大家解密自助服务的技术实现细节，最后给大家介绍冰山之下阿里云的AI及数据能力，剧透ECS自助服务的未来。

一、ECS自助服务概要

1、人工客服

人工客服流程
自助客服或者智能客户越来越普遍，其实从线下银行的ATM开始，用户就能体会到自助服务带来的便捷与省时。与自助服务相对的是人工客服的服务。在阐述自助服务之前，下面先谈谈与之相对的人工客服服务。

阿里云人工客服流程如下图所示：

首先用户遇到了一个问题，便向阿里云控制台中的智能在线模块的智能机器人诉说自己的诉求，如果智能机器人判断是一个问题，则自动开工单，用户也可以自己在线开工单描述自己的诉求。

所有工单到一线客服端，一线客服会与用户反复的确认具体的诉求，比如是什么商品，订单号是多少，具体什么时间，影响用户的影响面是多少。

这些问题弄清楚之后如果一线客服可以自己解决则直接指导用户解决问题。如果不能，则将问题向上反馈到二线技术支持端。一线客服是阿里云小二，二线技术客服是阿里云自营的技术专家，技术专家与用户沟通与处理疑难杂症。

如果二线技术专家依然解决不了问题，如阿里云本身的服务缺陷，或者用户受限制的特权类应用，则上升到三线工程师或产品专家手中，他们是阿里云研发团队内部最后台的技术人员和产品人员。真正需要修复代码或权限的问题才由三线工程师解决。

整个问题处理链条非常长，涉及到很多部门和人员。而针对大客户会有专门的企业服务钉钉群，相较工单能够得到更及时的响应。

阿里云对外公开的业务不可用工单响应时间小于40分钟，这仅仅表示一线客服响应的时间。真正问题解决周期大概是1至24小时。即使是企业客服钉钉群，依然不能保证分钟级的解决时间。

人工客服主要有几个痛点：

1）首先是需要多次反复的沟通流程。

因为一线客服没有权限查询用户具体的查询或操作记录，所以不得不与用户进行反复的沟通，需要询问用户的操作时间，操作的request ID，从而在内部工单系统中补充这些信息，方便后面的二线及三线客服排查问题。这就导致沟通成本高，而且用户也未必放心将这些隐私信息交给客服。

2）其次，客服问题处理时间较长。

这是因为但凡需要人解决的问题，就无法很快的处理和解决。人需要读完所有的日志，还需要进行逻辑判断和分析。在问题复杂，数据量大，人工处理时需要时间就会较长。一线客服可以处理的问题或许需要半小时，二线客服处理问题则需要2-3小时，如果需要三线客服来处理问题则要以天为单位来计算。

3）第三点，人工客服处理问题是通过内部接口处理的，用户会问客服做了什么操作，解决了问题，但目前并没有把所有操作透露给用户，导致用户质疑操作是否透明。

2.自助服务

随后，阿里云提出了服务的升级方案，既开始提供自助服务。自助服务的理念是由用户自己借助AI的能力检测问题并修复问题。如下图中提供了自助工具，用户可以进行问题诊断，自助工具会告知用户问题的根因，进而用户借助自动修复工具，一键修复问题，解决问题时间缩短至在分钟级。

自助服务水平的高低是云厂商的核心竞争力，阿里云经过过去几年的积累，已经有了非常高效的自助服务能力。今天就将这些能力透露给最终用户。

目前阿里云自助服务功能可以覆盖80%的ECS常见问题，剩余20%不能覆盖的问题依然可以通过开工单解决。

对于80%的问题，解决周期从几小时缩短至分钟级，这就意味着了户的故障修复时间大大缩短，提升了用户的体验。

整个自助服务过程中完全不需要人工参与，所有操作记录在用户端可见，保证安全合规，无隐私泄露风险。

诊断工具和修复工具都是通过AI+数据的方式，借助阿里云海量的工单数据，可以越来越精准地进行问题诊断和修复。

二、智能诊断

1、ECS常见问题

自助修复工具背后，需要厂商有准确的健康诊断能力，发现故障的存在与产生的原因。

ECS最常见的问题可以分为四类：实例无法远程访问、实例无法启动和停止、实例性能异常、磁盘扩容未生效等。

实例无法远程访问，包含SSH，VNC，或者是RDT。这样的远程无法访问问题造成的原因是千差万别的，如网络不通，实例没有启动，服务异常等等。即使是网络不通背后也有很多原因，如安全组不通，运营商的网络出现故障。因此对故障的诊断并不是简单的if else的问题。

2、ECS诊断能力

阿里云提供了一键开启ECS健康诊断能力，为了达到80%的目标，需要进行全面的体检，从内到外分别是ECS 服务自身的健康诊断（包括阿里云网络服务，数据化服务，后台硬件服务），磁盘健康诊断（如存储空间，IO读写速率，磁盘本身的一致性），网络健康诊断（包括网络链路层诊断，网卡丢包，网卡加载等），Guest OS健康诊断（网络配置，关键文件配置错误，权限错误等等）。

下图展示了目前所支持的ECS诊断能力。

首先，从用户场景方面，针对无法远程连接问题将虚拟化异常、物理机异常、资源争抢受限（入门级的实例中，会出现一台机器上存储资源争抢的情况）、服务控制侧异常等现象根因透露给用户。

针对实例无法停止或启动问题，着重诊断磁盘健康服务，所谓磁盘加载异常指的是云盘在Guest OS以内加载失败，还有磁盘IO Hang，磁盘读写受限，扩缩容异常等根因。

网络问题分为几类不同的表象，最常见的有网络延迟、网络丢包等。网络健康服务会针对网卡加载异常、网络链路异常、网卡丢包、网络会话异常等现象进行排查。

ECS诊断能力不仅覆盖底层网络，还会对Guest OS以内网络进行健康诊断。

针对Guest OS问题，首先检查所有进程，检查CPU使用率，网络配置项，关键系统文件权限，文件系统配置等问题。从而判断Guest OS是否有可能出现问题，以及修复问题。

3、ECS智能诊断demo

那用户怎么样可以使用这个自助智能诊断服务？下面是一个简单的ECS智能诊断的demo，右键菜单“更多”中有“实例健康状态”，勾选“同时检测ECS系统内相关配置”，就可以进行包含Guest OS的更全面的检查。如果不勾选则只会对服务侧进行检查。因为Guest OS的检测需要用户授权才能执行。可以发现一共进行了54项检查，用户可以继续查看针对报告和详细细节。最后会请求用户反馈。

如果检查不通过，则如下图中一样可以排查出是哪些项有问题。下图显示是Guest OS中Linux系统参数配置异常。下方给出了详细文档帮助用户进行问题修复。

三、自动化修复

1、实例自动化修复

诊断本身只是第一步，当诊断出来根因之后需要进行修复。目前ECS自助服务提供的是文档和链接，指引大家进行修复，由此可以更加保护用户隐私。

阿里云目前正在做自动化修复功能。实例自动化修复逻辑如下图，问题定位周期是1分钟，即问题诊断过程，找到根因之后用户可以手动修复，此时提供修复文档和详细修复步骤；还可以选择自动修复，即与OOS（阿里云运维编排系统）结合提供自动化修复方案，为修复场景提供一系列的公共模版。

公共模版指的是阿里云对公有云的最佳实践。在具体的修复场景中再次进行检查，判断问题根因，再集合用户配置进行问题修复。阿里云也在控制台中提供一键修复能力，支持多个问题同时修复。而由于修复本身是一个高危操作，因此还支持单个修复项的回滚。阿里云即提供Guest OS内部的修复能力，还提供基于快照的整体修复能力。在修复之前对整个ECS实例做备份，修复之后重新诊断问题是否修复成功，要求用户确认。如果用户确认修复不成功，则进行回滚，恢复到实例之前的状态。秒级快照能力为一键修复提供了强有力的支持。

2. ECS修复能力

对修复能力而言，而是着重对应诊断能力。自助诊断服务判断出问题根因，针对具体的根因，提供不同的修复能力。

下图展示了针对诊断能力提供的修复能力一览表。

比如，针对ECS系统服务或磁盘修复，首先进行重启，再进行重新部署。此时可能丢掉本地化实例原始数据；再进行自动故障上报，故障比较多时进行故障隔离，帮助客户进行迁移操作。

针对网络问题，修复系统会进行安全组规则调整；同时做故障网络设备隔离，如果故障是由底层的网络设备引起的，修复方案就是使用正常的设备提供服务。

当发现Guest OS以内的网络配置不正确时，修复系统会自动校正配置使得网络通畅。

ECS系统服务修复方案中包括，推荐用户进行实例规格升级、磁盘规格升级、关键系统问题权限授予、或者手动开启若干个关键系统进程（ssh）支持远程连接、还有磁盘文件挂载变更、网络参数变更等。

这些能力还会随着诊断能力不断的扩充，未来希望95%的工单都可以自动诊断，以及80%的工单可以自动修复，剩余的是人工诊断和修复。

3、修复能力透明合规性

修复能力本身是一个风险操作，因此其透明合规性非常重要。

阿里云通过运维编排服务OOS提供自动化引擎，云助手命令提供Guest OS内的执行能力。

OSS和Guest OS都是用户侧的工具，使用了用户侧的RAM权限进行所有操作。这样使得一切修复逻辑可见，管理员可以在用户侧看到所有操作步骤，包括OOS公共模版命令和云助手公共命令。阿里云目前已经在Github上开源了云助手所有代码。

其次，一切操作可回滚，通过镜像和快照实现整机的数据备份。首先是进行操作系统内的数据备份，在无法回滚时进行整机的数据备份。并且一切权限可控，阿里云所有的操作都是通过RAM角色，而RAM角色是由管理员自己配置，随时修改或禁用RAM角色的RAM功能。

最后，一切修复操作都可以审计和追溯。自助修复功能很快会与大家见面，感兴趣的用户可以先行体验自助诊断功能。

四、诊断数据背后的AI和数据

1、AI算法

上面提到的AI修复，自动诊断以及优化推荐都只是冰山之上的用户体验，在冰上之下是AI算法和数据中台的支持。

AI算法中最重要的是根因分析和特征分类。

● 根因分析是指，在日志数据和Guest OS中发现很多可能的问题原因，但究竟哪个是真正的root cause则需要AI做分析。人分析时会看时间，发生的顺序，调用链路，AI也是同样的逻辑。
● 特征分类是针对用户的操作和异常进行分类，将用户的操作、配置、异常分配到具体的根因上。
● 态势感知是对风险的预测。
● 预测和推荐其中的预测是非常重要的，很多诊断需要在用户没有感知时就提供异常诊断，将风险扼杀在发生前。
● 用户画像是针对用户本身的属性进展诊断，不同的用户往往有不同的操作记录，不同的异常问题，以及不同的行为，这都需要不同的诊断，因此用户画像和行为分析可以辅助自助诊断。
● 决策树或专家经验也是重要的诊断方式。

支持AI算法的是数据中台，无论是数据的清洗还是打标都离不开数据中台的建设。

2、数据中台

数据中台涉及数据采集、数据清洗、数据分析和数据模型。
数据采集中分为三类数据，包括实时数据、准实时数据、离线数据：
● 用户当前的健康数据、网络数据都属于实时数据。
● 用户当前的操作记录、监控数据属于准实时数据。
● 离线数据是指过去每一天的数据的快照，离线数据是可以支持构建用户画像，行为分析的数据。

同时从采集数据源角度可以分为物理机数据、虚拟化数据（虚拟化库，如阿里云神龙）、网络数据（网络组件）、控制面数据（用户所有操作记录）、Guest OS内数据（云监控及云助手采集数据）。

所有数据采集完成后是非常杂乱的，需要进行进一步处理。首先将所有数据变成监控项，产生告警、metrics、日志。同时提供查询分析能力，即提供给AI还提供给网络平台。事件通知是通过数据产生的数据推送和订阅，如AI中台对某一列数据感兴趣，则可以进行订阅，特定事件出现时推送给订阅对象。

3、AI举例

实时内存异常感知

下面举一个例子，即实时内存异常感知。实际上，数据和算法处理过程中会遇到大量的类似的例子。实时内存异常感知指的是当内存出现可能预期的错误时，会影响到虚拟机的稳定性，因此需要第一时间识别到内存的错误并进行内存的替换。

下图展示了针对此类实时内存异常感知问题所对应的AI算法模型运作流程。

首先，采集原始数据，包括CE（更正的错误）原始数据、特征等；

接下来，进行数据处理，特征数据进入到实时预测模型中，进行非预测宕机模型、可预测宕机模型、混合模型、高准确率、高召回模型；

下一步进入投票模型，投票到各种各样的优先级的sls预测数据中，当precision大于50%时进入主动运维监控报警中心，产生告警；

告警生成后，进行宕机事实验证，如果出现问题了表明算法正确，如果没有出现问题则回到算法中进行更正。

诊断决策树

此外，再给大家介绍一个例子：诊断决策树，这个例子很容易理解。

诊断决策树有三个关键要素，首先是专家经验，其次是案例库，还有知识库。

大量的工单经过一线、二线及三线人工客服形成了专家经验；案例库是阿里云内部的；知识库是提供给用户用的。

专家经验是基于案例库和知识库抽象出来的各种逻辑规则，比如ECS启动失败原因可能是库存原因、调度原因、块存储、控制侧异常、Guest OS启动异常、底层虚拟化异常等。专家决策和决策树会依次排查可能的原因，下图中每个方块都是一个案例，决策树中专家经验和案例库是固定的，但如果某个链路中的案例很多，会先走这条链路，也就是说决策树中的案例库先后顺序和权值是AI自动调整的。

总结

自助服务是云厂商的核心能力，自助诊断和自动修复是自助服务的核心功能。当大家遇到ECS问题时，请先尝试自助诊断服务，而不是直接开工单，这样可以更快速的解决问题，节省时间。最后，ECS自助服务团队求贤若渴，欢迎大家加入！有需要的同学可联系本次演讲嘉宾滕圣波（云普）。今天的分享到此结束，欢迎大家持续关注阿里云ECS更多服务能力的更新。