智能运维相关事件案例分享（智慧运维的案例让我们明白）

本篇文章给大家谈谈智能运维相关事件案例分享，以及智慧运维的案例让我们明白对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享智能运维相关事件案例分享的知识，其中也会对智慧运维的案例让我们明白进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、银行在数字化转型路上面临什么问题？
• 2、小米唐沐等大咖精心挑选的100个年度研发案例实践
• 3、智能运维是如何抑制告警风暴的？
• 4、智能运维现在在企业中的用例有哪些？
• 5、智能运维适合哪些场景？都涉及哪些领域？
• 6、IT运维平台算法背后的两大“神助攻”

银行在数字化转型路上面临什么问题？

1.信息不对称：直接导致信贷业务领域内的诈骗、套取资金、捋羊毛、盗用身份等欺诈行为层出不穷；
2.系统开发周期长：因为模型、经验都需要长时间积累，所以风控相关的试错成本太高，而市场环境瞬息万变，慢人一步，市场占有率就会大大降低；
3.授信客群数量庞大：如果单纯依赖线下方式对海量用户进行审核，就必须通过无限扩张来完成大量贷前贷后线下风险管理工作。
如果想进一步了解数字化转型，可以去中大咨询，记得是做这方面的业务的。

小米唐沐等大咖精心挑选的100个年度研发案例实践

2017年，机器学习、大数据、人工智能等词汇成为软件研发行业的主流，大前端、DevOps、区块链等技术方式成为热点方向；2017年，智能硬件开始成为新的焦点，这一年更被称为智能音箱井喷的一年；2017年，互联网更快速地发展，要求一切都变得更快，工程效率、交付速度、创新速度。还有软件重构、云平台搭建、多活改造、数据变现、大数据转型……
11月9-12日，北京国家会议中心， 第六届TOP100全球软件案例研究峰会 。4天时间，洞察100位技术带头人所思所想的案例实践。

2017年TOP100summit依旧是5个专场同时并行，15个话题方向全面展示软件研发全生命周期各个维度的实践和解决方案。

专场一：体验设计/产品创新/运营驱动

精选案例

●《Balancing Creativity and technology to make innovation product》

Ruthia He ——Facbook Product Designer

案例价值：设计过程就像一场需要在产品目标、技术实现、创意发挥、用户体验之间不断探索寻找平衡的旅程。在紧张的资源中纵横捭阖是一种艺术，举例来说，你需要时刻提醒自己你的产品目标是什么，但实现产品目标的技术实现资源很可能一直不足；又或者设计师的灵感催生了一项独特的创意，但是这种创意却不一定能被所有人接受。本案例将以讲师在硅谷的产品设计经验为内容告诉大家如何找到产品设计的「完美平衡点」。

●《“一元购画”背后的设计思考》

陈晓畅——腾讯用户研究与体验设计部设计中心总监

案例价值：8月29日，朋友圈被一幅幅出自“小朋友”之手的美丽画作所刷屏。短短半天时间，580万人次参与，筹得善款1500余万。互联网已经在改变我们的公益事业。科技连接信任，为公益做设计，那么怎样做才会有更好的效果，本案例会复盘整个传播事件，带大家去看“一元购画”背后的设计思考，同时结合设计团队在对腾讯公益10年的设计支持中的经验，探讨如何用服务设计为公益创造更多的价值。

●《揭开人工智能终端的时代——天猫精灵的思考和定义》

茹忆——阿里巴巴人工智能实验室（A.I.Labs）智能终端负责人

案例价值：天猫精灵的问世代表着阿里巴巴对人工智能时代下智能终端的思考和探索，智能终端在完善用户体验、降低使用门槛的同时也意味着终端生态的封闭加强。人工智能时代相对封闭的生态意味着厂商想要提供优质的服务体验，不通过终端很难完成，而未来云端一体将成为大势所趋的新格局，本案例思考在这样的趋势下如何利用自身优势定义和落地终端产品。

