跳到主要内容

标准化排障之路:内核行为可观测性应对标准化排障落地难题

· 阅读需 10 分钟
Kindling-OriginX
故障根因推理引擎

标准化排障之路:内核行为可观测性应对标准化排障落地难题

在当今快速发展的互联网时代,企业对于IT系统的依赖程度越来越高,系统稳定性成为企业持续发展的关键因素。为了提高系统稳定性,企业纷纷寻求标准化排障的方法。然而,在实施标准化排障过程中,企业往往会遇到一些落地难题。本文将探讨如何应对这些难题,推动标准化排障的落地,并提出以实现内核行为可观测性的方式来应对标准化排障落地的难题。

标准化排障之路:内核行为可观测性应对标准化排障落地难题

标准化排障的意义

排障流程的标准化是指将故障处理的各个环节规范化、流程化,以确保在面对系统或服务故障时,团队能够快速、有效地采取行动。同时能够最大限度减少因人员经验和技术水平差异导致的故障差异化问题,使排障流程能够可评估、可管理、可执行、可解释,改变依赖团队个别专家的窘迫局面,快速对齐团队人员排障处置能力。更多关于排障标准化的讨论可以参见#标准化排障系列文章

为什么标准化排障难以落地

标准化排障之路:内核行为可观测性应对标准化排障落地难题

标准化排障虽然具有重要意义,但在实际中却很难真正落地,企业中也更多的是以制定组织层级的故障响应联动机制为主,或者规范人员和资源的协调机制。对于具体故障定位和分析的方法难以做到标准化和规范化,具体深度分析解读可参见文章

最佳实践解读:互联网公司线上故障标准化排障流程

标准化故障根因定位应该怎么做

究其原因主要有以下几个方面:

存在观测盲区和孤岛,缺少穿针引线能力

目前大部分可观测体系建设后,仍存在很多可观测盲区和数据孤岛,各个工具各自为战,缺少将这些工具和数据串联起来的能力。

依赖专家经验和能力

目前排障过程中更多依赖参与处置人员的经验和综合能力水平,使得个体或单一团队的处置经验无法短时间传递到其他个人或团队,排障模式无法复用。导致即使制定排障的标准化流程也难以实施。

使用可观测性数据和工具的能力不一

业务开发团队、运维团队、容器团队等对于可观测性工具和数据的熟悉程度不同,对于相同指标的理解也有差异,使得即使建设了可观测性体系也无法直接进一步做到标准化排障。同时对于一些指标的含义长时间不使用也会生疏,这也使得故障发生时需要查阅资料。

工作量大,难以规范统一

以 Trace 数据为例,对其进行人工分析工作量巨大,所以往往也无法直接制定以人工分析可观测性数据为基准的标准化排障流程。

可观测性建设成熟度有差异

各个企业在可观测性建设、团队技术能力、组织协调水平上都有巨大的差异,这导致业内一些企业的优秀方法论难以在其他企业内部得到落地推广。例如一些公司花费巨大的人力、物力成本进行可观测性数据的指标治理,对可观测性数据进行自动化分析,但这种方式对于团队技术能力、企业重视程度都有很高要求,往往不具有普适应。

应对标准化排障落地难题的策略

标准化排障之路:内核行为可观测性应对标准化排障落地难题

针对上面种种困难和挑战,工业界和学术界都在不断寻找对应策略。Kindling-OriginX 基于 eBPF 实现内核行为可观测性,穿针引线联动网络、Trace、日志、系统指标等各种相关数据,构建一体化的可观测能力,使可观测性数据的价值能够充分发挥,进而能够落地根因推导、标准化排障等高阶能力。

标准化排障之路:内核行为可观测性应对标准化排障落地难题

Kindling-OriginX 实现标准化排障的关键路径具体来看主要是:

利用 eBPF 技术穿针引线,真正实现可观测

基于eBPF内核行为可观性数据,穿针引线联动应用可观测性数据,网络可观测性数据,日志可观测性数据,最大化可观测性数据价值,增强各个工具普适能力,真正实现可观测。

内核行为可观测性,消除盲区

通过 eBPF 和自动化Tracing 分析,将内核行为与上层业务调用关联,消除盲区的同时不遗漏任何异常数据。直接给出问题结论,自动关联问题数据相关指标、日志数据并对其进行下钻,通过结论即可进行故障预案执行或定界交接。

