酷家乐《定位时长缩减90%+:酷家乐魔方语言在提升根因分析准确率中的应用》

如何获得讲师PPT：

扫码关注公众号，后台回复「Q102」即可获得讲师PPT哟～

还能一键订阅后续精彩活动内容～

Q&A环节答疑：

1、实际应用起来，魔方语言有没有啥局限性？比如限制条件啥的？

目前，我们的局限性相对较少。如果想拓展更多功能，我们有能力扩展语言。当然，也存在一些限制条件。例如，我们在线上的自动化操作命令方面相对谨慎，这些可以视为局限性之一。目前，线上的变更都需要经过审批流程，我们不能直接进行自动化运行。但我们可以在扩容等风险较小的操作上进行自动化。

2、魔方语言的扩展性和维护情况怎么样？包括和其他工具的集成情况

目前，我们主要依赖内部工具和API进行开发工作，尚未与第三方工具进行集成。例如，我们尚未使用Get Lab等代码获取工具。在扩展性方面，如果我们需要接入第三方工具并获取其数据，只需新增一个命令，并按照我们的命令规范来实现。这个命令会调用第三方的API来获取数据，并在我们的内部命令系统中进行透传，从而可以在后续工作中使用这些数据。编写命令时，我们拥有很高的自由度，只要命令符合我们的规范，就可以轻松地与其他功能融合使用。

3、用语言加个lib 有啥不好呢？

这种思路确实值得考虑。你所展示的语言表达性很强，无需注释，我就能一眼看出其中的分析逻辑，这对于使用者来说非常重要。语言本身的直观性和易读性是关键，难度不应过高。在实验过程中，我能够直观地理解并调整编写的规则，这对于我们来说极为便利。随着分析规则的不断增加，现在可能已有几十条，覆盖多种场景。因此，在添加新规则时，需要确保整个规则的直观性，使得我能够清晰地看出其前后的逻辑关系。此外，我们也希望语言能够保持简洁性，因此定义了一些实现原则。

4、这得写多少规则，规则是能自动生成的吗？

规则确实很多的。因为分析本身就不是一件简单的事。我们曾考虑过自动生成规则，类似于自动化测试，通过记录操作步骤来生成。最初，我们设想了一个可视化的界面，用户可以在操作节点上查看下一步。但经过讨论，我们认为大部分规则仍由程序员编写更高效，因为他们熟悉语法结构。自动生成可能在中途出现问题，需要人工介入。在编写分析规则时，程序员需要人工分析调查思路，确定哪些步骤真正有效。因此，对于程序员来说，直接编写代码可能更快。基于这些考虑，我们决定直接编写代码，而不再开发可视化的配置工具。

5、调取数据的时候，安全性和数据保护呢？

我们不会读取不能使用的数据，因为许多安全数据都需要认证。我们仅允许读取经过授权的数据，同时确保不会泄露任何需要保护的信息。在实现过程中，我们专注于将根因分析的交叉思路转化为代码，这是我们的主要重点。至于数据保护和认证等安全问题，不在我们当前的语言考虑范围内。

6、定位在底层故障时发生的告警风暴，是能给出最核心的问题源吗？

简单来说，我们有两个维度来定位问题：一是责任人所在的最小单位，即服务；二是直接定位到问题的根本原因。当发生警报风暴时，我们首先会定位到相关服务，并通知责任人进行进一步分析。如果能够直接定位到问题的根本原因，如磁盘故障、实例挂起或网络中断等，那是最好的。这两个维度都是我们考虑的重要指标。对于不同类型的警报风暴，如流量类、网络类等，我们已经积累了较多的经验，并且能够比较准确地分析出根因。

7、你们是有建设预案平台吗？从发现到自动分析到快恢这块，目前的情况可以大概说下吗？

我们现有的预案平台还不够完善，因此今年的重点是将其建设得更完善。原来的预案平台主要基于一些基础恢复手段，如扩缩容和隔离。未来，我们将建设更完善的预案平台，针对不同指标异常制定恢复方案，并考虑不同故障类型，包括系统类和业务类故障。我们将结合故障定义，为每种故障制定不同的预案。在魔方语言的定位中，这也是我们考虑的一个方面。

