Microsoft AZ-305: 高可用性、災難復原與業務連續性 — 學習指南

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

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

總覽

在 Azure 中實現高可用性 (HA)、災難復原 (DR) 與業務連續性 (BC)，需要在運算、資料和網路層級上進行審慎的設計。彈性設計始於明確的復原時間目標 (RTO) 和復原點目標 (RPO)，然後將平台功能——例如可用性區域 (Availability Zones)、全域路由、資料複寫、備份和容錯移轉協調——組合成一個經過測試的自動化策略。Azure 提供區域 (zone) 和地區 (region) 的故障隔離、基於 DNS 和 anycast 的全域分發、多地區資料持久性，以及由原則驅動的備份/還原，以便在控制成本和營運複雜性的同時，滿足嚴格的目標。

由 RTO/RPO 驅動的架構與區域性/全域性彈性

設計始於 RTO 和 RPO。RTO 決定了服務在故障後必須多快恢復；RPO 則決定了可接受的最大資料遺失量。要達到低的 RTO，需要自動化的容錯移轉和預先佈建的容量；要達到低的 RPO，則需要同步或近同步的複寫以及頻繁的一致性復原點。

可用性區域 (Availability Zones) 是單一地區內各自獨立的資料中心故障網域。區域性 (Zonal) 服務（例如 Virtual Machines、受控磁碟、Standard public IPs）會被固定在單一區域中。區域備援 (Zone-redundant) 服務（例如 Azure Load Balancer Standard 的區域備援前端、區域備援儲存體方案，以及區域備援的 Azure SQL 層）會自動橫跨多個區域。一個典型的彈性模式是在至少兩個區域中部署區域性 VM，將它們放在同一個虛擬網路中，並公開一個區域備援的負載平衡前端。這可以消除單一區域故障導致的停機時間。

在全球邊緣，可以在基於 DNS 和基於 anycast-proxy 的負載分發之間做選擇：

• Azure Traffic Manager 是基於 DNS 的服務。它使用多種路由方法將用戶端導向至端點：效能 (最低延遲)、加權 (用於 A/B 測試和漸進式流量轉移)、優先順序 (用於主動/被動容錯移轉)、地理位置 (從符合區域法規的端點服務使用者)、多重值 (為簡易用戶端傳回多個健康的 IPv4/IPv6 記錄)，以及子網路 (將用戶端 IP 範圍對應到特定端點)。由於 Traffic Manager 是基於 DNS，它不會加速內容或代理流量；用戶端會直接連線到所選的端點，並遵循本地 DNS 的快取行為。
• Azure Front Door (Standard/Premium) 是一個全域性的 anycast HTTP/HTTPS 反向代理，具備智慧路由、TLS 卸載和整合式 Web 應用程式防火牆 (WAF)。路由規則會根據網域、路徑、方法和標頭進行比對，然後將流量路由到來源群組；規則引擎的動作可以重寫 URL/標頭並強制執行重新導向。健康狀態探查會根據可設定的路徑和通訊協定，持續評估來源的健康狀況；不健康的來源會從輪替中移除。來源群組支援跨地區的優先順序（主動/被動）和加權分發。WAF 原則可附加在端點或路由上，透過受控規則集、自訂規則和速率限制來緩解 OWASP 威脅和惡意用戶端攻擊。當您需要具備加速、邊緣安全性和應用程式感知容錯移轉的全域負載平衡時，請使用 Front Door；只有在需要非 HTTP 端點或 DNS 層級的控制時，才將它與 Traffic Manager 結合使用。

在第 4 層，Azure Load Balancer 為 TCP/UDP 提供超低延遲的負載分發。Standard Load Balancer 支援區域性 (zonal) 和區域備援 (zone-redundant) 的前端、HA 連接埠、輸出規則，以及預設安全的行為（需要明確設定 NSG 和後端集區）。健康狀態探查 (TCP/HTTP) 會判斷後端的健康狀況；發生故障的執行個體會從輪替中移除。Basic Load Balancer 缺乏區域感知能力、進階功能和 SLA——應避免在生產環境中使用。Cross-region Load Balancer 新增了一個全域 anycast 前端，可在不同地區的 Standard Load Balancer 之間進行平衡，為非 HTTP 工作負載實現主動/主動的多地區設計，並根據健康狀況提供快速的地區性容錯移轉。