无缝融入当前体系,模拟并优化了人工排障步骤

智能化、自动化的标准化排障流程实质上是模拟并优化了人工排障步骤,融合专家知识和相关数据。一方面消除用户排障过程中的心智负担和学习成本,另一方面轻松融入现有可观测体系,与企业现有工作流程结合实现标准化。

简化的操作界面

为所有技术水平的用户提供易于理解和操作的界面,降低使用门槛。直接根据故障结论进行预案执行。通过平台能力为操作者赋能,使其最短时间内就能参与到复杂故障的处理中。同时,无论业务团队、运维团队、容器团队等都能快速上手利用其解决各自关切问题。

排障知识库

既是内核可观测性产品,也是一个排障专家经验知识库,借助专家经验知识库平台能力能够迅速提升团队能力,最大程度消除人员经验和能力差异性。

小结

标准化排障之路:内核行为可观测性应对标准化排障落地难题

标准化排障具有重要意义,但在实际操作中却往往难以落地,更多依赖专家经验和个人能力,难以复制和标准化。Kindling-OriginX 通过 eBPF 建立内核行为可观测能力,穿针引线联动应用可观测性数据,网络可观测性数据,日志可观测性数据,为标准化排障的落地提供了一条可行之路。

标准化故障根因定位应该怎么做

· 阅读需 10 分钟
Kindling-OriginX
故障根因推理引擎

故障注入是检验可观测性建设成熟度的有效方法

在现代软件开发和运维中,故障的及时响应和有效解决是确保服务稳定性的关键。然而,由于技术环境的复杂性和多样性,故障的根因定位往往是一项耗时且充满挑战的任务。为了提高故障处理的效率和准确性,标准化故障根因定位的方法和流程显得尤为重要。本文将探讨为什么需要标准化故障根因定位,以及标准化故障根因定位应该怎么做。

为什么故障根因定位需要标准化

故障注入是检验可观测性建设成熟度的有效方法

标准化是提高工作效率和质量的基础。在故障根因定位中,标准化意味着建立一套统一的流程和方法,使得不同的人员在面对相同或类似问题时,能够按照既定的路径进行调查和分析。标准化有助于减少因个人经验差异导致的定位错误,消除这些差异导致的沟通障碍,提高故障处理的效率,同时也有助于知识的积累和传承。

1. 一致性和可复现性 标准化流程确保了每次故障排查时,都能按照相同的步骤进行,减少了因个人差异或方法不统一导致的排查结果不一致性。

2. 提高效率 标准化流程可以帮助排查人员快速定位问题所在,而不是从零开始,浪费时间在重复工作上。

3. 减少人为错误 人工排查过程中可能会因为遗忘、疏忽或操作不当导致错误。

4. 知识积累和传承 标准化的流程可以将专家的经验和知识固化成流程和工具,使得非专家人员也能够按照这些流程进行排查,从而传承和积累排障知识。

5. 持续改进 标准化流程便于统计和分析故障数据,有助于发现常见的故障模式和瓶颈,从而不断优化流程,提高排障效果。

6. 跨团队协作 在大型组织中,不同团队可能需要进行故障排查。标准化的流程有助于不同团队之间的协作和沟通。

7. 培训和验证 标准化的流程可以作为培训材料,帮助新员工快速上手。同时,也可以作为验证排查结果的标准,确保排查结果的正确性。

目前现状及问题

故障注入是检验可观测性建设成熟度的有效方法

目前,故障根因定位通常依赖于工程师的个人经验和技能。虽然有一些通用的排查步骤和工具,但往往缺乏统一的标准化流程。这导致在处理复杂故障时,不同工程师可能会采取不同的方法,有时甚至会导致重复劳动和资源浪费。此外,由于缺乏标准化,故障处理的经验和知识往往难以被有效记录和共享,从而影响了整个团队的学习和成长。

尽管当前AIOps技术取得了显著进步,业内也出现了许多优秀的AIOps工具,为解决故障根因定位提供了新的思路和方法,但AIOps系统虽然能够推荐可能的故障根因,却往往难以直接将这些推荐与具体的可观测性数据紧密关联。这就要求运维人员依靠自己的经验和知识,在海量的数据中寻找证据来验证这些推荐,这一过程既耗时又容易出错,也让故障根因定位工作再次回到了依靠个人经验和能力的老路上。关于AIOps的讨论,可参考文章:AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

