aiops指南（aiops理念）

本篇文章给大家谈谈aiops指南，以及aiops理念对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享aiops指南的知识，其中也会对aiops理念进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、AIOps未来的发展是怎样的？
• 2、听云AIOps平台可以与APM产品高效融合吗？
• 3、国内优秀的IT运维企业有哪些
• 4、国内应用性能管理（APM）厂商哪家比较好？主要考虑技术和服务层面
• 5、国内优秀的IT运维企业有哪些？
• 6、IT运维平台算法背后的两大“神助攻”

AIOps未来的发展是怎样的？

AIOps 是运维发展的必然趋势。
一个很明显的规律，凡是让能让我们的生活变得更美好、更简单、更方便的技术，一定会具有强大的生命力，也必然会成为发展趋势，而 AI 正是这样的技术之一，AIOps 又是其中的一个专业领域。运维的发展变化是随着业务和技术发展变化的，根本上还是业务驱动和倒逼出来的。
当前这个阶段，现实情况，系统里面已经有大量软硬件模块、日志、监控告警指标也纷繁复杂，一方面是无法在问题萌芽状态就发现问题，无法提前做出预判，另一方面是发生了问题又无法快速确定根因，造成持续的资损。技术发展上，随着计算能力、数据量的积累、以及机器算法的进步，如何更加高效地开展 Ops 这个问题就摆在我们面前，AIOps 的模式应运而生。
所以，运维一步步发展到当前这个状态，根本上讲还是业务高速发展倒逼出来的，同时，从手动运维到运维自动化，再到 AIOps，这个过程根本上是在朝着如何更加高效运维的趋势在发展。

听云AIOps平台可以与APM产品高效融合吗？

在Gartner 4月份发布的另一项研究报告《AIOps市场指南》中，亦强调AIOps功能是APM工具的定义功能之一。听云作为国内APM行业领军者，5次荣登Gartner APM魔力象限，多次得到Gartner的认可足以证明了听云的能力。听云AIOps平台——北冥 通过将APM平台汲合的大量数据、事件、日志、拓扑信息等进行关联并收敛，从中识别出重要的告警信息进行分析并以可视化方式向用户进行说明，同时与CMDB、ITSM和Automation集成，可以将AIOps能力与APM产品高效融合。

国内优秀的IT运维企业有哪些

近日aiops指南，Gartner发布了《中国智能运维市场指南》（以下简称“《指南》”）aiops指南，擎创科技再次因为在智能运维领域产品的创新力及其成熟度，被Gartner提名为AIOps领域代表供应商。而在去年7月份，擎创就被Gartner评为中国AIOps领域重点推荐服务商。

Gartner《指南》指出，在中国特有的生态环境系统下，全球性的IT巨头虽然进驻中国市场数十年，但是却难以在AIOps领域扩张。主要原因在于，这些全球性供应商提供的ITOM工具的许可证模式比较昂贵，而且功能也难以完全满足中国本土客户个性化的需求，这样进行大规模部署时需要大量的客户化定制，总体拥有成本就十分高昂。

而中国本土AIOps供应商，对本土客户的需求十分熟悉，aiops指南他们通过人工智能等手段，极大提高了数据智能分析能力和运维场景丰富度等，解决了IT运维的关键问题，逐渐获得了越来越多中国本土客户的青睐。

根据对中国AIOps市场的调研，Gartner发现中国的本土客户，特别看重AIOps以下两个关键点aiops指南：

监控平台整合能力。现有的企业监控平台很多，但却彼此孤立，这些企业希望通过AIOps工具进行监控平台的统一管控。

数据监控能力的加强。企业希望通过AIOps工具增强其数据分析和监控能力，以增加监控实时性，提升监控的效率。

而这两方面，恰恰是擎创专精的领域，也是擎创产品最大的优势。Gartner认为，“（EOITek擎创科技）运维行业经验丰富，产品成熟度很高且无需过多的定制化。” 擎创自研夏洛克AIOps智慧运营平台，目前已经能够打通并整合不同的监控平台，具备多源数据的监控能力、实时分析能力和事故预判能力，还能进行智能化分析。

