面向业务的智能运维：中国移动智能运维系统探索与实践

1、BAIOPS-业务智能运维

智能运维（AIOps-Algorithmic IT Operations 基于算法的 IT 运维）是人工智能技术在 IT 运维领域的运用，引用 Gartner 的报告的一段话“到 2020 年，将近 50%的企业将会在他们的业务和 IT 运维方面采用 AIOps，远远高于今天的 10%”，最近 2-3 年智能运维的概念随处可见，各大互联网公司、传统 IT 公司、金融业等都在谈他们的智能运维设想，同时也有人谈 AI 色变，觉得人工智能只是一个愿景，要落地很难。其实 AI 已经不是一个新的概念了，百度、微软、谷歌等公司早就在 10 几年前开始自己的人工智能布局了，到现在均已成为人工智能行业的领跑者了。

话不多说，人工智能那么强大，应用场景十分的广泛，当然也包括运维领域，而且面向业务的运维更是运维发展的热点趋势，下面我就和大家就“面向业务的智能运维体系建设的探索与实践”这个话题发表下我的个人见解。

2、传统运维-痛之又痛

传统的运维中，存在着诸多痛点 ：

（1）被动低效的运维难以保证业务连续性

• 运维人员往往扮演着事后“救火”的角色，待事故发生后才去处理；

• 数据分散在多处，出了故障无法快速修复，业务连续性难以有效保障；

• 随着业务复杂性不断提高，人工运维的成本呈指数级增长。

（2）缺乏统一的运维监控体系和技术工具

• 针对不同运维实体的烟囱式的运维工具，功能重叠、难以整合；

• 运维的自动化程度偏低，运维脚本泛滥，层次化、模块化程度不足；

• 监控、运维、告警平台林立，各成体系，缺乏统一化体系。

（3）海量的运维数据的价值无法充分挖掘

• 传统运维系统收集了大量的运维数据，但是却缺乏有效的手段加以分析和利用；

• 运维数据的利用仅限于简单的可视化和浅度的分析上，缺乏纵向数据的关联挖掘，无法快速定位故障根因；

• 固定式的阈值告警造成了大量的误判和漏判，而且人工调整阈值的方式也比较费时费力。

（4）缺乏全方位端到端的运维监控手段

• 大部分的运维监控仅停留在针对主机、网络的层面，忽略了业务层面的识别手段，故障的发生无法从最直接的业务层面得以发现，产生预警；

• 性能管理大多停留在服务单应用性能的管理和分析上，无法提供端到端的掌控。

3、业务智能运维的切入点

针对上述这些传统运维中存在的痛点，智能化的运维出现必定具有划时代的意义，智能运维系统的设计可以从如下几方面进行展开思考 ：

（1）面向业务维度实现异常检测

业务运维是运维的大趋势，需从最复杂的业务维度入手，根据业务维度的指标（如 PV、响应时间、错误率、GC 等）上的异动进行异常检测，提前预警；

（2）提供业务全局关系视图

业务应用维度的复杂性是运维过程中最高的，往往是二线和三线运维之间界限最模糊的区域，所以智能运维可以先解决的就是向用户提供全面、清晰的业务关系视图，让运维人员对业务应用的掌控得心应手；

（3）KPI 可视化与下钻定位

KPI 指标可以通过丰富的可视化手段展示给运维人员，业务系统的故障可以清晰的体现在可视化终端，同时支持详细的下钻手段，直至定位到发生故障的环节，甚至代码段；

（4）采用动态阈值思想的异常检测

避免传统固定阈值告警的弊端，引入机器学习算法来进行阈值动态化的异常检测效果；

（5）重视故障的全流程管理

故障发生时，可以提供一定的手段将业务层面的 KPI 异常与引起故障的原因联系起来，支持手动下钻之余还可以自动定位和关联；

（6）立体化监控体系的建设

覆盖从资源、平台层、应用监控和微服务调用链的立体化的运维分析能力。

4、业务智能运维体系架构

4.1 智能运维核心要素

智能运维体系架构的建设应该考虑如下因素 ：

数据

我们要搭建智能运维平台，首先要数据驱动，数据驱动下要做好以下几件事：

• 海量数据存储：运维数据的量级是亿级、TB 甚至 PB 级别的，所以存储系统一定要具备高容量和扩展性；