典型人工排障步骤

典型的故障根因定位步骤包括:

  • 根据Tracing数据,查看一定量的Trace识别可能的异常服务点。人不可能分析所有的Tracing,所以这个步骤可能漏掉关键异常服务点,导致排查功归一篑。

  • 根据Tracing数据得到异常服务点的相关Span数据,遇到SPAN简单的问题,立马判断出故障根因。但是SPAN信息反映不出问题,继续下一步。

  • 根据经验查看异常服务节点相关告警,一一排查是否是根因,同时结合指标和日志进行确认。如果是上游节点受到下游故障的级联影响,在上游疑似节点很可能排查不出来任何真实有效的故障。如果公司对指标没有治理,完全是大海捞针式的找异常指标不现实,公司如果对指标进行了治理,分层,分成基础设施指标、网络指标、应用指标、中间件指标等,排障过程会快点,但是仍然需要一定的运气。

Kindling-OriginX 如何做的

Kindling-OriginX 将上述人工排障的典型步骤智能化、自动化统一为标准化的排障流程。

  • 通过对接Tracing数据,分析Tracing,识别Tracing的异常服务节点。

  • 采样异常服务节点,通过eBPF获取的北极星指标排障体系给出故障根因。

  • 在识别出异常服务节点的根因之后,关联相关日志和指标证明这次根因结论。

这个过程完全是模拟人排障过程,但不是简单的再现了人工排障的步骤,而是融合了专家知识和相关数据,实现了自动化与智能化的提升,从而在效率和准确性上显著超越了传统的人工排查方法。

故障注入是检验可观测性建设成熟度的有效方法

总结

故障注入是检验可观测性建设成熟度的有效方法

标准化故障根因定位是提高服务稳定性的关键。标准化流程能够确保故障排查的一致性和可复现性,提高效率,减少人为错误,并促进知识的积累和传承。当前,故障根因定位往往依赖于工程师的个人经验和技能,缺乏统一的标准化流程,导致处理复杂故障时存在重复劳动和资源浪费的问题。Kindling-OriginX 通过智能化、自动化的标准化排障流程,模拟并优化了人工排障步骤,融合专家知识和相关数据,实现了效率和准确性的显著提升,为解决故障根因定位问题提供了新的思路和解法。

棘手的级联故障

· 阅读需 8 分钟
Kindling-OriginX
故障根因推理引擎

已经使用很多可观测性工具,排障为什么仍然难?

在 Google 提出的SRE理念中,依据运维黄金指标是容易判断业务正常与否的,但是业务异常了,如何找到根因却是当前比较艰难的任务。

对于为什么排障难,不同角度能够得到不同的结论。本文主要从技术角度来谈谈为什么排障这么难?

各种可观测性工具 Traces、Metrics、Logging 的使用对于排查简单的问题确实比较有用,依据专家经验是能够做到快速排除故障的。

现在比较棘手的难题是出现一些级联的故障,也就是当业务出现异常的时候,各种异于平常的指标告警很多,即便在专家在场的情况下,依次排查每个告警仍然需要消耗非常多的时间。特别是在现代服务系统架构中,拓扑结构复杂,各服务间互相依赖,同时系统中存在着各类中间件,这些都使得大型业务系统中的故障往往都表现为级联故障,而且更加难以快速定位排障,在这种情况下,想要落地 1-5-10 是非常难的。

传统运维观念中为什么要设置不同种类的告警?

很多告警都是在踩坑中得到的经验教训,当业务异常之时,如果没有告警也就没有线索,不知道该往哪个方向排查。所以在传统排障理念中,告警提供了排障线索。

随着业务复杂化,踩得坑越来越多,告警规则以及各种类型的告警也变得越来越多。 在这种前提发展之下,实际生产中就会陷入左右为难的困境,不设置告警就没有了线索,或者缺失线索。但是告警过多又会带来很多干扰,产生告警风暴、埋没根因等问题,同时在一定程度上也会导致 OnCall 人员麻痹大意。那么这种困境该如何解决呢,是不是存在更加科学有效的方法?

Kindling-OriginX 创新提出仅仅依赖API SLO违约告警

