Microsoft AZ-104: Azure Monitor、備份與站台復原 — 學習指南

By Laurynas Brazys · 7 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

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

總覽

要在 Azure 上實現卓越營運，需要三大支柱共同運作：可觀測的遙測資料、可復原的資料，以及具備彈性的持續性計畫。Azure Monitor 及其 Log Analytics 基礎可收集高擬真度的計量和記錄、驅動智慧型警示，並呈現應用程式效能。Azure Backup 透過由原則驅動、以保存庫為基礎的復原機制來保護平台和 IaaS 資料，其中包含可將停機時間降至最短的即時還原功能。Azure Site Recovery (ASR) 會將工作負載複寫到備援站台，並調度容錯移轉和容錯回復，以滿足企業的 RPO/RTO。輔助服務——用於網路診斷的 Network Watcher 和用於平台感知的 Azure Service Health——構成一套完整的管理員工具組。

Azure Monitor 與 Log Analytics

Azure Monitor 統一了平台的計量與記錄。計量是數值型時間序列，已針對近乎即時的分析進行最佳化（高基數、多維度、對大多數資源而言為一分鐘的細微性）。使用 Metrics Explorer 進行視覺化，並透過靜態或動態閾值設定近乎即時的計量警示。記錄是儲存在 Log Analytics 工作區中的結構豐富的記錄，可使用 Kusto Query Language (KQL) 進行查詢，以利調查、建立儀表板和設定排程（記錄）警示。

診斷設定是從資源連接到遙測接收器的橋樑。在每個 Azure 資源上，設定診斷設定以選擇類別（平台計量、平台記錄和資源記錄），並將它們路由到一個或多個目的地：

Log Analytics 工作區，用於分析和以記錄為基礎的警示
儲存體帳戶，用於長期、低成本的保留和合規性
Event Hubs，用於串流至 SIEM 或第三方工具

請審慎地設計 Log Analytics 工作區：

工作區範圍與存取：在工作區和資料表層級使用 RBAC，以符合最低權限和營運邊界（例如，依據環境和區域）。資源內容查詢允許團隊查詢他們有權存取之資源範圍內的記錄，即使記錄是集中存放的。
資料收集：優先使用 Azure Monitor agent (AMA) 搭配 Data Collection Rules (DCRs)，而非舊版代理程式。DCRs 定義要收集的內容（效能計數器、Windows/Linux 事件記錄、syslog、自訂文字記錄）、從哪些機器收集，以及存入哪些資料表，從而實現每個範圍的精細管線。
成本與保留：透過每個資料表的保留、封存和適時使用基本記錄來控制成本。盡可能在收集時使用取樣和篩選。
資料來源：Azure Activity Log、透過診斷設定的資源記錄、VM insights 和 Container insights、Azure AD 登入和稽核記錄（透過診斷設定）、Azure Firewall/NSG 流量記錄、自訂應用程式記錄，以及透過 Azure Monitor agent 的地端資料。

精通 KQL 至關重要。範例如下：

快速稽核：

undefined

效能分類：

undefined

錯誤率：

undefined

動作群組定義了由誰以及由什麼來回應警示：電子郵件/簡訊/推播/語音、安全的 Webhook、ITSM 連接器、Functions、Logic Apps 和 Automation runbooks。在不同的警示規則之間重複使用動作群組，並強制執行一致的事件路由。

Azure Monitor 支援多種警示類型：

計量警示：以近乎即時的頻率評估平台或自訂計量，可使用靜態閾值或能學習正常基準的動態閾值。
記錄（排程查詢）警示：依設定的頻率在工作區資料上執行 KQL；根據結果計數或數值彙總觸發。對於跨資源的複雜模式很有用。
活動記錄警示：在控制平面事件上觸發（例如，當 VM 被刪除或角色指派變更時）。這些不需要工作區。
智慧偵測：主要針對 Application Insights 資源的異常偵測和失敗率遽增；會自動通知擁有者，並可與動作群組整合。

Application Insights 與警示

Application Insights 檢測程式碼和平台，以提供端對端的應用程式遙測。使用連接字串和第一方 SDK（.NET、Java、Node.js、Python）或 OpenTelemetry 進行廠商中立的追蹤。對於 PaaS 服務（App Service、Functions、AKS），在可用時啟用自動檢測，以在不變更程式碼的情況下擷取要求、相依性、例外狀況和追蹤。維持分散式追蹤內容，以相互關聯用戶端、API 和後端躍點。

