分布式主动感知在智能运维中的实践|分享实录

导读：企业数字化使得运维智能化转型成为必然，宜信积极推进 AIOps 在科技金融企业的落地实践。本次主题是探索 AIOps 落地的一种形式：经过行为采集、仿真模拟、主动感知等手段，从用户侧真实系统使用体验出发，结合全维监控数据，更加有效的实现智能异常检测和根因分析。

1、运维的发展

1.1 运维的价值

早期的运维工做比较简单，通常是先由系统集成工程师及研发工程师研发完项目后交付出来，再由负责运维工做的人员从后台作一些操做，保证系统正常运行。

图1

随着软件研发行业和技术的发展，运维的工做也变得愈来愈丰富。现阶段运维的工做与价值主要集中在三个方面：

1）效率

大量业务上线，运维人员须要保障快速高效地为系统提供资源、应对业务变动、响应操做请求。

2）质量

运维的目标是保障质量及系统的稳定性。也就是说，要保障业务和系统7*24小时在线上稳定运行，为用户提供流畅温馨的体验。为实现这个目标，运维的相关工做包括：

• 故障预测：没出现问题以前预测到故障发生的可能。
• 异常检测：出现问题时很快检测并定位到异常点。
• 根因分析：分析问题的诱因，找出真正致使问题的根本缘由。
• 动态扩容：问题处理的过程当中可能受到复杂因素的影响，须要对系统进行动态扩容。
• 服务降级：不影响核心业务的边缘业务可能须要作服务降级处理。

3）成本

随着公司规模的不断壮大，投入产出比也愈来愈被重视。运维的另一个价值在于下降成本。主要体现为：

• 容量规划：规划每一年在IT运维层面投入多少人员和资源。
• 弹性调度：如何调度和分配资源，实现资源的充分利用。
• 利用率分析：利用率分析包括动态和静态两个方面。
• 趋势分析：好比今年花了多少钱在IT运维层面，明年要花多少钱在这个方面，这是一个趋势分析。
• 成本分析：成本分析包括今年有多少业务、每一个业务用了多少钱、多少IT技术设施、多少人员。

1.2 运维的困境

图2

如图所示，横坐标表明服务规模。公司业务不断增加，服务规模也相应增加，此处咱们简单理解为这是一个线性的变化，不考虑业务的暴增。

然而，业务规模增加反映到运维的复杂度增加上最少体如今三个层面：

• 服务规模的增加直接致使服务器量及网络量的增加，随之而来的是网络拓扑的增加。
• 业务增加，服务的技术栈也是增加的。之前可能前边跑一个服务，后边跑一个数据库就能够了，如今随着服务规模的不断增加，引入不一样服务形式，可能就有了队列、缓存等，相应的，技术栈也不断增长。
• 服务拓扑不断增加。之前可能一个烟囱型的服务就能够了，而如今随着微服务的应用，服务之间的调度很是多，须要增加服务拓扑来知足需求。

随着服务规模的增加，运维复杂度呈现指数级增加，那运维人员是否也随着增加了呢？纵观各司，答案是否认的。出于节约成本的考虑，各司各岗位人员并不会随着服务复杂度增长而扩张，反而是愈来愈趋于平稳。基于这个比例，至关于运维复杂度愈来愈高的状况下，运维人员愈来愈少了。

中间的差距如何来弥补呢？这就须要运用到运维手段了。即上图所示的：运维质量=运维人员 X 运维手段。运维人员要经过各类运维手段来解决运维困境，进而推进运维的发展。

1.3 运维的发展

图3

如图所示，运维的发展大体分为四个阶段：

1）手工阶段

手工阶段比较好理解，研发人员交付一个系统，运维人员经过手工执行操做保障这个系统正常运行。此阶段的运维工做没有什么标准可言。

2）标准化阶段

随着企业IT系统愈来愈多地引入运维，且全部业务都变成系统形式在线上运行，运维工做的重要性愈来愈高，但同时带来的是运维和研发、业务人员工做中的沟通壁垒。这时就衍生出了一些标准，其中最主要的是ITSM（IT Service Management，IT服务管理）。ITSM的目标是把平常全部的运维工做，包括流程、信息管理、风险控制等，经过系统建设和标准化固定下来，像流水线同样，人员只须要按照标准参与便可。

3）自动化阶段