SLO 违约告警其本质是依赖于 Google 提出的运维黄金指标来判断业务是否正常,如果业务不正常了,SLO 也就产生违约了。 Kindling-OriginX 能够不依赖于其它的告警,是因为 Kindling-OriginX 认为不管何种故障,最终都会影响到业务体验上,例如用户的访问请求等。如果任何业务都没有受有影响,即任意访问请求都没有变慢也没有出现任何错误和异常,那这个故障为什么能称之为故障呢?Kindling-OriginX 的核心能力是针对每次请求的故障trace,能够直接给出故障根因报告,在这种能力加持下,也就可以不用配置种类繁多的告警了。

面对棘手的级联故障,Kindling-OriginX 如何处理

面对棘手的级联故障,从本质来讲其实有两种优化手段

  • 通过算法判断出故障线索之间的潜在依赖关系,从而找到故障的根因,这也是传统 AIOps 的思路。
  • 重新组织故障线索,加快每个故障线索的分析,一分钟将所有故障线索都分析出结论。

Kindling-OriginX 选择了第二种方式来解决棘手的级联故障,通过trace来组织故障线索,每个故障trace都直接给出当前故障trace根因报告。

为了能够说明问题,这里以 soma-chaos 案例为例,通过注入一个网络故障后整个业务系统的变化分步作一具体说明。

  1. 对 routes service 注入网络故障。
  2. routes service 响应变慢。
  3. travel service 响应变慢,且比 routes service 更慢
  4. 初步走查发现大量请求在 travel service 处等待。

通过对故障现场的初步分析,我们可以得到两个线索

  1. travel service 响应变慢,同时大部分请求在等待
  2. routes service 响应变慢

通过对故障现场的数据观察和简单分析,得到了两个线索,但仍旧处于无从下手的阶段,往往需要更多的数据进行分析,或者需要有更丰富排障经验的专家来提供思路和排查方向。下面再看看 Kindling-OriginX 的解决方法。

对于这个故障,Kindling-OriginX 对于 travel service 的慢请求和 routes service 的慢请求都会分别直接给出根因报告,travel service 慢的根因是锁的时间很长,routes service 慢的根因是网络故障。

接下来不用再花费精力分析为什么 travel service 慢以及 routes service 慢,因为每个线索都已经快速的拿到了结论。接下来只需要根据结论来进行方案的研判或启动对应的应急预案即可以最快的速度进行业务的恢复。

在传统的排障方法中,很可能处置人员的注意力会被 travel service 的锁故障分散,甚至认为可能是根因,从而花费大量的时间和精力来分析和处理 travel service 的故障,但是却又不能精准快速定位,只能通过重启扩容等方案来进行穷举,浪费大量人力物力却也没能使业务快速回复。

Kindling-OriginX 通过对每个故障节点都直接快速给出结论,在排查级联故障之时,只需要遵循以下原则即可:

  • 被依赖的故障根因节点和基础设施故障(CPU、网络、存储)优先解决

磁盘故障!Demo环境全部宕机!

· 阅读需 9 分钟
Kindling-OriginX
故障根因推理引擎

每一个微小的警告信号、每一个看似不起眼的小故障都可能是一场灾难的序曲。新年伊始Kindling-OriginX 内部Demo环境经历了一次由磁盘故障引发的重大事故,本文带大家一起回顾下这次看似由种种巧合因素导致的故障是如何发生的,又该如何去规避。