●《用户至上--从智能家居终端的战争中脱颖而出》

陈亚——Amazon 资深工程师

案例价值：智能家居的终端作为智能家居的入口，是各大巨头抢占市场的主要阵地。那什么让亚马逊一个零售业起家的电商从这场战争中脱颖而出，以压倒性的优势，占据终端市场70%的份额? 本案例将以Echo产品为例，从产品设计及开发管理模式两大方面来分析，亚马逊是怎样将Customer Obession深入到产品的各个阶段，压制了以技术见长的Google。同时本案例也对目前国内的智能家居终端做一个探索性的分析。

●《滴滴新业务背后的增长抓手》

李森——滴滴 增长负责人

案例价值：本案例将讲述分享者自2015年加入滴滴后，先后负责的顺风车车主拉新、巴士产品用户增长、小巴产品冷启动、快车重庆区县业务等从0-1的增长型业务的思考和实践，从增长的逻辑展开，通过复盘业务介绍给大家一些屡试不爽的增长抓手，介绍滴滴快车、小巴等业务从0到1冷启动项目如何解决增长问题，如何解决场景内最后一公里的交通问题。

专场二：工程文化/团队增长/绩效考核

精选案例

●《The Science behind Art - Five Years Journey of Data Team at Riot Games》

李仁杰——Riot Games Head of Data

案例价值：本案例以Riot Games数据团队五年的心路历程为主线介绍如何从零到有建立一支国际一流的大数据团队, 每年团队的工作和vision如何成长和进化，以及这其中的收获和走过的弯路。以每年精选一个case study为副线，介绍全球最受欢迎的游戏《英雄联盟》是如何用数据来提高玩家的体验，支持和帮助公司每一个部门的商业决策和运营计划，以及如何用机器学习和人工智能来颠覆传统的产品。

●《Google如何利用OKR帮助团队挑战不可能的任务》

Zhouzhou He——Google 产品经理《从传统项目转型敏捷，你只需要两天》

案例价值：Google作为世界顶尖的科技公司之一，挑战了许多在之前看来不可能完成的高精尖任务，比如AlphaGo围棋，谷歌翻译，自动驾驶汽车，Tensorflow，TPU等。Google是如何组织和激励团队的？又如何确保团队齐心协力，向同一个方向冲刺？本案例来自于Google现任美国总部产品经理的第一手体验。他会从机制、人文、流程、决策方法、产品方针以及公司组织等多方面，分享Google的管理成功之道。

●《华为百人团队精益看板演进变革之路》

陈军——华为敏捷精益专家

案例价值：面对市场需求的激增及快速变化，研发团队需要灵活应对快速响应，并在有限的人力下提升研发效率，决定引入精益看板能有效帮助提升研发效率。本案例讲述华为百人团队精益看板演进变革的历程，从建立看板（四个实践）到运作看板（四个实践），取得小胜利，再到团队遇到困局，停滞不前甚至倒退，面对困局同团队一起再审视改进，重新走上了正确的道路。

●《从传统项目转型敏捷，你只需要两天》

古月——平安科技高级敏捷教练

案例价值：敏捷转型不仅是应用一套新的流程，而是要改变人的思维方式和工作方式，甚至改变企业的组织架构。转型是否有捷径可走？平安科技两天的Quick Start工作坊又是如何成为从传统轨道切换到敏捷轨道的有力扳手的？本案例将一一为您揭晓。

●《非典型敏捷：10天一个版本》

左杨眉——：中兴通讯 敏捷教练

案例价值：“快”是相对的。传统的电信领域仍然坚持严格的加法规则和安全要求，遵循基本的“需求-实现-发布-升级”的流程。本案例从重新梳理用户价值出发，引入过程交付物的概念，实现了客户的深度参与和快速反馈；重新审视典型敏捷流程的核心实践，基于“快速验证客户的产品假设”这一目标，去掉自动化测试和持续集成等实践，引入以手绘为中心的低保真交付，引入数据模拟和切面功能。某种程度上，本案例是对《设计冲刺》在电信领域的一次加长版交付项目实战。