事实上，智能运维AIOps已逐渐成为抢占国内数字化转型高地的不二之选。越来越多的企业开始运用大数据和人工智能等技术管理IT运维，企业基础设施运维负责人也希望提高实时分析、异常检测和关联分析的效率，从而为业务侧提供强有力的决策支撑。

根据Gartner预测，到2022年在AI产品细分领域中，将只有少数玩家占据主导地位，引领AI发展潮流aiops指南；而到2023年，40%的DevOps团队将会采用AIOps平台，以此增强应用程序和基础设施监控能力。并且预测未来两到三年内，成功的AIOps用户案例将会向多样化场景解决方案演进，而并非用一种复杂的、大而全的产品去实现所有需求。

擎创作为国内较早专注于智能运维的科创公司，已经在智能运维领域深耕了数年，专注于将人工智能赋能IT运维管理，激活运维数据智慧，提高IT运维效率和智能化水平，助力客户数字化转型。在产品的综合能力方面，擎创已经实现了多样化智能运维场景的模块化部署能力，客户可以根据自身运维成熟度灵活选择；而在产品的成熟度方面，擎创拥有丰富的开箱即用的产品功能和独特的多元化数据实时性智能分析优势，这也是能够再次被Gartner提名成为国内AIOps领域的代表性供应商的根本原因。

国内应用性能管理（APM）厂商哪家比较好？主要考虑技术和服务层面

我在APM行业工作过，目前主流的APM厂商是博睿数据和听云，据我了解，两家的发展重点完全不同：首先，听云更多投入是在市场开拓，包括建立分支机构和大力发展渠道代理，博睿数据在市场策略上略显保守，更注重技术研发投入，据我所知他们的技术人员和技术专利是最多的，其次，在服务客户方面，从两家所展示的案例上来看，博睿数据更侧重大型企业，听云大企业也有，但中小占比较高，再次是产品线和能力，两家都具有端到端的能力，但博睿数据在数据采集和移动应用监控领域具有独家产品，大数据和人工智能投入也很早，现在都有相应产品输出，听云也形成了全套产品线，但这几年在研发产出上并没有太大的新动作。
我觉得IT运营是一个高风险的职业，尤其现在与数字化业务紧密结合，更是如履薄冰,APM对于IT运营来说是极好的工具，能让问题防患于未然，能让IT运营工作有理有据，不再背锅，对于供应商的选择当然要非常重视，除了对比产品的功能，有一个细节往往是大家忽略的，那就是APM探针对资源的占用情况，这决定各APM服务商在基本功能相当的基础上，判定谁更优质的重要因素，建议大家可以通过对比测试被监控应用在无探针和有探针下的性能损耗来判断，一切用数据说话。

国内优秀的IT运维企业有哪些？

国内优秀的IT运维企业有哪些

极其流行，同样也是竞争力极其大的一种商业模式。虽然国内软件开发公司都发展壮大起来了，但是各地软件开发公司的实力及资质仍然参差不齐。下面为大家介绍下近期国内软件开发公司的排名汇总。

1：华盛恒辉科技有限公司

上榜理由：华盛恒辉是一家专注于高端软件定制开发服务和高端建设的服务机构，致力于为企业提供全面、系统的开发制作方案。在开发、建设到运营推广领域拥有丰富经验，我们通过建立对目标客户和用户行为的分析，整合高质量设计和极其新技术，为您打造创意十足、有价值的企业品牌。

在军工领域，合作客户包括：中央军委联合参谋(原总参)、中央军委后勤保障部(原总后)、中央军委装备发展部(原总装)、装备研究所、战略支援、军事科学院、研究所、航天科工集团、中国航天科技集团、中国船舶工业集团、中国船舶重工集团、第一研究所、训练器材所、装备技术研究所等单位。

在民用领域，公司大力拓展民用市场，目前合作的客户包括中国中铁电气化局集团、中国铁道科学研究院、济南机务段、东莞轨道交通公司、京港地铁、中国国电集团、电力科学研究院、水利部、国家发改委、中信银行、华为公司等大型客户。

