Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1320599
  • 博文数量: 179
  • 博客积分: 4141
  • 博客等级: 中将
  • 技术积分: 2083
  • 用 户 组: 普通用户
  • 注册时间: 2009-03-21 20:04
文章存档

2024年(1)

2019年(13)

2016年(1)

2014年(16)

2011年(8)

2010年(25)

2009年(115)

分类: 系统运维

2024-08-16 11:56:37

当前,IT 基础设施的复杂性日益加剧,而与此同时,系统可靠性的高标准需求愈发凸显,众多系统需实现近乎不间断的 7×24 小时服务。企业普遍对关键系统设立了严格的服务水平协议(SLA)指标,这些系统的{BANNED}{BANNED}最佳佳低可靠性标准常设定为三个 9 的可用性,即全年故障时间不得超过 8.76 小时。鉴于此,迅速识别并定位根本故障原因(根因分析)变得至关重要。
然而,面对庞大且错综复杂的 IT 基础设施,加之多部门间的紧密协作需求,如何高效地进行故障定位成为了巨大挑战。这恰好是本课程探讨的核心议题:是否存在利用软件手段来加速故障定位过程的方法?如果存在,具体的实施策略又是什么?
在深入探讨之前,让我们先对根因分析进行简要概述,以确保我们的理解基础一致。

根因分析的难点

说到故障定位,特别是那种大故障,咱们心里压力山大不说,还得过五关斩六将。系统复杂得跟迷宫似的,硬件软件满天飞,找问题源头就跟捉迷藏一样难。监控数据倒是多,能看清系统里的一举一动,但处理起来也是头疼,得是那种经验丰富的工程师才能挑出关键信息。
跨部门合作吧,本来是个好事,可有时候专业术语满天飞,沟通起来跟打哑谜似的,费时费力不说。更别提那些不是真正原因的故障了,它们就像迷雾一样,特别是核心系统一出问题,连锁反应跟着来,告警信息多得跟乱码似的,想找到真正原因,简直比登天还难。
但话说回来,业务要跑得快,系统就得稳当当的,所以这就凸显出了根因分析系统的价值。

根因分析系统的设计目标

在讨论根因分析系统这一复杂系统时,为了保持视野的广阔与深度并重,我们可以暂时抽离于细枝末节的纠缠,转而从宏观层面出发,探讨其设计目标。
不同企业及其系统间的数据完备性存在着显著差异,这一差异直接影响了根因分析系统所能提供的分析结果类型与精度:
  • 确定性模型:在运维数据极为丰富且详尽,同时自动化运维水平达到高度成熟的场景下,企业往往期望根因分析系统能够充分挖掘并利用这些宝贵的数据资源,通过精密的算法与模型,输出准确无误的故障根因分析结果,以满足其对系统稳定性与可靠性的高要求。
  • 概率模型:然而,若面临运维数据严重缺失,或是运维平台尚处于初级阶段、功能较为基础的情况,则要求系统给出绝对准确的结果便显得不切实际。在这种情况下,根因分析系统通常会转而依赖历史故障案例与经验积累,运用概率统计等方法,为用户提供基于经验的、可能性的故障根因分析结果,作为决策参考。这种方法虽然不能完全确保结果的准确性,但在数据受限的条件下,仍不失为一种有效的应对策略。
在审视分析过程时,我们明确地识别出两大类应用场景,它们各自对信息的需求侧重点有所不同:
  • 结果导向型场景:在此类场景中,我们的关注点直接聚焦于{BANNED}{BANNED}最佳佳终的分析结果。以摄像头监控设备健康状态为例,这里涉及的是图像识别技术的应用。对于这类任务,用户更关心的是系统能否快速、准确地告知设备是否处于健康状态,而非背后的算法推理过程。简而言之,用户需要的是“是或否”的答案,而非算法如何得出这一结论的详细步骤。
  • 过程解析型场景:与结果导向型场景形成鲜明对比的是,某些应用场景下,用户不仅要求知道分析结果,还渴望深入了解导致该结果的具体原因和过程。以分布式系统的故障根因定位为例,当系统判断是死锁导致了数据库服务中断,并进而引发了一系列连锁反应时,用户不仅要知道故障的结论,更希望系统能够详细阐述为何是死锁造成的,以及这一故障是如何逐步影响系统其他部分的。这种场景下,系统的解释能力和透明度变得尤为重要。
在面对多样化的根因分析场景时,对故障根因分析的速度与响应时间有着不同的需求:
  • 实时分析场景:针对那些要求即时响应的紧急情况,如系统短时间内生成大量告警(如1000个告警)时,根因分析系统需具备极高的效率,力求在极短的时间内(如1秒之内)迅速定位出故障的根源,或将故障范围有效缩减至可管理的边界,以迅速恢复系统稳定并减少潜在损失。
  • 离线分析场景:然而,并非所有场景都适宜或能够执行实时分析。当面临海量数据处理、算法复杂度高或资源限制等挑战时,实时分析可能变得不切实际。此时,离线分析作为实时分析的有效补充,被广泛应用于此类场景。离线分析允许在不受时间紧迫性约束的条件下,深入剖析故障数据,尽管分析过程可能耗时较长,但能够提供更全面、细致的分析结果,为后续的系统优化与故障预防提供有力支持。

