摘 要：随着X86分布式技术应用，服务器数量越来越多，网络拓扑结构越来越复杂，运维越来越辛苦，风险越来越高。智能化运维AIOPS将AI技术应用在运维场景,是DevOps的运维部分，是“开发运维一体化云中心”的重要基础设施之一，其最大的价值在于缩短故障恢复时间，提高IT服务连续性。
本文描述一个运维及在这个场景下对AI的需求，目标是尝试将AI引入运维过程，提高运维效率、缩短故障恢复时间。
关键字：机器学习；DEVOPS、AIOPS、流量预测
随着X86分布式架构应用，服务器规模越来越大，一个交易经过的服务数量，一个请求的可能路径以笛卡尔乘积方式增加，一个节点异常往往会引起网络上多个服务器告警。这给故障定位、故障应急处理、系统瓶颈预测带来巨大的挑战。针对这种情况业内把人工智能引入到分布式系统运维管理中，以期通过人工智能提高运维效率，缩短故障恢复时间。业内称加入人工智能的运维为AIOPS。根据 Gartner Report，智能运维相关的技术产业处于上升期。2016 年，AIOPS 的部署率低于 5%，Gartner 预计 2019 年 AIOPS 的全球部署率可以达到 25%。随着人工智能的成熟，运维工程师将逐渐转型为大数据工程师，主要负责开发数据采集程序以及自动化执行脚本，负责搭建大数据基础架构，同时高效实现基于机器学习的算法。
AIOPS代表结合人工智能的IT运维。它是指利用机器学习从各种IT运营工具和设备收集的大数据并训练模型，实时自动发现问题、分析问题、响应问题的多层技术平台。Gartner通过图1解释了AIOPS平台如何工作。AIOPS有两个主要组件：大数据和机器学习。为了将大数据平台中的参与数据（通常在票据、事件和事件记录中找到）与观测数据（如监控系统和作业日志中的观测数据）结合起来，AIOPS需要从传统IT数据中移除。 AIOPS针对合并的IT数据实施全面的分析和机器学习（ML）策略，找到故障模式和故障处理的关系，AIOPS可以被认为是核心IT功能的持续集成和部署（CI / CD）。现阶段网络性能管理的难点在于缺少业务视角，同时缺少覆盖全局和第三方的视图。Gartner提出了AIOps的概念，并预测到2020年，AIOps的采用率将会达到50%。（部分论述来自Gartner Report）
从外部看，分为感知、分析和处置三部分.如图2所示，在AIOPS前端是传统的监控系统——称为感知部分，主要负责现实物理状态的获取，它是整个AIOPS的前提，只有准确、及时、全面的了解系统当前运行状况，后面的处理才可能实现。在AIOPS后端是IT运维管理系统、自动部署系统、通知告警系统——统称为处置类系统，这类系统根据AIOPS指令转换为操作具体服务器等IT设备的批量作业流，并通过执行作业流响应AIOPS指令。
从内部看AIOPS内部主要是平台资源管理、大数据管理、机器学习和模型应用几个部分。平台资源管理主要是计算资源管理、存储资源管理、任务调度等，可以基于现有的云平台实现；大数据管理主要包括数据介入、管理ETL、数据检索等大数据平台功能；模型应用主要是运用训练好的模型，根据感知输入，决定处置动作。
机器学习是AIOPS的核心，机器学习用来识别感知数据中的模式。虽然限制机器学习算法很健全，开源库也很多，截止目前真正在运维中使用AIOPS的才5%，清华大学裴丹教授总结说“智能运维落地的核心挑战是：从工业界的角度，我们有数据、有应用，但是缺乏一些算法和经验；从学术界的角度，我们有不少理论算法，但是缺乏实际的数据以支持科学研究，也不熟悉运维的场景。”基于这个思路，业内一部分同仁通过收集了很多的数据，数据的形式有KPI时间序列、日志等。假如打开首页的响应时间是我们的KPI，当首屏时间不理想、不满意时，我们希望能够找出哪些条件的组合导致了首屏时间不理想。这个方案有三个困难，第一打开首页设计的网络节点的日志必须全部收集，不仅仅是主机的，还包括相关网络设备等。第二，每个节点采集的指标要和“首页打开”这个动作相关，比如存储空间使用率监控指标对“首页打开”没有意义的，实际情况是做AI的人并不知道感知给他的数据是否决定了现在的现象，为了避免依赖不得不扩大指标采集范围，这不仅增加了成本，还会因为指标相关性引起模型训练困难。第三，机械学习需要很长实际的数据积累，这里不仅包括监控数据，还要包括故障数据——告诉机器什么情况是故障，这需要大量的数据标记工作。由于数据不足等原因，我了解的情况是自动化运维系统更多的是在预测、分析、告警信息筛选等方面，直接对服务器执行重启、扩容等动作的很少。
当你成功在运维场景和人工智能之间找到结合点的时候，你会发现拓扑结构、系统架构、操作系统特性、中间件特性、数据库等都会对AIOPS的决策产生本质的影响。更为困窘的是市场变化导致IT服务的频繁变化，以实施敏捷、DevOps的团队为例，软件发布周期普遍在几天到几周之间，而这种变化要经过一定的时间、一定的数据积累才能反馈到模型中去。
这让我想起裴丹教授说一般有“前景光明”、“前途光明”这些词的时候，下面跟着的就是“道路曲折”。实际上，智能运维是一个门槛很高的工作。实施AIOPS需要对银行系统、运维知识、机器学习都有深入的了解，才能取得成效。幸运的是，这三方面技能在中国银行软件中心都能找到。对银行系统的了解，首推总体部，总体部架构师队伍设计了中行系统，并且通过接口管理系统记录银行业务系统之间的调用关系；软件中心有专门的运维队伍，他们运维经验丰富，不仅熟悉系统状况，而且详细记录了各个产品部署关系；随着DevOps的实施，部署关系已经很好的管理起来，提供了精确的部署系统，而且为自动化处置提供了必要的条件。这些软件中心独特的有利条件，使我们不需要从零开始，而是结合决策树、知识图谱等已知的知识进行模型训练。主要工作思路如下：
- 建立运维知识图谱
- 选图的节点： 服务/接口 进程 容器 VM 模块 产品。
- 设置属性：给每个节点设置属性。比如CPU数量；历史TPS峰值等
- 建立图中节点关系：首先建立静态关系，通过自动部署中的CMDB内容，建立节点/节点组中的关系。通过总体部接口管理文档建立调用关系图，此时已经标记了可能路径。静态关系有可以分为启动依赖关系；运行时依赖关系；分类关系（见扩展分类）。
- 建立动态引用关系：通过监控发现的彼此之间的调用关系，这里主要指全路径跟踪发现的关系。
- 路径学习：由于负载均衡、SOA等策略，一些路径可能不存在，但随时会建立。这部分需要机器学习自动识别补充
- 选择典型场景应用AIOPS
AIOPS运维场景有十几种，由于篇幅所限，本次主要分享根本原因分析这个运维场景。在中国银行的IT系统中，完成一个业务交易需要经历多个产品、多个节点、多个进程、会调用多个接口。一旦交易链路上某个节点异常，会导致上游所有节点表现异常，此时监控系统上会表现为多个产品同时告警。理想状态下故障点及之前的节点交易堵塞，故障点之后的节点没有请求，此时只需将交易路径上的负载及情况可视化就能够快速定位问题。不过实际情况是一个接口往往被很多交易使用；一个节点上一般提供多个接口服务；负载均衡器等分流设备后有多个同类型节点。这些因素构成了一个复杂的IT服务网络，在复杂网络下，几笔交易异常，很难在监控系统上引起明显特征。这种场景适合应用人工智能，人工智能系统能够很好的捕捉这个特征，在故障发生且还没有引起大规模业务堵塞的时候通知处置系统采取动作。这不仅降低了运维人员应急处置压力，更为重要的是提升了系统连续性。基于运维知识图谱选取数据，训练模型可以有效降低模型训练时数据范围，去除服务网络上无关数据干扰，使模型训练更快速准确。在训练根本原因分析模型时，主要是找出交易异常发生位置与交易路径上各种监控指标的关系。
大道至简，模型训练过程方法很好说清楚，但实际训练过程很复杂，如特征选择、降维、共线性等都需要非常专业的数据处理知识。笔者仅以此抛砖引玉，借助软件中心架构师队伍的知识理论降低人工智能在运维场景的应用难度。谬误之处，请批评指点！