如何构建面向故障恢复的可观测体系？

如何获得讲师PPT：

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

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

1、如何区分强依赖和弱依赖？强弱依赖怎么去做保鲜？

要区分系统的强弱依赖关系，需要借助工具进行测试。我们目前使用混沌工程进行测试，例如对A应用和B应用之间的接口进行故障注入，观察A应用的响应。如果A应用仍然正常返回结果，则说明B应用对A应用来说是弱依赖；如果A应用返回异常结果，则说明B应用对A应用来说是强依赖。这种方式可以通过一些开源工具实现，通过注入延迟或超时等问题来模拟故障情况。

强依赖保鲜是一个重要问题。我们之前采取过一种定期演练的方式，对应用进行测试以保障强依赖的数据正常。为了降低人力成本消耗，我们可以尝试自动化测试。我们曾尝试过每天晚上自动运行所有应用的强依赖校验，并生成一个报表。这个自动化测试会对接口进行断言，如果接口通过断言，我们认为它是弱依赖，否则可能是强依赖。这样，我们可以了解每个应用的强依赖或弱依赖接口，并生成相应的报表。对应的应用所有者会收到这个报表并进行确认和反馈，这样可以减轻一些人力负担。

最开始的基础数据要怎么收集？

在做根因分析时，我们不自己存储数据，而是从各种数据源获取。例如，我们使用ELK套件来处理日志数据，通过事件平台的接口获取事件日志。类似地，我们还可以通过其他接口获取告警信息或通过我们的接口获取其他数据。我们不选择自己存储数据，因为数据源众多，自己存储既不现实也没有必要。

根因分析的准确率是怎么统计的，Top 1的准确率大概能达到70%-80%吗？

我们有一个故障平台，可以查看所有故障。首先，我们能观察到所有的故障，这是第一点。其次，运营这个平台需要人力，例如当出现故障或告警时，QA团队会联系故障的所有者或相关人员进行询问并收集反馈，这是第二点。

现在，我们的更新分析平台拥有自己的反馈通道。比如在推送报告后，有一个反馈模块可供用户点击，询问分析的准确性等。我们通过这两种渠道收集数据。

Metric是否会对异常Metric数据做持久化保存，还是要按需持久化？

我们现在不会做持久化的处理，我们都是会进行实时的一个分析。

Metrics永远不会过期吗？ 过期时是怎么设计的呢？

我们目前存储数据的时间是一年。数据的过期时间与具体业务需求有关。例如，如果你的业务需要存储2～3年的数据，那么可能需要在数据库中存储两到三年的数据。对于不同的TiDB，设置过期时间的方式可能不同。例如，对于whisper这样的轮转式DB，您可以在配置中设置过期时间。另外，像VM那样的TiDB会对每个指标的数据进行分区。如果您需要删除超过一年的数据，您可以直接删除相应的分区。

秒级 metric 采集使用的 prometheus 吗？

不是，这个前面也有讲到，我们没有用到prometheus我们现在用的都是自研的。像我们叫Q monitor对。自研的一些SDK采集册也是自研的这样。

根因分析迭代中对权重、排序做调整时，如何保证历史类似故障还能准确定位？或者说是如何在对历史故障做回归的？

在迭代过程中，根因分析涉及到对权重的排序和调整。历史上，由于某些原因，这方面没有详细讲解。验证根因分析的准确性其实不太容易，我们的验证方式是利用混沌工程。在回归阶段和开发阶段，我们都使用混沌工程来验证。举个例子，我们真实地模拟了一套线上外部环境，然后给这个环境注入MySQL异常，观察是否能分析出来。再注入其他故障，看看是否能分析出来。这是验证根因分析的一种方式。

系统目前都有哪些数据源？ metrics、logs、 trace 类型的来源是什么？

metrics我们目前使用TiDB，并重视TiDB。一种是whisper、一种是ClickHouse。但由于历史原因，我们使用了一部分。还有我们新型的VM. 像是logs核心是ES,大家也用的比较多。至于trace，我们直接使用自研的API接口查询相关数据，trace存在ClickHouse里面。

接口偶发性超时，调用链只能看到超时接口名称，看不到内部方法，无法定位根因，也难以复现，怎么办？

在进行根因分析时，我们首先需要界定什么是根因。比如当接口超时，可能是代码存在bug，也可能是其他原因，如依赖项导致接口调用超标或自身性能问题。为了确定这些问题，我们需要观察和收集可观测数据。但是，目前对于我们来说，接口超时可能只是一种异常日志，只能分析到异常日志的程度。

要进一步分析接口为什么超时，可能需要进行更深入的分析。例如，可以通过在线火焰图的采集等手段，进行持续的数据采集和分析，这样才有可能准确定位问题的根源。

请问根因定位的话，异常数据、知识图谱的规则，是一开始就设定好的吗？怎么维护的呢？你们根因定位，做到现在的效果，大概做了多久啊？

我们从去年开始进行维护和运营，目前已经有一年左右的时间。对于异常数据知识图谱的规则，我们一开始就设定了一些简单的规则。这些规则很好理解，例如在构建知识图谱的关联时，你需要设定一些规则进行分析。一开始，你可能不会考虑到所有的规则，但你可以在后续慢慢补充。

变更是导致故障占比很大，一些变更和trace上的服务是能关联，一部分比如策略、离线、数据是很难和服务很难关联，你们怎么做？

我刚才提到，业务线会进行上线活动、下线活动、开启新流量等策略。这些策略可以作为事件进行统一收集，并暴露出来以便进行关联和分析。通过暴露这些事件，我们可以获取离线服务和类似数据分析的服务。然而，目前这些服务的确很难与业务线进行关联。我们目前还没有涉及这方面的分析，因为离线任务等具有很强的隐蔽性。如果能够统一采取一些动作或事件等行为，将有助于我们进行观测和分析。