網路 AIOpsNOTE

20260920-SADE

SADE(Symptom-Aware Diagnostic Escalation)

中文叫做症狀意識診斷升級

主要是說現在網路連線有問題，會有許多消費者影響到，很多大公司的工程師需要頂住很多壓力再做維修，但是他們也需要很多時間去檢查到底哪裡出現了問題，無法最即時的修復完成。 所以他覺得需要一個系統是在做主動式收集資訊來找到問題所在 那這個框架是吸收ReAct在動態環境中可以靈活推理與調用工具，同時加上Anthropic Agent Skills規範，做出模組化的技能庫，讓這個框架可以遵循這個標準化且可重複利用的診斷程序

他借鑑Cisco網路故障排除方法論，將他編成agent的決策策略

那他有四大核心診斷階段

第一階段：初次掃描（Initial Scan）

調用NIKA平台的get_reachability ()函式，對Kathará 模擬器中的所有主機發起兩兩對應（All-pairs）的 Ping 連通性測試。

它傳回每個主機的完整 ping 結果向網路中的所有其他主機傳回所有對的矩陣。每個可達性條目記錄來源、目的地、傳輸和接收的資料包、遺失百分比、狀態和目標IP資訊

具有非零資料包遺失、逾時、的條目拒絕連線或 ICMP 無法存取的回應都會受到處理作為候選症狀並轉發到步驟 3,同時全部其他情況則進行深度網路掃描（步驟 2）。

可能會產生不明確的輸出當名稱解析在來源失敗時,會產生行狀態 = “未知 ” 且傳輸為空，系統會自動切換為直接IP探針（direct-IP probe）重新Ping，藉此區分究竟是DNS名稱解析還是實際的L3網路路徑阻斷。


第二階段：深度網路掃描（Deep Network Scan）

當 Initial Scan 未發現連通性症狀或是故障被冗餘路徑、連接埠過濾等機制遮蔽 由下而上排查

  • Phase A（L2 / 基礎設施掃描）：使用 infra_sweep.py 與 l2_snapshot.py 檢查 nftables 防火牆攔截、IP/路由/預設網關缺失、ARP 快取不匹配及重複 MAC 地址等底層問題。

  • Phase B（控制平面與路由掃描）：使用 ospf_snapshot.py、bgp_snapshot.py 與 tc_snapshot.py 查詢 FRR 進程狀態、OSPF/BGP 鄰居建立情形、路由通告與流量控制（QoS/限速）設定。

  • Phase C（主機本地與 DHCP 掃描）：使用 host_path_snapshot.py 與 dhcp_link_history.py 檢查主機內核路由路徑（ip route get）、鏈路抖動（link-flap）歷史及 DHCP 事件日誌。

  • Phase D（服務與資源壓力掃描）：使用 service_snapshot.py 與 pressure_sweep.py 檢查 DNS 解析、HTTP 服務延遲，並監測 CPU 負載與 Socket 突發增長等資源爭用訊號。


第三階段：症狀至故障家族映射（Symptom-to-Fault-Family Mapping）

透過預先定義好的規則及與故障索引，將一二階發現的異常，動態映射到對應的高階故障家族，後續需要調用的專用診斷技能。

  • 去模糊化邏輯（Disambiguation Logic）：
    • 解決跨層多因問題：同一個表層症狀可能源自不同網路層級的故障。例如「路由器上遺失 OSPF 鄰居（OSPF neighbor missing）」，既可能是實體/鏈路層斷開，也可能是控制平面路由協定配置錯誤。
    • 動態證據驗證與分流：Fault-Index 不會靜態地將症狀死板綁定到特定故障，而是根據實時收集到的證據進行去模糊化判定：
      • 先利用 infra_sweep 檢查介面狀態：若介面為 DOWN，症狀會被路由至 link-fault-skill（鏈路故障技能）。
      • 若介面狀態為 UP 但 OSPF 鄰居表為空，才歸類為路由層異常，並路由至 ospf-fault-skill（OSPF 故障技能）。

第四階段：基於技能庫的故障檢測與定位（Fault Detection and Localization）

  • 動態調用專用技能：第三段後會透過Skill工具從包含15個Claude Skills的技能庫（Skills Bank）中，調用對應故障家族的聲明式技能文件。
  • 結構化技能文件內容
  • 執行針對性探針：Agent 依據技能指引發起針對性的命令或MCP探針。
  • 指紋比對與設備定位：Agent在運行時將探針收集到的數據與SKLL.md中的故障指紋進行動態推理比對。一旦某台設備的數據與指紋完全吻合，即可精確定位出引發故障的具體設備。
  • 停止並提交機制：一旦指紋比對成功，Agent會立即觸發終止規則，提交規範的故障標籤與設備名稱並結束診斷。這種明確的停止點設計，能有效停止傳統LLM Agent因盲目探測而耗盡診斷預算。

EXPERIMENT SETTINGS（實驗設定）

  1. 實驗設置（Experimental Setup）
    • 測試平台與模擬環境

      IKA 資料集共包含 640 個故障事件，涵蓋 54 種網路問題、12 種情境配置，並劃分為 5 大網路情境（數據中心 CLOS、三層式校園網、ISP 骨幹網、SDN 及 P4），且包含小型（small）、中型（medium）與大型（large）多種拓撲規模。

    • 資料集劃分
      • 開發/訓練集：保留 ospf_dhcp 配置（包含 108 個事件）作為 SADE 的開發與微調資料集。
      • 測試集：其餘 4 個網路情境在扣除部署時跳過的異常案例後，最終保留 523 個獨立測試事件（Held-out Test Incidents） 進行嚴格的公平評測。
    • SADE實作與對照模型
  2. 評估指標（Evaluation Metrics）
    • 異常檢測準確率 (Detection Accuracy)：

      評估 Agent 是否能正確判斷網路中是否存在異常（對應 is_anomaly 布林值標籤）。

    • 根因分析 F1 分數 (Root-Cause F1 Score)：

      計算 Agent 預測的故障標籤與真實根因（Ground Truth）之間的 F1 分數（考慮單一事件可能包含多個相關故障標籤）。

    • LLM-as-Judge 綜合評分：

      採用 gpt-5-mini 作為評審模型，針對 相關性（Relevance）、正確性（Correctness）、效率（Efficiency）、清晰度（Clarity） 及 最終結果（Final Outcome） 等 5 個維度進行 1～5 分的評分，並輸出綜合平均得分。

    • 診斷效率與成本指標：

      記錄每次診斷所發起的 工具調用次數（Tool Calls） 以及 Token 消耗量（Input/Output Tokens），用以衡量診斷效率與實際維運成本。