定位时长缩减90%：酷家乐如何提升系统故障根因分析准确率？

一分钟精华速览

酷家乐开发魔方语言的目的是解决其2B SaaS系统在复杂微服务架构下的故障定位难题，以提升系统稳定性并加速故障恢复。由于原监控工具操作复杂，需要人工逐项点击且依赖经验，导致处理效率低下。魔方语言通过自动化根因分析，显著提升了故障处理的覆盖率和准确率，从而减少了重复操作，降低了技术门槛，有效提高了客户满意度和产品竞争力。初步成效显示，大部分典型故障定位时长缩短90%以上 ，已进入1分钟定位阶段。详细的解决策略和方法，请参阅文章正文。

作者介绍

酷家乐监控负责人——少丰
TakinTalks稳定性社区专家团成员，酷家乐监控负责人、技术专家。主要专注稳定性保障、新一代监控系统的研发工作。此前在诺基亚工作十年，先后参与和负责过诺基亚运营商通信系统、创新业务、基础设施架构、新一代Dev0ps平台方面的工作。

温馨提醒：本文约6500字，预计花费12分钟阅读。

TakinTalks稳定性社区后台回复 “交流” 进入读者交流群；回复“Q102”获取课件；

背景

酷家乐致力于为家居设计师们提供稳定可靠的3D设计工具，目前酷家乐的B2B服务已经触达了200多个国家和地区。产品的稳定性是酷家乐的立业之本。随着业务的快速成长和技术的不断进步，酷家乐的监控系统也在加速进化。

我们知道客户最在乎的是：当问题发生时，解决速度越快越好。为此，酷家乐特别搭建了一个根因分析系统，目的就是要把问题解决的时间缩短，提升定位问题的速度，使监控系统更加易于使用。

图-酷家乐监控系统（Tetris）概况

接下来，本文会带大家深入了解酷家乐监控根因分析系统的成长历程，还有酷家乐独创的“魔方语言”，它是如何帮助自动化分析问题，让客户对故障处理的时效更满意，也让酷家乐的服务更上一层楼。

一、酷家乐根因分析系统各阶段存在哪些问题？

图-酷家乐监控系统发展的四个阶段

初级阶段 — 在这个阶段，监控子系统相互独立，没有整合。如果需要定位一个问题，必须亲自到每个系统中去找数据，非常依赖员工的个人经验。

进阶阶段 — 这一阶段，我们建立了不同监控数据之间的联系，并增强了警报系统的覆盖率。警报系统开始充当了一个统一的入口，我们对警报和健康数据进行了基本的分析，这极大提高了问题定位的效率。

专业阶段 — 到了这个阶段，我们投入大量资源构建了一系列辅助定位系统，并进行了深入的专业分析。

专家阶段 — 去年我们开发了基于魔方语言的自动化定位系统，进一步优化了问题解决流程。这部分我会在后面重点介绍。

1.1 初级阶段（2021年之前）

酷家乐监控系统一直持续建设了很多年，至2021年，已经建立了比较完整的指标、日志、调用链、警报系统，采集的数据也较全面，这也为后面的工作奠定了坚实的基础。但各个系统及数据还比较隔离，我们定位它为初级阶段。这个阶段，问题需要定位时，我们一般一个系统一个系统地查：到指标系统查指标，再对应按时间段查日志，也需要进入调用链系统输入一定的条件查询需要的调用链进行分析，如果有警报，就跳到警报系统，分别去对应的系统里找答案。

1.1 图 -酷家乐监控系统初级阶段，各系统各自而战

1.1.1 存在的问题

但这样的做法有一个明显的问题，就是数据孤立。这个阶段，我们面临的挑战主要有两个。

首先，警报系统覆盖不全面，故障发现率低，经常出现警报缺失、故障漏报的情况；故障恢复后，还得投入大量人力去核实问题是否真的解决了。

