智能运维中的实践

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

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

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

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

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

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

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

3.3 采集和处理

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

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

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

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

• 机器人，机器人怎么观察环境、怎么查看边缘信息、怎么识别物体。 

• 自动驾驶，如果将现实中获取的所有图像数据都交给一个中心去处理，这个信息量和计算量是非常大的，目前的芯片还不能满足这样的体量处理。我们的方式是在探知环境数据的时候感知变化，获取变化数据。 

• 智能手机，主要体现在手机的GPS、摄像头，可以感知环境变化。直接作用并影响到人。 

• 路网监控，路网识别，包括主动感知车速变化，判断行驶的车辆是否超速。

  • 全网Agent获取当地职场信息，包括出口、网段、地理位置和运营商信息，并反馈到拓扑和图谱中，同时ITSM会管理所有的组织和职场信息，这些职场身份信息和主动感知的Agent反馈的信息结合，绘制出一个准确而详细的拓扑/图谱。 

  • 全网Agent从网络中获取并反馈所有职场设备及其分布情况。 

  • 全网Agent会嗅探风险端口、扫描攻击，并反馈风险的细节扫描数据。 

  • 全网Agent会将网络统计数据反馈到系统中，帮助完善拓扑和监控。 

  • 我们可以通过网格数据加上职场身份给不同 Agent加上不同的监测模拟配置，由Agent发起模拟监测的数据。当发现异常时，可以从全网获取更详细的拓扑网络监测和密集系统检测数据。
    宜信是相对比较早进行AIOps实践的公司，我们在赋能AIOps同时也注重将经验反馈给社区，本文所介绍的主动感知技术也计划开源，与大家一同探讨和进步。
    

（编辑：鹰潭站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!