如果想对根因分析做进一步了解的,欢迎移步我在《极客时间》的专栏《智能运维之根因分析》。
课程介绍
随着时代的发展,现有的企业 IT
设施越来越庞大、越来越复杂。根因分析的定位,变得越来越难。由此引出了一个问题,是否可以借助人工智能技术,实现故障的智能定位?现在市面上关于根因分析的材料并不多,更多的是以论文的形式出现,都在探索不同的算法在特定场景下的效果。学术研究本来就应该百花齐放,但是工业界除了关心理论本身,更关心的是如何落地以及如何为企业带来效益。本课程以实际业务场景为出发点,结合产品、数据、工程、算法不同领域的专业知识,帮助大家全面的了解根因分析系统如何从实际问题出发,一步一步的实现智能化、自动化。
通过课程,你将会学到:
  • 算法原理:深入了解根因分析的基本原理;
  • 系统架构:深入了解根因分析系统的设计和实现思路;
  • 快速上手:课程在讲解原理的同时,提供翔实的配套代码,方便大家学习;
  • 前沿技术:了解目前业内关于根因分析的前沿技术;

根因分析系统的评估

在评估根因分析系统的效能时,我们可以从以下九个核心维度进行综合考量:
根因分析系统的核心评估指标:
  • 准确率:这是一个直观且关键的性能指标,它衡量了系统在执行根因分析时的精确程度。具体而言,就是评估在进行了100次根因分析任务后,系统能够正确识别出根本原因的比例。
  • 场景覆盖率:此指标用于评估系统对不同操作环境和问题类型的广泛适用性。它可以从两个子维度来审视:系统覆盖面:考察当前根因分析系统能够支持并有效分析哪些子系统的故障根源;故障类型覆盖面:分析系统能够处理并精确定位哪些类型的故障,比如性能下降、服务中断、数据异常等,这体现了系统对多种故障模式的覆盖能力。
  • 实时响应能力:每次故障发生后,能够在多长时间内精确识别出导致该故障的根本原因。这一能力直接关系到问题解决的速度和效率,对于维护系统稳定性和用户体验至关重要。
  • 多根因并发分析能力:在复杂的系统环境中,可能出现多个故障同时发生并相互交织的情况,如交换机与数据库同时遭遇故障,且各自触发了一连串的告警。此时,评估根因分析系统是否具备同时识别并区分这些独立故障根源的能力显得尤为重要。系统若能有效支持多根因分析,将极大地提升故障处理的全面性和准确性。
根因分析系统,除了实时、准确地分析出根因之外,还需要考虑系统本身的开发成本:
  • 不完全信息下的分析能力:评估根因分析系统的一个重要维度是其是否能在信息不全面的情况下依然能够输出有效的分析结果。这要求系统无需获取与根因相关的全部变量数据,即可进行推理分析。
  • 自动发现变量与根因关联:系统是否依赖预先设定的变量与根因之间的对应关系也是评判其智能程度的关键。某些高级算法,如因果图分析、频繁项集挖掘等,能够直接从数据样本中自动挖掘并揭示变量间的潜在关联,无需人工干预或预设规则,从而增强了分析的灵活性和准确性。
  • 鲁棒性与容错性:在工业应用中,根因分析算法必须具备高度的鲁棒性,以应对复杂多变的线上环境。由于线上告警可能由多种故障交织而成,且故障类型和发生时间均难以预测,因此算法必须能够有效区分不同故障信号,忽略噪声干扰,确保在复杂情境下仍能稳定输出可靠的分析结果。
  • 故障传播的不完全性处理:系统还需具备处理故障不完全传播情况的能力。即当某一故障(如A)影响多个组件(如B和C),但并非所有受影响组件的告警都能被及时捕获时,系统应仍能通过分析剩余信息(如C的告警),推断出故障的真正源头(A)。这种能力对于快速定位并解决隐藏故障至关重要。
  • 算法的泛化能力与适用性:评估根因分析算法时还需考虑其适用性和泛化能力。一个优秀的算法或解决方案不仅应在特定场景下表现出色,还应能在类似或相关的场景中灵活应用,减少重复开发和调试的成本,提高整体运维效率。
小结
好了,这就是今天的主要内容。{BANNED}{BANNED}最佳佳后我们一起来回顾一下。
  • 根因分析的难点:首先如果你的IT系统不够复杂,比如说只有几百台机器、百来个应用程序,那么完全没必要开发智能根因分析系统。智能根因分析系统,只有在大型、复杂的IT系统中,才能发挥出它应有的价值;
  • 根因分析系统的设计目标:我们分别从分析结果类型与精度、分析过程、分析实时性三个维度,探讨了分析系统的目标设定;
  • 根因分析系统的评估标准:如何评价一个系统的好坏,其实是开发系统要面临的{BANNED}中国{BANNED}中国第一个难题。在这里,我们给出了9个评估维度,包括4个核心指标:准确率、场景覆盖率、实时性、多根因分析能力;
阅读(89) | 评论(0) | 转发(0) |
0

上一篇:人工智能解决方案 --- 智能运维

下一篇:没有了

给主人留下些什么吧!~~