专场三：架构演进/工程实践/大前端

精选案例

●《618大促网关承载十亿级的调用量背后的架构实践》

王栋 京东 京东商城开放平台总架构师

案例价值：每年618大促京东商场开放平台在保证近千个不同类型服务接口的海量调用的同时，还要确保服务接口之间的互不干扰，并且能够快速响应任何复杂情况。稳定、快速是一直追求的目标。本案例将分享实践过程中常用的隔离技术、缓存技术、SQL优化、降级限流等方法。学习京东团队如何将这些技术应用到每一次的备战中，确保了每一年的618平稳度过。

●《深圳证券交易所新一代交易系统架构转型之路》

喻华丽——深圳证券交易所 总工程师

案例价值：处于行业核心地位的业务系统对持续平稳运行有着严苛的要求，如何对这些核心业务系统进行升级换代以满足业务发展和技术进步的需要，是很多CIO及其研发团队所面临的难题。本案例分享了深圳证券交易所在核心系统特别是高可用高性能的实时处理系统，实施去IOE、走向开放平台开源技术、分布式处理、高可用低时延设计的架构转型、平稳升级的成功经验，分享如何在这种全面重构的架构转型中确保安全平稳升级、并同时带领全市场平稳升级。

●《饿了么整体服务异地多活改造》

李双涛 饿了么 中间件团队首席架构师、异地多活项目总架构师

案例价值：本案例描述了饿了么的异地多活改造，从设计到正式上线的过程中，做的各种取舍，以及如何协调业务团队，和中间件团队的工作，安全而平稳的改造整个业务，使业务从一个单机房的服务，变成多机房多活的服务。当发生机房级故障的时候，服务方可以把用户路由到健康的机房，保证在故障发生时，业务可以正常执行，减小机房级故障带来的巨大损失。

●《Uber for Business, 从0到1健康医疗数字化转型中的微服务创新实践》

时晓宇——Uber Tech Lead

案例价值：本案例将分享如何从0到1实现一个高可用的系统，解决实际的Uber for Business业务问题。通过具体的项目需求和系统架构，包括支付系统，账单系统， Policy系统来分析如何end to end完成这些系统。如何完成从0到1的过程，短短两年成为Uber一个非常重要的业绩增长点。同时，从一个6人的工程师团队发展到近40人。

●《小米直达服务平台与移动端服务未来形态探索》

董红光——小米MIUI系统框架负责人团队主管

案例价值：移动端服务目前的承载形式，无论是应用还是网页，都有着一些不足之处，导致用户使用起来不方便，同时对开发者自身也有一定的影响。如何更加高效的分发和使用服务，是行业中非常关心的一个话题。小米在这个领域也做了一些探索，推出了直达服务这样的技术平台，旨在解决传统应用和网页承载服务的情况下存在的一些问题，提高用户和开发者各方的效率。本案例主要围绕小米直达服务平台，聊一聊小米在这一块的思考和目前的一些实践成果。

专场四——数据科学/人工智能/数据驱动

精选案例

●《美国NFCU银行如何利用大数据AI开启转型之路》

江晓东——NFCU 金融数据架构师

案例价值：美国NFCU银行是家财富200强企业，到2016年底，已在全球拥有280个分行，资产超过 7千4百亿美元，全美拥有6多万会员（客户）, 全球雇员1万4千人。 如何管理体量如此庞大的全球线下各分行，ATM机每日的现金流，整合总部与分行，分行柜台与顾客，顾客与ATM机间的现金存储，转账，提取等交易额，决定着银行与运钞车，央行以及银行内部的结算和现金流监管管理成果和效率。此案例为大型传统金融企业实施大数据和AI项目开辟了一个非常有意义的案例，将分享NFCU银行运用大数据和人工智能算法解决企业现金流管理的方法和途径。

