传统排障方法的局限性​

传统故障排查的痛点​

在复杂的分布式系统中，故障排查一直是一个让人头疼的问题，其中机器宕机、进程存活、程序异常报错等故障相对而言比较好排查，有直接的指标能够反应出问题，难排查的问题是流量突增，时延变化等故障，特别是在分布式系统中，这类故障更难排查。传统的方法往往需要工程师逐一排查各种可能性，耗费大量时间和精力，效率低下且盲目。

传统故障排查方法的低效性主要源于以下几点：

• 时间消耗巨大： 需要逐一检查系统中的各个组件和指标，排查流程繁琐，耗时长。
• 盲目性： 没有明确的线索指引，排查过程中往往需要凭借经验和直觉，试错成本高。
• 数据分散： 各类监控指标彼此独立，缺乏统一的视图，导致难以全面了解系统状态。

这些痛点的根源在于我们所使用的指标大多是结果性指标，指向性不明确。例如，CPU利用率、内存使用率等指标只能反映系统的当前状态，却无法直接指出问题的根源，给故障排查带来了巨大的挑战。

常规的指标局限​

在实际应用中，工程师们常常依赖于各种常规的性能指标，例如：

• CPU指标： 反映系统的计算资源使用情况。高CPU使用率可能是由于多个原因导致的，例如某个服务在进行高计算密集型操作。但是，CPU指标并不能告诉我们具体是哪个请求导致了高CPU使用率，通过人为分析才能知道是哪个进程的CPU使用率高，然后借助更多的工具才能知道可能是哪一段代码导致的，但是业界还缺少业务视角关联，没有办法知道哪个URL导致了CPU升高。
• 网络指标： 反映网络传输的性能。无法明确是哪一个具体请求导致的带宽占用，例如一个文件服务器在处理多个文件上传和下载请求。网络指标只能显示整体的网络带宽使用情况上升，却不能确定是哪个具体请求导致的带宽占用增加，也缺少业务视角关联。
• 文件指标： 反映磁盘I/O操作的效率。高磁盘IO使用可能是因为某些请求涉及大量的文件读写操作。然而无法具体指明是哪一个请求导致的磁盘IO高使用，缺少业务关联视角。
• 内存指标： 反映系统的内存使用情况，同理缺少业务关联视角。
• GC指标： 反映垃圾回收的频率和时间，同理缺少业务关联视角。

虽然这些指标在一定程度上帮助我们了解系统的运行状态，但它们彼此独立，无法构建出一个完整的故障图景。这种独立性导致了以下问题：

• 无法关联： 各个指标之间缺乏关联，难以看出它们之间的因果关系。
• 片面视角： 只能看到单个指标的表现，无法形成整体视图。
• 低效排查： 无法通过单一指标判断问题的根源，需要逐一排除各种可能性，效率低下。

常规指标的这种局限性导致在排障过程中，我们常常需要逐一排查每一个可能的原因，耗费大量时间和精力，难以快速定位问题。

---

北极星指标带来的革命性变化​

业界提供因果性的工具​

为了应对复杂系统中的故障排查问题，业界提出了一些具有间接因果性的工具。然而，这些工具和方法也有其局限性：

• 分布式追踪（Distributed Tracing）：

○优点： 提供请求的完整路径信息，详细展示每个服务调用的耗时，帮助识别系统中的延迟和瓶颈。

○局限性： 在稍微复杂的场景下，因噪音和故障级联的存在，瓶颈点经常会被误判。需要结合业务逻辑和经验分析，才能推断因果关系，找到真正的瓶颈点。

• 依赖图（Dependency Graph）：

○优点： 展示系统组件之间的依赖关系，便于理解系统架构，帮助识别关键路径和潜在的瓶颈。

○局限性： 依赖图是静态分析工具，无法实时反映系统运行状态。随着系统规模的增加，依赖图的复杂性也增加，难以管理和维护。

• 日志（Logging）：

○优点： 详细记录系统运行状态和事件，便于追踪和分析，具有高度的定制性，可以记录各种所需的信息。

○局限性： 需要精心设计和管理日志记录策略，否则会产生大量无用数据。分析日志数据需要强大的工具和技术，如ELK栈。日志数据分散，难以直接构建因果关系，需要结合其他数据进行综合分析。

• 事件监控（Event Monitoring）：

○优点： 可以实时监控系统中的各种事件，如错误、警告等，帮助快速响应和处理异常事件。

○局限性： 事件监控通常是离散的，难以直接构建事件之间的因果关系。需要结合历史数据和上下文信息进行分析和推断。

利用eBPF技术获取北极星指标​

北极星因果指标的获取依赖于先进的分布式追踪技术和内核级数据关联。具体过程如下：

1. 分布式追踪： 首先，通过分布式追踪技术，捕获每个请求的完整路径信息。这包括请求在不同服务节点之间的传递和处理时间。
2. eBPF在内核追踪线程信号： 在系统内核中，追踪执行请求的线程信号。这些信号反映了线程在处理请求过程中的各个状态变化和资源使用情况。
3. eBPF在内核实现系统调用信号关联： 将分布式追踪数据与系统调用信号关联起来，形成对请求处理全过程的详细分解。这一步骤涉及将应用层的请求数据与内核层的系统调用数据进行关联，确保每个请求的所有资源使用情况都被捕获和分析。

通过这种方法，我们能够生成北极星因果指标。该指标不仅提供了各个性能指标的详细数据，还展示了它们之间的因果关系，从而帮助工程师快速定位故障根源，提升排障效率。

北极星因果指标的组成: 一次业务视角的请求耗时被完美且完整拆解成以下指标​

CPU耗时​

• 定义和意义

○指请求在CPU上消耗的时间。

• 如何影响请求处理

○高CPU耗时可能指向计算密集型任务比如循环和递归。

网络耗时​

• 定义和意义

○指请求在网络传输中消耗的时间。

• 如何影响请求处理

○高网络耗时可能指向网络延迟、带宽不足或下游节点代码执行异常，典型的就是SQL语句执行慢。

文件读写耗时​

• 定义和意义

○指请求在文件系统读写操作中消耗的时间。

• 如何影响请求处理

○高文件读写耗时可能指向磁盘I/O瓶颈或文件系统问题。

内存消耗耗时​

• 定义和意义

○指请求在内存分配和管理中消耗的时间。

• 如何影响请求处理

○高内存耗时可能指向内存泄漏、内存分配不当或频繁触发Pagefault。

锁耗时​

• 定义和意义

○指请求在等待锁资源中消耗的时间。

• 如何影响请求处理

○高锁耗时可能指向锁争用、死锁或锁机制设计不合理, 绝大多数都是代码类库使用了隐藏锁而开发人员不自知，比如数据库连接池锁等。

GC耗时​

• 定义和意义

○指请求在垃圾回收过程中消耗的时间。

• 如何影响请求处理

○高GC耗时可能指向内存管理不当或垃圾回收频繁触发。

CPU调度耗时​

• 定义和意义

○指请求在执行过程中，由于CPU调度而产生的延时