資料保護與災難復原：Azure Backup 和 Site Recovery

Azure Backup 提供時間點復原；Azure Site Recovery (ASR) 提供工作負載複寫與協調的容錯移轉。它們滿足互補的需求，且經常結合使用。

Azure Backup 保存庫選項：

• Recovery Services vault 保護 Azure VM、Azure VM 中的 SQL Server、Azure VM 中的 SAP HANA、Azure Files 以及 MARS/MABS 代理程式。它與 Backup policies 整合，定義排程、保留期，以及在支援的情況下進行應用程式一致性備份。
• Backup vault 是為較新的工作負載（如 Azure Disks 備份和 Azure Blobs 備份）設計的現代化保存庫，在支援的區域提供精細的 RBAC 和區域備援保存庫儲存。請根據工作負載和治理模型選擇適合的保存庫類型。

Backup policies 控管備份執行的時間、其保留層級（每日/每週/每月/每年）以及一致性設定。虛刪除 (Soft delete) 增加了一個安全緩衝期，在此期間可以取消刪除已刪除的備份項目，以防止意外或惡意刪除。當保存庫儲存使用異地備援選項時，跨區域還原 (Cross-region restore) 能夠從次要區域進行還原；此功能必須啟用，且受限於區域功能支援和資料平面整備度。

Azure Site Recovery 跨區域或可用區複寫工作負載，並協調端到端的災難復原 (DR)：

• Replication policies 定義快照頻率、復原點的保留期、應用程式一致性快照的節奏，以及 RPO 警示閾值。原則需在複寫頻寬、儲存成本和復原精確度之間取得平衡。
• Recovery plans 為多層式應用程式提供有序的容錯移轉，包含群組（例如，資料庫、API、Web）、前置/後置步驟，以及透過 Azure Automation runbooks、指令碼或手動操作實現的自動化。在計畫中整合 DNS 變更、Traffic Manager/Front Door 端點更新以及應用程式組態。
• Test failover 使用非生產 VNet 或測試網路執行隔離的復原，以驗證 runbooks、開機順序和應用程式健康狀況，而不會影響生產環境或複寫。定期測試對於驗證 RTO 至關重要。
• Failback 當原始站點或區域恢復正常時，將工作負載移回。容錯移轉後，在新主要方向上重新保護工作負載、同步變更、安排計畫性的容錯回復時間窗，並驗證容錯回復後的複寫。對於 Azure-to-Azure 的情境，您通常會在配對的區域之間進行容錯移轉，並在準備就緒時反轉複寫方向以還原原始拓撲。

資料層的連續性：Azure SQL、儲存體複寫和 Cosmos DB

每個資料服務都揭示了不同的耐用性和容錯移轉語意，這些語意必須與應用程式的一致性需求保持一致。

Azure SQL Database 和 Azure SQL Managed Instance：

• Active geo-replication 為單一資料庫或彈性集區建立最多四個可讀取的次要複本。它提供資料庫層級的複寫，支援手動或 API 驅動的容錯移轉，從而實現讀取擴展和災難復原 (DR)。當您需要對每個資料庫進行控制和自訂協調時，此選項是合適的。
• Auto-failover groups 建立一組資料庫（或整個受控執行個體），它們會與一個接聽程式端點一起進行容錯移轉。它簡化了跨區域容錯移轉和連接字串管理，並在寬限期後支援自動容錯移轉。對於需要協調容錯移轉和簡化用戶端連線的多資料庫應用程式，請使用容錯移轉群組。
• Zone redundancy 在一個區域內跨可用區放置複本，以在發生可用區故障時存活，但不提供跨區域復原。為支援它的層級啟用此功能，以在不改變延遲設定檔的情況下提高本機可用性。

Azure Storage 複寫選項：

