开发者学堂课程【阿里云可观测峰会：行业实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1060/detail/16102
行业实践
五、微服务异常诊断与根因分析算法实践
本次分享将围绕了三部分来展开。第一部分是AI OPS系统有哪些能力？第二部分是异常诊断和根因分析的算法介绍。第三部分是微服务分析案例。这一部分我们主要从三方面来展开，第一部分是AI OPS 系统落地的一些挑战。第二部分是从机器学习视角浅谈一下 AI OPS 系统的能力。第三部分是日志服务平台具备什么样的一些能力？先看我们的系统挑战，在落地过程中我们会发现我们所面临的这个产品线是众多的，模块众多，所涉及到的对象指标事件也是非常多的，非常复杂的。第二部分是比较快，变化比较快。这里面主要是两部分，一部分是微服务的网络结构很复杂，依赖关系很复杂，所以导致的是服务变更比较频繁。第二部分是日志格式发生了比较频繁的变化，还有是界定不是很清晰。单点异常跟全局异常没有办法准确的来确定。第二个是微服务之间的关系是错综复杂的，包括一个服务内部之间的关系也是非常复杂的。而异常会随着网络进行传导，它的传播链路也是非常复杂。
接下来我们从机器学习的视角来浅谈AI OPS应该具有哪些系统的能力。我们经历了 DevOps 又到 data OPS 到这个 MLOps 再到 al OPS 的一个演进。我们要解决的是 al OPS 中的一些问题，必须要具备的是数据跟建模的一些能力。
从数据跟建模那我们避免不了要看一下是我们到底需要从系统中采集哪些可观测的数据，以及这些数据在未给模型之前需要哪些有用的特征。假设我们已经有这样的一套非常复杂的工具，帮我们去解决特征工程的这部分，接下来我们会针对这种场景设计不同的模型，特征还要去适配不同的一些模型。当我们拿到了一个模型，我们会涉及到模型的评估跟模型的更新。评估主要会分为性能的评估以及准确性的评估。模型的更新可能会涉及到这个模型是不是是不太适用以及对于一些未见过的数据或者一些比较是偏离分布的一些数据，可能会有一些兜底的策略。这个时候可能都需要去更新我们的一些模型。在整个这个生命周期过程中，每一步都少不了我们人的一些参与。比如最开始的时候，我们需要明确我们有哪些数据，以及我们的特征质量怎么样，数据质量怎么样。同时还要会对我们的模型做监控，还要对模型做一些可解释性。到线上的时候还要考虑模型的一些泛化。
接下来我们要谈一谈 sls 是什么。日志服务平台是一个云原生可观测的一个平台。我们为这个 log metric trace 提供了这种大规模低成本实时的平台化的服务。我们最核心的两个点在于统一的接入跟一站式的服务。它可以覆盖的场景是包含了开发、运维、运营安全等。
接下来我们一起看 sls 提供的一些基础能力。首先下面这一层是我们的数据接入层，在这一层里面我们是要对系统的可观测性的数据做全方位的接入，比如变更事件程序日志中间件的一些日志包括操系统的一些系统日志，甚至可能我们依赖的一些云产品的一些日志，包括我们所服务的这些云原生的这些 POD matric 的一些指标性的数据。再往上我们提供两个非常核心的能力，一个是对于我们的数据的一些孵化处理流转的一个工具，叫做数据加工。还有一个是非常强大那种聚合分析的能力，是 SQL 的能力。通过这种转换，我们可以把原始数据按照不同的场景跟需求生成不同的特征存在我们的 low store matric store 甚至是我们的 top store 中。在这个之上我们会有从不同的这种消费的形式。比如我们可以通过搜索的方法可以做这种所见之即所得的这种查询。同时我们可以通过这种流的方法去做下游的一些消费，同时我们也可以去批量的去拉出来一批数据，然后做这种模型的训练。在这之上我们会针对这些特征，包括指标的特征跟文本的特征会构造一些标签。这个是一个比较重要的这种标签标注的一些能力。在这个基础之上我们才具备了建模的一些基本的要素。这个时候我们可以利用我们的一些算法工具，比如统计算法、学习算法跟深度学习算法，然后去解决我们各场景中的一些问题，比如扩缩容告警聚合，然后文本模式的挖掘，然后根因分析的定位等，以及系统的稳定性的一些观测等。
再往下到我们下一个板块，那是异常诊断算法跟根因分析算法的一些介绍。这个里面我们先要进行对于微服务做一些系统的拆解。同时我们要从数据跟算法的角度去看一下如何来建模，能比较好的去解决诊断的定位的问题。我们先从固等角度来拆分一下。针对于历史数据而言，我们是能做一些工作，比如通过历史数据里边我们要挖掘出来一些系统的瓶颈，然后以及系统在调度过程中的一些热点。还有是通过系统的一些指标，我们可以做相关的一些聚类，比如哪些可能是 CPU 密集型的，哪些可能是 IO 密集型的任务，那我可以把它放到不同的这个机器组里面去工作。还有是要做一些指标的关联跟指标的业因果分析。这个时候更多意义上讲是我们在一个垂直的角度来看各个模块之间的指标的一些异动跟联动的一些问题。还有是全链路的分析，这个时候可能会涉及到调用链跟这个网络传播链等。还有最后还有一部分叫做故障传播关系，这部分也是非常重要的。因为我们在线上的生产系统中故障是比较少的。我们在产生故障的时候是要大量的去汇聚所有的那些告警、指标，包括工单等。然后事后我们可以去根据它来复盘来去做这种流量的回放，然后去做这种故障的演练。再往下针对当前的事件，那我们可能最核心的关注点是在于有没有异常在哪里，然后以及能不能给更准确，做一些告警的聚合。针对产生的这些异常之后我们要做这种快速的止损以及非常好的根因的传播收听，是要做一些根因分析。对于一些未发生的一些事情，那我们可能需要做一些故障的预测，容量的预测，包括可能一些趋势性的一些判别，包括潜在的热点分析等。这里核心的这几点我是引自佩丹教授的一些分享，我觉得分享的是很到位，所以我拿过来直接引用。
往下我们可以通过系统角度来看我们运维场景需要哪几部分。第一部分我们叫做离线建模。在这部分过程中，我们有一个非常核心的点在于离线的数仓。这个数仓里面是混部了我们所有的一些数据。同时我们还有一些标注的服务，在标注服务里，它能帮我们去构造我们的一些样本。在离线数仓里，我们是通过分型的作业可以产生系统的特征，然后根据我们下游的很多场景的任务去训练不同的一些模型，这样以备于我们后续来使用。往下我们把这个部分叫做进线系统。那这部分的系统的核心能力在于我为实时计算部分会提供特征的生成跟模型的准备。这块我们可以看到这边会有很多热数据，热数据会通过这个分析的作业跟这个离线近似计算的这个模块会生成我们所需要的一些特征，然后传给特征服务。再到最后是真正的我们有数据或者是有事件触发，那我们需要快速的去做诊断。这个时候我们需要通过在线计算模块，把我们的热数据的一些特征包括我们之前训练好的一些模型加载，然后做这种推断好。
接下来我们对微服务系统做一些抽象。这个是一个典型的微服务的部署的物理模型。我们可以看到两边左右两边分别是两台物理机。在物理机我们通过一种虚拟化的手段隔离出来不同的一些环境。服务 A 是混部在两台物理机上，服务 B 也是混部在两台物理机上的服务，服务跟服务之间是通过这种网络可以关联起来的。在这样的一套微服务系统中，我们的服务的部署是混部的，故障是通过网络可以非常快速进行传播的。服务跟机之间的关系是动态发生变化的。指标跟事件的力度也是比较细的，我们是可以做到秒级别的一些指标监控。
针对左边的这一个物理模型，我们可以稍微抽象，我们可以把它变成两部分。第一部分是服务节点跟机器节点的一些依赖关系，这部分可以通过我们的 meta 数据可以拿到。那第二部分我们可以通过请求数据可以找到服务跟服务之间的一些关联，所以能把这个图给补充完整好。再往下我们可以一起看一下这个微服务系统可能需要关注哪些点。第一部分可能主要是容量的一些管理，主要是基础的资源的一些利用率，然后以及能否提供弹性的扩缩容。那第二部分是管理的配置跟编排，主要的点在于是应用跟服务之间的一些依赖关系以及自动化的部署。第三部分是我们今天所需要关注的一个核心，那是服务质量监控跟诊断。这时可能会涉及到数据的一站式的采集，包括这个基础设施的以及应用服务的一些监控和快速地进行根因的定位跟诊断。
首先我们来了解第一个点是如何通过指标了解我们的系统。我们下面稍微抽象一下我们的一个服务模型。微服在云原生的微服务环境中，服务是依赖于容器部署在不同的机器上的。在这个里面我们一共有这么几类指标，一类叫做服务的业务的指标，可能更多意义上是流量、延时等。那第二部分是服务所依赖的这些 POD 他们每时每刻所消耗的那些计算资源。那大部分来讲是通过这种网络流量，然后以及它的这个 CPU 内存的一个使用率等，包括磁盘的 IO 的这个情况。还有一部分是他们所部署的物理机的一些指标。那这个里面会有这么几个对象，对于单个对象来而言，我们需要关注的是这个对象本身的一个健康程度怎么样，以及在这个观测对象下它可能会有多维的指标，指标之间的一些依赖关系是如何的？第二部分是把它作为一个系统而言。我们可以看一下是系统的健康程度是怎么样的，然后以及系统各个模块之间的一些依赖关系是如何。这时候我们可以抽象出来有三个问题。第一个问题是当前是否有异常，多维度之间的关系是怎么变的？系统之间的异常是如何传导的？
首先我们来看是如何通过图来看这种单时序的一个演化，我们称为 state graph 这张图是我从系统中计算出来的是每隔 15 秒去采样在15秒窗口之内某一个服务的平均响应的一个延时情况。那我们可以看到它的波动噪音还是很大。但是我们可以看到这两个点在细微之处有一个是下降，还有一个是缓慢的上升的。这种模式在我们系统中出现是比较少，我们需要关注一下这种模式为什么会有这样的一个模式的产生。这时候我们会引入一个新的概念，叫做 ship late 应该是零几年 20几年的时候的一篇 KDD 的一个文章。它主要的点在于我在我一段在我一个单维的序列里面，我能否通过一些小的连续的波形，然后来表达当前的这个序列，然后使得当前的这个表达具有一定的排他性。这句话的含义是我要在一段观测里面，我要找到一个连续的波形，这个波形能最大限度上代表自己。在这过程中我们可以沿着这个思路，然后很多的同学会去研究系统的一些表达变化。这个时候我们会提出了一个东西，叫做演化状态演化的一个网络。它简单意义上是在一个单维度的一个时间序列里面，我们可以把它按照一定的维度可以做切分。比如我们可以按照小时或者是按照天级别来做一些切分。在每一个区分的分段里面，我们可以找到一个或者任意多个连续的设备的状态，用来唯一表达某一个分段的一个表达。这个里面我们可以看到在 xt 减 1 跟 T 跟 T 加 1 时刻，我们 T 加 1 这个时间段我们分别寻找出来了不同的这样的一些表达，是1234。在这个时序演化的过程中，我们是可以枚举出来这个序列所有的一些状态的。我们可以知道序列之间状态的一个演化关系。是 1 到状态2，在观测序列上来它的一个转移的概你是怎么样的？我们可以在某一段时间之前这段时间里面我们可以拿到我们可以拿到一个状态节点之间的一个演化关系。这样我们可以通过一个图网络来表达图网络中的一些节点是我们的 state ，这个图网络是能比较好的来表达一段时间观测以来当前的一个状态。接下来我们要去做一些预测。我们预测什么？我们预测下一个时间段下一个时间段它的状态应该是长什么样子，所以我们可以通过 xt 减一跟xt时刻来预测 xt 加一这个时刻它的状态长什么样子。这样我们可以做一个自监督的一个网络。这样我们可以把每一个图网络作为当前系统的状态的一个 in embedding 通过这个 embedding ，我们可以把当前的这个图网络作为系统在一段时间内的一个 embedding 我们把这embedding 放到一个序列的模型，类似于 RN 或者 LSTM 这样的一个算法里，模型，里我们可以学到它系统演化的一个特征，然后从而我们可以去预测下一个时刻的状态。这样的话我们可以构造出来一个样本的空间，拖出样本的一个特征，然后去做我们的一个训练。
这个文章是发表在这个 2021 年的一个 WSDM 上。我们来看这个文章的一个实验结果。目前可能主要是描述这个流量的一个情况。它有两个维度的指标，一个是流量，这个写入流量，还有一个是出网流量。在这个流量里面，我们可以发现 1234，4个时间片的一个 shiplet ，它可能是呈现了这样的一个状态。在这个首先第一件事是我们要对两维的时间序列，我们先把它进行 date 化。我们可以分别拿到不同的这个state 那我们可以举出比如 state 2， state 8， state 16 跟23，分别对应的是我们 B 图中的一些状态的节点，通过我们反复的学习跟建模，我们可以拿到稳态情况下的一个跳转关系，这样我们可以看到比如在这个第二个时间阶段，我们可以看到 2 跳到8，8跳到23。 8 跳到 23 这条线比较粗，意味着它可能偏离我们异常的一个概率是比较大的。所以可能会有一些问题可能需要我们去关注。通过这样的一些手段，是我们能比较好的去看在单维度的时间序列上来看，或者单实体的在这个角度来看，它的一个状态的演化规律，能给我们提供比较好的一个可解释性。
我们刚才提的更多的是从这个单实体的角度上来看它的时间特征。我们能不能通过系统的角度上来看一个端到端的一个遗传检测方法？对于现阶段的检测我们是怎么做的？是系统中可能有很多个节点，很多个观测对象里面我们都有多维的一个特征。每一个特征我们都会通过若干种检测器产生不同的一些事件，包括同比环比或者机型检测，包括机器学习的一些手段，会产生很多的一些事件。然后再通过反馈的一些手段，比如人工打标，或者是人工来调阈值调参等这些优化的手段，来进而指导这些检测器更好的工作。我们可以发现在整个这个过程中，我们所处理的这个对象是在微服务系统中的某一个观测对象。这个时候会带来一个问题，我们所需要观测的维度是众多的，数量是众多的。在数学这个角度上来讲，是它发生异常的概率也是非常大。但是是不是我们都需要去关注这些。所以我们想的是能不能在系统的角度上来做一个端到端的，针对于这个微服务系统的一个异常检测。
那我们一起来看两个数据。第一个数据是我们系统中 10 个 service 在某一个维度是每分钟的这个流量的一个时序图，可以看到是他们的首先第一点他们的波动还是比较大的，噪音也是比较明显的。第二个我们也看到他们的形态是非常丰富的，比如像这个 cars 跟这个 catalog 它可能是这种缓慢的抖动式的上升。还有一个是缓慢的这种阶梯式的下降。还有一个问题是他们的这个 Y 轴差异是比较大的？这种的话是对于我们去设计算法设计模型来是非常有挑战的。
第二个是我们从一个实体对象上来触发，比如以我们举的例子是以 front end 前端的这样一个服务模块，我们可以看它的一个多维特征的一个构造。可以看到我们有它的这个每分钟的这个流量，然后以及在一分钟以内是超过10 毫秒的请求的数量，以及超过 100 毫秒请求的一些数量，甚至我们还有它的平均响应的延时以及 95 分位数的一些延时情况。我们也看到它的这个有很多特征，可能是相似的，还有可能还有很多特征可能是全都是 01 条直线，是非常丰富的。
这个时候我们需要回答几个问题，比如第一个是如何区分流量的自然下降，如何区分流量的自然下降，还是依赖服务的产生了一些异常而引发的当前这个服务 A 的一个流量的下降，这是第一个。第二个问题是算法模型能否适应系统的一些自愈。因为在生的环境中会有很多种，是自动重启的一些方法。或者比如这个服务可能超过了一些负载，它可能超过了它的一些限制，它能自动重启。或者如果你 P 如果你配置了那个 hpa 的话，可能在某个观测情况下，它可能会随着这个流量或者 CPU 的消耗，它可能会自动做一些扩缩容？这个时候都会变成了我们系统学习的一部分。还有是我们经常遇到的一个问题，是告警风暴的一个治理。这里面要问一个问题，告警风暴的治理能否在告警的产生阶段处理完，因为你是因为你的告警的数量实在是太多了，所以它大概率上讲会产生这样的一个风暴。能不能从系统角度上来做，是它只有一个告警可以解决我现在的一个系统的问题。这个时候我们自然会想到一个问题，所有这些东西都是围绕着能否把系统作为一个整体进行异常检测。接下来我们可以一起来看一下我们设计的一个出发点，是本身它应该是一个微服务的一个模块。它天然是一个图结构，是一个图网络。每一个图中的这个节点都是有这种依赖跟被依赖的是影响跟被影响的一个关系的。每一个服务模块都是对上层提供 sla 。我们有这么几项想要潜在的一个规则。第一个是服务的 SLA 可以反映出来服务的质量。第二个是各个子系统分别对调用方保证服务的 SLA ，还有是下游系统的异常会按照一定的逻辑向上传递。接下来我们那如果我们设计这套系统，那我们样本怎么采集？我们通过不同流量压力的pattern，给系统注入流量来模拟系统服务情况，进而产生样本。正常系统观测是这样每隔一段时间我们可以给系统注入异常，异常大部分是未例举的，比如摘心跳等。我们要注入异常时数据保存，作为副样本，接下来建模。图模型更好的是在于处理了是具有传递依赖关系的这些极点的一些特征的一个 embedding 。我们下游挂一个分类任务，这个分类任务主要的问题是在解决当前这个服务是不是正常，以及当前哪一个服务可能有问题，这样的一种方法来去学习，然后来帮我们去定位到底哪一个服务有异常。第二部分是刚才我们一直都在讲的是系统中的指标观测，接下来我们可能要稍微聊一下系统中的文本观测，文本也是能给我们很多信息。这一部分可能会涉及到是第一部分的图会是我们的这个系统的是 ECS 物理机的这个 message 的信息。这里会包含在什么时间？然后某一台机器上，执行了什么样的一个命令，这个命令的一些状态等。
右边这张图表达的是我们的 K8S 的一个世界中心的日志。它的物理意义是某台机器上的某一个 POD 然后镜像拉取失败。有这样的一些数据，我们可以做一件事情，我们可以对我们的系统的事件做一个粗分类。这个粗分类是哪一个模块？比如 K8S 的模块什么样的一些操作，它有一些 action 以及它的这个操作内容是什么。这个时候我们可以先对原始数据做一些标签的分类。第二部分是什么是我们要对这些数据做一些预处理。预处理这部分非常关键的是我们要把文本中的一些噪音去掉，或者把一些没有意义的一些东西，我们可以把它给 token 化掉。比如我们这个第一个里面我们可以把时间这个点，因为我们会按照顺序来排布我们的文本，所以时间可能不是特别关键。所以我们把时间这个信息维度先去掉，然后进程 ID 可能我们也可以把它去掉。然后还有那些 POD 的 name 因为它很多都是那些 MD 5 包括随机值产生的一些这个 UUID 的编码，我们把这东西去掉。这样我们会拿到一个较为干净的一个文本，这个时候我们可以做一些模型的微调。那这个时候我们会引入 BERT ，通过 BERT 我们在我们的这种文本系统上，是在我们的这个系统日志上做一些微调，使得它能更好地适应我们的系统日志。那这个时候我们通过 bird 能产生出来一些文本的一个向量，从而实现了 text to at 这样的一个表达。我们可以实体按照采集的时间顺序，然后把事件在实体维度上做展开，我们可以拿到一个事件的序列特征。
我们刚才提到了是时间序列，然后包括文本特征。
接下来我们要谈系统中的这个 graph ， graph 里最核心的点在于是这个鞭子们拿到。我们在这个图中是稍微简化了一下现在的一个物理模型。这里一共有三类节点，一类是服务节点，还有一类是机器节点，还有一类是服务的进程节点。它有几种关系，有一种关系是服务 A 是部署在这个机器组上的，它可能是一个部署关系。这种是服务本身的压力可能会对系统指标产生一些影响。系统的一些指标也会进而影响到这个服务本身对它有一种部署关系，在里面也有一种影响跟被影响的关系在里面。还有一个叫做服务 A 跟进程的一个访问关系，第三个是服务 A 跟服务 B ，是服务跟服务之间的一些访问关系。通过这样的一些手段，我们可以拿到系统的一些边结构。在现实生活中，我们怎么拿这些信息，我们可以有这么几种手段。第一种手段是我们可以通过这个在 K8S 场景中，我们可以通过Prometheus比较容易的拿到 POD 跟机器的关系。第二种我们可以通过这个网络上的抓包分析，可以拿到一跳跟另一条间的一些关系。还有我们可以通过这种 EB PF 的方法也可以拿到一些东西。如果更准确我们可以在系统中做一些埋点，可以通过 trace 的数据也能拿到这样的一些关系。
在我们拿到了那个节点跟节点的特征以及边的关系之外，这个时候我们要去构造一个模型，去用来做我们的根因的一些定位。这个时候的话我们参考应该是 2000 年前后发的叫异构图神经网络的一篇文章。它里面的核心思想是在服务系统中是有不同类型的节点的。然后不同类型的节点之间是有不同权重的边的关系在传导的。这个里面我们会定义出来这四种边的关系。一个边的关系是服务跟机器之间的一个关系。第二个是服务跟服务之间的一些关系。第三个是指标跟服务之间的一些关系，还有是机器跟服务的之间的一些反作用的一些关系。这四种边构成了我们这样的四个异构图的这样的一个麦塔 pass 在这个里面，我们通过简单的这些部署关系跟依赖关系，我们把它构造成一张异构神经网络。放到一个 GCN 里面去学，那他学到的是什么？学的是各个节点的一个 embedding ，然后我们最终接的一个下游任务是一个分类任务，因为我们会反复的往系统中注入异常，然后去定位当前这个故障在现有状态下可能是哪一个节点的某一个指标产生了一些异常。可以通过一个 NN label 可以去对接一个分类任务，这样我们可以把这个网络给关联起来，通过这种 BP 的方法可以去学习。
接下来到最后一部分是微服务系统的这个案例分析。实验环境的介绍，在我们的现有的实践环境中，我们所有的数据都是围绕着日志服务展开的。我们在 K8S 环境中是搭建了这个 SOC shop 这样的一个微服务系统。然后我们可以通过 ilogtail去采集这个物理机的一些指标信息。同时我们可以通过 ilogtail去物理机上去采集它的这个message 的信息。同时我们还可以通过在集群中去采集这个 K8S 的Prometheus的一些数据。同时我们要通过做一些这种探针的方法把这个基于 OT 协议的一些 trace 数据也可以把它采集，在这个 K8S 环境中，我们把这个网络的数据也采集，这样我们能构造一个比较完整的一个实验环境。再往下会涉及到一些数据的实验特征。
这张图表达的它是微服务系统的这个物理机的一些特征。我们可以比较快速的是拿到这个系统的一些这个load 包括它的 CPU 利用率，包括它的这个内存的一些使用情况，包括磁盘的一些使用情况等。还有一部分信息是这个 K8S 的 POD 的一些指标，我们也是可以比较好的统计出来。第三个可能是基于 trace 数据，我们会拿到这个入口服务，各个入口服务的一些服务指标，这也是我们的一些 crv 的指标。还有是我们的 k8s的事件中心数据，那同时还有是它的系统的一些 meta 数据。所有的这些数据都可以通过我们日志服务非常好的做加工跟整理以及特征的一些转换跟生成。
我们进行实验环境的介绍，在这一部分我们要先进行一些流量的模拟，我们使用卢卡斯的进行流量模拟，提供了不同用户数、不同服务入口以及不同访问频率，还有是不同波形的一些流量的压力，使得我们现在的这个模拟是波形更丰富，然后更能逼近我们真实的一些场景。第二部分是在实验中注入一些异常。在注入异常，我们使用的是 stress NG 跟 TC 工具，它分别在物理机跟容器环境中注入了以下四种故障。第一个叫做 CPU 故障，第二个是内存的 OM 跟内存泄漏，第三个是网络的延时，还有一个是网络的丢包。注入的命令在表格中已经给大家展示出来。这个里面需要讲的一点是我们希望我们注入的这些异常尽可能的去影响我们的服务质量，否则的话很难起到真实的这种故障诊断定位的作用。举个简单的例子，比如一台物理机它的内存可能是 32个 GB 那目前的系统跟微服务一共可能用了十几个 GB 那你往这个物理机上注入一个10 或者是注入一个 3 GB 的内存的泄露或者一个内存的使用，对于服务质量来没有任何的影响，仅仅是使得你的是在这个观测维度上只能让你的机器的内存指标可能会有所上升。这个时候它并不是一个有效的能影响服务质量的一个异常。所以建议大家在注异常的时候，更多意义上讲要考虑如何去影响服务，这样的话才能找出这种更真实的这种实验环境。
这一块我们勾勒出一张是我们微服务的一个拓扑图。这里面粉色的这个节点主要表达的是服务节点，服务跟服务之间是有边连接的，那意味着是在一段时间之内，他们之间是有系统调用的或者是网络调用的。还有一部分是一个方框，方框表达的是这个服务所部署的或者所依赖的这些 POD
接下来进行一些实验结果的说明。实验样本是在一个具有 20 台 ECS 的 K8S 集群中，我们部署了 SOC shop 这样的一个微服务系统，然后通过反复的是增加流量的压力以及在 POD 跟 ECS 中每小时注入一些异常，然后得到了我们的实验数据，然后通过我们的 circle 然后可以得到相关的一些特征以及通过 perform 秋丝跟 east aisle trees 等，我们可以拿到一些点跟服务节点之间的一些关系。我们可以看一下，是在这几个主要服务里面，我们分别注入了不同的异常。我们可以看在 CPU 跟内存异常里面，我们都是能比较好的去定位到的。是在网络里面，我们定位的还不是特别好。究其根源是因为网络它的传导性是非常复杂的，而且跟流量当时的情况也是有一定关系的。那我们可以看到像这个 user 包括这个前端等它的这个只能稍微低一点。这也是因为它在图中的一个所关联的一个节点的复杂度也是有关的。我们可以看到 orders ，它可能关联了很多很多个服务。
下一步的一个重点是我们现阶段实力实验是大量的使用了 GCN 网络。对于异常的现场的可解释性，我们要做进一步的一些探索。还有是我们系统中很多地方都是需要一些标签的比如文本的构造，这部分可能需要一些预训练，然后可能还会接一个下游的分类任务，很使得我们的特征可能更好。第二部分是我们要对我们的系统反复的注入故障，这样我们要拿到我们这样的一些故障标签。这个东西对于生产上来是比较难，因为对于我们的客户不对，我们线上系统我们很难一比例的去构造出来这样的一套实验环境，这个成本还是很高的。
第三部分是我们要探索是否具有更通用的一个网络结构，能比较好的去迁移到其他的微服务中去。因为现有的这个网络结构还是跟网络的物理环境的结构本身是相关的。能不能有一些手段可以使得我们的微服务的这个网络结构跟我们的微服务之间是可能没有一些物理上的一些关系，这样可能比较好迁移。
第二部分是我们产品化的工程化这一块，我们会逐步的将这个场景的算法整合到我们平台中去。然后接下来我们也会在平台上提供我们的建模跟标注的一些能力。
接下来是产品支持与服务。