2：五木恒润科技有限公司

上榜理由：五木恒润拥有员工300多人，技术人员占90%以上，是一家专业的军工信息化建设服务单位，为军工单位提供完整的信息化解决方案。公司设有股东会、董事会、监事会、工会等上层机构，同时设置总经理职位，由总经理管理公司的具体事务。公司下设有研发部、质量部、市场部、财务部、人事部等机构。公司下辖成都研发中心、西安研发中心、沈阳办事处、天津办事处等分支机构。

3、浪潮

浪潮集团有限公司是国家首批认定的规划布局内的重点软件企业，中国著名的企业管理软件、分行业ERP及服务供应商，在咨询服务、IT规划、软件及解决方案等方面具有强大的优势，形成了以浪潮ERP系列产品PS、GS、GSP三大主要产品。是目前中国高端企业管理软件领跑者、中国企业管理软件技术领先者、中国最大的行业ERP与集团管理软件供应商、国内服务满意度最高的管理软件企业。

4、德格Dagle

德格智能SaaS软件管理系统自德国工业4.0，并且结合国内工厂行业现状而打造的一款工厂智能化信息平台管理软件，具备工厂ERP管理、SCRM客户关系管理、BPM业务流程管理、
OMS订单管理等四大企业业务信息系统，不仅满足企业对生产进行简易管理的需求，并突破局域网应用的局限性，同时使数据管理延伸到互联网与移动商务，不论是内部的管理应用还是外部的移动应用，都可以在智能SaaS软件管理系统中进行业务流程的管控。

5、Manage

高亚的产品 (8Manage) 是美国经验中国研发的企业管理软件，整个系统架构基于移动互联网和一体化管理设计而成，其源代码编写采用的是最为广泛应用的
Java / J2EE 开发语言，这样的技术优势使 8Manage
可灵活地按需进行客制化，并且非常适用于移动互联网的业务直通式处理，让用户可以随时随地通过手机apps进行实时沟通与交易。

IT运维平台算法背后的两大“神助攻”

智能运维(AIops)是目前 IT 运维领域最火热的词汇，全称是 Algorithmic IT operations platforms，正规翻译是『基于算法的 IT 运维平台』，直观可见算法是智能运维的核心要素之一。
本文主要谈算法对运维的作用，涉及异常检测和归因分析两方面，围绕运维系统Kale 中 skyline、Oculus 模块、Opprentice 系统、Granger causality（格兰杰因果关系）、FastDTW 算法等细节展开。

一、异常检测

异常检测，是运维工程师们最先可能接触的地方了。毕竟监控告警是所有运维工作的基础。设定告警阈值是一项耗时耗力的工作，需要运维人员在充分了解业务的前提下才能进行，还得考虑业务是不是平稳发展状态，否则一两周改动一次，运维工程师绝对是要发疯的。

如果能将这部分工作交给算法来解决，无疑是推翻一座大山。这件事情，机器学习当然可以做到。但是不用机器学习，基于数学统计的算法，同样可以，而且效果也不差。

异常检测之Skyline异常检测模块

2013年，Etsy 开源了一个内部的运维系统，叫 Kale。其中的 skyline 部分，就是做异常检测的模块， 它提供了 9 种异常检测算法 ：

first_hour_average、

simple_stddev_from_moving_average、

stddev_from_moving_average、

mean_subtraction_cumulation、

least_squares

histogram_bins、

grubbs、

median_absolute_deviation、

Kolmogorov-Smirnov_test

简要的概括来说，这9种算法分为两类：

从正态分布入手：假设数据服从高斯分布，可以通过标准差来确定绝大多数数据点的区间；或者根据分布的直方图，落在过少直方里的数据就是异常；或者根据箱体图分析来避免造成长尾影响。

从样本校验入手：采用 Kolmogorov-Smirnov、Shapiro-Wilk、Lilliefor 等非参数校验方法。