• 如何影响请求处理

○高CPU调度耗时，意味着容器的CPU资源不充分。

为什么北极星因果指标是排障的最关键指标​

基于北极星因果指标排障，立刻获得了多个性能指标的关联分析结果，有了系统的整体视图。

北极星因果指标具有以下独特优势：

• 因果性：

○北极星指标通过数据关联和因果关系分析，提供了请求处理过程中的详细分解。各个指标之间的因果关系明确，能够帮助工程师快速定位问题根源。

• 全面性且无盲区遗漏：

○北极星指标覆盖了请求处理的全过程，从CPU耗时、网络耗时、文件读写耗时，到内存消耗耗时、锁耗时和GC耗时，确保了指标的全面性并且没有盲区。

• 高效性：

○通过提供因果关系视图，北极星指标可以快速定位故障根源，减少排障时间和降低排障复杂性。工程师无需逐一排查每一个可能的原因，而是能够通过整体视图快速确定问题所在。

• 一体化视图：

○北极星指标将多个独立的性能指标整合为一体化视图，便于综合分析和决策。这样，工程师在查看指标时，不再需要切换不同的监控工具，而是可以在一个视图中看到所有关键性能指标及其关联关系。

---

总结​

北极星因果指标的引入，彻底改变了故障排查的方式。通过提供因果关系和全面视图，它不仅提升了排障效率，还显著减少了排障过程中的盲目性和试错成本，真正实现了高效、精准的故障排查。

●永久免费

●多语言支持：Java、Python、Nodejs、一键安装

●标准PQL语句查询数据

在故障推理引擎加持下如何实现减少告警，做到精准告警​

在 Kindling-OriginX 中只有业务请求受到故障影响才会告警，其他时候指标异常、故障都不会告警。为什么要这样设计呢？主要有以下几个主要原因：

• 传统基于指标的告警：误报与漏报的告警非常多，信噪比非常高，会导致运维人员疲劳而忽略了真实的告警，而延误了告警的处理时间，导致严重的故障后果。
• 基于指标的告警的本质是基于经验的设计告警的大杂烩，每个运维团队的告警都是在不断采坑中，不断完善指标告警，但是这个告警处理依赖于设计这个规则的人。但是人员是流动的，这些经验往往不会及时调整，而是不断累积，形成一个庞大而复杂告警体系。
• 庞大而复杂的告警体系中，多指标是在技术上其实关联的，但是由于指标告警的时候是没有理解其内在关联性，一旦真实故障产生，各种误告警会不断产生，引发告警风暴。
• 告警还有一个作用，就是当业务发生真实告警之时，期望指标告警能够为故障定位提供指导，但是没有专家经验治理的情况下，会产生告警太多的困惑，到底哪个是因，哪个是果不清楚，该往哪里排查也不清楚。

在Kindling-Originx中不需要传统告警提示排查方向​

Kindling-Originx的核心能力就是故障根因推导，能够分钟级甚至秒级出故障报告，直接给出故障定位的初因。在这种情况下，无需配置指标告警来提示根因了，用户直接在故障根因推导的报告中能够得到定位的初因，同时也能够完整查看故障根因推导的过程，看出在整个推导过程中，有哪些指标是异于平常，同时可以通过Grafana大盘去观测更多的相关指标，进一步确认故障根因推导的正确与否。

基于API的SLO告警是Kindling-OriginX的使用入口​

为了能够在生产环境中真正完成“1-5-10”，即1 分钟发现-5 分钟处置-10 分钟恢复的目标，通过 Kindling-OriginX 用户只需要设定和关注 API的SLO，并通过 SLO 关注系统状态结合 Kindling-OriginX 精准高效的故障根因分析技术，就能够使用户在极短的时间内响应并解决问题，发现各种隐患。这意味着即使是没有深厚技术背景和强大专家团队的用户也能够利用 Kindling-OriginX 来达成“1-5-10”目标，大大降低了技术门槛，提升了效率和可靠性。

推荐步骤​

1. 定义 API SLO (系统默认以历史数据设定)
2. 当 SLO 违反时，查看对应时间段所生成的故障报告
3. 根据故障报告内的根因分析数据，定位并解决问题，或根据推荐操作启动对应处置方案。
4. 针对存疑根因分析结果，查看其详细推导数据与过程。

推荐流程​

通过 Kindling-OriginX 只需要简单几步就能在不改变组织内原有应急策略和响应流程的情况下，快速提高故障发现速度与故障处理时长，帮助用户找到切实有效的方法落地实践“1-5-10”。

直接使用 Kindling-OriginX 基于SLO业务级别的告警，是否会有滞后性，是否会导致早期潜在故障发展成严重故障？​

例子：传统运维视角，配置了JVM内存使用量告警，一旦JVM内存使用量达到一定阀值意味着内存可能存在泄露的可能，JVM内存使用量告警可以及早的请相关人员介入，避免潜在的风险演变成严重的内存OOM问题导致用户在业务接口上延时和错误率上升。

对于所有存在潜在问题发展成严重事故的故障，都会遵循以下的演变规律:

1. 初始阶段（无明显影响）

• 比如CPU使用率高：一开始，系统可能有足够的资源来处理增加的负载，所以高CPU使用率不会立即影响业务性能。
• 比如内存泄露：同样，内存泄露在早期可能不会立即耗尽可用内存，因此不会直接影响业务请求的处理。

2. 渐进阶段（轻微影响）

• 随着时间的推移，如果CPU持续高负载运行，可能会导致处理能力下降，开始影响到处理请求的速度，出现轻微的延时增加。
• 内存泄露逐渐消耗更多内存，开始影响系统的性能。这可能首先体现为偶尔的性能下降或轻微的延时增加。

3. 加速阶段（逐渐增加的影响）

• CPU使用率高：随着系统负载的继续增加，CPU可能无法有效地处理所有请求，导致响应时间显著增加，甚至影响到其他并行运行的服务或应用。
• 内存泄露：内存消耗接近或达到系统上限时，可能导致内存不足，影响到新的请求处理，甚至引发系统的虚拟内存使用，进一步降低系统性能。

4. 临界阶段（严重影响）

• 此时，系统可能变得过载，无法有效响应请求，导致大量请求延时显著增加，错误率上升。
• 在极端情况下，系统可能完全无响应或崩溃，需要重启或其他紧急措施来恢复服务。

5. 恢复和分析

• 一旦问题被识别并解决（如优化资源使用、修复内存泄露问题），系统性能会逐渐恢复正常。
• 通过分析导致问题的根本原因和过程，可以采取措施预防未来类似问题的发生。

传统的指标阀值告警模式也许能够在初始阶段就告警，从而为潜在风险提供更多的处理时间，如果告警能够做到精而准确实能够帮助用户争取更多的时间来处理潜在的风险。但是实际情况往往是告警误报过多，从而导致疲劳忽略了告警，别说争取时间了，就是故障已经发展到3或者4阶段的告警都可能被忽略，反而影响了告警的高效处理。