• 数据多样化：运维过程产生的数据多种多样，如应用产生的性能数据，服务器基础监控产生的 CPU/IO/Net 数据，服务间调用链数据、日志数据等，那么需要针对不同类型数据进行区别化的存储结构的设计，保证数据存储的扩展性，同时建立数据之间的关联支点；

分析能力

分析能力是智能运维平台的核心，可以应用大数据+机器学习的分析能力，结合成熟的开源分析算法实现基本的数据分析，再结合具体的应用场景，做出一些适应性改造或匹配来实现相对较好的分析效果，千万不要只想着做出来一个分析平台来，这个平台做出来不是难事，关键在于这个平台在运维领域没有实际意义。

运用起历史数据的价值，且可以有效识别出数据的各维度的规律，如周期性、趋势等，而且分析能力必须结合应用场景，判别相对适合的算法模型来训练数据，方能保证预期的设想。

分析能力可以随着时间的推移不断的演进，可以将新数据的特性带入到模型中来，以不断提高算法的准确度。

4.2 智能运维体系架构

一个通用化的业务智能运维的体系架构一般如下设计 ：

在上述的架构设计中：

（1）用户层 ：

面向业务的智能运维面向的用户，不光光是面向于传统的运维人员，此外，业务监控人员、业务部门主管、客服人员都可以在系统上找到自己所需要的数据、看到自己所想看到的东西；

（2）视图层 ：

提供 WEB 端丰富的可视化视图、大屏方式的业务状态视图、以及满足移动办公需求的手机端 APP；

（3）服务层 ：

业务智能运维将提供给用户业务视图服务、拓扑服务、性能 KPI 服务、运维分析服务、告警服务、报表服务以及系统服务等，为用户提供丰富的监控、分析和告警视图功能。

（4）核心能力层 ：

智能运维系统的最关键部分，可以分为三个较大的模块“智能监控”、“智能分析”和“智能告警”。

智能监控 ：

实现针对各个层面的监控覆盖，包括用户体验的监控、应用性能的监控、中间件监控、基础设施的监控，只有收集了全面的数据，才有可能从数据中寻找关联，从关联中发现规律，丰富运维知识库。

智能分析 ：

智能分析为整个核心能力层中最核心的部分，该部分应该涵盖离线算法的训练模块和在线实时分析模块

离线算法训练模块要根据历史数据来以离线的方式训练和修正算法模型，然后生成的算法模型就类似于一个个的[if else]判断形成的规则组合，当最新的数据输入到算法模型，就可以实时的给出推测，用于预测、异常检测、故障定位等场景，这里面当然就需要机器学习和深度学习的算法来撑场面了。

在线实时分析模块要实现实时的算法分析，并不依赖于历史数据所训练出的离线模型，而是进行实时的计算，这里则需要大数据的实时计算技术了。

智能告警 ：

智能告警需要可以有效的遏制“告警风暴”，这个可是告警系统中必须面对的问题，那么需要提供较高效的分析算法，实现告警的自动归类、自动消除，那么归类中最合适的方法就是寻找告警之间的关系关系，将相近的告警合并为一条发送，避免告警风暴。

智能告警还可以动态调整告警短信/邮件发送的频率和周期，还有告警通知对象的智能配置，保证运维人员处理告警的专注性，不会被突如其来的海量告警所淹没。

5、业务智能运维典型应用场景和关键设计

5.1 数据的采集

（1）业务层数据的采集

包括接口响应时间、调用次数、服务间调用关系、时延、慢 SQL、JVM 内存消耗、以及线程栈信息，上述数据的采集可以参考 Google Dappe 的思想实现，其中一款较好的开源软件就是 pinpoint。

pinpoint 运用 JavaAgent 字节码增强技术实现应用服务端数据的采集，且无侵入式的设计，使用方便，无需更改业务代码。可以内置支持 JAVA 程序内几十种协议交互的兼容，如 http、okhttp、mysql、oracle、postgresql、dbcp、cubrid、kafka、rabbitmq、springboot、log4j、logback、redis 等。

Pinpoint 的架构原理图如下 ：

采用 hbase 实现海量数据的存储，通过部署在业务远端的 agent 通过 UDP+thrift 的方式将应用采集的数据传输到 collector，经过处理后实现 hbase 的落存。Web UI 实现监控的可视化。