随着互联网大爆发，服务交付模型愈来愈多，用户对互联网和IT的要求愈来愈高，ITSM的缺点也愈来愈明显，主要表现为时间过长、成本太高，不能适应快速多变的需求。因而从工程或运维的角度自发出现了一种文化：DevOps，DevOps强调运维、研发及QA工程师工做的高度融合，要求运维从工程交付的角度不断迭代。

同时从企业IT管理或运营诉求出发也要解决快速演进的问题，因而演化出了标准ITOM。ITOM和ITSM很像，区别是把“S”改为“O”，即把Operation自己及其带来的各类自动化工具归入模型中，包括主机、运营、发布系统等等。

• DevOps不断发展演变成如今的ChatOps，ChatOps的目标是将研发、运维、QA融合起来，以说话（Chat）的方式进行交流，但 ChatOps 只考虑了交流的形式，并无就如何实现基于 Chat 方式的总体解决方案，ChatOps 并无很好的解决 DevOps 的困境。
• ITOM把全部的Operation线上化、自动化后，发现IT运维所产生的大量数据是很是有意义的，特别是对于企业数字化而言，这些数据通过加工分析，能够对平常业务产生价值。因而Gartner提出了一个新的标准“ITOA”。ITOA强调IT数据的价值，提出对IT运维分析的诉求，但没说明这个数据能干什么。很快Gartner就将ITOA演化成“AIOps”。这时AIOps中的“AI”是指“Algorithm（算法）”，强调的是数据分析自己产生的价值，包括经过算法来解决线上故障发现、平常交互等运维问题。

4）智能化阶段

随着行业对IT运维要求的不断提升，不管是AIOps仍是ChatOps，都面临一个严重的问题：人处理不过来了。从工程角度来看，运维面临的现状是异构性很是强，须要引入三方应用和各类各样的设备，交付模式也愈来愈多，运维复杂度出现指数级增加。为解决上述问题，Gartner适时提出了“AIOps”的概念，这里的“AI”表明的是人工智能，经过机器人的参与将人工智能技术体系带入到运维的各个环节，帮助解决运维问题，运维发展也由此进入智能化阶段。

2、什么是智能运维

2.1 什么是智能运维（AIOps）？

图4

BMC给了AIOps定义是：

AIOps refers to multi-layered technology platforms that automate and enhance IT operations by 1) using analytics and machine learning to analyze big data collected from various IT operations tools and devices, in order to 2) automatically spot and react to issues in real time.

简单来讲，就是引入多层平台，使用大数据分析和机器学习等方法，增强IT运维自动化的能力。

上图底部三张小图分别表示201六、201七、2018年的AIOps架构演进，都是围绕Machine Learning和Big Data来建设的。

2.2 技术、场景与算法

图5

AIOps涉及的技术、场景和算法如图所示。

1）技术层面

• 大数据分析：主要关注点在分析的部分，包括基于海量数据的分析。
• 机器学习：数据量太大，人工的简单分析远远不够，须要它本身产生智能，这是机器学习的价值。
• 知识图谱：平常运维会产生各类经验数据，这些数据如何反过来对运维工做产生真正的价值，这就涉及到知识图谱。
• 天然语言处理：天然语言处理是ChatOps能引入到AIOps这个领域的缘由，咱们但愿可以找到一个相对简单且容易接受的交互界面，最好的就是聊天平台Chat，这就须要使用天然语言处理的方式，理解人的语言并反馈给人，并理解相关的执行动做。

2）涉及场景

• 单指标异常检测：好比想要知道一个实时数据的指标是否出现异常，咱们能够对它进行检测，若有异常就反馈出来。
• 多维指标异常检测：指标和指标以前是有关系的，经过好比聚类的一些操做可以检查出更多异常。
• 趋势预测：主要体如今成本部分，可以经过人工智能的方式预测出将来的增加和变化，更好地指导决策。
• 日志异常检测：检测日志是否出现异常。
• 根因分析：出现故障时，可以从时间维度和空间维度找到致使故障出现的缘由。
• 智能问答：之前每次变动操做都须要向运维提出要求，如今这些职能所有被承接下来变成一个智能平台，平常运维的工做能够经过智能平台或机器人直接完成。
• 智能执行：这是咱们期待的最好的方式，经过聊天窗口可以实时感知线上业务发生的变化，需求提交给平台后平台会自动执行。

3）算法层面

• 规则
• 统计
• 机器学习
• 变分自编码器、GBRT、EMA、极限理论
  • Pearson 相关系数、DBScan 算法
  • FP-Tree
  • Path Ranking

2.3 AIOps平台架构

图6

上图所示是一个比较典型的AIOps平台架构。

