云平台产生告警风暴（四）：如何实现根因分析系统？

你好，我是王钊扬。

在上一讲中，我们深入且系统地阐述了根因分析（RCA）的全过程，旨在为大家构建一个清晰的理解框架。现在，我们的焦点将转向一个更为实践性的问题：如何将这些理论上的根因分析流程转化为实际操作中的有效应用？这正是本讲所要探讨的核心议题。

使用场景分析

在设计解决方案之前，我们首要任务是深入剖析潜在的用户场景，以确保我们的方案能够精准地满足用户的实际需求，从而实现更加高效和针对性的设计。

故障平台

故障平台是一个综合性的管理工具，旨在详尽记录故障的各方面信息及其处理流程。当系统遭遇大规模告警时，若根因分析系统能够自动识别并定位故障根源，并将这一关键信息连同受影响的其他告警一并记录在故障平台上，那么该平台的功能便得到了显著拓展。它不再局限于简单的故障记录，而是转变为运维工程师快速响应与定位问题的得力助手。
面对系统故障，运维工程师能够迅速访问故障平台，直接获取当前活跃故障的详尽信息，包括主导性的核心故障及其波及范围——即所有受影响的系统以及相关联的告警信息。这种即时的、全面的视野，极大地提升了故障排查与处理的效率与准确性。

历史故障追溯

当运维工程师着手追溯历史故障时，他们往往需要依据特定的时间范围来搜索这一区间内发生的所有故障详细记录。这一搜索过程旨在全面获取包括根本故障（即根因故障）在内的所有相关信息，同时追踪由该根本故障所波及的系统范围及其触发的所有相关告警。通过这样的时间区间查询，运维工程师能够系统地回顾并分析历史故障事件，为未来的故障预防与快速响应提供宝贵的经验和参考。

根因分析系统方案设计

经过对上述两个典型用户场景的细致剖析，我们可以清晰地认识到，一个完善的根因分析系统应当兼备实时根因分析与离线根因分析这两项核心能力。实时根因分析功能确保了系统能够在故障发生时迅速响应，即时定位问题根源，为运维团队提供即时的决策支持；而离线根因分析则侧重于对历史故障数据的深度挖掘与分析，帮助工程师从过往经验中汲取教训，优化未来的故障预防与处理策略。

基于前述深入剖析的业务需求，我们制定了根因分析系统的设计方案。此设计方案的核心内容已通过附图全面呈现，图中不仅详尽描绘了知识图谱的构建过程，还清晰地展示了根因分析的整体流程。接下来，我们将逐步深入，对这一流程进行详尽的阐述与解析。

知识图谱的构建

首先，让我们聚焦于设计图的右侧区域，这一关键部分聚焦于知识图谱的构建与可视化展示。知识图谱的构建过程被细化为两大核心环节：一是实体知识图谱的构建，它聚焦于实体间关联性的挖掘与呈现；二是事件知识图谱的构建，旨在揭示事件之间的逻辑关系与动态演进。

实体知识图谱构建

实体知识图谱的数据源广泛多元，尽管其数据来源多样，但实体间的关系可归结为三大类，每类均承载着不同的业务与技术逻辑：

• 任务关联类关系：这涵盖了任务之间的依赖链条及任务与服务间的映射关系。此类信息往往隐匿于配置文档与详尽的日志记录之中，通过深入解析这些数据源，我们能够清晰地勾勒出任务执行的脉络与服务调用的全貌。
• 应用依赖类关系：此类关系聚焦于应用层面的相互依赖与配置详情。应用间的依赖关系，可通过高效的链路追踪系统或精心设计的配置管理来揭示；而应用的部署详情，无论是传统方式还是容器化部署（如Kubernetes环境），均可通过相应的配置中心或管理平台轻松获取。此外，应用的特定配置，如数据库连接信息，则可从敏感资源管理系统中安全提取。
• 基础设施支撑类关系：这包括但不限于网络的复杂拓扑结构、服务器的具体部署位置等关键信息。此类基础设施层面的数据，同样是构建全面知识图谱不可或缺的一环，它们同样可通过专业的配置中心或管理平台进行统一管理与查询。