故障回溯

  • 这里简单介绍下整体环境情况,Kindling-OriginX 目前生产环境涉及到的全部集群和设施均在AWS中国区,分布在北京和宁夏两个AZ,依托此构建生产环境的容灾方案,后期会加入阿里云来建设多云容灾和就近接入。 而目前的演示环境相对就比较简单,集群在公司内的小机房内,各种容灾和电源方案都相对比较简陋,这也是这次故障的伏笔之一了。

  • 开年的第一个工作日,我们发现内部的产品Demo演示环境的请求会不时出现无规律变慢。初始的直觉让我们以为是有用户在演示环境中体验故障注入,观察后发现在没有故障的注入的情况下,这种情况仍旧时有发生。此时我们打开 Kindling-OriginX 的慢请求根因分析报告,根据根因报告中的分析确定了问题的初因--磁盘I/O出现了异常,通过下方报告截图可以明确的看出主要耗时是由于文件I/O时长增大导致。之后查看机器相关数据后确定是磁盘坏道引起的。 问题根因 文件读写耗时 io耗时分析

  • 确定了慢请求是磁盘导致的后,这个问题并没有引起我们的重视,一方面磁盘存在一定的坏扇区或者坏道并不是致命故障,同时我们也乐观的认为这个情况也能更方便用户在使用Demo时体验磁盘故障。 接下来又一个不幸再次发生,一天后该磁盘硬盘灯亮起了红灯,彻底宣告故障。但此时大家仍比较乐观,因为我们对Demo环境所在集群的 RAID5 还是颇为自信的,认为目前即使已经整盘挂掉,损坏一块短时间内也问题不大。然而,这种过于乐观的心态使得我们未能及时采取行动。我们的拖延,最终为后来的麻烦埋下了又一个伏笔。 io耗时分析

  • 明确问题后,开始了从供应商购买硬盘,并计划换盘时间的相关准备工作。和供应商沟通,快递收发货,安排合适的停机更换时间,由于之前的大意,每一个步骤都几乎耗费了2天的时间,甚至于拖拖沓沓。回头看来,整个过程都显得迟缓而被动。同时在这个过程中,这块问题磁盘彻底坏掉无法使用。

  • 就在我们准备换盘的过程中,运气似乎并不站在我们这边,又一块磁盘宣告故障,RAID 状态也变为 FAILED,经过近一天的反复折腾和各种尝试后确定无法拯救。这次,RAID5的冗余也无法挽救数据的完整性,我们面临的是更加复杂的数据恢复和环境重建工作。 io耗时分析 io耗时分析

  • 我们别无选择,只能从头开始,重建RAID5磁盘阵列,重新安装并配置整个环境。这一过程耗费了我们大量的时间和资源,演示环境也只能无奈的一直高挂免战牌。

  • 经过漫长的重建、重装、环境分配、拉起各个服务各个环节后,1月6日周六晚一切终于恢复,整个故障从发现到完全恢复,耗时近一周时间,算是开年第一周给自己好好的上了一课。原本一个小小的磁盘故障,也通过 Kindling-OriginX 的故障报告早早发现定位到,但却由于各种策略上的大意,认为是Demo环境在行动上没有足够的重视,让小故障变成了大事故,浪费了大量的时间和资源。

  • 在经历了这次磁盘故障后,我们重新审视Demo环境故障的处置机制,以此为鉴,不只生产环境的稳定性和可用性需要得到保证,Demo环境同样需要有合理的机制和稳定性保证,不然同样会酿成大祸。

  • 在事后复盘过程中,我们也对 Kindling-OriginX 在生产环境中高可用性、灾难恢复能力和扩展能力的设计方案进行了复盘和总结,确保在公有云自身的HA能力之上能提供更高的容灾恢复能力。在这里也推荐有条件的团队可以多尝试公有云,在容灾方案设计和高可用性方面很大程度上能够节约多人力和硬件成本,以AWS中国区通用性SSD卷为例,提供不超过十毫秒的延迟以及 99.8% 到 99.9% 的卷耐用性,年故障率(AFR)不高于 0.2%,这意味着在一年期间内,每 1000 个运行的卷最多发生两个卷故障。再配合合理的快照策略和可用区分配,几乎能满足大部分普通业务场景的可用性需求。还可以通过 AWS Fault Injection Service 在EBS上进行测试来进行故障演练和方案验证。

复盘总结

在问题出现的最早期,Kindling-OriginX 已经在第一时间给我们定位到了问题,并在根因报告中给出了问题故障根因,但是却没有引起足够的重视,最后在多种因素综合下变成了重大故障。也希望大家引以为鉴,故障的处置不仅仅需要第一时间发现、定位、分析出故障根因,也需要在处置策略上有合理的流程,在战略上对任何有问题有足够的重视,才能真正的做到 1-5-10。

有兴趣的朋友们可以通过在线故障注入系统注入磁盘相关故障,体验真实系统中磁盘故障,同时通过 Kindling-OriginX 在线演示系统查看磁盘故障的根因报告。

级联故障该咋办?

· 阅读需 9 分钟
Kindling-OriginX
故障根因推理引擎

级联故障

单个服务发生故障,有可能导致故障沿着调用链路,扩散至多个上游服务,进而可能会导致多个服务均产生不同的故障现象,这就是典型的级联故障。在级联故障中,常常会被复杂多变的故障现象所误导,进而选择了错误的排查方向导致不可能及时完成排障。面对棘手的级联故障,究竟该怎么办?

