「 背 景 」

众所周知，变更是线上环境不稳定的⾸要因素，有研究表明，线上70%的故障都是由某种变更⽽触发的。因此，当⽣产环境发⽣故障产⽣告警时，管理员第⼀直觉是怀疑近期是否发⽣过变更。此时，我们往往需要⼿动查找变更⽇ 志，确认近期的变更计划，这个过程既繁琐⼜低效。

另外⼀种导致⽣产环境故障的原因，则是服务所在基础设施的⾼负载，⾼饱和度影响了服务的容量和性能。

我们希望具备这么⼀种⾃动分析的能⼒，它能够联动⽣产环境的告警，并⾃动分析产⽣告警的原因是由于变更，还 是由于系统的⾼负载。并且分析结果能以直观的拓扑结构展示出来，我们希望能看到服务间的调⽤关系，所依赖的 中间环节和基础设施以及哪个环节出现变更或者异常。如下图所示：

并且，它可以智能将告警服务周边所有的服务调⽤链路环节贯通并分析出导致异常的可能原因：

这种能⼒就是EasyOps平台的故障根因分析的能⼒。我们看看如何配置和使⽤它们，以及图表达的含义。

「 实 践 」

⾸先，先定义出服务的SLI。我们选择 detect_code 作为服务能⼒的SLI，我们认为⼀旦 detect_code 不为0，表示服务不可⽤。此时告警系统会触发⼀个严重级别的故障，这个故障将被管理员接收。

这个SLI已经内置到平台当中，⽆需额外配置。我们需要做的仅仅是定义出拨测采集策略和告警规则即可。⽐如：

注意：选择的告警资源类型是【服务】模型下的⼦模型，此处为HTTP服务。平台定义只针对服务类的资源做根因 分析。

仅需简单的两步配置，即可使⽤故障根因分析的能⼒！

「 效 果 解 释 」

⼀旦某个HTTP服务发⽣告警，我们通过点击【故障分析】，即可跳转到根因分析⻚：

以开头的图为例说明：

通过上图可知，标红的服务为告警服务，其下是⼀系列围绕此服务的调⽤与被调⽤服务，并且⽗服务和⼦服务的关 系也呈现出来。⽽拓扑最下层是基础设施，也就是主机。

通过这个拓扑结构我们可知，告知故障的原因⼤概率是两台操作系统主机发⽣过变更动作。 结合右侧的传播图我们进⼀步明确变更时间点和故障时间点：

通过上图可知，变更是发⽣在1⽉18⽇，22:03:30，⽽故障是发⽣在1⽉18⽇，22:04:09，很明显此次故障是由于变更导致。在上述案例中，确实也是由于变更时将有缺陷的代码包发布到⽣产环境上，进⽽导致服务不可⽤。

在明确了故障原因后，管理员可以快速决定下⼀步操作，⽐如及时回滚，以减少故障修复时间，提⾼MTTR。