其次，由于各个系统之间相互独立，团队成员在定位问题时往往需要花费大量时间，这不仅依赖于个人的能力和经验，更需要对监控系统的熟练操作和对业务的深刻理解。那时候，我们还没有全链路的依赖关系可视化，对于那些因底层问题引起的复杂故障链路分析来说，难度非常大。更别说缺乏专业的故障定位工具，这使得问题定位变得相当困难。

这就是我们最开始的阶段，虽然有不少挑战，但它也为我们后来的改进奠定了基础。

1.2 进阶阶段（2021年-2022年）

1.2.1 阶段成果

这个阶段最大的进步就是全面提升了警报的覆盖和分析，以及搭建了应用拓扑依赖关系图。警报覆盖的提升，让我们实现了故障发现率的飙升，系统类故障发现率几乎达到了100%。应用拓扑依赖关系图也极大地辅助了我们对链路故障的分析，帮助我们能够准确追踪到问题的根源。

1.2.1 图 - 进阶阶段工作成果

警报系统也变得更加成熟，能够作为统一入口进行问题分析。我们在警报中进行了初步分析，直接关联了该警报相关的日志、指标、调用链数据，支持下钻分析，从而简化了调查流程，显著降低了故障调查的门槛。此外，我们实现了系统间的无缝链接，并利用拓扑图加强了系统之间的协同作用，这样一来，故障定位的效率得到了进一步的提升。

1.2.2 存在的问题

• 没有专业工具，定位难的问题依然没解决。依然较依赖调查人员的个人能力和经验；

• 定位效率还是不理想。很多人工操作，人工分析，依赖人的经验进行定位；

• 提升警报覆盖率后，业务抱怨警报太多。做了大量的警报降噪、警报聚合等降警报的工作；

• 底层故障会引发大规模警报风暴，定位很难。大量服务、组件都报警时，快速定位到根因服务和根因，是一件不容易的事。

1.3 专业阶段（2022年-2023年）

为解决上面的问题，我们随后设计并开发了一系列精准的故障定位工具。

1.3 图 - 专业阶段的根因辅助定位系统

1.3.1 链路分析-警报拓扑图

我们开发了警报拓扑图产品，该图基于应用和API之间的依赖关系。通过这个可视化工具，用户能够一目了然地在拓扑图中查看任意结点的所有相关指标、日志、调用链、警报、上下游服务、中间件、存储、宿主机等数据。当发生故障时，可以快速定位根因节点。

1.3.1 图1 - 链路分析-警报拓扑图

1.3.1 图2 - 案例：定位Hbase引发的故障

1.3.2 专项分析-鲲鹏诊断系统

鲲鹏诊断系统是一个基于关键性能指标和日志分析的高级诊断工具。它允许用户基于前端、应用、存储、系统多个维度深入分析，基本包含这些维度的所有场景异常情况，调查人员只需要逐个点击查看，即可定位异常。

1.3.2 图1 - 专项分析-鲲鹏诊断系统

1.3.3 警报分析 - 架构层级分析

进一步地，我们实施了警报的层级分析，便于用户迅速识别由底层问题触发的故障。基于警报信息，按硬件、网络、主机、存储、应用、API、网关、前端、业务等架构层级，分析出各个层级的异常情况，能很方便地自底向上分析根因。

1.3.3 图 - 警报分析 - 架构层级分析

比如，发现某个宿主机有故障，而同时该宿主机上层的其它服务都有问题时，基本可确定故障为该宿主机引起的。又或者，发现某个数据库有故障，而同时依赖它的大量服务都报警，则可怀疑是该数据库引起的故障，可以初步定位根因为该数据库，进而进一步调查。

1.3.4 警报分析 - 聚类分析

我们还对警报数据进行了聚类分析，对警报进行分类、分级，基于警报应用、类别、级别、负责人以及聚类数量进行聚类分析，分析最可能的根因服务和根因。通常数据较多的，解决根因服务的概率更大。通过聚类聚焦，能在大型警报风暴故障中快速缩小范围，和快速找到对应的负责人。

1.3.4 图 - 警报分析 - 聚类分析

1.3.5 业务分析与故障定位