目前 Kindling-OriginX 基于SLO围绕业务告警，针对慢性问题发展成严重故障，基本上做到在3阶段-加速阶段实现告警，这个时候告警完全有时间进行快速处理。未来 Kindling-OriginX 争取发展到2阶段，在早期尽量给用户争取更多的时间来处理潜在的风险。

本系列文章将以云原生环境下分布式系统的不同类型故障入手，从真实系统出发，分别以不同类型的故障为例，对故障根因报告进行介绍和解读。

本篇将通过实际案例对故障根因报告进行解读。将会使用开源模拟故障案例集系统 soma-chaos 作为故障注入平台，在 Kindling-OriginX 在线Demo上进行故障报告的解读，可以通过点击阅读全文进入 Kindling-OriginX 官方网站，实际体验故障注入和 Kindling-OriginX 的故障根因推理能力。

报告解读​

• 在 ts-order-service 中注入故障：运行额外任务抢占Pod可用的CPU资源。

  注入完成后稍等片刻，进入 Kindling-OriginX 的「服务健康检测诊断」页面，在「SLO实时异常检测」Tab页下我们可以看到 ts-order-service 涉及的服务入口出现 SLO 告警。

• 在这里可以看到目前异常根因节点占比 ts-order-service 和 ts-seat-service 各占一半，他们都处于报警服务入口调用链路中。具体情况我们通过诊断报告详细展开。

  进入故障列表后也可以看到，这里分别有ts-seat-service和ts-order-service两个节点的多份故障报告，同时已经做了聚合。 点击ts-seat-service的TraceID后进入该节点最新的故障报告。一份故障根因诊断报告有部分内容及多种相关Log、Trace、Metrics数据聚合分析而成，这里分别简单介绍。

• 诊断报告概要。包括TraceID、故障发生时间、请求耗时、耗时对比信息等基本信息。

• 单次调用链路信息。故障链路的调用详细信息及耗时信息。

• 故障根因。即该故障报告的最终结论信息及建议处置方法。该报告显示故障根因并不在 ts-seat-service 处，判定根因节点在下游服务处。接下来在对报告中关联的各类指标介绍过程中简要说明为什么会得到这个故障根因结论。

• 故障节点分析。报告中会对响应时间与历史基线进行比对，同时自动关联异常时间段的日志信息，无需再去通过其他手段查找。

• 接口执行耗时分析。这部分报告会对本次调用的北极星排障指标与历史基线值进行比对。主要包括CPU时间、网络时间、等待时间、其他时间（主要为存储时间等）。这里可以看到本次调用耗时最长的是网络时间 183.35ms，而且远超历史基线值。分析到这里往往会认为该服务可能存在网络问题。接下来我们对该指标继续下钻，对网络层面的指标进行更加深入地钻取。

• 对外调用具体信息。

• 请求网络耗时详细分析。这部分报告针对网络指标进行了更加详细的拆分和数据钻取，对广义上的网络耗时进行的更细致的分析，为判定网络是否出现问题提供更有说服力的证据。

• 网络质量指标。同时 Kindling-OriginX 会对整体的网络质量进行分析，即结合分段的网络时间和网络质量来综合判定网络耗时长是由于网络问题还是由于其他问题导致。所以在本例中分析后得出的故障根因结论为下游服务可能出现问题

• 接下来继续分析ts-order-service的故障根因报告。同样打开一份ts-order-service的诊断报告。故障根因显示：Runq耗时高，存在CPU抢占。从接口执行耗时分析中也可以看到，runq耗时占比最大，耗时180.27ms。根据这份报告，先来解释下什么是runq。

  runq(Run Queue Latency) 是一项描述操作系统性能、稳定性的重要指标，它描述了线程从进入就绪态到运行态的等待时间。CPU runqueue是一个表示等待CPU时间的概念。它是一个系统的活动队列，用于存储正在等待CPU资源的进程。当一个进程请求CPU资源时，它会被添加runqueue，等待CPU分配时间片。

  

• 结合runq的定义和 Kindling-OriginX 给出的根因报告，我们可以得到的结论是ts-order-service节点 CPU资源不足。

  到目前为止，报告解读完成，目前根据得到故障报告可以得到两个结论，分别是：

  1. ts-seat-service 网络指标正常，但网络耗时高，可能为下游节点故障。

  2. ts-order-service CPU资源不足。

级联故障处理​

• 在微服务系统中，任何单一故障往往都会以级联故障的形式表现出来，在该例子中即为ts-seat-service 和 ts-order-service 都发生了故障。从调用链路图中可以看到，ts-seat-service 是ts-order-service的上游节点。结合目前的结论和调用链路图，可以判定出ts-seat-service的调用慢非常有可能是由于ts-order-service慢导致的，根据级联故障处置优先级原则，应当优先解决被依赖节点的故障及ts-order-service。

  

• 在 ts-order-service 的故障根因报告中显示「Runq耗时高，存在CPU抢占」即表明该节点CPU资源不足，执行业务过程中耗费了大量的时间等待CPU资源。即CPU资源被我们注入的故障「运行额外任务抢占Pod可用的CPU资源」所抢占，导致链路中的请求在此处产生大量的等待，所以同时也会看到ts-seat-service的网络调用变慢，因为ts-seat-service的下游服务有锁。

小结​

故障根因报告在 Kindling-OriginX 中扮演着重要的角色，它综合分析和展示了各种分散的Log、Trace、Metrics数据，结合专家经验自动完成关联聚合，避免了可能的信息断片和数据交叉误解，真正做到了从表面现象到深层次原因的逐步剖析。通过直观的报告展示方式，以全新的思路为故障排查定位以及故障根因的确定提供更加高效和便捷的解决方案，为实现分钟级定位级联故障，落地 1-5-10 故障响应机制提供一条可行之路。

随着云原生、微服务等技术给企业带来竞争力的同时，也使得系统更加的复杂。日趋复杂的系统让故障根因难以排查，导致处理故障的大部分时间都用在了对问题的定位上。能够明确知道系统发生了什么是进行问题定位的前提之一，所以如何对系统进行监控，如何获取到规模庞大的系统的运行状态，也都成为了新的挑战，这种挑战反过来也促进了可观测性领域的发展。

可观测性的目标​

对于很多成熟企业，很多已经构建了APM、NPM等监控体系，以及Trace、Log分析系统等。而对于一些起步不久的企业，可能还处于可观测性建设的初期阶段。

那么对于不同阶段的企业和技术团队，是否对可观测性的要求有所差异呢？

总体上来说，可观测性代表了当前对系统形成洞察的能力，可观测性成熟度越高，对系统的洞察能力就越深入越完整，即系统的可观测性成熟度越高，就能越迅速、越准确地从发现的问题中找到根本原因。因此无论企业目前处于什么阶段，当前可观测能力的建设水平如何，其对于可观测性能力建设的目标应当都是一致的。

目标具体包括：

• 更全面的数据采集
• 更有效的关联各种类型数据
• 更快速与自动化的确认问题根因