●《人工智能时代，二手交易平台的智能推荐系统如何演进》

孙玄 转转 架构算法部负责人

案例价值：转转的推荐系统从0开始打造，针对业务的不同阶段，一步步发展演进。在发展的过程中经历了全局无个性化推荐阶段、个性化离线推荐阶段、个性化实时推荐阶段、机器学习排序推荐阶段等。本案例会详细讲解不同发展阶段的原因、架构的演进，让听众对二手交易平台的智能推荐系统能够深刻认识。

●《先知：人工智能助力Fintech反欺诈让黑产无处遁形——大数据和人工智能如何助力风控防御体系》

王婷——宜人贷 数据科学家

案例价值：先知是基于宜人贷的反欺诈云平台，面向Fintech全行业的一种反欺诈解决方案，以强大的金融数据能力、反欺诈智能和线上客户获取服务能力，帮助Fintech企业解决在信贷申请欺诈、金融中介识别、团伙监控/预警上面临的一系列问题，为金融科技企业提供更强大的信用评估、风险控制和精准获客。本案例将分享在反欺诈云平台的构建过程中，如何利用人工智能实现以上功能。

●《线上到线下场景中机器学习和统计建模的一些应用》

张健——3M 数据科学技术负责人

案例价值：线上到线下是未来发展的重要趋势， 数据发掘和机器学习已经广泛成熟运用到线上软件开发，推荐匹配， 用户分析等等方面。然而线下和线上的数据融合，优化才刚刚开始。本次分享将从线上到线下零售的具体案例中通过建设线上到线下数据反馈与优化系统，将A/B 测试，深度个性推荐，加强学习等统计与机器学习方法运用其中，达到提高数据分析效率，了解用户行为，增加线下收入等一系列具体的目标。

●《联想大数据助力联想业务转型升级》

于辰涛——联想集团 大数据事业部高级总监、首席研究员

案例价值：以数字化转型为驱动的第四次工业革命已经开始，它开启了一条大数据、云服务与智能技术并行的新航路。企业也赢得机遇的同时也面临很多难题：企业内各个系统数据无法共享，数据区块化现象严重，直接导致企业采购、生产、物流、销售等环节效率降低。本案例分享联想如何在成本可控的前提下，借助大数据、工业互联网4.0、中国制造2025的契机，解决上述问题，借着风势得到一个快速的发展。

专场五——质量管理/智能运维/DevOps 专场

精选案例

●《无人测试如何助力京东提升产品测试效率与质量》

杨瑾——京东 B2B产品质量团队负责人

案例价值：随着业务的发展，系统通常会经历单体式，服务化，平台化的过程，在系统持续演进的漫漫长途中，不管是小需求，还是大改动，每一次的上线都伴随着大量的回归工作，即使是经验老道的测试老司机也没有100%不出问题的信心。在迭代周期短，发版频率高的互联网行业，产品质量的如何在频繁的上线中，保证产品质量，提升用户体验是我们一直在努力探索和实践的。本案例讲述了一种高效的回归测试方法以及此方法在提升产品测试效率与质量方面的实践。

●《阿里移动DevOps实践》

陆义元 阿里巴巴 平台产品负责人

案例价值：移动开发模式已经进入两级分化：超大规模APP的研发模式偏项目式，研发协同的人员、模块较多，需要完整的构建、测试、发布、运维等DevOps体系；而一些创新、试验类的APP在商业模式和业务形态未完全确定的情况下，更适合以较快的方式来测试和验证业务的想法，所以以最低成本快速创建一个 APP 就是当务之急。本案例将分享阿里移动技术在过去几年如何沉淀和解决这些问题。

●《以Kafka为例的大规模有状态集群优化方法探索》

秦江杰 LinkedIn Staff Software Engineer