事件知识图谱构建

事件知识图谱，类似于故障树。在此框架下，事件可以划分为两大类别：常识性事件与普通事件。
常识性事件，作为一类不特定于具体业务逻辑，而是广泛适用于技术领域的通用知识，涵盖了如服务器宕机必然导致其承载服务中断、交换机网络中断将引发相关联服务器网络故障等普遍现象。这类事件可通过人工方式直接录入事件知识图谱中，为系统提供初始的、基础的知识储备，有效解决了系统初期因缺乏数据而难以启动的“冷启动”问题。
相比之下，普通事件则根植于过往故障数据的深度挖掘与分析，其识别与定义依赖于运维工程师的专业知识与经验，通过对历史数据的细致标注与解读，逐步构建出更为精准、全面的故障模式与影响分析体系。
事件知识图谱的构建正是基于上述两类事件——常识性事件与普通事件而展开的。在这一知识图谱中，每个事件都被精心构建，以包含两类核心信息：故障类型与故障对象。故障类型明确指出了事件所归属的故障种类或类别，为后续的故障分析与处理提供了直接的参考依据。
而故障对象作为事件的主体，其信息则更为详尽且多维度。它不仅包括了故障对象的类型，即该对象在技术或业务层面上的具体分类；还涵盖了故障对象所属的业务或系统信息，这有助于快速定位故障发生的上下文环境；此外，故障对象的实例信息也是不可或缺的一部分，它详细记录了故障发生时具体涉及的实体或资源，为故障排查与修复提供了精确的目标指向。通过这样的信息组织方式，事件知识图谱得以全面而深入地反映系统故障的全貌，为运维工作提供了强有力的支持。
事件知识图谱与实体知识图谱之间一个显著的区别在于其内在的方向性特征。实体知识图谱主要聚焦于实体之间的关联与属性，这些关系往往被视作无向的，即不特别强调信息的流动方向。然而，事件知识图谱则截然不同，它明确引入了方向性概念，以反映事件之间的因果关系、影响路径等动态特性。
在实际业务场景中，服务之间的调用关系确实遵循着明确的方向性，如服务A调用服务B，这种调用链清晰地展示了服务间信息的流向。然而，当我们将视角转向故障传播时，情况就变得复杂起来。故障的传播并不总是简单地沿着调用链的上下游进行，其方向性受到多种因素的影响。
具体而言，某些故障可能仅沿着调用链的下游传播，影响被调用服务；而另一些故障则可能逆向传播，即向上游服务反馈问题；还有部分故障更为复杂，它们可能同时在上下游两个方向上进行传播，形成广泛的故障影响范围。
因此，在事件知识图谱中，故障的传播方向并非仅仅与故障对象本身相关联，而是需要综合考虑故障对象、故障类型以及它们之间的特定关系。这种绑定关系使得事件知识图谱能够更准确地描述故障的动态传播过程，为故障的快速定位与解决提供有力支持。

如果想对根因分析做进一步了解的，欢迎移步我在《极客时间》的专栏《智能运维之根因分析》。

课程介绍

随着时代的发展，现有的企业 IT
设施越来越庞大、越来越复杂。根因分析的定位，变得越来越难。由此引出了一个问题，是否可以借助人工智能技术，实现故障的智能定位？现在市面上关于根因分析的材料并不多，更多的是以论文的形式出现，都在探索不同的算法在特定场景下的效果。学术研究本来就应该百花齐放，但是工业界除了关心理论本身，更关心的是如何落地以及如何为企业带来效益。本课程以实际业务场景为出发点，结合产品、数据、工程、算法不同领域的专业知识，帮助大家全面的了解根因分析系统如何从实际问题出发，一步一步的实现智能化、自动化。

通过课程，你将会学到：

• 算法原理：深入了解根因分析的基本原理；
• 系统架构：深入了解根因分析系统的设计和实现思路；
• 快速上手：课程在讲解原理的同时，提供翔实的配套代码，方便大家学习；
• 前沿技术：了解目前业内关于根因分析的前沿技术；

知识图谱的展示

