Microsoft AZ-400: 監控、可觀測性與回饋 — 學習指南

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

屬於 Microsoft DevOps Engineer Expert AZ-400 — 學習指南. 使用經過驗證的解答練習： Microsoft 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

現代的 DevOps 團隊將監控、可觀測性與回饋視為一個持續的循環，為工程、營運和產品決策提供資訊。在 Azure 中，遙測資料從應用程式與基礎設施流入 Azure Monitor 和 Log Analytics，並在其中進行查詢、關聯與視覺化。分散式追蹤將各個服務串連成端對端的交易，而警示與待命 (on-call) 整合則驅動快速的修復。Azure DevOps 的儀表板、工作項目分析與實驗，透過將洞見回饋到規劃與交付流程中，來形成閉環。本節提供了設計整合式可觀測性堆疊所需的深度知識，以在每個階段提供可行的回饋。

遙測、追蹤與 Azure Monitor

Application Insights 是 Azure Monitor 的應用程式效能監控 (APM) 元件。可透過以下方式加入檢測 (instrumentation)：

• SDK 與自動檢測：.NET/.NET Core、Java、JavaScript、Node.js、Python，以及適用於 .NET 和 Java 的 Application Insights Agent。使用連線字串並設定 cloud_RoleName 來區分不同的元件。
• 遙測初始化器 (initializer) 與處理器 (processor)：在發送前新增或變動屬性 (例如 tenantId) 並過濾 PII (個人識別資訊)。
• 自訂遙測：使用 TrackEvent 追蹤商業行為、TrackMetric 追蹤數值型 KPI、TrackException 追蹤錯誤情境，以及 TrackDependency 追蹤需要明確建立模型的外部呼叫。

遙測類型包括請求、相依性 (HTTP、SQL、Azure SDK)、追蹤、例外、頁面瀏覽、頁面載入效能、可用性測試結果、自訂事件/指標，以及即時計量。取樣 (Sampling) 在保留訊號的同時，控制資料量與成本：SDK 自動適應取樣會針對每種類型自動調整速率，以維持目標輸送量與關聯性；固定速率取樣則為符合法規要求而提供確定性的取樣。建議採用 SDK 端的取樣，這樣下游系統就永遠不會處理到被丟棄的項目。維持黏性取樣 (sticky sampling) 以確保端對端追蹤的完整性。

分散式追蹤提供端對端的交易可視性。Application Insights 實作了 W3C Trace-Context 標準 (traceparent/tracestate)，可自動跨 HTTP 傳遞關聯 ID；將情境資訊 (context) 跨越非同步邊界與自訂協定進行傳遞，以避免追蹤鏈斷裂。相依性追蹤會自動收集常見的對外呼叫；針對訊息佇列的躍點 (hop) 或非標準的 RPC 發出自訂的相依性，以完善呼叫圖 (call graph)。App Map 和 Transaction Search 可將跨服務的流程、延遲與故障熱點視覺化。為了實現前端到後端的關聯，請啟用 JavaScript SDK，並確保伺服器端接受關聯標頭，以衡量真實的頁面載入時間與使用者旅程。

Azure Monitor 統一了平台與應用程式的遙測資料：

• 指標 (Metrics)：多維度、近乎即時 (一分鐘或更佳的細微性)。使用帶有靜態或動態閾值的指標警示，以進行快速、低延遲的偵測。
• 日誌 (Logs)：位於 Log Analytics 工作區中的半結構化遙測資料，可使用 KQL 進行查詢，以進行深度分析與異常獵捕。
• 警示 (Alerts)：指標、日誌與活動日誌規則會路由到動作群組。使用動態閾值、多資源目標以及通用的警示結構 (schema) 以進行一致性的處理。
• 動作群組 (Action groups)：電子郵件/簡訊/語音、推播通知、webhook (包含 PagerDuty/OpsGenie)、ITSM 連接器、Logic Apps、Azure Functions，以及用於修復的 Automation runbook。
• 診斷設定 (Diagnostic settings)：設定每個 Azure 資源，將平台指標/日誌串流至 Log Analytics、Azure Storage (用於封存) 和 Event Hubs (用於 SIEM 系統的擷取)。透過由原則驅動的部署來確保一致性。

使用 Log Analytics (KQL) 進行查詢與分析

Log Analytics 工作區是日誌的查詢與治理邊界。依據環境與資料主權進行規劃：為生產與非生產環境分離工作區可以簡化 RBAC 與保留原則；集中化則有助於跨服務的關聯分析。資料來源包括 Azure Diagnostics (平台日誌/指標)、VM 代理程式 (Syslog/Windows 事件、效能計數器)、Container Insights/AKS、Application Insights 元件日誌 (統一於 Azure Monitor Logs 之下)、Azure AD 登入、透過擷取 API 傳入的自訂日誌，以及使用資料收集規則 (Data Collection Rules) 進行精確的串流路由與轉換。