• GRS (geo-redundant storage) 將資料從主要區域（三個複本）非同步地複寫到配對的次要區域（三個複本）。在正常操作期間，讀取和寫入都針對主要區域。
• RA-GRS 當主要區域效能下降時，為次要端點增加讀取存取權限，適用於緊急報告或分析等情境。
• GZRS (geo-zone-redundant storage) 將主要區域的 ZRS（區域耐用性）與到次要區域的非同步複寫相結合，從而提高本機和區域的彈性。
• RA-GZRS 為 GZRS 帳戶的次要區域增加讀取存取權限。 如果主要區域無法復原，您可以啟動帳戶容錯移轉到次要區域。容錯移轉後，儲存體帳戶在次要區域變為主要帳戶，並且通常會恢復為本地備援（直到您重新設定）。預期會有一定的 RPO（非同步複寫）；應用程式應在容錯移轉後處理冪等性 (idempotency) 和資料調節 (reconciliation)。

Azure Cosmos DB：

• Multi-region writes 允許寫入任何已設定的區域，並搭配衝突解決策略（透過指定屬性實現「後寫者為準」(last writer wins)、自訂策略或多主機策略）。這可以減少寫入延遲並提高可用性。
• Automatic failover 使用一個有優先順序的區域列表，在發生中斷時提升一個新的寫入區域。結合所選的一致性層級（從「強式」(Strong) 到「最終」(Eventual)），您可以在可用性與一致性之間進行權衡。
• SLAs 涵蓋可用性、輸送量、延遲和一致性。透過多區域寫入，假設多區域設定正確，Cosmos DB 可為讀取和寫入提供高達 99.999% 的可用性。設計用戶端時應使用 SDK，並具備端點探索和重試機制，以充分利用這些保證。

總結：滿足特定的復原目標

根據 RTO/RPO 和故障域，將每一層對應到其連續性機制：

• 區域內可用性：使用 Availability Zones。將區域性運算資源部署到至少兩個區域；使用區域備援前端 (Standard Load Balancer、具備區域備援的 Application Gateway v2，或在邊緣使用 Front Door)。在支援的情況下啟用 SQL 區域備援，並對同時需要區域性和地區性彈性的儲存體使用 GZRS。
• 跨區域 DR：對於具狀態層，優先選擇原生的異地複寫 (SQL auto-failover groups、Cosmos DB multi-region accounts、Storage GRS/GZRS) 以達成低 RPO。對於具狀態的 IaaS 或沒有原生複寫功能的工作負載，使用 Azure Site Recovery 搭配經過良好調整的複寫原則和復原計畫。對於暫時性運算資源，使用 Infrastructure as Code 從映像檔或 VM Scale Sets 重新建立。
• 全球路由與容錯移轉：對於 HTTP/S，Azure Front Door 提供由健康狀態探查驅動、具應用程式感知能力的容錯移轉和 WAF 保護。對於非 HTTP 或混合式通訊協定，視情況加入 Traffic Manager (DNS) 或 Cross-region Load Balancer (L4 anycast)。使用優先順序路由以達成嚴格的主動/被動 RTO 目標；使用加權路由以進行分階段推出，並使用效能路由以獲得最低延遲的使用者體驗。
• 備份作為最後一道防線：即使有複寫機制，仍要維護 Azure Backup，其保留原則需符合合規性要求，啟用虛刪除以防清除事件，並為使用異地備援儲存體的保存庫設定跨區域還原。備份可以防範邏輯性損毀、勒索軟體和操作員錯誤——這些是複寫機制可能會一併傳播的風險。

測試是不容妥協的。排定定期的 ASR 測試容錯移轉，執行 Front Door/Traffic Manager 健康狀態演練測試，在負載下驗證 SQL 容錯移轉群組的行為，並在沙箱環境中執行儲存體容錯移轉模擬。建立 RTO 量測機制，並使用 runbook 自動化復原/容錯回復。記錄並演練操作 runbook，以便值班應變人員在壓力下能一致地執行。

實務問題情境

Expedia Group 必須現代化其全球旅遊預訂平台，以滿足核心預訂服務 RTO ≤ 15 分鐘和 RPO ≤ 5 分鐘的要求，同時在重大旅遊活動期間承受 10 倍的流量高峰。該平台為全球的網頁和行動用戶端提供服務，包含混合 HTTP 與非 HTTP 的工作負載。

1. 在主要區域建立區域性彈性