上图是通过 pinpoint 进行链路追踪的原理图，可以简单的理解为在一次交易过程中，贯穿的整个分布式系统的各个环节内都维持着一个唯一的 transactionid，且允许记录上下文环节的 spanid，从而实现链路信息的洞悉。

且 pinpoint 允许开发者自定义开发插件，实现更多协议的监控支持，如 activemq、zookeeper、consul 等。

不过 pinpoint 的功能如此强大的同时，还需要我们做适当的优化，如：

Agent 发送海量的 udp 数据到 collector，很有可能遇到网络和 collector 的阻塞，那么，这个时候可以在 agent 和 collector 之间加一层 kafka 实现消息的缓冲，提升系统稳定性。

Pinpoint 没有用户权限体系，需要我们自己实现。

可以通过参数自定义的方式来指定实际需要采集的指标项，避免 agent 多余的性能损耗，降低系统负载。

（2）关联数据的采集

关联数据包括基设施数据和中间件数据。

首先，基础设施数据如服务器的性能状态的数据，包括 CPU、磁盘、内存、IO、负载等维度各个参数的获取，您可能首先想到的是 zabbix，那么 zabbix 确实功能强大，但是“杀鸡焉用牛刀”，上述 CPU/磁盘/内存等几个参数就是我们随手敲行代码就可以搞定的事，只不过做成定时任务即可，所以我们不用 zabbix，转向轻量化的开源手段，其实 TICK 数据采集框架您可能都听过，那么我们模仿 TICK，通过 TIG（Telegraf+influxdb+grafana）框架也可以轻松搞定了。

Telegraf 是一种轻量级的采集框架，支持秒级别间歇的采集粒度，对服务器的资源占用很小（不到 3%）；

Influxdb 是一种高性能的时序数据存储引擎，可支持百亿级别的时序数据的存储，而且内置强大的连续计算、API 功能，你可以轻松的实现数据的汇聚和外部调用；

Grafana 是一款基于 JS 的前端可视化引擎，支持丰富的 dashboard 组件，如图表、仪表盘、表格、清单等，你可以利用它轻松实现各种高大上的性能监控页面，另外 grafana 和 influxdb 的兼容性也异常的友好。

同样，常见的 Paas 和 Daas 层中间件，如 nginx、apache、zookeeper、docker、mesos、ZFS、Elasticsearch、mysql、mongodb、postgresql、sql server、rethinkDB、influxdb、couchDB、redis、memcache、rabbitmq 等的组件的监控也都可以通过 TIG 框架实现监控。

至此，我们已经可以实现应用层数据和其关联数据（Iaas 层、Paas 层）的集中采集和汇聚，那么有了数据，能做的事情简直太多了。

5.2 业务层面的精细划分

欲建立面向业务服务维度的监控体系，首先需要针对业务服务做出分层次的划分，即对业务监控对象的管理需要建立体系，智能运维产品的业务服务管理体系结构如下 ：

如上图中的②③④层，专注面向业务维度的监控的同时，更要对业务层面进行精细化分层，比较容易想到的办法就是建立系统、服务、实例三层的业务监控体系。

针对系统、服务、实例做一个概念的普及 ：

系统 ：完成某一类完整需求的系统体系，如 OA 系统，系统是一个比较抽象的概念，一般由一个或多个运维人员来管理

服务：系统的下一层模块，即完成系统内某一个完整的相对独立功能的模块，如 个人信息管理服务、薪资管理服务、流程引擎服务 等；一个服务一般部署为一个集群，包含多个应用实例（如 tomcat）

实例：属于一个服务集群中的一个具体的应用实例，一般一个服务集群会部署多个实例到不同主机上，如 薪资管理服务实例一、薪资管理服务实例二 ，实现负载均衡。

在这三个层次上进行性能的监控，实现了业务应用从上到下三层的数据关联，服务运维人员可以更深入的掌控系统业务的关联状况。

那么我们是否可以针对系统、服务、实例分别进行性能监控呢？如果发生故障，就可以寻根溯源，举例：如果一个服务层的指标（如服务整体平均响应时间发生偏高的异常），那么必定是由其下的一个或多个实例导致，现在我们去查看每个实例的性能信息，通过皮尔曼相关系数，发现性能曲线和服务性能曲线最近的实例，就是异常实例，进而可以针对该实例的 Top N 请求进行下钻分析就可以得到故障所对应的代码行，问题就可以解决了。