这些都是统计学上的算法，而不是机器学习的事情。当然，Etsy 这个 Skyline 项目并不是异常检测的全部。

首先，这里只考虑了一个指标自己的状态，从纵向的时序角度做异常检测。而没有考虑业务的复杂性导致的横向异常。其次，提供了这么多种算法，到底一个指标在哪种算法下判断的更准？这又是一个很难判断的事情。

问题一： 实现上的抉择。同样的样本校验算法，可以用来对比一个指标的当前和历史情况，也可以用来对比多个指标里哪个跟别的指标不一样。

问题二： Skyline 其实自己采用了一种特别朴实和简单的办法来做补充——9 个算法每人一票，投票达到阈值就算数。至于这个阈值，一般算 6 或者 7 这样，即占到大多数即可。

异常检测之Opprentice系统

作为对比，面对相同的问题，百度 SRE 的智能运维是怎么处理的。在去年的 APMcon 上，百度工程师描述 Opprentice 系统的主要思想时，用了这么一张图：

Opprentice 系统的主体流程为：

KPI 数据经过各式 detector 计算得到每个点的诸多 feature；

通过专门的交互工具，由运维人员标记 KPI 数据的异常时间段；

采用随机森林算法做异常分类。

其中 detector 有14种异常检测算法，如下图：

我们可以看到其中很多算法在 Etsy 的 Skyline 里同样存在。不过，为避免给这么多算法调配参数，直接采用的办法是：每个参数的取值范围均等分一下——反正随机森林不要求什么特征工程。如，用 holt-winters 做为一类 detector。holt-winters 有α，β，γ 三个参数，取值范围都是 [0, 1]。那么它就采样为 (0.2, 0.4, 0.6, 0.8)，也就是 4 ** 3 = 64 个可能。那么每个点就此得到  64  个特征值。

异常检测之

Opprentice 系统与 Skyline 很相似

Opprentice 系统整个流程跟 skyline 的思想相似之处在于先通过不同的统计学上的算法来尝试发现异常，然后通过一个多数同意的方式/算法来确定最终的判定结果。

只不过这里百度采用了一个随机森林的算法，来更靠谱一点的投票。而 Etsy 呢？在 skyline 开源几个月后，他们内部又实现了新版本，叫 Thyme。利用了小波分解、傅里叶变换、Mann-whitney 检测等等技术。

另外，社区在 Skyline 上同样做了后续更新，Earthgecko 利用 Tsfresh 模块来提取时序数据的特征值，以此做多时序之间的异常检测。我们可以看到，后续发展的两种 Skyline，依然都没有使用机器学习，而是进一步深度挖掘和调整时序相关的统计学算法。

开源社区除了 Etsy，还有诸多巨头也开源过各式其他的时序异常检测算法库，大多是在 2015 年开始的。列举如下：

Yahoo! 在去年开源的 egads 库。(Java)

Twitter 在去年开源的 anomalydetection 库。(R)

Netflix 在 2015 年开源的 Surus 库。(Pig，基于PCA)

其中 Twitter 这个库还被 port 到 Python 社区，有兴趣的读者也可以试试。

二、归因分析

归因分析是运维工作的下一大块内容，就是收到报警以后的排障。对于简单故障，应对方案一般也很简单，采用 service restart engineering~ 但是在大规模 IT 环境下，通常一个故障会触发或导致大面积的告警发生。如果能从大面积的告警中，找到最紧迫最要紧的那个，肯定能大大的缩短故障恢复时间(MTTR)。

这个故障定位的需求，通常被归类为根因分析（RCA，Root Cause Analysis）。当然，RCA 可不止故障定位一个用途，性能优化的过程通常也是 RCA 的一种。

归因分析之 Oculus 模块

和异常检测一样，做 RCA 同样是可以统计学和机器学习方法并行的~我们还是从统计学的角度开始。依然是 Etsy 的 kale 系统，其中除了做异常检测的 skyline 以外，还有另外一部分，叫 Oculus。而且在 Etsy 重构 kale 2.0 的时候，Oculus 被认为是1.0 最成功的部分，完整保留下来了。