• 將無狀態微服務部署為區域性 VM Scale Sets，橫跨兩個或多個 Availability Zones，並搭配 Standard Load Balancer 的區域備援前端。這消除了單一區域的故障風險，並確保了區域內的低延遲流量。
• 使用已啟用 auto-failover groups 和區域備援的 Azure SQL Database。Auto-failover groups 提供協調的資料庫容錯移轉和穩定的接聽程式，以最少的維運負擔滿足 15 分鐘的 RTO。
• 將工作階段成品和映像檔儲存在 GZRS 儲存體帳戶中，以結合區域性耐久性與非同步的地區性保護。當與應用程式端的冪等性結合時，這能滿足 5 分鐘的 RPO。

2. 新增具備主動/主動讀取能力的跨區域 DR

• 在兩個配對的區域中設定預訂網站/API 的來源，並將其置於 Azure Front Door Standard 之後。健康狀態探查和優先順序路由能夠根據應用程式健康狀況快速進行容錯移轉，而 anycast 則加速了使用者流量。具備受控規則集和速率限制的 WAF 原則可防禦容量攻擊與應用程式層攻擊，這在流量高峰期間至關重要。
• 為行程和個人化服務啟用 Cosmos DB 多區域寫入，以降低全球使用者的寫入延遲，並提供 99.999% 的可用性。自動容錯移轉會優先選擇次要區域，無需手動介入即可維持低 RTO。
• 對於交易式預訂，在相同的兩個區域間使用 SQL auto-failover groups，以便在次要複本上進行讀取擴展以供報表使用，同時確保快速、協調的容錯移轉。

3. 保護狀態並支援從損毀中復原

• 如果仍有任何舊版元件，使用 Recovery Services vaults 進行 Azure VM 備份（在支援的情況下採應用程式一致性）和 VM 內的 SQL 備份。套用具備分層式保留的備份原則，並啟用虛刪除以防範意外或惡意刪除。
• 對於託管特殊工作負載的 Azure Disks，新增以 Backup vault 為基礎的 Azure Disk Backup，以擷取與客體作業系統代理程式無關的增量快照。這使復原選項多樣化。
• 在使用異地備援儲存體的保存庫上啟用跨區域還原，允許在部分控制平面中斷期間，從次要區域進行資料平面還原。

4. 協調 DR 並驗證 RTO

• 為任何非原生複寫的服務（例如，舊版 Windows 服務）設定 Azure Site Recovery。建立復原計畫，依序安排資料庫就緒、接著是 API、然後是 Web，並包含 Azure Automation runbook 來更新 Key Vault 參考、透過 Front Door 規則清除 CDN 快取，以及為非 HTTP 端點切換 Traffic Manager 的優先順序。
• 每季使用遮罩後的資料，在隔離的 VNet 中進行測試容錯移轉，以驗證 runbook、量測實際容錯移轉持續時間，並優化容量保留。測試後，清理成品並根據 15 分鐘的 RTO 目標檢討指標。

5. 適用於混合式通訊協定的全球路由

• 對於 HTTP/S，Front Door 處理由健康狀態驅動的容錯移轉和邊緣安全性。對於非 HTTP 通訊協定（例如，合作夥伴的 TCP 整合），部署 Cross-region Load Balancer，並以區域性的 Standard Load Balancer 作為子端點。健康狀態探查會立即移除故障的區域，維持連線而不受 DNS TTL 相依性的影響。在需要 DNS 層級的地理圍欄（例如法規要求的端點）時，在特定區域的端點前，再疊加一層 Azure Traffic Manager 的地理路由。

為何選擇這些服務

• Availability Zones 和區域備援前端以最小的延遲影響消除單一區域故障。Azure SQL failover groups 抽象化連線管理並自動化容錯移轉，符合 15 分鐘的 RTO。Cosmos DB 多區域寫入滿足全球性的超高可用性與低延遲寫入需求。GZRS 和 RA 選項提供具備可控 RPO 取捨的區域性加上地區性耐久性。Front Door 在邊緣提供全球加速、應用程式感知容錯移轉和 WAF。Cross-region Load Balancer 和 Traffic Manager 涵蓋了非 HTTP 和地理路由的需求。Azure Backup 和 ASR 提供獨立的復原路徑——從時間點還原到全堆疊容錯移轉——確保平台能從基礎設施故障和邏輯性資料損毀中復原。

← 網路與連線能力 · 所有領域 · 安全架構與零信任 →

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

瀏覽 Microsoft →