为了业务故障的更好观测，我们构建了详尽的业务看板，特别是在复杂的业务链路中，我们专门创建了业务链路，进行分析定位。当链路的某一个节点发生故障时，我们可以很快速精准的可视化定位到。

1.3.5 图 - 业务分析与故障定位

1.3.6 阶段成果

建立了全面而完整的根因分析和定位的系列工具，对于各类常见故障，基本都能通过点击系统对应功能进行定位，典型故障的定位时间已大幅缩短至5分钟内。

使用门槛也大幅降低，根因分析系统自动按照分析规则做了完整分析，即使是不熟悉监控系统或业务的人员，也能做到只需要点击即可查看故障定位。这不仅降低了应急成本，也大大减轻了应急时的焦虑感。

1.3.7 存在的问题

尽管我们拥有了这些工具，但在进行故障诊断时，如果要逐项检查，过程可能会显得效率不高，耗时较长。尤其针对某些隐蔽故障，它们可能深藏于系统的某个特定环节，这时单纯依赖逐个点击的方式很难实现快速定位。这导致了一个不容忽视的问题：重复的操作不仅让团队成员感到疲惫，也引发了对效率低下的抱怨。团队急切希望拥有一个能够自动识别并报告问题的系统，减少人工参与的环节。

另一个问题是现有工具的迭代更新速度不尽人意。当需要为系统引入新的诊断特性时，我们不但要进行前端页面的开发，还需要进行大量的设计工作，这使得整个流程周期变得漫长。这样的情况，如果持续存在，不仅会影响到与开发团队的协作，还可能在一定程度上削弱团队的士气和积极性。

1.4 专家阶段（2023年之后）

基于这些考虑，我们开始思考如何将页面操作的复杂性转化为自动化流程，以便更迅速地定位故障。目标明确：构建一个能够自主识别并报告故障根因的系统，而不再需要人工逐项排查。此外，我们希望该系统能超越对专家经验的依赖，借助嵌入的智能自动化识别和判断故障，从而根除重复性的手工操作。

1.4.1 人工定位自动化实现思路

决策树推理是故障定位系统的核心。基于实践经验，我们清楚业务专家凭借经验迅速诊断问题的能力通常比单纯的决策树推理更高效、更精准。因此，我们面临的关键挑战是如何将这些专家知识融入系统中，并实现自动处理。我们采纳了一种融合决策树推理与模仿人工定位的混合方法。

1.4.1 图 - 人工定位自动化实现思路

1.4.2 魔方语言自动化根因定位实现思路

在自动化根因定位的过程中，我们优先植入了专家制定的人工定位规则。系统首先尝试使用这些规则定位问题，若成功则直接输出定位结论。当人工规则不起作用时，系统会兜底执行决策树规则，进行更深入的分析。

1.4.2 图1 - 魔方语言自动化根因定位实现思路

为了实现1分钟自动化定位，起初我们采用了Go语言开发自动化分析规则，但随时间发展，我们发现准确率并不理想。问题主要在于——

1.4.2 图2 - 踩坑记录：“Go语言版”自动化根因分析定位系统

为此，我们打造了一种专为根因分析设计的新规则语言——“魔方语言”，以期解决上述诸多问题。

二、“魔方语言”如何帮助实现1分钟定位？

2.1 实现原则

为了追求高效且精确的更新分析体验，我们确立了几项核心的实施原则。以下原则旨在通过魔方语言为用户提供一个快速、直观且强大的自动化根因分析工具，赋予技术团队以更高效率解决问题的能力。

2.1 图 - 酷家乐自动化根因分析解决方案实现原则

2.2 系统架构概述

2.2 图 - 魔方语言系统架构

架构的顶层是用户接口层，通过这一层，用户可以自定义分析规则并启动分析过程。系统与应急预案平台无缝融合，它能够自动地导出分析结果并给出预案建议。用户在审核结果无误后，可方便地选取并实施合适的预案。

在规则库的构建上，我们综合梳理并集成了多样的分类规则，涵盖了故障分析、警报处理、工单处理等多个领域，以适应各种应用场景。"魔方语言"不仅内置了一个强大的规则引擎，它还能支持复杂数据的处理和多样化的指令执行。

