开发者学堂课程【玩转云上智能运维：ECS 自助服务之智能诊断和自动化修复】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/118/detail/1971
ECS 自助服务之智能诊断和自动化修复
内容介绍：
1. ECS 自助服务概要
2. 智能诊断
3. 自动化修复
4. 自助服务背后的 AI 与数据能力
一. ECS自助服务概要
自助服务诞生之前，人工客服的流程：
首先假设我们的用户遇到了一个问题，他在阿里云的控制台上会有一个智能在线，就是我们的客服机器人，他会向客服机器人来诉说自己的诉求。
如果克服机器人判断这是一个问题，会自动的开工单，其实用户的话也可以在线提交阿里云的工单，描述自己的问题，所有的这些工单都会到我们的一线电话客服，一线客服会跟我们的用户进行一个反复的沟通和确认，沟通清楚之后，一线客服如果能自己确认，就直接指导客户去修复问题。
如果一线客服觉得这个问题比较困难 或者可能是产品测本身的问题会上升到我们的二线技术支持，如果二线技术支持依然不能解决客户的问题，会继续上升到我们的三线工程师或者是我们的产品专家，我们的三线工程师和产品专家实际上是我们研发团队内部的最后台的我们的技术人员，以及我们的产品人员，所有的问题都会在三线这边得到一个解决。
但是只有真正需要三线去修代码的问题或者需要加特权的问题，这是我们目前对于人工客服的一个流程。
人工客服的三大痛点:
1、为什么我的实例出问题了?
-背景沟通成本高
2.为什么这个问题这么久了还没解决?
-问题复杂、数据量大、人
工处理需要较长时间
问题看起来是修复了，你刚才做了什么?
-客服操作不透明自助服务
自助服务的理念是由用户自己去借助 AI 的能力和自动化的能力去检测问题并修复问题，在这个链条里，除了刚才的工单之外，还添加了一个更快的通路，就是提供了自助工具给用户，用户可以直接在控制台做资源的诊断，我们会告知用户根因是什么，用户可以进而用我们的自动修复工具一键的把问题修复，我们认为，自助服务水平的高低是云厂商的核心竞争力。
在我们的诊断工具和修复工具中，都是通过我们的AI和程序去分析问题的修复问题的，没有人去记录用户的这些隐私数据，所有的操作记录都在用户册的操作审计里面可见这也就保证了安全合规 同时借助我们阿里云海量的用户以及海量的日志，在未来诊断的准确率也会继续的提升。
二、智能诊断
我们举一个例子，ECS 最常见的几类问题是什么？
最常见的问题，列了四类，第一类是实例无法远程访问，这的远程访问包含 ssh 或者是 vnc 或者是 windows 的 rdp，这样的远程访问无法连接所造成的原因也是千差万别的。
这就决定了我们对根因的分析也是不能简单的写出来，这个诊断本身是一个很复杂的过程。另外几类常见的客户侧问题包括实例，启动和停止失败，实例的性能达不到客户的预期，磁盘的扩容没有生效等等。
—键开启 ECS 健康诊断：
为了达到我们百分之八十的目标，需要提供全面的体检，这里的全面体检从内到外，包括 ECS 服务，自身的健康诊断。
我们后台的硬件服务，同时我们还会做磁盘测的健康诊断，磁盘的健康诊断就包括我们的这个存储空间，我们的 IO 的读写速率，磁盘本身的数据一致性会做这些诊断，同时还会做网络侧的健康诊断，另外就是最上层的 Guest OS 本身的健康检查。
具体诊断能力：
从用户场景上，对于无法远程连接的访问，我们会诊断他的 ECS 系统服务。包括虚拟化异常，物理机异常资源争抢受限，所谓的资源争抢是指在某些入门及实例里面在一台服务器上存在着资源争抢的可能性，在这种问题下，我们会把这种现象透露给我们的用户。另外就是服务管控测的异常，这些我们都会通过我们的诊断能力把这些现象和根因透露给用户。
再比如说实例无法启动，带宽或者 CPU 跑满，对于这类的场景，我们会着重去诊断他的磁盘健康服务。另外就是磁盘读写受限，扩缩容易长等等。网络健康服务，网络其实分为几类不同的表象，最常见的表象是网络的延迟，网络的丢包以及网络的彻底不同，对这类网络的健康服务，其实会将会做他的网卡的加载异常。
三、自动化修复
诊断本身其实是第一步，就是当我诊断出来我的根因之后，用户一定是需要修复，做了自动化的修复才能提供最好的客户体验，可以看到我们的整个修复逻辑
首先，问题定位一分钟，找到根因之后，用户可以选择手动修复，手动修复就是会给出详细的修复文档和修复步骤，用户也可以自动修复。阿里云 OOS 为我们的修复场景提供了一系列的公共模板，这些修复相关的公共模板针对我们最常见的根因提供了修复场景，在具体的修复场景里面，会再次做检查，判断用户的根因，同时根据具体的根因采用不同的修复逻辑，因为不同用户场景下的修复逻辑也未必相同，跟用户的配置相关。
修复本身是一个高危操作，因为尤其是 AI 的修复不能保证百分百的修复成功率，这也是AI目前的限制，为此，我们就必须要支持回滚，如果修复不成功，在这种情况下，要提供回滚的能力。在修复之后，我们会重新诊断，确认修复是否成功，并且要求用户确认，如果用户确认修复成功 那么整个修复逻辑完成，如果用户认为修复不成功，我们会帮助用户恢复到修复之前的状态
ECS 修复能力一览表：
对修复能力来讲，我们着重建设的修复能力，也是针对我们的诊断能力来做的。
比如说 ECS 系统服务侧的修复和磁盘的修复，我们首先会尝试重启，重启之外还有一个重新部署，所谓的重新部署是指针对本地盘实例，我们会进行重新部署，重新部署可能就会丢掉本地盘实力原有的数据，同时，我们还会进行自动的故障上报和隔离。同时，我们还会做故障的网络设备的隔离。
我们会让诊断能力覆盖我们尽可能多目标百分十九十五这样的工单，也就是说，未来我们希望分之 95 的工单都是可以自动诊断的，那在可自动诊断的工单里，我们希望进一步有 80 %的工单是可自助修复的，当我们诊断发现了根因没有办法自动修复的时候，用户可以尝试手动自己修复，或者继续开工单让我们的人来修复。
修复能力的透明合规：
1，运维编排服务 OOS 提供自动化引擎，云助手命令提供 GuestOS 内的执行能力。
2，一切修复逻辑可见:OOS 公共模板和云助手公共命令，代码开源 3，一切修复操作可回滚:镜像、快照，数据备份。
4，一切权限可控:阿里云 RAM 角色控制。
5，一切记录可审计:阿里云操作审计 ActionTrail
4、自助服务背后的 AI 与数据能力
刚才的异常诊断，自动修复，以及我们正在做的优化推荐，都只是冰山之上的用户体验
在冰山之下其实是我们的 AI 算法和数据中台。在这块 AI 算法针对异常诊断最重要的有两个，一个是根因分析，一个是特征分类，态势感知是什么？态势感知其实是我们对于风险和安全的一个预测，这是一个安全相关的一个感知算法，因为安全本身也是一场诊断要做的一个重要的方向，还有预测和推荐算法，预测是这里面非常重要的事情，很多诊断都是在用户还没有感知的时候，我们就可以给到一场诊断。
数据中台的建设很重要，这里面就涉及到了采集，清洗，分析，还有我们的数据模型。
分为三类：数据，实时数据，准实时数据，离线数据。
什么叫做实时数据？
我们认为用户当前的性能数据，当前的网络数据，以及当前的这个健康数据都是属于实时数据。
准实时数据是说用户的操作记录。离线数据是我们指的我们有另外一个 T+1 的一个时间，就比如说我们今天可以获得昨天的数据，我们每一天都会把所有的数据打一个快照，这个离线数据是我们进行数据化，用户画像，进行行为分析，进行数据训练所必须的一些数据。
同时，对数据的划分有两个不同的维度了实时数据，整实时数据和离线数据是我们的一个维度。
网络数据其实就是我们的单独的这个网络组件所采集的数据包括在网络的交换机上，虚拟交换机上，防火墙上等等所采集的网络侧的数据。
特征和分类本身也是基于数据来做的，事件通知是指客户侧的事件通知，这个事件通知是我们通过我们的数据和我们的规则产生了一些事件推送，产生了一些订阅，就是事件和订阅是相对应的。
