背景
众所周知，变化是网络环境不稳定的关键因素，研究表明，70%的在线故障是由某种变化引发的。 因此，当环境收到“关闭”警报时，管理员的直觉是怀疑最近是否有更改。 此时，我们经常需要主动查找变更历史，确认下一次变更的计划，这是一个繁琐且效率低下的过程。
环境故障的另一个原因是服务所在基础结构的负载和饱和度，这会影响服务的容量和性能。
我们希望能够分析环境并分析警报是由于更改还是由于系统负载造成的。 分析结果可以以直观的拓扑形式呈现，我们希望看到服务、它们所依赖的中介和基础设施之间的关系，以及哪里有变化或例外。 如下图所示：
此外，它可以智能地连接告警服务周围的所有业务调试环节，并分析异常的可能原因
这种能力是EasyOps平台分析故障根本原因的能力。 让我们来看看如何配置和制作它们，以及该图代表什么。
实践
首先，定义服务的 SLI。 我们选择检测代码作为服务能力的 SLI，我们认为如果检测代码不为 0，则表示服务不可用。 此时，告警系统将触发严重性级别故障，管理员将收到该故障。
此 SLI 已内置于平台中，需要额外的配置。 我们需要做的就是定义拨号测试收集策略和告警规则。 如：
注意：选择的告警资源类型是服务模型下的模型，在本例中为 HTTP 服务。 平台定义仅对服务资源进行根本原因分析。
只需简单的两步配置，您就可以进行根本原因分析！
效果解释
一旦HTTP服务发送告警，我们可以通过点击【故障分析】跳转到根本原因分析。
以开头的图表为例：
从上图可以看出，红色标示的服务是告警服务，下面是围绕该服务的一系列中介和调度服务，也呈现了服务与服务之间的关系。 拓扑的最低层是基础结构，即主机。
从这个拓扑中，我们可以看出，故障原因的概率是两个操作系统主机进行了更改。 结合右边的传播图，进一步明确了变化的时间点和失效点
从上图可以看出，变化发生在1 18 ，22：03：30，故障发生在1 18 ，22：04：09，因此很明显，故障是由变化引起的。 在上述情况下，确实有缺陷的 ** 包在更改时被释放到生产环境，这使得服务不可用。
在明确故障原因后，管理员可以快速决定后续步骤，例如及时回滚以减少故障修复时间并改进 MTTR。