各个企业在观测性建设成熟度上的差异，也主要体现在对这些目标的达成程度的差异。

可观测性成熟度​

为了能够更好的帮助与指导企业进行可观测性的建设，衡量及评估自身当前可观测性建设水平，有很多机构与公司都发布过对可观测性成熟度模型的定义，本文以龙蜥社区与信通院稳定性保障实验室联合发布的《2023年可观测性成熟度模型白皮书》为例进行说明。该模型是一种用于衡量和评估企业软件系统内部可观测性的框架或方法，同时也是一种用于反馈企业可观测性体系建设成熟度水平的框架或方法。

该模型包含五个级别，分别是：

• Level 1：监控。确定系统组件是否按预期正常工作。

• Level 2：基础可观测性。确定系统为什么不工作。

• Level 3：因果可观测性。找到问题的根本性原因，并确定它的影响面，避免再次发生。

• Level 4：主动可观测性。自动化的找到问题根本性原因，自动化的响应处置，智能化的预测预防，阻止异常风险发展成为问题故障。

• Level 5：业务可观测性。确定对业务的影响，如何降低成本、增加业务营收、提升转化率、辅助商业决策。

可观测性建设成熟度越高，团队越能够通过合适的数据自动发现和修复问题，甚至主动识别和预防问题。可以简单理解为越多的故障能够通过可观测性工具发现，甚至主动预防，说明其成熟度越高，如果仍旧有较多问题通过客服侧或其他渠道上报而来发现，那么说明其成熟度还不够。

使用故障注入对可观测性成熟度进行检验​

什么是故障注入​

混沌工程是一种方法论，而混沌工程的核心就是注入故障。通俗理解，以应用为出发点，在各种环境和条件下，给应用系统注入各种可预测的故障，以此来验证应用在面对各种故障发生的时候，它的服务质量和稳定性等能力。

故障注入是衡量可观测性建设质量的有效标准​

在实际生产环境中，对可观测性建设成熟度及质量的最直接的衡量方式就是评估有多少故障是通过可观测性工具发现甚至预防的。

这是一个最直观的标准，如果花了很多精力、物力、人力做了完备的可观测体系建设，但是仍旧有大量的故障没有能够被观测到，甚至仍旧出现P0级别的故障，是没有人能够认同这个体系的建设是成熟的、是高质量的，只是单纯的可观测性数据和工具的堆砌。

而故障注入作为真实故障的模拟，与真实场景最为接近，也最能够有效地评估系统在面对实际故障时的响应和恢复能力，也最能够有效的反映出可观测性体系在实际问题场景中是否能够真实有效的发挥作用，为解决问题提供最切实有效的价值。业内技术领先的公司，也经常采用故障注入演练的方式对自身系统的健壮性进行检验，查漏补缺不断提高可观测性工具对问题发现和预防的比例。

故障注入虽不能涵盖全部的故障问题，但目前主流工具已能将大部分常见的网络、系统、代码、容器问题进行模拟，能够有效帮助组织评估、改进和发展其可观测性能力。Kindling-OriginX 在产品设计与开发过程中也使用这种方式进行能力的检验和产品的迭代。

总结​

如果想要对自身可观测能力进行检验，也可与Kindling-OriginX Demo采用类似方式，在目标环境中部署soma-chaos。

soma-chaos 目前已支持的故障类型有：

• 网络类故障案例。例如丢包率较高、重传率较高、带宽限制打满、DNS故障、TCP建连延时高

• 存储类故障案例。例如IO延时高

• CPU类故障案例。代码自身CPU使用率高、共享环境其它进程抢占CPU

• 内存类故障案例。FULL GC频率很高、共享环境其他进程抢占Memory

• 代码类故障。代码抛出异常导致错误码返回、HTTP请求返回错误码

soma-chaos 是一个开源模拟故障案例集系统。该项目开源在龙蜥社区系统运维联盟之下，其中包括复旦大学SELab开源的业务模拟系统Train-Ticket、Chaos-Mesh开源云原生混沌工程平台、收集整理的真实故障案例集。欢迎任何单位和个人提交贡献故障案例，一起讨论故障注入实践或在使用过程中产生的任何想法和问题。

参考资料​

Train Ticket：A Benchmark Microservice System

gitee-soma

Chaos Mesh

故障注入使用指南

线上故障通常是指影响线上服务可用性的问题或者事件，包括服务性能的降低、出现影响用户体验的问题、不同程度的服务不可用等。为了确保服务稳定性和用户体验，线上排障的第一目标是恢复线上服务或者降低影响。随着技术的发展，产生了诸如Google、Amazon、Twitter、淘宝、得物、字节等新兴互联网公司，其业务体量大，系统复杂程度高，时时刻刻服务成千上百万的用户，这都对故障处理的能力和及时性都提出了更高的要求。本文对互联网公司线上故障标准化排障流程做一简单分析，总结一些肤浅的方法论，以求共同探讨，共同提高。

故障处理目标​

故障管理的目标是“尽快恢复服务到正常运行，并且最小化对业务运营的不利影响，从而尽可能地保证服务质量和可用性的水平”，即所谓的止血。即使不能立刻完全恢复，也要想办法将其影响降到最低，迅速止血。所以往往重启服务、扩容、降级、熔断等方法都是在紧急情况下首先想到的方法，先试试再说，之后再彻查问题，从根本上解决问题。

实际工作中，找到了问题的根因原因，解决问题之后，并不代表本次处置就完成了。对于任何一个故障，其真正的处理目标应该是两方面，一方面尽快恢复服务，完成止血；另一方面要及时复盘总结，举一反三，不断完善流程处理机制，弥补操作过程中的规范问题，形成报告，在公司层面分享总结经验，提高应对能力的同时也要能够减少同类故障的发生。

故障处理思路​

线上故障处理的目标是最快速度恢复线上服务或者降低对线上服务的影响，“快速”是对其最基本的要求之一，所以要要求故障发生时候需要能够最短时间发现，发现后要能最快对其进行评估和分类，同时根据评估结果能够充分调动各方资源最短时间内制定出可执行的应对方案，同时在整个处置过程中也都需要运维、业务研发、产品、基础设施等多团队互相协作，保持高效的沟通。基本的处理思路如下：

故障识别与告警​

线上故障一般通过多种途径传递到开发、运维团队中，例如主动巡检发现，各纬度各类型监控告警，关联故障追溯，生产事件上报。首先需要对上报的信息判定是个例问题，还是确实是线上故障。以主动发现为根本建设目标，例如可观测性建设的目标和价值体现就是能够将故障主动、及早发现和定位。

故障评估与分类​

针对识别出的问题，进行严重性评估，判断问题的影响范围和严重性。根据评估结果，将问题进行分类，设定问题处理的优先级，同时通知各相关业务、技术部门人员故障情况，准备参与排查。进行评估分类需要多维度的数据支撑，往往缺失数据或存在盲区时更多依赖人员经验和能力。

故障定位与分析​

