背景
眾所周知，變化是網路環境不穩定的關鍵因素，研究表明，70%的線上故障是由某種變化引發的。 因此，當環境收到“關閉”警報時，管理員的直覺是懷疑最近是否有更改。 此時，我們經常需要主動查詢變更歷史，確認下一次變更的計畫，這是乙個繁瑣且效率低下的過程。
環境故障的另乙個原因是服務所在基礎結構的負載和飽和度，這會影響服務的容量和效能。
我們希望能夠分析環境並分析警報是由於更改還是由於系統負載造成的。 分析結果可以以直觀的拓撲形式呈現，我們希望看到服務、它們所依賴的中介和基礎設施之間的關係，以及哪裡有變化或例外。 如下圖所示：
此外，它可以智慧型地連線告警服務周圍的所有業務除錯環節，並分析異常的可能原因
這種能力是EasyOps平台分析故障根本原因的能力。 讓我們來看看如何配置和製作它們，以及該圖代表什麼。
實踐
首先，定義服務的 SLI。 我們選擇檢測程式碼作為服務能力的 SLI，我們認為如果檢測程式碼不為 0，則表示服務不可用。 此時，告警系統將觸發嚴重性級別故障，管理員將收到該故障。
此 SLI 已內置於平台中，需要額外的配置。 我們需要做的就是定義撥號測試收集策略和告警規則。 如：
注意：選擇的告警資源型別是服務模型下的模型，在本例中為 HTTP 服務。 平台定義僅對服務資源進行根本原因分析。
只需簡單的兩步配置，您就可以進行根本原因分析！
效果解釋
一旦HTTP服務傳送告警，我們可以通過點選【故障分析】跳轉到根本原因分析。
以開頭的圖表為例：
從上圖可以看出，紅色標示的服務是告警服務，下面是圍繞該服務的一系列中介和排程服務，也呈現了服務與服務之間的關係。 拓撲的最低層是基礎結構，即主機。
從這個拓撲中，我們可以看出，故障原因的概率是兩個作業系統主機進行了更改。 結合右邊的傳播圖，進一步明確了變化的時間點和失效點
從上圖可以看出，變化發生在1 18 ，22：03：30，故障發生在1 18 ，22：04：09，因此很明顯，故障是由變化引起的。 在上述情況下，確實有缺陷的 ** 包在更改時被釋放到生產環境，這使得服務不可用。
在明確故障原因後，管理員可以快速決定後續步驟，例如及時回滾以減少故障修復時間並改進 MTTR。