基于AIOps第四方物流信息平台智能运维理论基础

 

2.1AIOps（智能运维）

          在第四方物流信息智能运维平台，管理主机快速增加，IT架构日益复杂，复杂的拓扑与不可靠的CMDB，让运维系统更加复杂多变，机器学习和大数据给了运维新的出路。智能运维（AIOps）是人工智能（机器学习）、互联网领域知识、工程的交叉领域。互联网领域技术和工程开发技术在此不赘述。智能运维常用到的机器学习技术包括相关性分析、回归、关联分析、聚类、决策树、随机森林、支持向量机、隐氏马尔科夫、卷积神经网络、LSTM（Long Short Term Memory) 等等。这些算法在各种（开源或闭源的）工具集中都有现成的代码实现。智能运维的一个主要挑战是根据具体需求评判应用哪些机器学习算法，并适配或改造。

 

                       

                                                                图  第四方物流智能运维平台

 

                                                                            图  智能运维分析

     从技术上看，AIOps与大数据，云计算关系密切，而大数据与云计算的关系就像一枚硬币的正反面。大数据必然无法用单台的计算机进行处理，必须采用分布式架构。其特色在于可对海量数据进行分布式数据挖掘，但必须依托云计算的分布式处理、分布式数据库以及云存储、虚拟化技术。大数据和云计算给了AI第二次生命。

   其实海量数据主要分成两块，一是系统建设技术，二，海量数据应用。系统建设现在主流的技术是HADOOP，主要基于mapreduce的分布式框架。在分布式系统出来之前，主要是集中式架构，如DB2，oracle。为什么现在用分布式架构，那是因为现在集中式架构受限于IO性能，出来速度慢，如果又一种硬件技术，可以很快地处理海量数据，性能上能满足需求，那么集中式架构优于分布式架构，因为集中式架构稳定，运维压力小。现在的集中式架构要么性能达不到要求，要么就是过于昂贵。

 而第四方方物流智能运维场景产生的海量数据大体上可以分为两类：一类是时序数据，例如：CPU，内存，磁盘等数据，主要反映系统当前以及历史运行状态；另一类是事件数据，例如:报警，异常，上线，变更事件，主要用于记录发生事件详细信息

                                               复杂数据的保存策略

场景	时间范围	查询数据量	查询频率	时效性要求
汇聚值报警	最近数分钟或者小时	小	高	高
异常检测	多个时间区间	小	高	高
实时报表	最近数小时或者数天	大	高	低
历史趋势	自定义时间	小	低	低
离线分析	数天，数周或数月	大	低	低

 

智能运维是相对传统运维的一种升级和进化，智能运维能够实现业务系统的自动化故障智能检测，自动判断哪些异常、哪有告警，从而能够辅助管理者进行故障根源判断和处理。几年前一般的企业只有几十个或者几百个服务器资源，而今天随着云计算、虚拟化技术的发展，互联网技术的广泛应用，一个企业拥有几千台或者上万台服务器资源也是常见的。这30-40倍的增长使得在运维层面的负担变的更加严重。在监控层面要想获得每一个服务器的每一个指标更加困难。

     另一方面，业务系统复杂度也在增长，架构更加复杂，cache数据、非关系型数据库、大数据架构、离线的数据处理、app、PC端应用等，这些以传统监控方式一个一个配置已经不能满足管理需求。随着管理资源的数量和负责度增加，监控出现了太多的指标和图表，人的精力是有限的，工程师规模却没有太大的增长。那么如何从海量的指标中找到工程师关注的指标、关注的图表，传统的监控一个一个配置方式已经不能满足需求。所以，今天的运维管理人员更需要智能化的运维来帮助他们降低运维的压力。

      AIOps的落地，将把日常的IT管理工作移交给拥有机器学习和自动化运维的智能运维平台，大大降低企业管理的时间成本和资金投入。而运维管理人员也可以从筛查海量告警信息、执行重复性巡检任务、人工判断故障、手动解决问题的低效工作中释放出来，专注于构建更加高效、高扩展的IT系统，支持企业的数字化业务发展，这也就是业界所倡导的“IT从运维到运营”之路。

        AIOps智能运维平台还能有效预测潜在的IT故障，并在无需人为干预的情况下提前解决掉这些问题，而应用系统故障率的降低，将有效提高资源的使用效率。这得益于机器学习和深度学习算法在IT监控和应用性能管理系统中的持续积累，不断记录IT运维人员在不同场景下使用故障排除或修复基本问题的自动化工具的操作。当针对不同型号设备、不同应用系统、不同的云平台的学习样本数据足够丰富时，AIOps智能运维平台就可以自动评估系统的健康状态，如CPU使用率、磁盘吞吐率、设备故障率等，如果发现了系统的异常活动，就能提前自动触发相关运维操作。

      采用AIOps的能力不仅取决于IT监控系统的数据规模和自动化系统的可用性，还取决于人员和流程的一致性。服务商可以在很短时间内把AIOps智能运维平台部署到企业，但任何管理转型都不是安装一套系统那么简单，需要根据业务特点对人员和流程进行调整，而这往往需要更多的时间。

      要衡量AIOps智能运维平台在企业中的实施效果，可以重点关注两项关键指标，平均故障恢复时间（MTTR）和事务（故障）处理数量，这两项指标反映到客户满意度上，就是AIOps的价值。