确定故障后，需要快速定位到问题点，找到原因，以便针对性的采取合适的应对方案。在这过程中需要该故障涉及到的业务、开发、运维人员各负其责，分析系统日志，查找错误信息和异常行为，收集与问题相关的数据，如流量统计、错误率等，为问题解决提供依据。

该阶段是排障过程中最关键的阶段，往往无法估计具体时间，具体步骤往往也根据业务种类、问题表征、可观测性建设成熟度、团队能力等不同而有所差异，现阶段难以进一步标准化，所以也导致该阶段也是最难得一步。

这里举一个简单的例子，排查中往往是排查三板斧：模拟复现，找相关数据，分析完整请求链路。这其中找相关数据需要在各个可观测性工具里找到相关的数据，并将其关联，这是一个非常复杂且耗费时间的任务。同时，需要将这些数据，与其对应的 Trace 数据相对应，才能尽可能真实地还原出问题现场。但实际生产环境下，Trace数据茫茫多，人工分析几乎不可能，这也是为什么经常会重启服务、扩容、降级先试试看的原因。

故障排除与管理​

根据问题定位和分析结果，制定相应的行动措施，执行对应的预案或采取合适的措施修复问题。同时在解决问题时，也需要遵循变更管理流程，确保每一步更改都有记录，以免派生出新的故障。

故障验证​

在完成恢复或修复操作后，进行必要的测试，查看相应的监控指标数据，确保问题已经解决。同时恢复服务后，继续监控以确保系统稳定。将信息同步反馈到各干系人，如有需要，配合业务方完成故障期间受损的数据。

故障复盘​

一般在故障处理结束后24小时内产出故障报告，包括故障过程回顾、故障原因分析、改进预防措施制定、故障定级等。故障定级分为P0、P1、P2和P3四个等级（依次降低），各公司都有特定的等级定义，主要从业务影响面和影响时间来确定。一些团队或公司会总结故障知识库，作为排障知识的传递方式，以期保证人员能力和经验能够进行复制。

排障流程的标准化​

排障流程的标准化是指将故障处理的各个环节规范化、流程化，以确保在面对系统或服务故障时，团队能够快速、有效地采取行动。

通过对故障处理思路的总结，可以看到排障流程标准化存在的主要问题一方面是故障定位和分析难以快速完成，同时也无法标准化；另一方面人员能力和经验的差异也导致标准化处理的过程在很多团队难以落地。

相关案例​

下面以一些互联网公司的故障处理流程为例以供参考，图片和资料均来自于网络。

得物容器SRE响应流程​

有赞故障处理流程​

美团大数据运维故障处理流程​

标准化排障流程需要体系和工具支撑​

从上面的案例可以看到，标准化排障流程需要一套完整的体系支撑，以确保流程的顺利执行和持续优化。以下是构建支撑体系的几个关键要素：

1. 技术工具​

• 成熟的可观测性体系：建立成熟完善的可观测性体系，能够确保尽早发现问题，同时排障过程中能够覆盖尽可能多的数据，以期最大限度消除观测盲区。

• 故障响应平台：能够对故障生命完整生命周期进行追踪，同时对各类指标数据进行治理，在故障时刻提炼相关联的数据，帮助处理人员聚焦核心指标。

• 知识库：建立和维护故障知识库，用于存储故障案例、解决方案和预防措施，为各类问题提供可执行的预案。

2. 流程文档​

• 标准化手册：制定能够对于不同类型的故障能够统一执行的操作方法。

• 操作指南：为常见故障类型提供操作指南，帮助不同经验和能力水平的团队成员快速定位问题和解决方案。

3. 组织结构​

• 专业团队：建立专业的技术和运维团队，负责监控、响应和解决系统故障。

• 角色定义：明确团队成员的角色和职责，确保在故障发生时，每个人都清楚自己的任务。

小结​

线上故障处理的目标是快速止血，标准化排障流程是实现其方式的关键因素之一。通过建立一套完整的体系支撑，并不断优化排障流程，以期能够更好地应对系统故障，提高服务质量和用户满意度。

标准化排障流程的成功实施需要一套完整的体系和工具支撑。这包括组织结构、流程文档、技术工具、沟通机制、团队培训、持续改进等多方面因素。一方面很多团队很难像这些大型互联网公司一样真正落地故障处置规范，建立完备的可观测性体系，花费人力物力进行数据指标的治理。另一方面很多企业建立的完善的可观测性体系，但是仍旧无法通过现有工具弥补人员经验、能力、操作方式、使用习惯的差异。这都使得标准化排障流程难以真正落地实施，致使可观测性数据价值无法被有效发掘。这些问题都需要平台化的能力和更先进的工具来解决。

随着技术的发展，特别是可观测性领域的发展，目前也出现了一些新工具能够帮助我们缩小这其中的差距，例如Datadog、Kindling-OriginX、X-Ray、Dynatrace等都通过各自不同的方法和理念去实现故障标准化排障流程。

在现代编程中，线程池已经成为了不可或缺的一部分，特别是在Java编程开发中，线程池更是绕不开技术点。然而，要想取得优秀的性能表现，需要对线程池的参数进行调优。本文将深入讲解 Java 线程池的调优方法和技巧，帮你提高编程技能和优化系统性能，并介绍如何使用 Kindling-OriginX 来深入理解线程池参数设置。

什么是线程池​

线程池是一种管理和重用线程资源的机制，是利用池化思想设置和管理多线程的工具。线程池维护一定数量的空闲线程，当有任务需要时，就从中选择一个空闲的线程用来执行任务，当使用完成后该线程就会被重新放回线程池中，通过这样循环使用的方式来节省创建线程和销毁线程的各项资源开销。

线程池重要参数解析​

线程池中有多个关键参数，需要在创建线程池时对其进行设置，合理的参数设置能够达到最佳的性能，适应任务场景。这里以ThreadPoolExecutor为例，对几个重要的参数进行解析说明。

corePoolSize​

核心线程池中线程的数量。当提交一个新任务时，如果当前线程池中的线程数量少于corePoolSize，就会创建新的线程。即使此时有空闲的非核心线程可使用，也会创建线程，直到达到corePoolSize配置数量。

maximumPoolSize​

线程池中最大的线程数量。包括核心线程池和非核心线程池，即在任务队列已满的情况下，可以创建的最大线程数。当线程数量超过maximumPoolSize时会执行配置的拒绝策略。

keepAliveTime​

线程存活时间。当线程池中的线程数量大于corePoolSize时，超出的空闲线程最大能存活的时间，超过这个时间，线程就会被回收，直到线程数等于corePoolSize。

unit​

时间单位

workQueue​

任务队列实现。用于存储已提交未被执行的任务。线程池根据任务队列的策略来进行等待任务的调度。常见的队列有：

• ArrayBlockingQueue：数组实现的有限队列，可以指定队列长度。

• LinkedBlockingQueue：基于链表的无限队列，长度可以无限扩展。

• PriorityBlockingQueue：优先级队列，可以设定队列里任务的优先级。

参数设置原理​