Oculus 的思路，用一句话描述，就是：如果一个监控指标的时间趋势图走势，跟另一个监控指标的趋势图长得比较像，那它们很可能是被同一个根因影响的。那么，如果整体 IT 环境内的时间同步是可靠的，且监控指标的颗粒度比较细的情况下，我们就可能近似的推断：跟一个告警比较像的最早的那个监控指标，应该就是需要重点关注的根因了。

Oculus 截图如下：

这部分使用的 计算方式有两种：

欧式距离，就是不同时序数据，在相同时刻做对比。假如0分0秒，a和b相差1000，0分5秒，也相差1000，依次类推。

FastDTW，则加了一层偏移量，0分0秒的a和0分5秒的b相差1000，0分5秒的a和0分10秒的b也相差1000，依次类推。当然，算法在这个简单假设背后，是有很多降低计算复杂度的具体实现的，这里就不谈了。

唯一可惜的是 Etsy 当初实现 Oculus 是基于 ES 的 0.20 版本，后来该版本一直没有更新。现在停留在这么老版本的 ES 用户应该很少了。除了 Oculus，还有很多其他产品，采用不同的统计学原理，达到类似的效果。

归因分析之 Granger causality

Granger causality（格兰杰因果关系）是一种算法，简单来说它通过比较“已知上一时刻所有信息，这一时刻 X 的概率分布情况”和“已知上一时刻除 Y 以外的所有信息，这一时刻 X 的概率分布情况”，来判断 Y 对 X 是否存在因果关系。

可能有了解过一点机器学习信息的读者会很诧异了：不是说机器只能反应相关性，不能反应因果性的么？需要说明一下，这里的因果，是统计学意义上的因果，不是我们通常哲学意义上的因果。

统计学上的因果定义是：『在宇宙中所有其他事件的发生情况固定不变的条件下，如果一个事件 A 的发生与不发生对于另一个事件 B 的发生的概率有影响，并且这两个事件在时间上有先后顺序（A 前 B 后），那么我们便可以说 A 是 B 的原因。』

归因分析之皮尔逊系数

另一个常用的算法是皮尔逊系数。下图是某 ITOM 软件的实现：

我们可以看到，其主要元素和采用 FastDTW 算法的 Oculus 类似：correlation 表示相关性的评分、lead/lag 表示不同时序数据在时间轴上的偏移量。

皮尔逊系数在 R 语言里可以特别简单的做到。比如我们拿到同时间段的访问量和服务器 CPU 使用率：

然后运行如下命令：

acc_count<-scale(acc$acc_count,center=T,scale=T)

cpu<-scale(acc$cpuload5,center=T,scale=T)

cor.test(acc_count,cpu)

可以看到如下结果输出：

对应的可视化图形如下：

这就说明网站数据访问量和 CPU 存在弱相关，同时从散点图上看两者为非线性关系。因此访问量上升不一定会真正影响 CPU 消耗。

其实 R 语言不太适合嵌入到现有的运维系统中。那这时候使用 Elasticsearch 的工程师就有福了。ES 在大家常用的 metric aggregation、bucket aggregation、pipeline aggregation 之外，还提供了一种 matrix aggregation，目前唯一支持的 matrix_stats 就是采用了皮尔逊系数的计算，接口文档见：

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-matrix-stats-aggregation.html

唯一需要注意的就是，要求计算相关性的两个字段必须同时存在于一个 event 里。所以没法直接从现成的 ES 数据中请求不同的 date_histogram，然后计算，需要自己手动整理一遍，转储回 ES 再计算。

饶琛琳，目前就职日志易，有十年运维工作经验。在微博担任系统架构师期间，负责带领11人的SRE团队。著有《网站运维技术与实践》、《ELKstack权威指南》，合译有《Puppet 3 Cookbook》、《Learning Puppet 4》。在众多技术大会上分享过自动化运维与数据分析相关主题。 关于aiops指南和aiops理念的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 aiops指南的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于aiops理念、aiops指南的信息别忘了在本站进行查找喔。