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

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

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

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 通过智能化、自动化的标准化排障流程，模拟并优化了人工排障步骤，融合专家知识和相关数据，实现了效率和准确性的显著提升，为解决故障根因定位问题提供了新的思路和解法。

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

在 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、网络、存储）优先解决

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

故障回溯​

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

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

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

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

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

• 我们别无选择，只能从头开始，重建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 在线演示系统查看磁盘故障的根因报告。

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

什么是级联故障​

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

为什么级联故障难以处置​

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

该如何开始？​

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

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

下面这条数据看上去是 ts-travel-service 有问题。

接下来这条看上去也是 ts-travel-service 出现了故障。

再打开一条显示 ts-travel-service 和 ts-basic-service 调用时间很长。

看到这里一头雾水就暂且认为故障发生在 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 违约服务入口的故障节点全部列出，以节点比例进行统计根因占比，另一方面聚合故障报告数据。能够在排障开始阶段就能够对全局状态有所掌控，不再盲目查找数据。

直接给出故障根因​

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

标准化级联故障排障方式​

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

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

解密北极星指标体系如何实现根因分析​

在之前的文章中提过我们的观点，AIOps实践中常见的挑战：故障根因与可观测性数据的割裂 认为依赖算法给出根因建议缺乏可解释性，本篇文章重点介绍下我们的根因定位的思路, 按照这个思路去快速实现根因定位，我们认为是能够落地1-5-10的，如果对文章的思路有任何疑问，欢迎联系我们一起探讨。

为什么高效定位故障根因定位难​

排障过程本质是我们拿着程序最后的执行结果去猜测验证程序执行异常的过程​

当前人为定位故障主要依赖于指标告警，但是现在绝大多数指标反映的程序执行结果，并未对程序执行过程提供更多的信息。举例说明，CPU利用率是程序执行完代码之后的CPU的被使用的反映，内存利用率是程序已经使用内存的执行结果，所以排障过程本质是我们拿着程序最后的执行结果去探索程序执行异常的过程。

在探索程序执行异常的过程中，有哪些数据能反映程序执行过程呢？能反映程序执行过程数据目前常规就是日志以及各种事件（将APM数据称之为程序执行的事件数据，比如执行的代码堆栈、慢方法等）。

由于可观测性盲区的存在导致猜测验证过程依赖专家经验​

不管是日志、APM数据所反映出程序执行过程其实都存在很多盲区，关于程序执行盲区，可以参考团队在KubeCon，eBPF大会等会议上分享内容。也可以参考可观测性工具的盲区与故障排查困局 这篇文章，里面有更加详细讨论。

什么数据能够对故障定位起到决定性作用​

基于以上的论述，我们认为要能够实现故障定位的关键数据要满足以下特点：

• 覆盖程序执行的盲区，不管程序任何操作都应该有数据能够和程序执行过程对应起来
• 数据分类要足够抽象，便于排障的人员能理解，这点很重要因为团队之前拿着程序依赖内核的行为数据去和用户沟通之时，绝大多数开发不能理解这些数据，就别提用这些数据进行排障
• 每个数据分类要足够隔离，不要相互影响

北极星指标体系是故障定位中的关键数据​

北极星指标体系是基于TSA方法论得到的程序执行过程完整数据，关于TSA的方法论，有兴趣的朋友可以参考大神的博客，https://www.brendangregg.com/tsamethod.html 也可以参考这篇公众号的文章，TSA方法：基于线程时间分布分析性能瓶颈http://u6v.cn/5yDFVr

从这套方法论来看，采集的数据是覆盖了程序的完整执行过程，第一个要求满足了，那第二个要求就是我们将程序与内核交互的数据进行抽象而得到的。第三个就是因为我们是根据进程在操作系统上执行On与Off数据而来，所以数据是隔离没有影响的，这里也许有内核专家会疑惑比如由于网络包产生的软中断会消耗很多的CPU，所以CPU时间和网络时间不能隔离，但是我们是基于On与Off数据而来，由于网络包产生的软中断CPU消耗会被计算到ON的CPU时间之上，并能通过内核火焰图反应出最终的问题。

一次接口执行的北极星指标

围绕着北极星排障指标的建模​

在有了一次接口执行的北极星数据之后，我们可以对历史数据进行基线判断，也就可以形成以下的数据

当某一次异常执行过程和基线对比之后，我们可以很快知道故障方向，比如以下的示例，问题明显就是文件方向：

问题：多分项的异常怎么办？​

同时出现CPU耗时超出历史基线和net耗时超出历史基线怎么办？该往哪个方向排查？

针对一次请求的异常，我们认为应该聚焦突变最大的异常，所以只会关心突变最大的异常方向，但是并不是忽略其他突变的异常，对于根因定位而言，不能因为一次请求的异常就完全定出根因，应该对请求进行全面的分析。其它异常突变的分项如果真的是根因，在其它请求中一定也会有所反应，而偶发的噪音在其它请求中就能被过滤掉。

基于北极星指标的初因判断​

对于突变最大的异常，我们会做一个初因判断，也就是某单次请求的初因异常，这样每个异常请求都会一个初因的标签了。

对请求全面分析之后的节点级故障特征​

单次请求的异常可能是偶发因素，但是对节点所有请求进行全面分析之后，并统计之后，就能够形成故障特征，准确度大幅提高。比如某节点其故障特征如下：

对该特征的解释如下：

• 有些请求是幸运儿，没有经过长时间的锁等待就调用成功了下游服务节点，但是由于下游服务节点异常从而产生了网络调用耗时长的初因故障
• 更多的请求由于对外调用连接池的限制，产生了长时间的锁等待，所以产生了锁等待的故障

所以对于该特征的节点，大概率不是故障根因节点，因为其长时间的等待都是由于下游故障而导致的。

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

• 一次棘手的容器故障，我终于知道SRE有多重要了 - 得物技术
• 容器网络延时之 ipvs 定时器篇 - 趣头条技术分享
• SRE 高延迟问题的罪魁祸首 System.gc() - eBay技术荟
• Netty堆外内存泄露排查盛宴 - 美团技术团队
• 开工第一天，这个超时问题把我干趴下了
• 性能分析之用户登录 TPS 低及 CPU 被打满问题分析

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

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

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

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

故障发现延迟​

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

排障效率低下​

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

排障流程不统一​

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

故障复现困难​

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

目前的一些解决思路​

1. 提高故障发现能力

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

2. 优化排障工具和方法

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

3. 统一排障流程

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

4. 提高故障复现能力

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

常用的排障工具和方法​

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

排障工具​

• 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. 标准化和文档化：

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

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

2. 自动化和工具化：

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

3. 智能化和数据分析：

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

4. 培训和提高团队能力：

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

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

5. 故障演练和复盘：

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

结语​

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