小提示
- 請使用假設導向的調查，而非隨機對數搜尋。
- 提供完整的證據鏈，說明 為什麼 會造成這種情況。
- 回想過去類似的事件及其解決方法。
問題是：日誌搜尋不是調查
大多數除錯都是從「給我看錯誤」開始的。你查詢日誌、瀏覽結果、複製時間戳、切換工具，然後執行另一個查詢。 你不是在調查。 你是在手動對應資料，並將推理放在腦中。
真正的問題不是找到木頭。 它就是知道該問什麼問題、檢查哪些工具，以及如何串連日誌、指標、部署和過去事件之間的關聯。 這個心智模型存在於資深工程師的腦海中，他們不可能參與每通電話。 新成員花上好幾個小時處理老手幾分鐘就能解決的問題，因為這些理由根本沒有被記錄下來。
Azure SRE 代理如何解決此問題
您的 Agent 會像專業的 SRE 專家一樣進行調查。 它不只是搜尋記錄。 它會針對發生錯誤的情況提出假設，並用證據系統性地驗證每一個假設。
- 收集上下文：查詢應用程式洞察、Azure Monitor、部署歷史、活動日誌及資源屬性。
- 形式假設：根據證據模式產生理論。
- 驗證每一項：系統性地檢驗假設，排除假線索。
- 解釋結論：展示完整的推理過程及支持證據與引用。
這種做法有什麼不同
與記錄搜尋不同，你的代理人會針對問題進行推理。 「顯示錯誤」功能會提供資料以供解讀。 你的代理人會透過建立理論、測試並解釋結論來解讀資料。
與靜態儀表板不同，您的客服人員會根據特定事件進行調整。 它不只是顯示指標。 它決定哪些指標重要，將它們與其他證據相關聯，並告訴你原因。
與劇本不同，你的經紀人處理的是新穎的情境。 腳本每次執行的步驟都一樣。 你的代理會根據這次的不同之處進行思考，並調整其調查方法。
前後比較
| 類別 | 之前 | 之後 |
|---|---|---|
| 調查方法 | 搜尋日誌，希望能找到一些東西。 | 代理人形式與檢驗假設 |
| 工具已開啟 | 4+ 門戶，手動關聯 | 0（代理查詢所有來源） |
| Reasoning | 「我想是資料庫的問題......」 | 「資料庫 DTU 98%，已驗證」 |
| 證據追蹤 | 在你腦海裡 | 完整鏈條及說明 |
| 下次見 | 從頭開始 | 記憶中回憶起類似事件 |
範例：資料庫逾時調查
症狀：「/api/orders 端點出現 500 個錯誤」
HYPOTHESIS 1: Recent deployment broke something
├─ Checked: Last deployment was 3 days ago
├─ Evidence: Error rate stable until 30 minutes ago
└─ Result: INVALIDATED
HYPOTHESIS 2: Database overloaded
├─ Checked: Azure SQL metrics (CPU, DTU, connections)
├─ Evidence: DTU at 98%, query duration 4x normal
├─ Traced: SELECT * FROM orders WHERE... taking 8.2s
└─ Result: VALIDATED
ROOT CAUSE: Orders table missing index on customer_id column.
Query plan shows full table scan on 2.1M rows.
RECOMMENDED ACTION: Add index on orders.customer_id
Similar fix applied in INC-2341 (3 weeks ago)
開始
根本原因分析可透過 Azure 內建工具自動運作。 為了促進更深入的分析，請考慮以下改進。
| 增強功能 | 它所帶來的意義 | 設定 |
|---|---|---|
| 源碼管理 | 錯誤與程式碼相關性、語意碼搜尋 | 連接原始碼 |
| 知識庫 | 假設產生的背景 | 上傳知識 |
| 自訂遙測 | Kusto 中的商業指標 | 設定 Kusto 連接器 |