为了最大程度利用线程池的资源，充分发挥线程池的执行效率，需要对线程池的主要参数进行合理的设置，对于不同的业务和场景，也需要根据实际情况来进行调整。

• 核心线程池大小corePoolSize和最大线程池大小maximumPoolSize一般需要根据实际场景设置，主要与执行任务的类型和数量相关。一般最佳实践建议是将核心线程池设置为CPU核心数 + 1，最大线程池大小设置为CPU核心数 x 2。

• KeepAliveTime线程存活时间，一般根据任务处理的耗时配置。如果任务密集且耗时长，则可以适当增加空闲线程的存活时间，根本目的是尽可能减少线程的创建和销毁操作，原则上不超过60s。

• workQueue阻塞队列的类型及大小需要根据具体场景来设置。通常来讲任务数量多或并发高，选择无界队列，避免任务被拒绝。任务数量可控选择有界队列。

---

虽然参数设置原理看似简单，但实际使用中仍存在一些问题：

• 人员经验和能力不同，经常以个人习惯或理解进行设置，没有标准或者数据依据。

• 执行情况和任务类型、并发情况、机器配置都有关系，导致同样参数也可能运行起来情况有差异。

• 同一个应用中可能存在多个不同业务类型的线程池。

常见线程池参数配置方案及其问题​

上面参数设置大多基于经验，是否有科学的方式能够根据场景对其进行计算或者评估？

常见理论方案​

这里以美团技术团队调研的业界一些线程池参数配置方案为例：

• 第一种方案过于理论化，偏离任务场景。

• 第二种方案也不符合实际情况，应用中往往不可能只存在一个线程池。

• 第三种方案过于理想，正常情况下流量存在高峰低谷，同时大促、秒杀等运营活动期间流量更不可能是均衡的。

其他方案​

在《linux多线程服务器端编程》中有一个思路，CPU计算和IO的阻抗匹配原则，根据这个原则可以推出估算公式：

最佳线程数目 = （线程等待时间与线程CPU时间之比 + 1）* CPU数目

这也是网络上流传的比较多的方法之一，包括其衍生出的案例：

假如一个程序平均每个线程CPU运行时间为0.5s，而线程等待时间（非CPU运行时间，比如IO）为1.5s，CPU核心数为8，那么最佳的线程数应该是？

根据上面这个公式估算得到最佳的线程数：((0.5+1.5)/0.5)*8=32。

这个方法看似严谨，但也存在很大问题，因为其结论可以简单等价为线程等待时间所占比例越高，需要越多线程，忽略了线程切换开销和锁，同时也忽略应用CPU密集型、IO密集型、内存型区别，以及硬件环境不同带来的差异性。

上面的这些方案看似合理，但是在实际场景下却未必合理，实际情况下都需要结合系统实际情况和硬件环境，通过合适的工具尝试达到一个符合实际场景需求的合理估算值。

使用 Kindling-OriginX 进行参数调优​

这里以 Kindling-OriginX 为例，说明如何使用其提供的北极星指标体系进行线程参数配置的优化。

北极星指标​

cpu​

程序代码执行所消耗的CPU cycles

runq​

线程的状态是Ready，如果CPU资源是充分，线程应该被调度到CPU上执行，但是由于各种原因，线程并未调度到CPU执行，从而产生的等待时间。

net​

网络时间，主要包括DNS，TCP建连，常规网络调用

futex​

通常指的是一个线程在尝试获取一个futex锁时因为锁已经被其他线程占用而进入等待状态的时间。在这段时间内，线程不会执行任何操作，它会被内核挂起。

file​

存储操作时间

通过上述指标的具体时间，我们就可以知道每一次调用程序具体耗时在哪些地方，该从哪些方向进行优化，cpu资源是否被充分使用，还是时间都被消耗在了线程切换上等等。

调优案例解析​

下面以使用 Kindling-OriginX 为例，说明如何对线程池进行参数设置与优化，并找出系统链路中的真实性能瓶颈。对于单一线程池可以通过 Kindling-OriginX 确定其是cpu密集型还是说IO密集型任务，对于多线程池可以通过 Kindling-OriginX 以数据为基础，对多个线程池综合调优，使应用达到最佳状态。

案例一​

从北极星指标中可以看到，该次调用futex时间很长，可能是存在Full GC导致，也可能是程序中产生了锁等待，锁的竞争非常激烈，此时增大线程池也并不可能提高性能，可以考虑从优化任务执行代码入手。如果该服务是上游服务，则可以考虑加大下游服务的线程池尝试增强处理能力。

案例二​

runq是一个表示cpu等待的概念，它是一个系统活动的队列，用于存储正在等待cpu资源的进程，本例中runq数值很高，说明cpu资源紧张，没有资源分配给线程使用，可以认为该线程池处理的任务为cpu密集型任务，一方面配置参考Ncpu + 1的方式，尽可能提高利用率，减少上下文切换，同时考虑减少目前配置大小，合理配置线程池队列长度，设置合理的拒绝策略，避免导致上游方法或服务产生大量锁等等。另一方面需要考虑扩充资源或查看机器监控等指标，分析是否出现了异常的资源抢占。

案例三​

在北极星指标中，file一般指代存储相关操作。该例中，主要操作耗时是磁盘存储操作，在不考虑存储设备异常的前提下，该线程池可被认为是一个负责处理IO密集型任务的线程池，这种情况下可以考虑对该线程池采用Ncpu * 2的方式进行配置，并酌情增大。

对于单个或多个线程池的参数调优，亦可以Trace的角度出发，通过链路分析的方式，对单一节点的调用耗时进行分析来判断该服务中线程池的优化方向，单个线程池可以根据任务类型参考业内最佳实践，多个线程池可以根据北极星指标分别针对性的调整后综合分析，以求达到多个线程池的最佳资源利用状态。

小结​

对于业务中的线程池问题，需要对线程池的工作原理及各参数含义有深入理解，同时也需要能合理根据实际场景选用合理的工具对其参数进行调优，不能一味生搬硬套业内经验。可以通过 Kindling-OriginX 等工具对程序执行的各项指标进行分析，以数据为导向，合理调配，才能真正提高线程的复用和效率，适用不同的业务场景，提供系统性能，结合实际情况和真实数据才是最佳实践。

系统在业务平峰期间运行稳定、性能良好，但在大流量时就会出现各种各样的问题，例如接口时延变大，CPU占用率升高、频繁发生Full GC、代码中出现死锁等等。大流量意味着高并发，高并发也是很多开发人员所期望拥有的经验，一方面能够接触更加复杂的业务场景，提高自身能力，另一方面对于高并发的解决思路需要依靠经验积累，通过踩坑填坑的方式不断精进。而这其中扩容又是最常见的应对高并发场景的思路。

什么是扩容​

扩容，通常指为了提高系统的处理能力，而采取的增加计算或其他资源的一系列措施，以此来提升系统的性能。