上面所建立的系统服务实例的关系，本身就是利用了业务应用运行时本身就存在的关系，那么为何不利用起来呢，到这里还没用到高大上的 AI、机器学习呢。

5.3 故障可视化与故障重现

故障可视化

当发生故障时，可以在指标的运行图谱高亮显示该异常点，也是可视化工作中必须的，正如如下图：

上图内，系统识别到了“响应时间”的异常，当前时间点的异常指标为 11ms，同时一个友好的智能运维系统会把该时刻系统其他方面的指标也展示出来，运维人员可以直观的看到不同曲线之间的关系，并且图中每一个坐标图的右上角都展示了该指标与异常指标之间的“相关系数”，并且按相关系数绝对值倒序排列，相关系数绝对值越接近于 1，那么就越有可能是问题的直接或间接原因。

故障重现

另外当业务系统的一次请求发生了错误，如果我们可以提供手段将该次请求的过程进行一次重现，对于运维人员的排错支持也“将是极好的”。

如上图所示，可以对一次应用的请求进行回放，每一个环境执行了多长时间都可以一目了然。

5.4 异常检测

说到异常检测，应该是业务智能运维领域中的一个最常见的场景了，异常检测的方法很多，本篇中会重点的介绍一下我的见解 ：

（1）传统的异常检测方法

传统模式下完全基于人的主观经验，也即基于固定阈值的异常判断，如 CPU usage 高于 80%就告警，这种方式适配性是很差的，需要针对不同的场景设定不同的阈值，甚至同一个业务不同时间段的阈值都是不一样的，大量个性化的配置要求，对于运维人员来说是十分崩溃的。

后来就出现了一定的改进，如 3-sigma 算法，是根据正态分布的概率，自动的调整告警阈值，是的，告警阈值的配置不用人工进行，一定程度上提高了运维效率。但是，该类的算法机器容易忽略指标的周期性和趋势性，造成误判的问题也很常见了。

（2）基于统计学和机器学习的异常检测方法

总结前面的异常检测方法，可以概括为两点：人工运维工作量大、算法适配性低下。其实归结为一句话，就是动态阈值怎么评定的问题。

这个时候就比较适合引入机器学习了，比如基于指数的三次平滑算法、基于分解的傅里叶/小波分解算法等，可以有效的识别出指标的周期性、趋势性，可以快速识别出一些尖峰（spike）异常。

另外自回归移动平均模型（ARIMA 算法），对于稳定的时序数据的异常检测是非常有效的，该算法也非常适合用作时序数据的预测场景。

还有基于深度学习的循环神经网络 RNN 算法和长短期记忆网络 LSTM 算法，比较适合处理和预测时间序列中间隔和延迟相对较长的重要事件。

基于机器学习的众多算法，都可以大大的提高运维的效率，发现人工难以发现的问题，提高预警的及时性。

（3）异常检测模型优化

上一小节提到的各类机器学习算法，虽然都功能强大，但是往往都有一定的局限性，那么我们在对具体的一个场景指标（如响应时间）做异常检测的时候，我们到底选哪个算法呢？

• 方法一：这个问题可以通过“自动模型选取”方式来解决，即采用多个算法同时运行，然后通过投票的方式抉择产生最终的结果。

举个例子，针对“响应时间”指标进行异常检测，采用同比、环比、ARIMA、LSTM、KNN、高斯共 5 个算法同时进行异常检测，当其中的一半（即>=3）的算法判定为异常时，方认为该时刻的指标是异常的。

• 方法二：在方法一的基础上为每个算法加入权重值，5 种算法初始值均为 20（总合为 100），当一次异常的判断后，比如算法 1/2/3 都判定是异常，算法 4/5 都判定为非异常，那么最终结果为判定为异常，系统向运维人员发出告警，当运维人员在平台上通过指标横向对比、请求下钻、事件挖掘之后发现该时刻的指标确实为异常，那么运维人员会将这个告警处理掉，那么此时后台就会默认向投票正确的算法的权重倾斜，为其权重加 1，同时为投票错误的算法权重扣分（但总分仍保持 100 分）；而如果运维人员发现该告警是误报，则会在平台上反馈“误报”，则后台会向投票为非异常的算法权重倾斜，为每个算法权重加 1，同时为投票为异常的算法权重扣分（但总分仍保持 100 分）。如此经过长时间的不断调整，算法组合就越来越接近于准确。