底层是全部数据的来源，咱们把大量数据收集起来，经过实时分析交付到算法平台。算法平台包括三部分，首先是基于规则和模式进行简单的分类，而后经过域算法，最后经过机器学习和AI的方式影响Operation，让自动化运行起来。

若是你们了解AI，就会发现这其实就是一个AI智能体，包括从Sensing到Thinking到Acting，即感知到思考到执行的过程。

3、宜信智能运维实践

3.1 宜信IT运营架构

宜信正在落地“中台化战略”，将可复用的技术集中到技术中台、数据/智能中台、运维中台，统一提供服务，节约了人力和资源，提升需求响应速度。

图7

宜信的IT运营架构分为四部分：

• 居于中心的是技术中台，真正承载业务。技术中台沿用了云平台的概念，从底层的物理环境开始，包括IaaS、PaaS、SaaS，这里的SaaS其实是一种中台的概念，将通用性的系统软件沉淀到中台上，统一为业务系统提供服务。
• 数据/智能中台，为其余业务和平台提供统一的可复用的数据和智能服务。
• 运维中台，积极响应研发、业务发起的请求，维护线上业务系统。运维方面采用传统运营的方式和互联网快速迭代共同交互的方式，在监控、信息、自动化等垂直领域创建全部套件。

运维如何使用数据/智能中台的数据和应用呢？咱们创建一个通用的管道，把运维产生的有价值的数据传输到数据/智能中台，数据/智能中台经过对这些数据进行分析，并基于运维须要的场景反馈智能应用。

3.2 运维管理

图8

上图所示是运维管理架构。

从左到右是从运营到运维，也能够说是从运营到DevOps，左边更偏向于ITSM的概念，右边更偏向于DevOps的概念。从上到下是从入口到执行。 你们可能更熟悉DevOps，以这部分为例介绍上图所示架构。

咱们的建设方式是从自服务入口，它被对接到持续集成和持续发布平台，持续集成和持续发布平台会利用全部的自动化建设，包括主机、域名、数据库、负载均衡及其余组件，实现自动化，最终咱们会把线上的系统数据收集起来，包括指标、跟踪、日志等，这就是监控的部分。

上述DevOps部分的运维管理架构对于交付2C产品是很是适合的，但对于像宜信这样，有大量系统是面向内部人员的，要求可以快速响应用户的问题，而且能快速沉淀更有价值的运维请求和数据，单一的运维管理架构不足以知足上述要求。

所以咱们也会建设ITSM部分，即偏运营、偏管理、偏审核的部分。ITSM部分以服务台为入口，涉及的内部管理包括请求管理、事件管理、问题管理、变动管理、需求管理和编排管理等，涉及的信息管理包括资产管理和CMDB。 下面咱们经过一个实例来看ITSM的价值点。

系统出现一个故障：业务人员在提交一个用户的手机号时报错，提示系统出现故障请联系开发人员。若是是在DevOps领域处理这个问题就很简单，把故障报给研发，研发就给解决了。但这样处理，下次可能还会出现一样的问题。

若是将故障放到ITSM部分进行分析，就能让问题获得更根本的解决。发现故障后，经过请求管理把这件事告诉后台人员，后台人员看到请求后将故障升级为“事件”并提交给研发人员，研发人员分析得知引起故障的缘由是手机号触发了风险控制平台，而风险控制平台因为刚刚上线因此状态码的解释并不充分，研发人员将平台关闭，故障处理完成，同时将该“事件”升级成“问题”。研发和产品人员对该问题分析后认为须要变动相关服务，提供更细的状态码和更清晰的错误提示，因而将“问题”提交成“需求”。最终“需求”完成，“问题”解决，以后相似的状况也不会再发生。

3.3 采集和处理

前文提到运维中台和数据/智能中台之间有一个通用管道，运维中台负责采集全部数据，进行简单加工，并传输给数据/智能中台，智能中台分析处理数据并反馈数据及智能应用给运维中台。

图9

上图所示为数据采集和处理的架构。

采集的数据形式包括动态和静态两种：动态数据包括业务、应用、链路、技术设施、全网、日志数据等；静态数据包括配置、拓扑、工单数据等。

咱们经过自有系统将全部数据收集起来，经过统一管道（统一管道包括kafka、宜信开源的DBus，DBus会对结构化的数据进行配置或预处理。）传送到实时分析平台，对数据进行后期加工，包括相关运算，最终数据会分类存储到数据中台的数据库中，好比关系、指标、文档/日志型数据会存储在ElasticSearch中、结构化数据会存储在Hive中，其余历史数据会存储在HDFS中。