什么是级联故障

这里以一个例子来展示级联故障。在如下所示的服务调用结构中,对 ts-route-service 服务注入故障。之后受多种因素的影响,在 ts-route-service 的上游节点甚至旁路节点都出现不同的程度的故障现象,这就是典型的级联故障在实际系统中的现象。 级联故障-什么是级联故障

为什么级联故障难以处置

这里继续以前文的系统为例,试试看能否找到故障。

该如何开始?

打开 Skywalking,筛选持续时间在 500ms - 10000ms 之间的近10分钟的请求数据,可以看到有667页近 10,000 条数据,这还是在并发量不大的情况下,如果稍有并发量这个数字更是难以想象,这么多 Trace 数据中究竟哪些有问题?哪些又能对我们定位帮助有帮助?该从哪些 Trace 数据着手开始分析?还没开始解决问题,就已经又得到了一堆的问题。 级联故障-如何开始1

既然看似都有问题,那就先随机选择几条 Trace 数据,抓紧时间开始排障。

下面这条数据看上去是 ts-travel-service 有问题。 级联故障-如何开始2

接下来这条看上去也是 ts-travel-service 出现了故障。 级联故障-如何开始3

再打开一条显示 ts-travel-service 和 ts-basic-service 调用时间很长。 级联故障-如何开始4

看到这里一头雾水就暂且认为故障发生在 ts-travel-service 或 ts-basic-service 。

该如何选择,选择是否完备?

通过对 Trace 数据的分析,大致定位问题原因是 ts-travel-service 或 ts-basic-service 出现故障,导致链路在 ts-route-plan-service 调用下游服务时候出现问题。那么这两个服务该如何选择先处理哪个?系统中当前只有这两个服务出现了故障?是不是有可能两个服务都出现了故障?分析到这里我们得到的是更多的疑问。可事实上,在这里我们无论选择哪一个开始排查,都并不能找到造成问题的根因所在。实际情况中那只能重头来过,听天由命各凭本事了。

级联故障中一旦选错了排查方向就会导致做无用功,浪费了大量时间得到的是更多的疑问。传统工具的告警或 Trace 数据往往以单体应用的视角为出发点,更加容易分散注意力。大量的 Trace 数据反而会成为选择错误排查方向的诱因。在实际故障处置过程中往往变成无从下手,无法抉择。要不凭经验拍脑袋,要不就在所有人焦急的催促中不停地重启、穷举,希望能够撞个大运。 级联故障-怎么办

是否有更好的方法处理棘手的级联故障

面对棘手的级联故障,从本质来讲其实有两种优化手段

  • 通过算法判断出故障线索之间的潜在依赖关系,从而找到故障的根因,这也是传统 AIOps 的思路。
  • 重新组织故障线索,加快每个故障线索的分析,一分钟将所有故障线索都分析出结论。

Kindling-OriginX 选择了第二种方式,通过 Trace 来组织故障线索,每个故障 Trace 都直接给出当前故障 Trace 根因报告。

级联故障-有办法

重新组织故障线索

Kindling-OriginX 以全局视角切入,一方面将出现 SLO 违约服务入口的故障节点全部列出,以节点比例进行统计根因占比,另一方面聚合故障报告数据。能够在排障开始阶段就能够对全局状态有所掌控,不再盲目查找数据。

级联故障-重新组织故障线索1 级联故障-重新组织故障线索2

直接给出故障根因

Kindling-OriginX 在报告中已直接给出了故障根因,无需人工分析,即使像上图所示有多个节点的报告,也只需逐个打开查阅即可,而无需逐节点查找数据再进行人工分析。只需将全部故障节点报告逐个阅读后,统一判定即可,不用再苦于如何选择 Trace 数据进行排障。 级联故障-直接给出故障根因1 级联故障-直接给出故障根因2 级联故障-直接给出故障根因3

标准化级联故障排障方式

在复杂的级联故障中,通过 Kindling-OriginX 逐个查询全部故障报告后,结合排障优先级原则进行故障处置(被依赖的故障根因节点和基础设施故障「CPU、网络、存储」优先解决)即可。同时关联的各类 Trace、Log、Metrics 数据也为各职能团队进行定界与任务交接提供标准化的数据,这也能够使多团队协作排障有标准化的流程与依据。