识别出服务和根因后，我们会确定故障类型和对应的定义，并从预案平台中查找相应的恢复方案。目前，我们已能准确处理系统级和应用级的故障，如流量问题和爬虫发现等。这得益于我们丰富的经验。然而，对于硬件、网络等问题的预案尚不完善，且未与系统完全整合。这将是我们未来的改进方向。

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

找出真正的根因是一个挑战。首先，需要找准入口，这依赖于经验和对警报的判断。例如，我们会根据固定的指标去查找对应的调链，从而定位到出问题的服务或位置。然后，进行服务级或应用级的分析。这里有一个指标叫做“服务覆盖率”，它表示服务自动化分析的覆盖程度。如果入口选错，可能没有规则覆盖到这个故障，导致覆盖率较低。我们会通过这个指标来推动提升分析的准确性。

9、（接第8个问题）入口怎么理解？可以详细说下吗？

在警报风暴中，找到问题的入口是关键。这通常涉及到链路分析，从上层服务开始，根据依赖关系向下查找。同时，时序分析也很重要，要考虑哪个服务先出现问题，或者哪个服务的异常数量最多。这些都基于我们多年故障处理经验的总结。我们的分析规则经历了从V1到V3版本的迭代。在V1阶段，我们主要进行全面的扫描，尝试找出最符合问题的服务。但这种方法存在一些误报。到了V2版本，我们开始利用内部数据更精确地定位服务，这使得定位服务变得更容易。在定位到服务后，我们会进一步分析以找到真正的根因。在V3版本中，我们对服务定位进行了改进，将其独立出来，以提高分析的准确性。这一改进基于我们过去的警报数据和执行情况，是对经验的不断总结和调整。目前，我们按照这一思路进行操作。

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

我们通过故障复盘，结合监控和业务人员的经验，详细记录每个故障的发生、监控缺失、发现及恢复过程。这些文档为我们提供了基础的分析规则和经验。每次故障复盘都会添加新规则，以便下次同类故障能被覆盖。当出现新故障时，我们会立即复盘并添加规则。这种运营策略提升了分析的准确性。由于分析基于故障时刻的数据，我们需要在数据有效期内尽快复盘并验证规则。这样，我们就可以直接使用故障数据进行测试和验证。

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

找到入口是关键，之后还需根据强度依赖关系去重，排除无关因素，专注于当前故障时刻的异常。时序分析也很重要，可能涉及多种策略，整个分析过程确实复杂。然而，通过边运行边迭代的方式，我们可以不断完善它。

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

当发生警报风暴时，我们会先对故障时段的警报进行聚类分析，然后依据规则确定与故障最相关的警报。例如，如果一个API出现报错，我们会根据这个API查找对应的调链，从而定位到问题的服务。通常情况下，我们能定位到服务或P的级别，这时很可能是服务的问题，我们会进一步进行服务级的分析，包括查看各种指标和可能的处置措施。整个分析过程比较复杂，包括11个分析步骤。我们也会根据经验，例如查找固定的指标或网络异常警报，来辅助判断问题。例如，如果发现两个节点之间的网络中断或丢包率异常高，这可能是一个关键特征。

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

我们没有固定的算法，而是基于规则进行调查分析。我们根据问题的性质，按照一定的思路逐步进行，如第一步、第二步、第三步等。在这个过程中，我们会总结哪些方法是有用的，并将它们转化为规则。我们的分析方法最原始、最基本，主要是基于这些规则。在判断指标时，我们会考虑一些基本方法，如离群判断（如某个指标的值与其他指标相比有很大差异）和增长趋势分析。这些方法相对简单，没有使用其他复杂的算法。

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

我们的主要做法是复盘后分析故障时刻，找出为何之前的分析未能准确识别问题，然后基于这些反馈不断改进规则。

本文来自投稿，不代表TakinTalks稳定性技术交流平台立场，如若转载，请联系原作者。