Kusto 查詢語言 (KQL) 專為時間序列與遙測分析而優化：

• 核心運算子：where (篩選)、project (選取)、extend (衍生)、summarize by (彙總)、join/union (關聯)、parse/parse_json (提取)、mv-expand (陣列)、用於時間分桶的 make-series 和 bin、用於圖表繪製的 render。
• 模式：錯誤預算消耗 (時間加權的失敗率)、p50/p95 延遲分佈、相依性離群值偵測、請求成功率與流量的對比，以及使用 series_decompose_anomalies 進行具季節性感知能力的警示來偵測異常。
• 治理：儲存的查詢與函式可促進重複使用；RBAC 與資料表層級的存取權限可限制對敏感資料集的存取。
• 跨資源與跨工作區：使用 workspace("workspaceNameOrId").Table 和 workspaces() 函式來結合跨環境與訂閱的資料集；使用 resource() 進行跨資源的 join。應用 let 繫結和 materialize() 來控制大型 join 操作的效能。

在 Azure DevOps 中的視覺化與敏捷回饋

Azure DevOps 中的儀表板 (Dashboards) 可傳達營運與流程的健康狀況。團隊層級的儀表板專注於團隊的待辦項目 (backlog)、迭代 (iterations) 與在製品 (WIP)；專案層級的儀表板則呈現跨團隊與產品組合 (portfolio) 的視圖。小工具 (Widgets) 包含 Sprint Burndown、Burnup、Velocity、Cumulative Flow Diagram (CFD)、Cycle Time、Lead Time、Work Item Chart/Query Results、Build/Release 摘要，以及用於執行手冊 (runbooks) 和 SLO 狀態的 Markdown。使用儀表板權限來保護小工具，並將查詢範圍嚴格限定在團隊/區域，以避免跨團隊的資訊洩漏。

Boards 查詢 (透過查詢產生器或 WIQL) 是許多小工具的動力來源。依團隊的區域路徑/迭代將查詢參數化以便重複使用；當有基於 Analytics 的小工具可用時，優先選擇它們以獲得更高的準確性與效能。關鍵流程指標：

• Cycle time：從「作用中」(Active，進行中) 到「完成」(Done) 所經過的時間；使用 Cycle Time 小工具來追蹤執行效率。
• Lead time：從建立/承諾到「完成」(Done) 所經過的時間；標示出客戶所感知的系統總延遲。
• Throughput：每個時間間隔內完成的項目數量；與 WIP 策略比較以偵測瓶頸。
• Cumulative Flow Diagram：將不同狀態的佇列大小隨時間變化的情況視覺化；逐漸變寬的區塊揭示了限制與情境切換 (context-switching)。 對於衝刺 (sprint) 追蹤，使用 Burndown (剩餘工作趨向於零的趨勢) 和 Burnup (總範疇與已完成工作的比較，能適應範疇變更)。Velocity 報告每個衝刺平均完成的投入量，並為容量規劃提供資訊；僅匯總團隊間同類型的估算單位。

當需要產品分析時，可將 Azure DevOps Analytics 連接到 Power BI，以結合交付指標與營運遙測資料 (例如，lead time 與瑕疵逃逸率)，從而排定改善事項的優先順序。

可靠性、警示與持續回饋

SLI/SLO/SLA 將可靠性確立為第一級的功能：

• SLIs：使用者體驗的量化指標，例如：請求成功率、p95 延遲、關鍵端點的可用性，或 UI 中的任務完成率。
• SLOs：在一個時間窗內的目標，例如：99.9% 的月可用性或 p95 < 300 毫秒。將 SLO 與使用者旅程綁定，而非基礎設施。
• 錯誤預算：1 − SLO；用於管理發布風險、回滾標準和事件應對。使用 KQL 或指標警示來實作燃燒率警示（例如：2 倍和 14 倍的預算燃燒），以應對快速和緩慢的違規情況。
• SLAs：對客戶的外部承諾；通常比 SLOs 寬鬆，並包含罰則；它會驅動但不決定工程上的防護機制。

警示與 on-call：

• 對於延遲敏感的條件使用指標警示；對於複雜的判斷條件（例如：多信號關聯或異常分數）使用日誌警示。
• 透過重複資料刪除（警示處理規則）、動態閾值、嚴重性調整，以及在計畫性維護期間自動抑制警示，來減少警示疲勞。
• 透過使用通用警示結構描述 (common alert schema) 的動作群組 (action group) webhook 與 PagerDuty/OpsGenie 整合；對應警示關聯鍵以進行事件去重，並為每個服務定義升級策略。
• 使用 Azure Automation runbooks、Functions 或 Logic Apps 自動化修復（例如：根據佇列深度擴展、回收故障的執行個體、切換功能旗標）。將每個自動化操作記錄為 Application Insights 中的自訂事件，以供稽核。