整个系统的顺畅运行依托于与外部系统的深度数据整合，实现了对企业内部全域数据的访问，这些数据包含但不限于监控、大数据、DevOps、配置管理数据库(CMDB)、组织结构信息等。此外，系统还具备将不同数据源的数据进行重组和融合分析的能力。基于分析决策，系统能够调用外部接口，如DevOps工具、流量控制、资源扩容、服务隔离、应急预案系统、警报通知以及企业微信等，以通报分析结果、提供预案选择以及执行预设动作。

2.3 自动化整体流程

在我们的系统中，已经部署了一套自动化机制，这套机制能够实时监测并识别系统故障。

2.3 图1 - 魔方语言与预案、辅助定位系统融合

一旦检测到问题，它会立即激活故障分析程序。这个基于魔方语言的分析工具，能够进行高效的故障定位，无论是诊断服务问题还是推荐更新。一旦定位到问题，它会自动查询预案系统，提取相应的解决方案。然后，系统会展示这些预案，等待用户的确认和执行。如果故障没有被明确指向特定服务，我们的系统仍会进行深入分析，不仅限于根因分析。我们的目标是缩减调查范围，即使是微小的进展也是值得的，因此所有相关分析都会被呈现出来，以便人工进一步分析，最终目的是提升整个流程的效率。

这里有一些实践的经验，我们发现到如果没有明确定位到根因，同样需要公布结果。因为在最初阶段，我们缺乏数据支持，但随着用户逐渐习惯系统，他们开始期待故障分析的结果。如果不主动提供分析结果，等待时间可能会过长。因此，即使没有完成分析，我们也会发布当前的结果，以便团队可以手动启动调查。同时，监控人员也需要马上复盘，一旦确定该故障的调查方案，立刻将分析规则补充进分析规则库。

2.3 图2 - 未定位到根因的分析结果公布

2.4 在线调试工具介绍

为了便于规则的开发和测试，我们开发了在线调试工具。用户可以直接在工具中输入代码并运行，实时查看执行结果，极大地提高了调试效率和便捷性。

2.4 图 - 直接在工具中输入代码并运行，实时查看执行结果

2.5 语法和命令说明

我们的魔方语言提供了基本的语法和命令支持，包括变量定义、条件表达式、循环遍历（如for循环，不含break）。为了提升用户体验，我们还专门设计了中文操作命令，如警报查询和指标数据即时查询等。在操作逻辑上，这些命令与订阅系统中的操作密切相关，使得收集定位经验变得更加直接和高效。规则的编写与系统操作步骤相对应，简化了编写过程。

2.5 图 - 魔方语言的语法及命令

除了基础命令，我们还提供了算法命令，如指标突变判断、指标增长分析、分组聚合以及排序功能，例如“TOPN”命令常用于处理大量警报数据。这些功能在分析复杂数据时显得尤为重要。

2.6 代码示例

2.6.1 上游流量突增故障分析示例

可以看到，代码均以中文编写，极大地提升了可读性。通过输入相应的参数，代码首先执行实时查询，获取上游服务的QPM（每分钟请求数）。随后，通过一系列算法处理，对指标数据进行动态监测，以便捕捉任何潜在的异常突变。一旦通过设定的阈值判定出异常情况，代码便会自动进入下一阶段，执行分支判断，并采取相应的后续措施。

2.6.1 图 - 上游流量突增故障分析

2.6.2 用户流量突增故障分析示例

在这里，我们通过提取商户或用户ID，进而查询相关的指标数据。接下来的步骤包括对数据进行分析，以确定是否存在异常的流量增长。虽然实际操作可能比示例中展示的要复杂，但基本逻辑是清晰的。通过简化代码示例，我们能够一目了然地理解其背后的分析逻辑。与使用Go或其他编程语言相比，我们的示例代码明显更加直观易懂。

2.6.2 图 - 用户流量突增故障分析示例

2.6.3 宿主机故障分析规则示例

