1.商业智能操作和维护
智能运维(AIOps-algorithm IT Operations基于算法的IT运维)是人工智能技术在IT运维领域的应用。引用高德纳报告中的一段话“到2020年，近50%的企业将在业务和IT运维中采用AIOps，远高于今天的10%”，近2-3年智能运维的概念随处可见。各大互联网公司、传统IT公司、金融行业都在谈论自己的智能运维思路。同时也有人谈AI变色，认为人工智能只是一个视觉，很难落地。其实AI并不是一个新概念。百度、微软、谷歌等公司10多年前就开始了自己的人工智能布局，现在已经成为人工智能行业的领跑者。
不多说，人工智能这么强大，应用场景非常广泛，包括运维领域，面向业务的运维是运维发展的热点趋势。我就“面向业务的智能运维体系建设探索与实践”这个话题发表一下个人看法。
2、传统的操作和维护——痛苦而痛苦
在传统的操作和维护中，有许多痛点:
示例:它属于服务群集中的特定应用程序实例。通常，服务集群会将多个实例部署到不同的主机上，例如薪资管理服务实例1和薪资管理服务实例2，以实现负载平衡。
通过监控这三个层面的性能，实现了业务应用自上而下的数据关联，服务运维人员可以更深入的控制系统业务的关联状态。
那么我们可以分别监控系统、服务和实例的性能吗？如果出现故障，您可以追踪其来源。例如，如果一个服务层的指示符(例如整个服务的异常平均响应时间)出现，它一定是由它下面的一个或多个实例引起的。现在我们来检查一下每个实例的性能信息，通过Pearman相关系数找到性能曲线和服务性能曲线最近的实例，这是一个异常实例。然后，我们可以深入分析这个实例的Top N请求，得到故障对应的代码行，问题就可以解决了
上面建立的系统服务实例本身的关系就是业务应用运行时存在的关系，为什么不用呢？高水平的AI和机器学习在这里都没有用过。
5.3故障可视化和故障再现
故障可视化
出现故障时，可以在指示器的操作图中突出显示异常点，这在可视化工作中也是必要的，如下图所示:
上图中系统识别出“响应时间”的异常，当前时间点的异常指标为11 ms，同时友好的智能运维系统也会显示系统当时的其他指标，运维人员可以直观的看到不同曲线之间的关系。另外，图中每个坐标图的右上角都显示了指标与异常指标之间的“相关系数”，按照相关系数的绝对值，按反序排列。相关系数的绝对值越接近1，则
故障再现
此外，当业务系统的请求出现错误时，如果我们能够提供一种方法来重现请求的过程，对运维人员的故障排除支持将是“优秀的”。
如上图所示，一个应用的请求可以回放，每个环境执行了多久一目了然。
5.4异常检测
说到异常检测，应该是商业智能运维领域最常见的场景之一。异常检测的方法有很多。本文将重点阐述我的观点:
(1)传统的异常检测方法
传统模式完全基于人的主观经验，即基于固定阈值的异常判断。如果CPU使用率高于80%，就会报警。这种方法适应性差，需要针对不同的场景设置不同的阈值。甚至同一个业务在不同时间段的门槛也不一样。大量的个性化配置需求对于运维人员来说是非常崩溃的。
后来有了一些改进，比如3-sigma算法，根据正态分布的概率自动调整报警阈值。是的，报警阈值的配置不需要人工操作，一定程度上提高了运维效率。但这类算法机往往忽略了指标的周期性和趋势性，导致误判。
(2)基于统计和机器学习的异常检测方法
总结以往的异常检测方法，可以概括为两点:人工操作维护工作量大，算法适应性低。其实归结为一句话，就是如何评价动态阈值。
此时更适合引入机器学习，如指数三次平滑算法、基于分解的傅里叶/小波分解算法等。，可以有效识别指标的周期性和趋势，快速识别一些尖峰异常。
此外，自回归移动平均模型(ARIMA算法)对于稳定时间序列数据的异常检测非常有效，并且该算法也非常适合时间序列数据的预测场景。
还有基于深度学习的循环神经网络RNN算法和长短期记忆网络LSTM算法，更适合处理和预测时间序列中间隔和延迟相对较长的重要事件。
很多基于机器学习的算法可以大大提高运维效率，发现人工难以发现的问题，提高预警的时效性。
(3)异常检测模型优化
前面提到的各种机器学习算法虽然功能强大，但往往都有一定的局限性。那么当我们对一个特定的场景指标(比如响应时间)做异常检测时，应该选择哪种算法呢？
方法一：这个问题可以通过“自动模型选取”方式来解决，即采用多个算法同时运行，然后通过投票的方式抉择产生最终的结果。例如，对于“响应时间”指标，同时使用五种算法，即同比算法、季度环比算法、ARIMA算法、LSTM算法、KNN算法和高斯算法进行异常检测。当其中一半(即>:=3)时，则认为当时的指数异常。
方法二：在方法一的基础上为每个算法加入权重值，5种算法初始值均为20（总合为100），当一次异常的判断后，比如算法1/2/3都判定是异常，算法4/5都判定为非异常，那么最终结果为判定为异常，系统向运维人员发出告警，当运维人员在平台上通过指标横向对比、请求下钻、事件挖掘之后发现该时刻的指标确实为异常，那么运维人员会将这个告警处理掉，那么此时后台就会默认向投票正确的算法的权重倾斜，为其权重加1，同时为投票错误的算法权重扣分（但总分仍保持100分）；而如果运维人员发现该告警是误报，则会在平台上反馈“误报”，则后台会向投票为非异常的算法权重倾斜，为每个算法权重加1，同时为投票为异常的算法权重扣分（但总分仍保持100分）。如此经过长时间的不断调整，算法组合就越来越接近于准确。(4)回答问题
但是，有些朋友可能会遇到以下问题:
问:当我要测试的指标只是在线的时候，我根本没有一个离线的训练模型怎么办？
答:在初始阶段，不使用离线模型的算法，而是使用ARIMA、同比、环比、KNN等算法运行，等待历史数据足够生成离线模型，然后加入到相同权重的算法集中(得到现有算法权重的平均值，然后进行100分支均衡)。
问:我用了这么多算法进行异常检测。配置前端报警规则时，如何选择使用哪种智能算法？
答:异常检测的目的是识别异常并发出警报，所以在警报规则中配置并选择智能方法检测异常的想法是正确的，但普通运维人员不需要看到我们提供的众多算法和算法逻辑。对于他们，我们只需要让他们选择“智能报警”等选项，后面的算法就交给专业的“运维算法工程师”了。
问:有了“智能报警”，固定阈值报警就没有必要了吗？
答:不是，智能报警解决了不能直观简单判断故障的场景。但对于差错率、CPU利用率、磁盘剩余量等基本场景，仍然可以使用阈值告警，甚至分级阈值告警(如一般告警、重要告警、严重告警等)。)都可以。这些基本阈值报警一般是发生后的严重情况，需要处理；而且这些告警信息也可以作为业务层面定位异常故障的参考，因为这些固定阈值触发的告警很有可能是业务层面故障的根本原因。
(5)算法培训和模型管理平台
好了，说了半天，我们好像忽略了一个关键问题，就是离线训练模型是怎么来的，怎么用，怎么选算法，怎么调，算法一定要好好工作吗？
有了这一系列问题，我们可以想象，一个离线的算法培训和模型管理平台是非常必要的，这就是“运维算法工程师”需要用到的平台。这个平台至少要实现以下功能:
算法如何选择算法的好坏可以评估算法最好经过测试后才可上线离线算法培训管理平台的设计可以参考以下模型:
离线算法培训管理平台架构图
平台可以获取待检测的指标，并显示过去一段时间(如一周或一天)的曲线；
特征分析器会提示指数曲线对各种特征的支持度(如上升趋势、周期性、随机性等)。)根据预设的特征组合(预先定义了曲线各种可能特征的识别判断方法库)。支持度越高，指标的特征越多；
然后算法推荐器会根据预设的特征-算法组合(预先定义了哪些算法适用于各种特征的映射库)推荐建议的算法集(多达一个)，当然，运维算法工程师在查看第一步的曲线后，也可以自行选择算法库。
在下一步中，模型将由前一个算法推荐器推荐的算法或者运维算法工程师定制的算法组合进行训练，生成的临时模型将被保存；
然后，用真实的在线数据运行这个临时模型，你会得到相应的报警；
运行一段时间(如一周或一天)后，将临时模型生成的告警与在线模型生成的告警进行对比，去除重复部分，通过运维工程师的标注和反馈，得到两个模型的虚警率(当然也可以采用虚警率)。如果临时模型的虚警率低于在线模型，则认为模型有效，可以发布。临时模型取代在线模型并进入生产。
注意:如果临时模型和在线模型的比较不能通过运维工程师的评估快速得到，也可以通过更一般的算法评估方法计算，但最好的手段是使用运维工程师的判断。
5.5相关性分析
关联分析通常用于故障定位和警报收集
(1)故障定位
基于关联关系的基础可视化辅助
有效检测系统异常后，故障范围大大缩小。例如，如果故障减少到一定的几分钟，然后其他相关指标曲线和故障曲线同时可视化显示，可以帮助我们深入数据定位问题:
理论依据：当某一个维度的指标发生异常时，那么相关的其他指标也极有可能一定程度上体现出正向或反向的波动，如果可以将多个疑似相关指标的曲线在一个图上展示，并提供格线比对功能，那么相比于传统的翻阅日志看log的情况，将会更快的定位到问题的原因。
基于多维数据的异常诊断分析
理论依据：通过贡献度和一致度评判问题根源（如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-memoryDb阻塞连接数激增：可断开超过设定阈值（如2分钟）的连接Docker性能下降：新建docker分配更大内存，对现有docker进行替代YARN资源分配失败：判断YARN资源情况，如果占用已满，进行动态扩容(3)Iaas层
磁盘满：调用清理文件脚本实现清理，并释放进程资源占用磁盘不可见：尝试重新挂载，如无效后直接将告警转发给硬件维护人员内存不足：尝试清理服务器page cache等辅助优化的方案：当发生故障后，并不一定需要立刻触发自愈操作，如突然的网络抖动，引起服务报错、性能缓慢的故障，很有可能过若干分钟即可自行恢复，此类则不需要立刻修复，那么优化后的方案可以参考如下的思路：第一次发现的故障暂时不会触发自愈操作，同一故障连续五次发生时会触发自愈操作；
收集某段时间的平均值。如果平均值没有超过阈值，则不认为是故障，不会触发自愈操作
7.智能运维不是万能的
智能运维不是万能的。智能运维的成功在于精通业务和实用。要点如下:
精于业务，了解业务的规律，才好选择好的算法模型；有了智能运维不代表就不需要运维人员了，因为毕竟算法是人写的，机器学习还是需要有“运维老司机”进行调教的；若想做好准确的预测，需要有足够、精细的历史数据为样本；需要将算法运用于贴合实际的某一个具体业务场景中，避免离谱夸大的设想，如“预测小米什么时候上市，没准说着说着就上市了”，其实前几天就已经上市了；智能运维的前提最好是先实现自动化，否则即使检测出故障和根因也无法自动修复；一定要贴合实际情况，一步一步来，切勿期盼一口吃个胖子。8.情绪低落
商业智能运维是运维发展的总趋势。没有恐惧，世界万物相连。凭借人工智能，我们对业务的深入了解和丰富的运维经验，相信中国移动智能运维系统的建立和落地指日可待！！
注:本文几个内容的思路和启发参考了百度、清华、领英、雅虎等运维领域专家的大作。谢谢你。
扩展阅读:
"
《牧场主》已在全球下载超过9000万次，部署超过2万个制作节点，拥有迪士尼、IBM、乐高、美国农业部、索尼、平安、海航集团等数百家大中型政府和企业客户。
"
1.《尖峰投票平台 面向业务的智能运维：中国移动智能运维系统探索与实践》援引自互联网，旨在传递更多网络信息知识，仅代表作者本人观点，与本网站无关，侵删请联系页脚下方联系方式。
2.《尖峰投票平台 面向业务的智能运维：中国移动智能运维系统探索与实践》仅供读者参考，本网站未对该内容进行证实，对其原创性、真实性、完整性、及时性不作任何保证。
3.文章转载时请保留本站内容来源地址，https://www.lu-xu.com/fangchan/1575295.html