持續回饋與實驗：

• A/B 測試與漸進式部署：使用 Azure Front Door 或 Traffic Manager 在邊緣進行流量分割，或使用 Azure App Configuration Feature Manager 實作功能旗標，以進行基於個別使用者或群組的部署。用旗標保護程式碼路徑，並為每個變體收集事件遙測。
• 使用者遙測：發送帶有功能旗標狀態、使用者屬性（非 PII）和情境識別碼的 TrackEvent。在 Application Insights 中分析漏斗、使用者流程、留存率和群組表現，以驗證假說。
• 功能使用分析：建立儀表板來追蹤 DAU/WAU/MAU、功能採用率和轉換指標。將結果回饋到待辦事項的優先級排序中。使用 Azure Pipelines 閘門，在預備環境 (staging) 的 SLI 基線失敗或實驗 KPI 出現迴歸時，阻止生產環境的部署。

實務問題情境

Spotify 需要為其部署在 Azure Kubernetes Service (AKS) 和 Azure App Service API 上的 podcast 擷取與播放服務，改善端到端的能見度與回饋機制。事件偵測過晚，且產品團隊缺乏可靠的新播放功能採用率指標。

1. 檢測並關聯應用程式遙測

• 將 Application Insights SDK 加入 .NET 和 Node.js 服務；在 Web 客戶端啟用 Application Insights JavaScript SDK。設定 cloud_RoleName 和連接字串；啟用跨微服務和訊息佇列的 W3C trace-context 傳播。 原因：確保一致的關聯 ID 和分散式追蹤，以實現從瀏覽器到服務及其相依性的完整交易能見度。

2. 將平台診斷資料串流至 Log Analytics

• 透過 Azure Policy 將診斷設定應用於所有 AKS 叢集、App Service 方案、Application Gateways、Cosmos DB 和 Storage 帳戶，將資料路由到一個中央的生產環境工作區，保留 90 天並封存到 Storage。 原因：保證平台日誌/指標的統一覆蓋，以便進行 KQL 關聯分析和符合成本效益的長期保留。

3. 定義 SLIs、SLOs 和錯誤預算

• SLIs：p95 API 延遲、請求成功率、擷取管線吞吐量，以及播放器啟動成功率。
• SLOs：每月 99.95% 成功率、p95 播放啟動時間 < 300 毫秒、擷取延遲 < 2 分鐘。
• 建立基於 KQL 的錯誤預算燃燒率警示（快速/緩慢）和針對延遲的指標警示，並使用動態閾值。 原因：將業務成果轉換為可衡量、可操作的可靠性目標，並提供及時的警示。

4. 建立可操作的警示與 on-call 整合

• 建立具有智慧分組 (smart grouping) 功能的 Azure Monitor 警示規則；路由到一個動作群組，該群組使用通用警示結構描述透過 webhook 觸發 PagerDuty。附加 Azure Automation runbooks 以根據佇列深度自動擴展，並重新啟動不健康的 pod。 原因：透過可靠的呼叫通知和安全、可稽核的自動修復，減少 MTTA/MTTR。

5. 為工程和產品團隊建立儀表板

• Azure DevOps 團隊級儀表板：Cycle Time (Active→Done)、Lead Time (Created→Done)、CFD、Velocity 和 Sprint Burndown，供開發小隊使用。專案級儀表板：發布的 Burnup、跨團隊吞吐量，以及透過 Markdown/Analytics 小工具顯示的 SLO 狀態。 原因：讓開發小隊洞察執行狀況，同時為領導層提供專案組合和可靠性的健康狀況。

6. 實作實驗與使用分析

• 使用 Azure App Configuration 功能旗標，逐步推出新的「智慧跳過靜音」功能。在需要時，使用 Front Door 規則在邊緣進行 A/B 測試以分割群組。發送帶有 featureFlagState、使用者群組和結果指標的 TrackEvent。 原因：安全地驗證影響，同時捕獲高擬真度的使用者遙測，以進行基於證據的決策。

7. 透過閘門強制執行發布品質

• 在 Azure Pipelines 中，新增閘門來查詢 Application Insights/Log Analytics 的預備環境 KPI（p95 延遲、失敗率、實驗變體表現）。如果未達到基線或與 SLO 一致的閾值，則閘門失敗。 原因：防止迴歸進入生產環境，並使部署決策與可靠性和產品 KPI 保持一致。

← 測試策略與品質工程 · 所有領域 · 套件管理與成品管理 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Microsoft →