传统意义上的扩容一般只单单针对硬件计算资源，策略上可以分为两种，一种是对单机整体扩容，也就是整机的CPU、内存、磁盘等等；另一种就是扩容对应的组件，例如提高CPU性能，升级读写性能更优秀的磁盘等。而在云原生、微服务等技术越来越普及后，扩容的概念也不再单单指计算资源，而是扩展到架构领域，例如流量高峰期针对某一中间件资源进行扩容，或针对某一核心服务进行扩容，这使得扩容能够更高效、更有目的性。

随着技术的发展和业务的复杂度的上升，也要求扩容更有目标性，更快速，这就要求在实践中对于扩容的目标、策略、方法，以及系统的架构设计都要有深入的理解，同时也需要有合适的工具对其进行技术支撑。

扩容目标​

扩容是为了确保系统在面临高并发访问、大数据处理等场景时，能够保持良好的性能和稳定性，不会因为资源不足而出现服务响应缓慢、系统崩溃等问题。

扩容是一个系统性的工程，需要综合考虑成本、性能、可靠性等因素，并采取适当的策略和技术来实现。目标具体来看主要有以下几点。

提高系统并发能力：通过增加系统资源，提高系统处理请求的能力，从而应对高并发访问。

保证系统稳定性：在扩容过程中，确保系统运行稳定，避免因资源分配不当导致的性能波动。

降低成本：在满足业务需求的前提下，合理利用现有资源，降低扩容成本。

易于实现：能够快速做出响应，同时不影响正常的业务功能设计和开发。

常见扩容思路​

架构层面​

从架构上来看扩容可以分为两大类：

横向扩展(scale-out)​

又名水平扩展，即用更多的机器来支撑大量的请求。常见的集群模式往往就是这种思路。以运送货物为例，当大量货物需要运输时，使用更多的货车进行运输。

纵向扩展(scale-up)​

又名垂直扩展，扩展一个节点或单一机器的能力，使一个点能够支撑更大的请求。例如使用高性能计算服务器，其往往有更强的单体计算能力。同样以运送货物为例，当大量货物需要运输时，将货车升级，让每个货车更大更快。

业务层面​

从业务类型上来看扩容也可以分为：

读操作扩展​

如果系统中读操作占大多数，那么可以通过找到关键的资源瓶颈，对其进行扩容或增加其资源进行扩展。例如MySQL是资源瓶颈，那么增加多个只读从库，业务高峰期扩展只读库副本数进行横向扩展，亦可以提高MySQL服务器的性能采用垂直扩展的思路增强其处理能力；增加一个或多个redis将热点数据进行缓存等。这都是通过读写分离的思想，针对性的以业务角度出发对读操作进行扩展。

写操作扩展​

如果系统中写操作为主，往往提高单个节点的能力性价比较低，通常考虑使用HBase、MiniIO等分布式存储方案，方便后期不断进行水平扩展。

异步处理​

将一些有延迟、等待任务放入消息队列中，利用中间件实现业务功能，提高系统吞吐量。或通过异步的方式对服务进行解耦，一方面便于针对性进行扩容，另一方面将时延敏感度较低的业务分离，提高核心资源利用率。

利用云服务、CDN等第三方能力​

对于一些静态资源或大文件读写场景，使用CDN缓存的方式来减少自身服务器的压力，同时云服务厂商很多功能目前都已提供弹性扩容能力，按需付费即可获得自动化的扩容缩容能力。以阿里云函数计算为例，预留模式中只需要配置好弹性伸缩规则，即可自动根据流量情况进行实例的扩容缩容。

实际业务场景中，往往不是单一地使用某一种扩容方法就能解决问题，选择哪种扩容思路取决于具体的业务需求、系统架构、预算以及预期的性能目标。最佳实践应当是结合多种扩容策略，实现灵活、高效、成本合理的系统扩展。

评估扩容需求的步骤和方法​

评估是否需要扩容以及需要扩容哪些资源，通常需要进行全面的系统分析和性能监控，并且要能够准确地识别系统运行状态。

1. 性能监控：​

使用监控工具（如Prometheus）来收集系统的性能数据，包括CPU使用率、内存使用率、磁盘I/O、网络流量、响应时间等。

分析性能数据，找出系统的瓶颈所在。例如CPU使用率经常处于高位，则可能需要增加计算资源；如果磁盘I/O压力大，可能需要升级磁盘或使用更快的存储解决方案。

2. 容量规划：​

根据业务增长趋势和用户需求预测，进行容量规划。考虑未来的数据增长、用户增长和交易量增长等，预测所需的资源量。

对比当前资源容量和预测的资源需求，确定是否需要扩容以及需要扩容的规模。

3. 压力测试：​

通过模拟高负载场景来测试系统的性能极限。这可以帮助确定系统在压力下的表现，以及哪些资源会成为瓶颈。

分析负载测试结果，找出系统在哪些方面需要改进或增加资源。

4. 应用分析和优化：​

分析应用代码和架构，找出性能优化点。通过优化代码或改进架构，减少对资源的依赖。

使用 Kindling-OriginX 确定扩容策略​

这里以 Kindling-OriginX 为例，说明如何使用其提供的北极星指标体系找到高并发场景下的瓶颈点，为扩容方向提供明确指引。

北极星指标​

cpu​

程序代码执行所消耗的CPU cycles

runq​

线程的状态是Ready，如果CPU资源是充分，线程应该被调度到CPU上执行，但是由于各种原因，线程并未调度到CPU执行，从而产生的等待时间。

net​

网络时间，主要包括DNS，TCP建连，常规网络调用

futex​

通常指的是一个线程在尝试获取一个futex锁时因为锁已经被其他线程占用而进入等待状态的时间。在这段时间内，线程不会执行任何操作，它会被内核挂起。

file​

存储操作时间

通过上述指标的具体时间，我们就可以知道每一次调用程序具体耗时在哪些地方，结合SLO实时异常检测确认是否出现了影响用户体验的问题，即可快速对是否需要进行扩容，哪些节点，哪些资源需要扩容做出判断。

实战案例解析​

下面以使用 Kindling-OriginX 为例，说明在实际生产环境中，如何有针对性地确定和实施扩容策略。以数据为导向，告别盲目使用扩容、升配试一试的方式应对高并发场景下的各种问题。

案例一​

业务高峰期间通过SLO入口检测发现业务入口延迟变大，已经影响到用户体验。

通过查看慢调用的链路传播链，定位到造成影响的服务节点是ts-train-service

查看节点的北极星指标可以看到runq耗时异常，参照runq指标的含义，说明当前CPU不足，这种情况下优先考虑对该服务进行扩容。

案例二​

该案例中定位到产品问题的节点是ts-order-service

同样利用北极星指标分析，发现是由于file耗时异常导致， 此时盲目进行横向扩容并不能解决问题，对该存储相关操作异常的原因继续下钻分析。

下钻后 Kindling-OriginX 将会定位到具体文件，及该文件具体的读写指标数据，通过这些数据首先分析该读写操作是否是正常业务行为，如果是正常业务行为，接下来根据读写情况来看是否需要对其进行读或者写扩展。如果文件读写较为平均，那么考虑对问题节点或机器的磁盘性能进行增加，采取垂直扩展的思路先解决问题，之后从代码设计层面和系统架构层面考虑重新设计该文件操作的业务流程。

