缩短MTTR:利用机器学习解决问题

对于性能监控战略来讲,在某些关键性能指标 (KPI) 超出IT应用和服务正常运行而能普遍接受的范围时,这些战略会利用阈值提醒操作人员,这种情况很常见。

为了更好地理解这一点,我们可以通过实例来说明:电脑上的应用程序开始消耗大量内存时,其他操作似乎会变慢。

尽管大部分用户并没有通过设置阈值和提醒来消除电脑变慢的问题,但企业级计算需要这种通知和其他许多方面,以保证IT以最佳的性能运行。设想一下:在一个应用程序耗尽您的电脑内存时,您的体验非常差,而数千用户接入一个耗尽大量服务器内存的应用程序时,情况更糟糕。如果IT人员在超出阈值时能够收到问题提醒,他们希望实现最快的问题修复时间 (MTTR)。

服务热线场景

我们致电银行或医疗服务提供商的服务热线时,客户服务专员经常会说:“我的电脑今天运行速度比较慢。”他或她需要接入企业系统内的一个或多个关键任务应用。IT环境中导致您的服务请求处理速度缓慢的某个部件会对他们产生某种影响。服务处理速度缓慢和不良体验可能迫使您考虑其他选项。如果数百或数千客户有这样的不良体验,情况会如何呢?

该客户服务专员将服务单输入到运行速度缓慢的应用中,而且系统也根据一个或多个导致服务热线用户体验不佳的情况而发出提醒。

复杂性

这些问题之所以变得异常复杂,原因是企业级应用性能在传统架构和高度分布式的现代化微服务环境中的Web服务器、应用服务器和数据库服务器的所有层都需要最高的性能。对大多数企业来说,关键任务应用的复杂性涉及到数据中心、私有和公有云,甚至其他提供商的代理服务。如果应用不能平滑地运行,企业就会面临着利润、生产力、甚至品牌忠诚度损失。

如果IT运营人员每次在性能测量指标达到阈值时(甚至短时),对这些告警进行管理可能是异常噩梦。这种问题对最终用户体验可能没有严重或持续影响。但是,这种情况难以非常有效地处理。

因此,现代IT运营解决方案提供了除基本监控之外的其他能力,可降低与事件风暴相关的干扰。

机器学习与分析能提供什么帮助

多种机器学习和分析方法并非依赖静态阈值,而是根据优先级和影响而解决问题,从而缩短MTTR:

行为学习—采用机器学习的基准值和阈值组合确定什么时候有可能变成问题。只有衡量结果超出正常基准数据并且高于您指定的关键性能阈值时,您才会收到通知。一个典型的场景是预期使用量在一天或一周的最开头比较高。支持应用的服务器的CPU利用率在每星期一早上9 点至10 点可能达到峰值。

例如,您设置的CPU利用率绝对阈值为80%—一般视为应开始关注的服务器性能的合理值。如果根据学习到的85 – 95%的基准值,利用率达到90%,您不会收到告警。然而,如果在一周内的另一个时间,在基准值设置为65 – 75%时,利用率达到90%,您会收到需要处理的告警。对于第一种情况,实际利用率未超过阈值,也没有超出学习到的基准值。在第二种情况下,实际利用率超出正常值,并且高于绝对阈值。

这有助于您首先处理最重要的问题。

预测性事件—采用每小时基准数据和关键阈值的组合,在测量结果即将达到关键阈值时(一般是三小时),收到告警或事件通知。机器学习提供了每小时基准数据,而且您可以设置关键阈值。在测量结果开始超出阈值但尚未达到关键阈值时,您一般会收到警告信息。如果未及时采取措施,性能可能受到严重影响。

您的IT团队成员可能对配置进行更改,这会在峰值时段意外耗尽某种资源。预测性事件让您有充足的时间解决问题,而用户甚至不会注意到问题的发生。

可能原因分析—在解决问题时,采用一种流程分析数据并显示所有的相关事件和异常。在复杂的IT环境中,一般有多个因素可能影响应用或服务的性能。通过让系统缩小问题可能原因的范围,IT运营人员可以更快地确定问题的根本原因。需考虑的相关事件根据它们与初始事件的关系、时间范围、通过行为学习而获取的异常事件而进行排列并显示。

如果环境中服务器的处理器时间超出正常值并且与内存问题相关,您会收到告警。由于内存达到峰值,服务器未能快速对数据请求做出响应。通过解决内存问题,处理器时间重回正常水平。

模式匹配—几乎不需要提前计划,您可以将环境中可能发生问题的场景确定为知识模式,这样,以后出现的问题可以更快地予以解决。对于前例中的处理器时间和内存问题,您可以创建一种知识模式,在处理器时间和内存出现问题时,您能够识别需要处理的关键基础设施。您可以收到可能原因事件的通知,而不必重新进行可能原因分析。

如果处理器时间异常高,但内存没有问题,您可以进一步调查其他问题。

日志分析—通过将机器学习能力应用到大量日志文件的分析中,系统可以设定正常日志条目的基准。这意味着系统将学习哪些条目“正常”。无论与模式相符的日志条目数量何时由于异常数据量而发生变化,您则可以快速识别IT环境中的问题。

这种情况被认为是“超限”异常。这一问题的发生频率远高于或者远低于正常情况。如果突然有大量用户接入机器(以前从未这样),或者对于相反情况,大量用户不像以前那样接入机器,这一能力尤其有用。有些与接入列表 (ACL) 相关的配置变更需要您处理。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,980评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,178评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,868评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,498评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,492评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,521评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,910评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,569评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,793评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,559评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,639评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,342评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,931评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,904评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,144评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,833评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,350评论 2 342

推荐阅读更多精彩内容