關鍵遙測類型：

要求：傳入的操作，包含回應碼和持續時間
相依性：傳出的呼叫（HTTP、SQL、佇列），包含持續時間和成功狀態
例外狀況與追蹤：錯誤和診斷記錄，包含嚴重性
計量：自訂或標準計數器
頁面檢視與瀏覽器計時：前端效能
自訂事件與測量：特定領域的訊號

應用調適性取樣來控制擷取量，同時不失訊號擬真度，並在事件期間使用 Live Metrics Stream 進行低延遲的洞察。

可用性測試可驗證外部可連線性與 SLA：

標準（URL ping）測試：從多個 Azure 區域探測端點，驗證狀態碼、SSL 到期時間範圍、內容比對和回應時間閾值。
自訂測試：在程式碼中使用 TrackAvailability 進行綜合工作流程或受保護的端點。失敗可以自動產生連接到動作群組的警示。

在 Application Insights 中透過智慧偵測來增強警示功能，以應對：

失敗異常與效能降低
記憶體洩漏與相依性異常這些功能會學習典型模式並減少誤報，與基於閾值的警示相輔相成。

Azure Backup

Recovery Services vault 是備份管理、原則與復原的基礎。請將 vault 放置在與受保護資源相同的區域中（或在服務支援的跨區域還原情境中，放置在配對的區域）。透過虛刪除 (soft delete)、清除保護 (purge protection) 以及針對關鍵操作的多使用者授權 (multi-user authorization) 來強化 vault 的安全性。

備份原則定義了排程與保留期：

Azure VM 備份：每日快照搭配短期保留，可選用每週/每月/每年的長期保留；啟用時，可透過 VSS (Windows) 或前置/後置指令碼 (Linux) 實現應用程式一致性 (app-consistent) 的復原點。
Azure Files 備份：由共用快照支援的每日備份；保留期依業務需求而定；支援還原至原始或備用共用，並具備項目層級復原 (item-level recovery) 的能力。
Azure VM 中的 SQL Server：完整 (每日/每週)、差異 (每日) 與日誌備份 (頻率可低至每 15 分鐘一次)，可實現時間點還原 (point-in-time restore)。自動保護 (Auto-protect) 功能會探索新的資料庫。

Instant Restore 透過使用本機儲存的快照來加速 VM 復原，這些快照在存入 vault 進行深度儲存之前，會先被保留一小段時間。管理員可以：

還原整個 VM (成為新的運算資源) 以最小化復原時間
還原磁碟並將其重新附加到現有的 VM 上，以進行針對性的修復
透過將復原點掛載為暫時的 iSCSI 裝置到訂用帳戶中的任何 VM (需具備角色權限)，來執行檔案與資料夾層級的復原，這使得在發生如勒索軟體等事件後，能進行精準的還原

VM 備份的考量事項包括：針對非關鍵資料的磁碟排除、加密處理 (Azure Backup 支援加密磁碟)，以及一致性模型 (損毀一致性 (crash-consistent) vs. 應用程式一致性 (app-consistent))。Azure Files 備份利用儲存體快照，其優點是增量、節省空間的保留方式以及虛刪除 (soft delete) 保護。Azure VM 中的 SQL 備份使用一個由 vault 協調、具備工作負載感知能力的擴充功能，以在 Always On 可用性群組與獨立執行個體之間，產生合規且可還原的備份鏈。

Azure Site Recovery、Network Watcher 與 Service Health

ASR 提供工作負載複寫與協調復原：

複寫來源：從地端的 VMware/Hyper-V/實體機器到 Azure；Azure 區域對區域。受保護機器上的 Mobility service 會擷取變更並將其複寫到快取/目標儲存體。為共用寫入順序的分層應用程式啟用多磁碟一致性。
目標組態：預先建立或對應資源群組、VNet/子網路、可用性選項 (區域/集)、受控磁碟類型和命名慣例。使用網路對應和 DNS 更新以確保容錯移轉後的可連線性。
容錯移轉選項：測試容錯移轉 (隔離的驗證，不影響生產環境)、計劃性容錯移轉 (零資料遺失，來源會關機) 和非計劃性容錯移轉 (中斷期間盡力而為)。容錯移轉後，執行「重新保護 (Reprotect)」以反轉複寫方向；當主要站點就緒時，根據來源類型，透過處理序伺服器或直接複寫進行「容錯回復 (Failback)」。
復原計畫：透過群組、手動核准步驟以及 Azure Automation runbook 或指令碼 (用於應用程式暖機、負載平衡器重新設定和 DNS 變更) 來協調多 VM 層級。嵌入排序和逾時設定以達成可預測的 RTO。