通过上面两个案例可以看到，高并发场景下很多性能问题都可以通过扩容解决，但同样不存在银弹，盲目的扩大服务容量或提高机器性能，都可能只是无效扩容。没有合适的工具发现瓶颈点，选择了错误的扩容策略和方向，只会浪费时间、金钱、人力，却不能真正解决问题。

小结​

在高并发场景中选择合适的扩容策略，往往要对系统整体架构和各个业务系统非常熟悉，同时也要对常见系统性能优化方式有深入了解，这都需要大量的经验积累和技术能力，也需要能合理根据实际场景选用先进的工具获取系统中的关键运行信息，不能一味生搬硬套业内经验。可以通过 Kindling-OriginX 等工具对系统执行过程进行无盲区的观测，以数据为导向，采取对症下药的扩容方式。

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

标准化排障的意义​

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

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

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

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

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

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

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

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

依赖专家经验和能力​

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

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

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

工作量大，难以规范统一​

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

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

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

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

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

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

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

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

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

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

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

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

简化的操作界面​

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

排障知识库​

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

小结​

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

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

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

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

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

“很多用户觉得我们在吹牛，根因分析做不出来，其实我们一直在做对的事——现在论文也证明了这点。”

背景​

在当前AIOps领域，主流做法多集中在围绕 Trace、Log、Metrics 的机器学习建模与关联挖掘，寄希望于在复杂数据中“找出”故障根因。但我们在与大量企业沟通后发现，这种方式在实际生产环境中往往难以落地 —— 算法容易泛化失败，结果无法解释，根因归因流于表面，甚至被质疑“是否真的能做到”。

我们的观点是：如果一个经验丰富的人都很难给出确定且可解释的根因判断，而需要依赖现象推测与试错过程来还原问题，那算法更不可能自动做到这一点。因为这些故障往往需要通过上下文、调用链、线程与资源的交互等复杂的程序行为路径来还原，不是简单依赖几个KPI指标变化，靠模型“拟合波动模式”就能判断出来的。这类问题的本质并不是数据挖掘，而是“对程序运行机制的理解”与“对故障传播路径的观察”。只有把这些底层行为真正观测到，才能找出根因。

我们致力于通过eBPF技术直接采集线程级的内核资源交互信息，从线程与锁、磁盘、CPU调度、futex、epoll、socket 等系统资源的精细互动中还原问题现场。然后基于这些数据，结合我们的经验构建出专家规则小模型，并使用业界相对比较成熟的算法来实现故障根因分析 —— 用最基础但最扎实的方式解决根因定位的“最后一公里”。

我们这套理论比较新，和很多用户交流的时候，很多用户觉得我们在吹牛。我们理解这种质疑，但我们一直坚信：我们不是在“吹牛”，我们是在做对的事。

最近我们看到一篇 arXiv 上的最新论文《eBPF-Based Instrumentation for Generalisable Diagnosis of Performance Degradation》（2025年5月），首次从学术角度全面验证了我们坚持的方向是可行且高效的。

该研究提出了一套跨应用、跨语言的 eBPF 监控体系，通过16类内核子系统指标构建“线程行为画像”，在Kafka、MySQL、Cassandra等典型系统中完成了无需trace、无需日志的自动根因归因，准确识别出锁竞争、磁盘瓶颈、CPU争用、外部依赖等多种常见性能劣化问题，诊断路径完全可解释。

我们采集的数据基本一致，只是分析角度和论文略有区别，下面是论文的核心思路。

---

论文思路​

这篇论文的核心目标，是探索一套无需依赖应用层trace和日志，仅通过eBPF从系统内核采集“线程与关键资源交互数据”，就能完成跨应用场景的性能劣化诊断的方法论。

1. 核心问题定义​

论文指出，当前性能诊断面临两个核心难点：

• 第一是数据粒度不够：系统级指标（如CPU利用率）过于粗糙，无法解释“到底哪个线程在等待什么资源”；

• 第二是通用性差：很多诊断方法依赖特定中间件、语言、日志或trace结构，难以跨系统使用。 因此，作者尝试构建一个通用、跨平台、跨语言的“线程行为画像”体系，通过eBPF捕获线程与资源的交互路径，反推出性能问题的根因。

2. 指标体系设计​

作者基于六大内核子系统构建了16类eBPF指标，具体包括：

子系统	指标例子	描述
调度	runtime，rq time，iowait time	线程在CPU、runqueue、iowait上的耗时
futex	futex wait time，wake count	锁竞争情况，包括等待和唤醒频次
pipe/socket	pipe wait time，socket wait count	跨线程通信延迟，识别阻塞关系
epoll	epoll wait time，epoll file wait	识别异步IO等待瓶颈
block IO	sector count	识别磁盘压力或争用情况
VFS/网络	多个等待与访问频次指标	提供线程级资源使用视角

指标采集遵循“只监控与目标应用有关的线程”，避免全系统追踪带来的性能开销。

3. 分析方法：选择性线程追踪 + 行为分布变化检测​

诊断的关键流程如下：

1. 识别入口线程：通过 socket wait、epoll wait等指标找到对外提供服务的入口线程；
2. 追踪依赖线程：只追踪与入口线程有pipe/socket/futex等资源交互的“对等线程”，逐步构建线程依赖链；
3. 检测异常分布变化：将每个线程的指标时间序列与业务KPI（如95延迟）对齐，对齐后若出现类似分布漂移，即可标记该线程及其资源为瓶颈点；
4. 推断资源约束路径：如果瓶颈线程依赖于某共享资源（如同一个pipe、锁、磁盘），则反推出具体瓶颈资源；
5. 生成可解释路径：最终输出“哪个线程被谁阻塞、阻塞了多久、原因是哪个资源”，而非一个黑盒评分。

这种方法类似于“因果链回溯”，但基于资源交互而非trace span依赖，因此更真实可靠。

4. 实验设计与验证​

论文通过多个真实系统场景验证该方法，包括：

• MySQL 磁盘与锁竞争混合瓶颈；
• Redis CPU瓶颈；
• Kafka 外部服务阻塞；
• Teastore 微服务依赖延迟放大。

实验结果表明，仅靠这16个eBPF指标，就能精准还原各类瓶颈根因，诊断准确率和解释性俱佳。且 instrumentation 开销极低，Redis 平均增加仅 0.3ms。

5. 总结与价值​

该论文的几个关键贡献与我们坚持的方向高度一致：

• 以线程为单位，而非进程或服务；
• 以资源交互为基础，而非指标波动为假设；
• 只追踪相关线程，避免trace噪声污染；
• 可解释性极强，每一个瓶颈都有清晰的因果链路；
• 通用性极高，适用于多语言、跨系统架构。

这使得论文不仅是我们方法论的理论背书，更是整个“新一代根因分析体系”的奠基石。

---

论文原文 https://www.arxiv.org/pdf/2505.13160