（4）答疑解惑

不过有朋友可能会遇到如下问题：

Q：如果我要检测的指标刚刚上线，我根本就没有离线的训练模型怎么办？

A：那就初始阶段不利用离线模型的算法，先使用 ARIMA、同比、环比、KNN 这类的算法跑起来，等待历史数据足够了生成离线模型之后，再以同等权重（取得和现有算法权重的平均值，再进行 100 分支均衡）的方式加入到算法集合中。

Q：我使用这么多的算法来进行异常检测，对于前端告警规则配置的时候来说，我该怎么去选择我去使用哪种智能的算法呢？

A：异常检测的目的就是要识别异常并发出告警，那么在告警规则出进行配置，选择智能化的方法来检测异常的思路是正确的，但是没有必要让普通的运维人员来看到我们所提供的众多算法，还有算法逻辑，对于他们来说我们只需要让他们选择诸如“智能告警”这样的选项就好了，后面的算法选择交给专业的“运维算法工程师”来搞定就好。

Q：有了“智能告警”之后，是不是固定阈值告警就不需要了呢？

A：并不是，智能告警解决的是无法直观、简单判定故障的场景，但是对于错误率、CPU 利用率、磁盘剩余量这些基本场景时，还是可以使用阈值告警的，甚至做分级阈值告警（如一般告警、重要告警、严重告警等），这些基本的阈值告警发生后一般都是比较严重的情况，都是需要处理的；而且，这些告警信息汇聚起来，也可以作为业务层面异常故障定位的参考依据，因为很有可能这些固定阈值触发的告警就是业务层面故障发生的根因。

（5）算法训练和模型管理平台

好了，长篇大论了半天，我们似乎还忽视了一个关键的问题，那就是离线训练的模型是怎么来的，怎么用起来，怎么选算法，怎么调优，算法一定好用吗？

带着这一系列的问题，我们可以想象的到，一个离线算法训练和模型管理平台是十分必要的，这就是“运维算法工程师”所需要使用的平台了，这个平台至少要实现如下功能：

• 算法如何选择

• 算法的好坏可以评估

• 算法最好经过测试后才可上线

离线算法训练管理平台的设计可以参考如下模型 ：

离线算法训练管理平台架构简图

该平台可以获取需要检测的指标，展示过去一段（如一周或一天）时间的曲线；

特征分析器会根据预设的特征组合（事先定义好针对曲线可能的各种特征的识别判定方法库），提示出该指标的曲线对于各类特征（如上升趋势、周期性、随机性等）的支持度，支持度越高代表着该指标越具有什么特征；

然后算法推荐器会根据预设的特征-算法组合（事先定义好各种特征所适用何种算法的映射库），推荐出建议的算法集合（可 1 可多），当然也允许“运维算法工程师”在查看了第一步的曲线后，自定义选择算法库。

下一步就将通过前面算法推荐器推荐的算法或运维算法工程师自定义的算法组合进行模型的训练，将生成的临时模型保存起来；

然后，采用真实的线上数据来跑这个临时模型，会得到对应的告警；

当运行一段时间（如一周或一天）后，将临时模型发出的告警和线上模型产生的告警进行对比，去掉重复的部分，剩余部分通过运维工程师的标注和反馈，得到两个模型的误报率（当然也可以采用漏报率），若临时模型的误报率低于线上模型，则认为模型是有效的，可以进行发布环节，该临时模型替换线上模型，进入生产。

注：临时模型和线上模型的对比如果无法通过运维工程师的评估快速得到的情况下，也可以采用比较通用的算法评估方法来计算得出，不过最好的手段就是“利用运维工程师的判断”。

5.5 关联分析

关联分析一般会作用在故障定位和告警归集两个差劲

（1）故障定位

基于关联关系的基础可视化辅助

在针对系统的异常进行有效的检测后，极大的缩小了故障的范围，如将故障缩小到了某几分钟内，然后将相关的其他指标曲线和故障曲线同时可视化展示，则可以辅助我们深入数据进行问题的定位：