级联故障-标准化级联故障排障方式1 级联故障-标准化级联故障排障方式2 级联故障-标准化级联故障排障方式3 级联故障-标准化级联故障排障方式4 Kindling-OriginX 提供了一种新的处理级联故障的思路和方法,快速组织和分析故障线索,给出根因报告,并根据优先级原则进行故障处理。这种方法可以加速故障定位,避免级联故障中排查方向错误,同时能够以标准化的流程进行级联故障的排查,真正的有机会去在实践中落地 1-5-10 故障响应机制。

踩坑实践

· 阅读需 2 分钟
Kindling-OriginX
故障根因推理引擎

故障案例总结与整理,例该案例集主要从互联网上收集整理,分享经验避免重复踩坑。同时会逐步增加对应使用 Kindling-OriginX 解决相关案例问题的实践方法和思路供参考和讨论。欢迎大家分享给身边的朋友,同时也期待更多的同学加入分享自己的踩坑经验。我们会逐步模拟类似的场景如何使用,并介绍Kindling-Originx高效排查故障

运维痛点深度解析:当前排障流程的挑战与局限

· 阅读需 13 分钟
Kindling-OriginX
故障根因推理引擎

运维痛点深度解析:当前排障流程的挑战与��局限

在当今互联网时代,运维工作的重要性日益凸显。然而,随着业务规模的不断扩大,运维面临的挑战和痛点也越来越多。本文将深度解析当前排障流程的挑战与局限,提出相应的解决思路,并对未来运维及可观测的发展趋势进行展望,以帮助企业和运维团队更好地应对复杂多变的运维环境,确保业务稳定、高效地运行。

运维痛点深度解析:当前排障流程的挑战与局限

当前排障流程的最大挑战:排障难以标准化

目前在线上故障处置过程中,主要做法主要是跳坑、填坑、踩坑的方式,依赖处置参与人员对系统、业务、架构的熟悉程度,同时受人员综合能力及经验影响大,另一方面运维人员对各类可观测性指标与工具的熟悉程度,都会对故障的处置和恢复时间,甚至能否成功处置都会起到关键作用。即使相同的故障现象,不同人员也会有不同的理解和处理方式,导致处理结果不一,甚至导致故障升级。这些都导致排障流程难以标准化。

以下问题也是目前排障流程的挑战:

故障发现延迟

当前排障流程中,故障发现往往依赖于监控系统或人工巡检。然而,这些方式在实时性和准确性上存在局限,导致故障发现延迟。故障发现延迟不仅影响业务正常运行,还会增加故障处理的时间和难度。

排障效率低下

排障过程中,运维人员需要分析大量的日志、数据和相关文档。然而,由于缺乏有效的排障工具和方法,导致排障效率低下。此外,排障过程中的信息孤岛现象也使得运维人员难以快速定位故障原因。

排障流程不统一

不同团队、不同业务的排障流程可能存在差异,导致运维人员在处理故障时难以形成统一的操作规范。这不仅影响排障效率,还可能导致故障处理不当,引发更大的问题。

故障复现困难

故障复现是定位故障原因的关键环节。然而,在实际操作中,故障复现往往面临诸多困难,如环境不一致、数据丢失等。这给排障工作带来了极大的挑战。

目前的一些解决思路

  1. 提高故障发现能力

建立完备的可观测性产品体系,提高故障发现的实时性和准确性。同时,加强运维团队对监控系统的培训和团队能力,提高人工巡检的效率。

  1. 优化排障工具和方法

研发或引入专业的排障工具,如日志分析、性能监控等,帮助运维人员快速定位故障原因。此外,建立排障知识库,总结常见故障及解决方案,提高排障效率。

  1. 统一排障流程

制定统一的排障流程规范,明确各个阶段的操作步骤和责任人。通过培训和考核,确保运维人员熟悉并遵循排障流程,提高故障处理质量。

  1. 提高故障复现能力

建立故障复现环境,确保复现过程中环境的一致性。同时,加强对故障数据的收集和存储,为故障复现提供充分的数据支持。

常用的排障工具和方法

运维痛点深度解析:当前排障流程的挑战与局限

我们可以看到在实际的运维工作中,排障流程的挑战是多方面的,需要综合运用技术、流程和团队协作等多种手段来解决。在运维领域,有许多工具和方法可以帮助提高排障的效率和效果。以下是一些常用的排障工具和方法。