案例价值：分布式系统的动态负载均衡和自我管理始终是一个不太容易解决的问题。大多数解决方法是迁移整个应用进程来实现硬件资源的负载均衡，这种方法对无状态应用较为适用，但对于有状态集群（如Kafka）并不十分有效。因为迁移应用意味着大量状态的迁移，这是一个漫长又昂贵的过程。LinkedIn为解决这一问题开发了Cruise Control，其主要特点是可以根据应用的特点进行部分状态的迁移。本案例将通过对Cruise Control实践的解读，分享一套大规模有状态集群优化方法。

●《低成本实现系统接口测试--自动化、性能、持续集成线上监控》

九毫 大疆 测试开发工程师

案例价值：在大多数公司和项目中都存在对系统接口进行自动化测试、性能测试、持续集成、线上监控的需求。但现有方式都存在投入产出比低的问题，工具和技术栈多且杂，维护成本和学习成本居高不下。针对这一普遍存在的痛点，大疆探索出一种低成本的最佳实践方案，并将其沉淀为一款开源的接口测试框架 ApiTestEngine。本案例将拆解这一框架的技术要点和实现原理。

●《运维智能化@Pinterest》

孟晓桥——Pinterest 监控部门经理

案例价值：运维智能化是所有基于云计算的公司未来趋势。PINTEREST作为一个大型图片分享平台，后台的计算平台和软件架构非常庞大而复杂，如何用最少的人力和资源成本保证高质量的运维，是一个巨大的挑战。为此，我们监控部门搭建了一套集成式的监控平台，该监控平台高伸缩性、集成式、智能化三大特点，本案例将通过分享该监控平台，提供运维运维智能化方面的实践上的探索。

以上为部分精选案例展示，更多TOP100案例信息及日程请前往 [官网] 查阅。4天时间集中分享2017年最值得学习的100个研发案例实践。本平台共送出10张开幕式单天免费体验票，数量有限，先到先得。 免费体验票申请入口。

智能运维是如何抑制告警风暴的？

通常智能运维中的告警收敛场景，以机器学习算法为驱动，对海量的告警事件进行降噪和关联分析，辅助根因定位并可沉淀故障处理的知识，从而提升企业的运维效率，降低运维成本。 告警产生后，AIOps系统通过算法甄别 内容相关性（重复性、相似性）、时序相关性和拓扑相关
性 事件来进行告警事件的自动化抑制。这类收敛抑制，往往能得到99%的告警压缩率，极大地提高了告警有效性。

在一个完整的智能运维告警产品里，除了告警收敛，还可以基于故障传播链及拓扑信息 ( 可选 ), 智能发现突发故障场景；基于告警“熵值”算法，实现告警的动态优先级推荐；通过时序以及拓扑关系定位故障场景根因，并进行根因标记。当这些都可以完成时，由告警事件一步步引导的根因定位和排障，才是真正智能运维发挥了作用。

智能运维现在在企业中的用例有哪些？

我了解到智能运维现在还处于概念阶段，还远没到成体系的阶段，但一些提前布局的企业确实已经产生了一些用例并且应用在企业IT运维服务上，比如博睿数据的动态基线和根因分析。
感觉这是万里长征刚刚开始，任重道远，不过不积跬步无以至千里，企业需要从基础的数据资产沉淀开始做起。

智能运维适合哪些场景？都涉及哪些领域？

当代社会的生产生活，许多方面都依赖于大型、复杂的软硬件系统， 包括互联网、高性能计算、电信、金融、电力网络、物联网、 医疗网络和设备、航空航天、军用设备及网络等。这些系统的用户都期待有好的体验。 因而，这些复杂系统的部署、运行和维护都需要专业的运维人员，以应对各种突发事件，确保系统安全、可靠地运行。由于各类突发事件会产生海量数据，因此，智能运维从本质上可以认为是一个大数据分析的具体场景。

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》。在众多技术大会上分享过自动化运维与数据分析相关主题。 关于智能运维相关事件案例分享和智慧运维的案例让我们明白的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 智能运维相关事件案例分享的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于智慧运维的案例让我们明白、智能运维相关事件案例分享的信息别忘了在本站进行查找喔。