3.4 智能场景

图10

运维中的智能场景如上图所示。

智能中台根据运维中台提供的工单、编排规则、CMDB、画像、Tracing、KPIs、Logs等数据，经过算法为运维中台建设一系列模型和应用。

重点介绍一下编排规则。咱们用的编排工具是StackStrom，咱们把自动化的每一个动做都抽象成一个原子（atom），好比重启服务、重启机器、修改配置，这些atom经过StackStrom创建成一个个的工做流，这些工做流是咱们有经验的运维专家创建的一个更高级抽象、更语义化的模型。好比我想发布一个系统，包括扩容机器、无缝切换、涉及前端负载均衡的调整、后端应用的调整，这些都会是编排规则。

智能平台经过算法，包括NLP分析、根因分析、趋势预测、异常检测等，产生两个模型：知识图谱和搜索引擎。这两个模型应用于运维中台的问答后台、编排管理和监控系统中。

1）智能问答/执行

图11

如图所示是智能问答/执行的案例，用户经过服务台的会话窗口提出问题，这些问题以请求的方式发送到问答后台，后台利用搜索引擎和知识图谱的数据自动化反馈信息，包括问答、动做执行等。

2）故障检测

图12

目前的AIOps研究最多的是KPIs，将日志等各类数据，经过根因分析、趋势预测、异常检测等算法，生成对应的算法/模型，将这些算法/模型应用到监控系统中，就是监控报警部分。监控报警结果会展现到展板上，通知用户。

4、如何实现主动感知

4.1 痛点

图13

咱们的业务运行在IT环境中，这个IT环境就是承载业务的IT，包括数据中心、服务器、各类系统、三方应用、网络用户的设备等。而随着云平台的建设和微服务的发展，不少部分运维人员观察不到，再加上出于投入产出比的考虑，一些部分咱们不会去观察，所以，实际上运维人员可以观察到的IT远远小于真正承载业务的IT。

在运维可观察的IT环境中，真实观察到的IT数据每每仅包括交换机的流量包、进程的运行状态、网卡流量、CPU使用率、请求数等数据。 若是要建设AIOps，数据的完整是很是重要的，观察的IT环境越多，获取的数据越完整，越有利于AIOps的建设，这时就须要用到主动感知。

4.2 主动感知定义

图14

Wikipedia对主动感知的定义以下：

Active Perception is where an agents' behaviors are selected in order to increase the information content derived from the flow of sensor data obtained by those behaviors in the environment in question. ——Wikipedia

通俗来讲，主动感知实际上是赋予每一个参与者一个身份，这个参与者会主动获取环境中的数据，同时会根据从环境中获取的数据主动进行进一步的发现并获取新的数据，目的是增长得到数据的信息量、信息价值。

上图展现了一个比较典型的主动感知流程，重点来看感知部分。感知器从环境中经过情景感知、情景理解和预见的方式去感知环境，产生一个决策，决策产生一个动做，动做反馈到感知。

4.3 主动感知领域

图15

主动感知在人工智能领域并非一个陌生的名词，它已经有大量的应用，包括：

• 机器人，机器人怎么观察环境、怎么查看边缘信息、怎么识别物体。
• 自动驾驶，若是将现实中获取的全部图像数据都交给一个中心去处理，这个信息量和计算量是很是大的，目前的芯片还不能知足这样的体量处理。咱们的方式是在探知环境数据的时候感知变化，获取变化数据。
• 智能手机，主要体如今手机的GPS、摄像头，能够感知环境变化。直接做用并影响到人。
• 路网监控，路网识别，包括主动感知车速变化，判断行驶的车辆是否超速。

4.4 分布式主动感知

图16

AIOps引入分布式主动感知：

经过对真实 IT 环境的参与者创建模型，有目的的获取相关 IT 数据，并基于获取到的数据持续优化获取的数据和方法，以实现对真实 IT 实时完整的监控。

传统的监控方式是被动的，经过被动采集是不可能采集到全部数据的，没法保证数据的真实完整。若是可以对全部的IT参与者进行建模，经过模型去感知真正参与者的身份什么样的、有哪些数据，就能够采集到更加实时和完整的数据。

1）主动感知建模

主动感知的建模涉及到本地建模和全局建模。本地建模只须要关注IT参与者是什么，好比一个职场、一个主机；全局建模须要考虑全国有多少个职场、都分布在哪里、如何将它们联动起来。

