一、运维的发展

1.1 运维的价值

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

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

1）效率

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

2）质量

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

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

3）成本

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

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

1.2 运维的困境

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

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

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

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

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

1.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.1 什么是智能运维（AIOps）？

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运维自动化的能力。

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

2.2 技术、场景与算法

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

1）技术层面

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

2）涉及场景

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

3）算法层面

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

2.3 AIOps平台架构

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

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

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

三、宜信智能运维实践

3.1 宜信IT运营架构

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

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

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

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

3.2 运维管理

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

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

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

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

因此我们也会建设ITSM部分，即偏运营、偏管理、偏审核的部分。ITSM部分以服务台为入口，涉及的内部管理包括请求管理、事件管理、问题管理、变更管理、需求管理和编排管理等，涉及的信息管理包括资产管理和CMDB。

下面我们通过一个实例来看ITSM的价值点。

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

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

3.3 采集和处理

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

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

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

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

3.4 智能场景

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

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

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

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

1）智能问答/执行

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

2）故障检测

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

四、如何实现主动感知

4.1 痛点

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

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

4.2 主动感知定义

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 主动感知领域

主动感知在人工智能领域并不是一个陌生的名词，它已经有大量的应用，包括：
机器人，机器人怎么观察环境、怎么查看边缘信息、怎么识别物体。
自动驾驶，如果将现实中获取的所有图像数据都交给一个中心去处理，这个信息量和计算量是非常大的，目前的芯片还不能满足这样的体量处理。我们的方式是在探知环境数据的时候感知变化，获取变化数据。
智能手机，主要体现在手机的GPS、摄像头，可以感知环境变化。直接作用并影响到人。
路网监控，路网识别，包括主动感知车速变化，判断行驶的车辆是否超速。

4.4 分布式主动感知

AIOps引入分布式主动感知：

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

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

1）主动感知建模

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

2）主动感知的动作

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

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

3）主动感知的方法

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

4）主动感知的数据类型

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

5）主动感知系统

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

4.5 全网感知模型

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

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

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

4.6 全网感知应用

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

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

4.7 网络感知模型

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

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

4.8 主机/应用/业务感知

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

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

4.9 收益

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

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

4.10 问题与前景

1）问题

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

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

2）前景

AIOT带来的前所未有的运维数据爆炸
商用领域越来越丰富的算法应用降低落地门槛
SD(X) 系列的普及
IOT 带来的边缘智能未来

五、社区

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

本文转载自公众号宜信技术学院（ID：CE_TECH）。

原文链接：

https://mp.weixin.qq.com/s/7864h-nMasDn1a4EbUW_dg

创作场景

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