在知识图谱的呈现过程中，我们依赖于两大主要数据源：首先是实体知识图谱，它作为基石，负责详尽地展示实体本身以及这些实体间错综复杂的关联网络；其次是经过精心清洗的告警数据，这些数据如同一面镜子，映射出知识图谱中各个实体所遭遇的告警情况，直观反映了实体的健康状态与潜在问题。
关于技术实现层面，虽然具体的算法细节我们已在前文中深入探讨过，不再赘述，但在此有必要强调一点关键认识：知识图谱的构建与展示，各自拥有独特的数据模型设计考量。知识图谱的核心数据模型，旨在构建一个既通用又强大的框架，能够灵活适应多样化的业务需求，确保信息的全面覆盖与深度整合。
而相比之下，知识图谱的展示设计则更加聚焦于特定的业务场景或用户实际需求，强调用户体验的直观性与友好性。这意味着，在展示层面，我们需要根据用户的操作习惯、信息获取偏好以及具体业务目标，定制化地构建数据模型，确保信息的呈现既准确高效，又易于理解。因此，尽管两者都服务于知识图谱的同一目标，但在数据模型的设计上，它们之间确实存在着显著的差异与分工。

根因分析

接下来，让我们将注意力转向设计图的左侧关键区域，这里集中展现了两个核心分析模块：实时根因分析与离线根因分析。这两个模块分别针对不同的时间维度和场景需求，共同构成了问题诊断与解决流程中的重要一环。

数据清洗

实时告警数据是从监控系统获取的。因此一开始我们拿到的告警数据的格式，是监控系统自带的。但是我们的根因分析，数据源不止一个，如上图所示，还有配置中心，服务之间的关联信息。实际生产环境的数据源只会更多。因此我们的根因分析系统会基于系统的需求，设计一套内部的数据格式，任何外部的数据进入这个系统，都需要做数据格式的转换。

实时根因分析与离线根因分析

接下来，我们将共同探索根因分析这一关键领域。根因分析的应用场景可细分为实时场景与离线场景。在实时场景下，系统能够即时捕捉告警数据，并即刻启动分析流程，动态构建出故障树，为快速响应与问题定位提供有力支持。转至离线场景，用户则拥有更高的灵活性，通过指定一个时间段，系统便会基于该时段内累积的告警数据，进行深入分析，并可能生成多棵故障树，这些故障树的数量并非固定，而是根据数据的复杂性和关联性动态决定的。
值得注意的是，尽管实时分析与离线分析在算法逻辑层面共享着相同的理论基础，但在工程实践的具体实现上，两者却展现出四个显著的区别维度。

事件知识图谱的更新

常识事件作为一类基础且恒定的信息，其有效性跨越时间的长河，无需进行任何形式的更新操作。
相对而言，普通事件则承载着更为动态的内容。为了保持其信息的时效性和准确性，系统会记录每个普通事件的最新访问时间。一旦某个事件在预设的时间阈值内未被访问，系统将自动触发通知机制，提醒运维或开发人员关注并考虑是否需要对该事件进行必要的更新。此外，在事件分析过程中，若发现结果存在偏差或错误，系统亦会智能地提示运维人员，询问是否需要对涉及的故障传播链进行更新，以确保分析结果的准确性和可靠性。

小结

好了，这就是今天的主要内容。最后我们一起来回顾一下。
首先，我们深入剖析了根因分析系统的两大核心应用场景：一是故障平台上的即时诊断，它聚焦于实时分析，确保在问题发生的当下迅速定位根源；二是历史故障追溯，这一场景则侧重于离线分析，通过回顾历史数据，挖掘潜在原因，为未来的预防与优化提供洞见。
随后，针对上述两大技术需求，我们精心构思并设计了一套全面而高效的根因分析系统。在此过程中，我们不仅详细阐述了系统的架构与功能，还对其实现原理与操作流程进行了深入的讲解，特别是在实时场景和离线场景下做根因分析有四个维度的区别：告警覆盖度、实现机制、系统重启以及调试功能，力求让每一位参与者都能对系统有全面而深刻的理解。