2）主动感知的动做

主动感知的动做包括两个方面：有主动筛选的被动感知和有主动行为的主动感知。

• 有主动筛选的被动感知，好比网卡流量数据都是实时监控的，但我并不会把全部数据都收集起来，只有在数据陡增或出现异常时才会收集，这就是主动筛选。
• 有主动行为的主动感知，在真正获取环境数据时，只是粗略得到一些内网中机器的端口，若是发现有端口是危险的，就会对这些端口进行细致的探测，包括发一些协议请求去模拟这些行为，这就是有主动行为的主动感知。

3）主动感知的方法

主动感知的方法有两种：基于规则和基于智能算法（好比贝叶斯决策树）。基于规则的方法是目前使用最多的。

4）主动感知的数据类型

主动感知的数据类型包括画像数据、参与者与参与者之间的关联关系、主动筛选和主动行为的细节捕捉、定位跟踪等。

5）主动感知系统

主动感知系统包括全网Agent、业务Agent、网络Agent、应用Agent，这些都是咱们的感知器。

4.5 全网感知模型

图17

用一个例子来细化什么是分布式主动感知。

全网感知的背景：宜信在全国各地有不少职场，这些职场都是重要的参与者，每一个职场里有不少业务人员在使用业务系统，须要对这些职场进行监控。

咱们用分布式主动感知的方法，首先创建模型，即职场网络。在职场放一个Agent，由于职场分布在全国各地，自己是全网的，所以称之为全网Agent。感知的内容包括出口有哪些；网络、身份识别；这个网络有多大；边缘探测；还包括内部一系列的统计数据，同时还会作内部内网的风险监测，甚至会经过模拟数据、诱导攻击来发现内网是否存在安全隐患。

4.6 全网感知应用

图18

• 全网Agent获取当地职场信息，包括出口、网段、地理位置和运营商信息，并反馈到拓扑和图谱中，同时ITSM会管理全部的组织和职场信息，这些职场身份信息和主动感知的Agent反馈的信息结合，绘制出一个准确而详细的拓扑/图谱。
• 全网Agent从网络中获取并反馈全部职场设备及其分布状况。
• 全网Agent会嗅探风险端口、扫描攻击，并反馈风险的细节扫描数据。
• 全网Agent会将网络统计数据反馈到系统中，帮助完善拓扑和监控。
• 咱们能够经过网格数据加上职场身份给不一样 Agent加上不一样的监测模拟配置，由Agent发起模拟监测的数据。当发现异常时，能够从全网获取更详细的拓扑网络监测和密集系统检测数据。

图19

上图展现的是咱们全网感知的一些示例，包括职场信息、组织信息、模拟监控数据、动态监测配置，不展开细述。

4.7 网络感知模型

图20

上图展现的是网络感知模型，咱们首先进行建模，建模的点，也就是网络的参与者，即每一个交换机，并实时监测和扫描网络内部全部服务器。经过这个模型能够直观且实时看到异常细节数据，保证网络质量。

图21

上图展现了网络感知的示例。

4.8 主机/应用/业务感知

图22

除了上述应用之外，还有主机/应用/业务感知等等。

• 主机感知。出现异常时，异常时感知反馈进程、IO、网络 Dump 细节信息。
• 应用感知，根据运行状态动态调整采集密度和方法。
• 应用感知，包括主动业务异常捕捉和上报。

4.9 收益

图23

分布式主动感知的收益包括：

• 更丰富的画像和拓扑
• 更有价值的监控数据
• 知识图谱
• 根因分析
• 异常检测

4.10 问题与前景

图24

1）问题

主动感知在AI领域的应用已经有不少成功案例，但在AIOps领域仍是新兴事物，还存在不少问题：

• 缺少理论支撑
• 缺少智能的感知算法
• 主动感知数据对学习算法的挑战
• 较高的实施成本

2）前景

• AIOT带来的史无前例的运维数据爆炸
• 商用领域愈来愈丰富的算法应用下降落地门槛
• SD(X) 系列的普及
• IOT 带来的边缘智能将来

5、社区

图25

宜信是相对比较早进行AIOps实践的公司，咱们在赋能AIOps同时也注重将经验反馈给社区，本文所介绍的主动感知技术也计划开源，与你们一同探讨和进步。

分享嘉宾 | 宜信研发架构师肖云朋

文稿整理 | 宜信技术学院 Cynthia

内容来源 | WOT峰会

原创首发 | 宜信技术学院