排障工具

  • Prometheus:一款开源的系统监控和警报系统,提供了通用的数据模型和快捷数据采集、存储和查询接口。

  • Grafana:与Prometheus结合使用,提供强大的可视化功能。主要用于大规模指标数据的 可视化展现,是网络架构和应用分析中最流行的时序数据展示工具。

  • Skywalking:开源应用性能监控工具,支持对分布式系统的监控、跟踪和诊断。

  • OpenTelemetry:由OpenTracing和OpenCensus项目合并而成,是一组规范、工具、API和SDK的集合。使用它来检测、生成、收集和导出Metrics、Log和Trace,以帮助运维开发人员分析软件的性能和行为。

  • Nagios:一款流行的开源IT基础设施监控系统监控系统,用于监控网络和服务。

  • Kindling-OriginX:故障根因推理引擎,基于 eBPF 的自动化 Tracing 分析产品,以专家经验串联起来所有的可观测性数据,并推理成可解释、可行动的故障结论。

  • DeepFlow:基于 eBPF 的可观测性产品,旨在为复杂的云基础设施及云原生应用提供深度可观测性。

  • Splunk:一个强大的日志分析平台,能够处理大规模的日志数据。

故障排查方法论

  • 根本原因分析(Root Cause Analysis, RCA):目的是找到问题的根本原因,而不仅仅是表面的症状或止血方案。如果能够找到故障的根本所在,通过数据还原并佐证故障的过程,那么就可以采取相应的行动,对故障进行止血或者根除。但实际上往往不可能快速找到故障根因,所以该方法往往是最终目标,但很难有路径直达,在实际生产环境排障中往往难以直接应用,也是目前AIOps方向想要解决的核心痛点。

  • 故障树分析(Fault Tree Analysis, FTA):是由上往下的演绎式失效分析法,利用布尔逻辑组合低阶事件,分析系统中不希望出现的状态,通过构建一个故障树来分析特定事件的发生原因。从一个不希望发生的事件(故障)开始,追溯回可能的原因。例如构建事件墙,依据是否发生变更、是否做过配置更新等逐个事件回溯判断。

  • 排除法(Deductive Reasoning):通常用于逻辑性强、数据量少的情况。根据可观测数据排除干扰可能,主要适用于疑难杂症,对于常见故障,由于各类指标和相关数据既多又分散,且不一定都具有逻辑关联性,所以难以用于快速解决问题。

  • 假设验证(Hypothesis Testing):提出可能的假设,然后实施来测试这些假设,常见的随机变动讹方法就是其中一种,通过猜测方向和实验后验证结果来排除或确认假设。在实际场景中的例子就是处置人员往往根据经验判断问题点,之后优先选择进行重启、回滚、扩容等方式尝试解决故障,操作后如果各类指标正常,则完成止血确认假设。优点是简单速度快,缺点是主要依靠经验和假设猜测

排障流程优化策略

运维痛点深度解析:当前排障流程的挑战与局限

目前主要可以依靠提高团队质量和引入各类新工具来对流程进行优化,主要的方法有:

  1. 标准化和文档化:

制定标准的排障流程,确保每个步骤都有明确的指导和期望结果,以规定流程进行排障。

文档化所有的排障步骤和解决方案,建立企业和团队内部运维知识库,以便于知识共享和快速参考。

  1. 自动化和工具化:

引入更先进的工具和理念,通过引入先进平台和工具能力提高团队整体水平,优化排障能力和流程。

  1. 智能化和数据分析:

根据自身系统和业务特点,建立完备的数据分析和指标治理体系,提高可观测数据的使用水平。

  1. 培训和提高团队能力:

对运维团队进行定期培训,提高他们的技术能力和对最新工具的了解。

鼓励团队成员参加行业会议和研讨会,以获取最佳实践和新技术。

  1. 故障演练和复盘:

以混沌工程故障注入的方式定期进行故障演练,模拟真实环境中的故障情况,以提高团队的应急响应能力,每次故障后进行复盘会议,分析故障原因,总结经验教训,并更新排障流程。

结语

运维痛点深度解析,让我们看到了当前排障流程面临的挑战与局限。只有通过不断优化排障工具和方法、引入先进的工具和理念,帮助提高团队整体水平优化流程,才能由跳坑、填坑、避坑的处理流程演变为可管理、规范化、无差异化的标准工作流程。