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

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

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，将日志等各种数据，通过根因分析、趋势预测、异常检测等算法，生成对应的算法/模型，将这些算法/模型应用到监控系统中，就是监控报警部分。监控报警结果会展示到展板上，通知用户。

（编辑：ASP站长网）