在宿主机故障分析的场景中，我们也提供了一个简洁的例子。例如，在一个宿主机上运行的多个服务出现问题时，往往会触发一系列的警报或异常。在这种情况下，我们的代码会对所涉及的服务和报警节点进行分组聚合操作，以判断是否大部分异常均来源于同一宿主机。

2.6.3 图 - 宿主机故障分析规则示例

2.7 如何评估

评估自动化和分析的有效性是我们工作的核心部分。我们主要依据三个关键性能指标来进行评估。

2.7 图1 - 评估自动化和分析有效性的3个指标

首先，是自动化分析的覆盖率。由于我们的分析是基于预设规则进行的，覆盖率指的是能够与分析规则相匹配并得到分析的故障比例。如果出现新型故障，可能由于缺乏适配的规则，这时的匹配度便体现出我们规则完整性的不足，因此，覆盖率直接关系到我们规则的全面性。

其次，是服务定位的准确性。在初期，我们并未特别强调这一指标。但随着时间的推移，我们意识到其重要性：服务层往往连接着负责人。一旦能够准确找到对应服务的负责人，凭借他们丰富的经验，我们通常能更快地定位并解决问题。因此，我们特别增加了服务定位准确率这一评估指标。

最后，是根因定位的准确性。这是衡量我们系统直接定位到故障根因能力的指标。

2.7 图2 - 提升根因分析规则准确率的一些经验

2.7 图3 - 自动化根因分析实践经验总结

2.8 实际运行效果

大部分典型故障定位时长缩短90%以上 。进入1分钟定位阶段，分析路径精确的，一般能在发现故障后30s内定位完；较复杂的也能在1分钟内定位完。

2.8 图1 - 实际运行效果

V2版本定位服务准确率67% 。目前正在配置的V3版本预计超80%。

2.8 图2 - 实际运行效果

2023年下半年魔方语言分析规则上线后，迭代2次，目前在配置V3版本，预计在分析覆盖率、服务定位准确率和根因定位准确率等方面会有进一步提升。我们也在思考故障和根因分析准确率的理论上限，并通过持续的迭代改进，来进一步提升我们的系统性能。最终，我们的目标是实现从故障发现、定位到恢复的完整流程自动化，提高整体的运维效率。

三、总结与展望

3.1 魔方语言的应用场景

目前，魔方语言的应用越来越广泛，特别是在故障定位方面。在警报分析方面，针对特定警报，系统在接收到警报后会自动进行分析，并推送分析结果。系统甚至会提供一些有用的链接，比如跳转或分析链接，这大大提升了警报处理的效率。此外，在工单分析、变更分析和定时巡检等方面也有应用。对于需要综合判断和数据查询的复杂巡检，都可以通过魔方语言编写相应的脚本，并设定定时任务来执行，将结果推送至企业微信群或通过电子邮件发送。

3.1 图 - 魔方语言的应用场景

3.2 未来规划：大模型+魔方语言

3.2 图 - 魔方语言的未来规划：大模型+魔方语言

接下来，我们计划构建一个专门针对监控数据分析的私有模型，并利用大模型来解读故障、警报和工单，再自动生成魔方语言的分析规则。魔方语言作为一个结构化语言，拥有自己的语法和命令集，这使得它能够逐步实现自动化规则的生成。这是我们面向未来的一个重要目标。（全文完）

Q&A：

1、基于经验迭代增加分析规则，这个迭代过程是怎样的？比如，是不是先测试或者有一个评估流程后再更新？

2、配置了那么多规则，当多个规则计算出根因，是如何确定哪个是根因？

3、能以一条规则为例看看规则是怎么匹配问题的吗？问题输入人都有哪些信息呢？

4、根因分析使用的啥算法？

5、怎么做故障召回和报警召回的？分别都召回了哪些内容？

以上问题答案，欢迎点击“阅读全文”，观看完整版解答！

声明：本文由公众号「TakinTalks稳定性社区」联合社区专家共同原创撰写，如需转载，请后台回复“转载”获得授权。

本文由博客一文多发平台 OpenWrite 发布！