RPO/RTO 目標指導原則的制定：

RPO (可接受的資料遺失) 取決於變更率、網路吞吐量和複寫頻率。設定 RPO 閾值以在超過時引發健康狀態警示。
RTO (服務還原所需時間) 取決於開機時間、協調步驟、DNS/連線更新和資料平面操作 (如磁碟附加)。調整復原計畫、預先佈建容量，並使用測試容錯移轉來驗證是否達到目標。
複寫原則定義了應用程式一致性快照的頻率和復原點保留期間，以平衡儲存成本、復原彈性和效能。

Azure Network Watcher 為管理員提供精確的網路診斷工具：

IP 流量驗證 (IP flow verify)：驗證某個流量是否被 NIC 上有效的 NSG 規則所允許或拒絕，並識別出影響該決策的具體規則。
下一躍點 (Next hop)：計算到給定目的地 (網際網路、虛擬網路、虛擬設備) 的路由決策，揭示有效的「使用者定義路由 (UDR)」和系統路由。
連線疑難排解 (Connection troubleshoot)：在來源和目的地之間，跨 VNet 和混合式連結執行端對端的探測，報告可連線性、延遲以及發生故障的躍點。
封包擷取 (Packet capture)：在 VM 的 NIC 上使用篩選器 (通訊協定/連接埠/IP) 擷取封包，並儲存到儲存體帳戶或本機，有助於對間歇性問題進行深度檢查。需要在 VM 上安裝 Network Watcher 擴充功能。

Azure Service Health 以平台感知能力補強監控：

服務問題 (Service issues)：影響所選服務和區域的即時中斷和效能降低事件，並提供根本原因和緩解措施更新。
計劃性維護 (Planned maintenance)：關於即將到來、可能影響工作負載的平台維護時程通知，包含時間表和必要行動。
健康狀態建議 (Health advisories)：可能需要變更組態的最佳實務和安全性建議。建立範圍限定於服務/區域/訂用帳戶的 Service Health 警示，並透過動作群組進行路由，以便營運團隊在受到影響前收到通知。使用 Resource Health 來查看每個資源的可用性狀態 (可用、效能降低、無法使用、未知)，以區分平台問題與工作負載問題。

實務問題情境

Adobe 必須強化並營運一個部署在 Azure 上的新雙區域電子商務平台，達成嚴格的可觀測性、備份和災難復原目標，同時確保快速的網路疑難排解和平台感知能力。

每個區域部署一個中央 Log Analytics 工作區，並將資料收集規則 (Data Collection Rules) 附加到所有 VM 和 AKS 節點，以透過診斷設定收集效能、syslog/EventLog 和資源特定日誌。理由：區域性工作區可維持資料落地性和效能；AMA+DCR 提供精細、可擴展的收集方式和成本控制。
在 App Service、Key Vault、Azure Firewall、Application Gateway 和 Storage 上設定診斷設定，將日誌和計量路由到區域工作區，並路由到一個儲存體帳戶以供長期保留。理由：集中式分析能夠進行跨資源的關聯分析；儲存體保留滿足了合規性和鑑識需求。
使用 OpenTelemetry 為 Web 和 API 層級植入 Application Insights，並在 App Service 上啟用自動植入。從至少五個 Azure 區域建立可用性測試，並包含內容比對和 TLS 到期檢查。理由：深度分散式追蹤和綜合測試能在客戶發現前，偵測到影響使用者的功能衰退。
建立 Azure Monitor 警示：

針對 CPU、記憶體、HTTP 5xx 錯誤率和 App Gateway 後端健康狀態的動態計量警示
使用 KQL 針對異常的防火牆拒絕和登入失敗的排程查詢警示
針對關鍵資源上的刪除/角色指派事件的活動日誌警示
將所有警示連接到共用動作群組 (發送 email/SMS 給待命人員、webhook 到 ITSM 系統、用 Logic App 開立事件單) 理由：多信號警示透過可操作的路由傳送給人員和系統，縮短了平均偵測時間 (MTTD)。