• 理论依据：当某一个维度的指标发生异常时，那么相关的其他指标也极有可能一定程度上体现出正向或反向的波动，如果可以将多个疑似相关指标的曲线在一个图上展示，并提供格线比对功能，那么相比于传统的翻阅日志看 log 的情况，将会更快的定位到问题的原因。

• 落地场景：如上图所示，某服务器上某服务实例在 10:00 左右发生了响应时间严重变慢的情况，经过对相同服务器的各项指标分析，可知当时系统 CPU 占用在同一时刻上升，且内存的空闲率也大幅下降，但是实际的业务访问量并没有飙升，说明并非业务繁忙导致，疑似服务器硬件问题所致；同时在针对部署在服务器 B 上的相同实例的指标进行对比，发现各项指标并无明显波动，且和服务器 B 上正常指标类似，所以可以确定是因为服务器 A 的硬件问题导致，完成故障初步定界，继而再去排查服务器的相关指标，便可迅速定位问题。

基于多维度数据的异常诊断分析

• 理论依据：通过贡献度和一致度评判问题根源（如 ERROR 数量维度）

• 贡献度：即各维度异常数与总异常数的比例

• 一致度：即构成该维度的子维度的异常程度的相似度信息。

那么贡献度越高、子维度的异常相似度越高，则该维度为根因维度的可能性越大。

因此，可以将数据的各维度展开，分别计算各维度的贡献度、一致度两个特征，构建评估参数 P=贡献度/一致度，该值越高，则该子维度为根因维度的可能性越大。

• 落地场景：当发现某服务（如充值服务）的错误率告警突然大幅增加时，传统运维人员往往无法快速定位，甚至问题的定界都需要大量的时间，如果运用智能运维产品，可以将该服务的所有 6 个实例上进行 3 个错误共 6*3=18 中维度上进行分析，利用上述理论中的评估参数列出排名前 N 的组合，迅速将问题范围大幅缩小，提高排查的效率。

可以定位到实例 4 的 404 错误是错误数的主要原因，可针对性进行排查

（2）告警归集

基于关联挖掘的告警分析

采用机器学习算法实现告警的关联挖掘，进而实现告警前的合并优化，与告警后的数据分析，反哺合并策略。

• 理论依据：历史上每次某一个告警总是伴随着另外一个告警的出现，那么可以怀疑两类告警之间存在必然联系，甚至因果关系，所以可以考虑合并该两类告警，并积累在运维知识库内，随着历史数据的丰富，告警合并的准确性将不断提高。

• 落地场景：在历史数据上，A 实例的策略 R1 和 B 实例的策略 R2 经常同时报警，那么 A 实例的策略 R1 和 B 实例的策略 R2 就极有可能存在关联，经过一定的置信评级，就可以合并在一起发送。

注：置信度是针对一条关联规则 A 告警->B 告警而言定义的，代表了 A 告警导致 B 告警发生的可能的概率

智能告警体系下充分利用从业务到主机的纵向数据关联，实现告警的聚合与收敛

• 理论依据：将运维对象划分为不同的层次

业务角度 ：服务/实例/告警类型

部署角度 ：机器/机房

同一角度同一层次同时刻的告警，很可能存在着一定联系，故而可将这些告警合并。

• 落地场景：话费查询服务的信息港机房内服务 1 的 A 实例在发生进程丢失告警，同时该服务在信息港机房的服务 1 的 B 实例上也发生了进程丢失告警。这两个告警属于同一个机房的同一个服务的同一个策略（进程监控策略）下的告警，且为同一层次，因而可以实现收敛。

小结

上述基于关联关系实现了故障辅助定位和告警的智能归集，其实还有很多落地的场景，如根据事件依赖关系构造动态事件概率模型图，如果有大量的历史数据做分析，就可以充分的识别出各类事件之间的因果关系，这些因果关系就是最宝贵的运维知识库。

5.6 负载均衡优化

同时，智能运维系统也将辅助软件负载策略的优化，通过针对集群的全面监控和分析，在负载层做出更新时，可以及时的发现集群整体的健康劣化的状况，及时发现负载策略变更导致的问题，并向负载层软件上报问题或针对负载策略优化的建议，以更加智能化的手段提高系统的高可用性和效率。

负载均衡优化模型

辅助负载优化常用场景包括 ：

相同负载下某主机的硬件指标告警，则可以考虑将其上应用转移到其他低负载主机上，或降低负载均衡器的分配权重，达到所有主机整体健康；