智能运维（AIOps）常见算法应用包括如下：

(1) 指标趋势预测;通过分析指标历史数据，判断未来一段时间指标趋势及预测值，常见有Holt -Wintors、时序数据分解、ARIMA等算法。该算法技术可用于异常检测，容量预测、容量规划等场景。

    (2) 指标聚类:根据曲线的相似度把多个KPI聚成多个类别。该算法技术可以应用于大规模的指标异常检测:在同一指标类别里采用同样的异常检测算法及参数，大幅度降低训练和检测开销。常见的算法有DBSCAN, K-medoids, CLARANS等， 应用的挑战是数据量大，曲线模式复杂。

   （3）多指标联动关联挖掘:多指标联动分析判断多个指标是香经常一起波动成增长，该算法技术可用于构建故障传播关系，从而应用于故障诊斯。常见的算法有Pearson correlation, Spoarman correlation, Kendall corrolation特，应用的挑战为KPI种类繁多，关联关系复杂。

 （4） 指标与事件关联挖据 ：自动挖据文本数据中的事件与指标之间的关联关系(比如在程序A每次启动的时候CPU利用率就上了一个台阶）。该算法技术同用于构建故障传播关系，从而应用于故障诊断、常见的算法有Pearson  corrolation, J-measure,Two-sample test等, 应用的挑战为事件和KPI种类繁多，KPI测量时间粒度过粗会导致判断相关，先后，单调关系困难。

  （5）事件与事件关联挖掘：分析种常事件之间的关联关系， 把历史上经常起发生的事件关联在一起。该算法技术可用于构建故障传播关系，从面应用于故障诊断，常见的算法有FP-Growth，Apriori，随机森林等，但是前提是异常检制要准确可靠。

  （6）故障传播关系挖掘，融合文本数据与指标数据，从于上述多指标联动关联挖掘，指标与事件关联挖掘、事件与事行关联挖掘等技术。从tracing推导出的模块调用关系图。辅以服务器与网络拓朴。构建组件之间的故障传播关系。该算法枝术可以说用于的故障诊新。其有效性上要取决于其基于的其他技术，

   第四方物流信息平台的许多运维场景通过无法直接通过基于通用的机器学习算法以黑盒的方式解决，因为需要一些面向AIOps的算法技术，作为解决集体运维场景的基础。有时候一个算法技术还用于支撑另一个算法技术。

 

2.3 第四方物流信息平台系统架构的概念

第四方物流信息平台是将新一代信息技术应用于物流业中，实现物流的自动化、可视化、可控化、智能化、网络化，从而提高资源利用率和生产力水平的创新服务模式。由于物流业与民生、工业生产和经济发展高度相关，新一代信息技术在物流领域的应用效果明显示范性强，因此智慧物流备受*部门关注。预计将成为未来十年地方*和企业关注和发展的重点领域。

                                                    图  第四方物流信息平台

第四方物流信息平台IT资源从几十到几百台上升到万级甚至是十万级，监控本身每天可能产生的数据就是几十T到几百T，如何把这些海量的数据采集和计算存储下来，并且把这些海量数据给用户展现出来，从而进行一定分析，为管理提供决策，这是传统监控系统很难解决的。随着监控指标的增加，带来的就是报警的增加。假设每天发送3W-5W条短信、每天邮件报警量50W-100W，几百个工程师如何处理过来，工作负荷无缘无故增加。更新的基于大数据的智能监控方式可以解决，把相关度更高的告警聚合到一起，或者把重复的告警不发送，把最需要关注的告警和最需要的故障信息推送给工程师，这些需要通过大数据的相关性算法、聚合的处理能力来实现。监控系统有问题发现的功能，同时也要具备辅助工程师定位、处理问题的能力，传统的监控系统指标采集和图表展示。在人力经验和精力都无法满足的情况下我们希望智能运维系统能够自我诊断，从服务过去的第四方物流信息平台运维数据中自动识别故障特征，从而能够更准确的识别和诊断故障。

第四方物流信息平台智能运维其实还有很多领域可以突破，例如数据可视化技术让开发、运维人员更加直观的处理问题；利用基于大数据预测、预警的能力来实现故障预判，在故障发生前就提前进行预判，从而提升业务系统可用性；利用大数据的处理能力，采集处理更多的服务端的数据，这样使得监控运维的数据信息更加完整，形成全方位的运维数据覆盖，实现用户、服务、计算资源的无死角管理。

以下是第四方物流信息平台的架构

目标群体：系统日志、服务器、容器、系统软件运行指标

日志架构：ELK (Elasticsearch+Logstash+Kibana+Redis)

监控架构：GPE (Grafana+Prometheus+Exporter+Consul)

 

ELK由Elasticsearch、Logstash和Kibana三剑客组成，当然了以上是最基本的组件，为了使架构流程更加丰满，我们加入了Redis做缓冲队列，配置了sendmail做异常日志告警。

ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。它的特点有：分布式、零配置、自动发现、索引自动分片、索引副本机制、restful风格接口等。

Logstash数据分析工具，它可以对系统生成的的日志进行采集、分析，存储。2013 年，Logstash 被 Elasticsearch 公司收购，ELK Stack 正式成为官方用语。

Kibana是一个开源的分析与可视化平台，用来搜索、查看存储在Elasticsearch索引中的数据。

工作流程：

logstash(shipper) 实时监控并过滤收集每个服务的日志信息。

logstash(shipper) 把收集来的日志(INFO 、DEBUG 、RROR 、WARN等)分别发送到Redis。

logstash(indexer) 按照日志分类分别从Redis读取日志信息并发送给ElasticSearch

logstash(indexer) 过滤出RROR日志通过邮件或者其它webhook方式告警开发运维人员。

Kibana读取ElasticSearch数据结合自定义搜索进行页面展示。

2.2 ISO 20000和SLA

ISO 20000是面向机构的IT服务管理标准，目的是提供建立、实施、运作、监控、评审、维护和改进IT服务管理体系(ITSM)的模型。建立IT服务管理体系(ITSM)已成为各种组织，特别是金融机构、电信、高科技产业等管理运营风险不可缺少的重要机制。ISO 20000让IT管理者有一个参考框架用来管理IT服务，完善的IT管理水平也能通过认证的方式表现出来。

ISO20000标准着重于通过“IT服务标准化”来管理IT问题，即将IT问题归类，识别问题的内在联系，然后依据服务水准协议进行计划、推行和监控，并强调与客户的沟通。该标准同时关注体系的能力，体系变更时所要求的管理水平、财务预算、软件控制和分配。

 SLA(Service Level Agreement)即服务水平协议，指IT服务提供商和客户之间就服务提供中关键的服务目标及双方的责任等有关细节问题而签订的协议。 首先，SLA的实施，对服务的提供者（包括第三方服务供应商）和服务的使用者双方都澄清了一些有关服务质量的责权，把体现QoS(Quality of Services)服务质量的指标进行量化，在一定程度上避免了双方对服务质量的标准的歧义理解。因此SLA的实施，对澄清双方的责权是有利的。 
   另外，SLA过程中的一个行为，就是要把承诺的服务品质进行量化(QoS服务质量的指标)并定期的统计、分析、报告，进行透明化管理。尽管定期给客户提供系统运行的实际值，并主动报告“SLA违例”的情况的这种做法可能因为某些SLA违例带来一些收入上的少量损失，但有助于提高服务质量，提高服务提供商与用户之间的相互信赖指数，提高客户满意度。 

 

响应\级别	P1（重大故障）		P2（紧急故障）	P3 （一般故障）	P4 （正常业务）
	办公时间	非办公时间
远程响应	10分钟内	30分钟内	30分钟内	30分钟内	30分钟内
现场响应	1小时	2小时	2小时	4-8小时	适情况而定

 

重大故障（P1）：系统重大告警；设备停机；控制板、存储板等系统板卡出现硬件故障；系统超过50个或10%以上的用户无法正常工作；30%中继路由失控；系统自动重启两次或以上；电源故障；电脑话务员故障重大故障发生时，提供7*24*8小时备件服务。

紧急故障（P2）影响系统话务台或其他重要部位用户。VIP人员话机故障，如总裁/管理总监/执行总监/总经理/高级经理等呼叫中心座席分机故障；录音系统不能正常工作；CMS不能正常工作；计费系统不能正常工作；语音邮箱不能正常工作。

一般故障（P3）一般故障指重大故障及紧急故障以外的其他故障。