当发现某主机上应用响应变慢，并且将会发生故障时，负载均衡的 tcp 探查无法发现，运维系统可以实现事先预警，并定位事故原因（一般为硬件或负载均衡器分担错误问题），同时上报负载均衡器，事先负载重分等止损措施；

灰度发布过程中，可以通过智能运维产品监控新版本的性能情况，如可及早发现新版本应用性能较差或者存在错误警告，则可以及时上报灰度发布系统，及时止损，或触发自部署节点的回滚自愈操作。

5.7 日志分析

日志分析的作用，往往会体现在如下几个场景 ：

（1）针对业务日志进行业务的多维分析

如通过 CDN 的日志，实现用户的行为画像，也可以实现故障分布的拓扑视图；

（2）针对于日志中出现的各类关键日志

可以提炼出关键的事件来，这些事件如果和前面的业务异常所关联起来，就可以实现业务异常所对应的根因事件溯源；

（3）利用诸如 ELK 这样的平台

针对分布式的日志进行汇聚和索引后，就可以发挥和业务层性能采集一样的作用，将日志进行解析后，同样是是一列一列的性能指标，而后再来做异常检测还是可以的；

（4）利用日志做运维审计与合规

也是一个智能运维的典型场景。

6、智能运维的最高境界-故障自愈

针对于故障自愈应该以故障定位准确基础之上开展的，需要逐步推行，在此我就结合几个场景来聊一聊故障自愈的设计方案（按照云计算体系进行分层描述吧），以辅助落地 ：

（1）Saas 层 ：

• 服务 4/5 错误：直接重启进程后再检测。

• 服务性能缓慢：排查相同集群服务是否均发生劣化，如仅此节点劣化，可采取流量分担方案；如全部节点均劣化，可采取自动扩容方案。

• 频繁 GC：可按需增大 JVM 内存分配后继续监控。

（2）Paas 和 Daas 层 ：

• Spark executor 性能明显劣化：可在下次任务开始之前更新–executor-memory

• Db 阻塞连接数激增：可断开超过设定阈值（如 2 分钟）的连接

• Docker 性能下降：新建 docker 分配更大内存，对现有 docker 进行替代

• YARN 资源分配失败：判断 YARN 资源情况，如果占用已满，进行动态扩容

（3）Iaas 层

• 磁盘满：调用清理文件脚本实现清理，并释放进程资源占用

• 磁盘不可见：尝试重新挂载，如无效后直接将告警转发给硬件维护人员

• 内存不足：尝试清理服务器 page cache 等

• 辅助优化的方案：当发生故障后，并不一定需要立刻触发自愈操作，如突然的网络抖动，引起服务报错、性能缓慢的故障，很有可能过若干分钟即可自行恢复，此类则不需要立刻修复，那么优化后的方案可以参考如下的思路：

首次发现故障暂不触发自愈操作，待连续 5 次出现同样故障，触发自愈操作；

采集一定时间段的平均值，如平均值不超过阈值，则不认为是故障，不触发自愈操作

7 、智能运维不是万能的

智能运维并不是万能的，智能运维的落地成功性在于精于业务、切合实际，关键点如下 ：

• 精于业务，了解业务的规律，才好选择好的算法模型；

• 有了智能运维不代表就不需要运维人员了，因为毕竟算法是人写的，机器学习还是需要有“运维老司机”进行调教的；

• 若想做好准确的预测，需要有足够、精细的历史数据为样本；

• 需要将算法运用于贴合实际的某一个具体业务场景中，避免离谱夸大的设想，如“预测小米什么时候上市，没准说着说着就上市了”，其实前几天就已经上市了；

• 智能运维的前提最好是先实现自动化，否则即使检测出故障和根因也无法自动修复；

• 一定要贴合实际情况，一步一步来，切勿期盼一口吃个胖子。

8、感慨下

业务智能运维，是运维发展的大势所趋，无所畏惧，世间万物皆连接，有了人工智能这一利器，加之我们对于业务的深层理解，以及运维领域的丰富经验，相信中国移动智能运维体系的建成和落地，指日可待！！

注：文中少部分内容的思路和灵感参考于百度、清华大学、Linkedin、Yahoo 等公司运维领域专家的大作，谢谢。