Microsoft AZ-900: 支援、服務生命週期與 Marketplace — 學習指南

By Laurynas Brazys · 24 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

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

在 Azure 上要達到可靠的營運，取決於選擇正確的支援模型、理解服務健康狀態信號、依據已發布的服務等級協定 (SLA) 進行設計，以及透過商務市集負責任地採購第三方解決方案。此領域著重於 Microsoft 如何在雲端工作負載的整個生命週期中提供支援，以及客戶如何透過案例管理、提高配額、健康狀態警示和事件處理來將該支援付諸實踐。同樣重要的是圍繞持續變更的治理。Azure 服務遵循現代化的生命週期，提供頻繁、安全的更新，並對重大變更提供預先通知。Azure Marketplace 透過經過驗證的合作夥伴解決方案擴展了平台，讓客戶能在整合的 Azure 帳單和原則控制下，快速採用安全性、網路、資料和應用程式元件。

Azure 支援方案與案例管理

Microsoft 提供了多種 Azure 支援方案，以對應不同關鍵性的工作負載以及所需的指導建議等級。每個訂用帳戶都包含基本支援，但僅涵蓋帳務和訂用帳戶管理。開發人員支援針對非生產環境，在上班時間為較低嚴重性的問題提供技術指導。標準支援是取得 24x7 技術支援的入門方案，適用於大多數生產工作負載。Professional Direct (ProDirect) 增加了更快速的回應目標，並提供主動式指導建議、架構審查和網路研討會，以加速部署。Premier/Unified 是一個橫跨 Microsoft 雲端和地端產品的企業級保護傘，為您的組織配對一位客戶成功客戶經理 (Customer Success Account Manager)，並提供服務審查、工作坊、整備規劃和事件管理協調等主動式服務。支援要求是在 Azure 入口網站的「說明 + 支援」下建立。案例類型包括技術、帳務、訂用帳戶管理，以及服務與訂用帳戶限制 (配額)。技術案例需要付費方案 (開發人員、標準、ProDirect 或 Unified)。內建的「支援要求參與者」角色可讓使用者開啟和管理案例，而無需授予更廣泛的資源權限，而擁有者和參與者也可以提交案例。案例可以透過 Azure Monitor 動作群組和 ITSM 連接器與 ITSM 工具整合，以維護單一的事件佇列。

• 基本 (Basic)
  • 技術支援可用性：無 (僅限帳務/訂用帳戶管理)
  • 初次回應目標 (嚴重性 A/B/C)：不適用
  • 指導建議：僅限文件、社群
  • 主動式服務：無
  • 典型用途：試用、學習、非關鍵性帳戶
• 開發人員 (Developer)
  • 技術支援可用性：上班時間 (電子郵件/網站)
  • 初次回應目標 (嚴重性 A/B/C)：不適用 / 不適用 / < 8 小時
  • 指導建議：一般性的操作方法指導
  • 主動式服務：無
  • 典型用途：開發/測試和試行
• 標準 (Standard)
  • 技術支援可用性：嚴重性 A 為 24x7；較低嚴重性則為上班時間
  • 初次回應目標 (嚴重性 A/B/C)：< 1 小時 / < 4 小時 / < 8 小時
  • 指導建議：透過案例提供盡力而為的指導
  • 主動式服務：無
  • 典型用途：需要標準回應時間的生產工作負載
• Professional Direct
  • 技術支援可用性：嚴重性 A 為 24x7
  • 初次回應目標 (嚴重性 A/B/C)：< 1 小時 / < 2 小時 / < 4 小時
  • 指導建議：主動式指導、架構審查、上線引導
  • 主動式服務：網路研討會、服務審查、呈報管理
  • 典型用途：需要更快回應和指導的業務關鍵性生產環境
• Premier/Unified
  • 技術支援可用性：24x7 (廣泛的 Microsoft 範圍)
  • 初次回應目標 (嚴重性 A/B/C)：< 1 小時 / < 2 小時 / < 4 小時
  • 指導建議：指定的 CSAM、解決方案層級的指導
  • 主動式服務：工作坊、評估、服務審查、事件協調
  • 典型用途：橫跨多個產品的企業級產品組合

建立支援要求及提高配額與限制

支援要求是從 Azure 入口網站的「說明 + 支援 > 建立支援要求」發起。此流程會提示您輸入問題類型、訂用帳戶、服務、資源、區域和嚴重性。對於技術案例，您需要選擇一個與業務影響和您方案的回應目標相符的影響等級 (嚴重性)。提供診斷資訊 (時間戳記、相互關聯 ID、指標和變更歷史記錄) 以加速分類處理。對於帳務和訂用帳戶管理，基本支援就足夠了；對於技術問題，則需要付費方案。配額和限制的提高是透過「服務與訂用帳戶限制 (配額)」來提出申請。常見的要求包括每個區域的運算 vCPU 配額 (依 VM 系列)、公用 IP 位址、特殊 GPU 或 HPC 系列的核心數，以及 Azure Machine Learning 或 Cognitive Services 的配額。運算配額是按每個訂用帳戶、每個區域和每個 VM 系列來強制執行的；要求更高的配額可以讓您提出容量要求，但並不保證容量的可用性。為了獲得可預測的容量，請將提高配額與隨選容量保留或適當的區域性部署計畫結合起來。提交要求的存取權限是透過 Azure RBAC 控制。支援要求參與者角色可以在不授予資源修改權限的情況下建立和管理票證。較大的組織通常會將配額工作流程透過內部批准流程來處理，並在 ITSM 中進行追蹤；Azure Quota API 可以在預定閾值下自動監控和提出要求。提交後，案例會在需要時分派給工程團隊，並透過入口網站、電子郵件進行溝通，對於較高嚴重性的案例，可選擇透過電話聯繫。

服務健康狀態、計畫性維護與事件管理中的 SLA

Azure 提供多種健康狀態的檢視角度。Azure Status 是公開的、全域性的平台層級問題檢視。Azure Service Health 則是針對您的訂閱進行個人化，顯示影響您所在區域和資源的服務問題、計畫性維護和健康狀態建議。Resource Health 則深入探討個別資源的狀態，提供近期的可用性事件及其根本原因，例如平台事件、使用者啟動的操作或底層硬體故障。Service Health 警示可與動作群組整合，以進行電子郵件、簡訊、語音、webhook、ITSM 連接器和 Azure Functions 的通知。計畫性維護會透過 Service Health 進行溝通，並提供預期的時間範圍和影響細節。對於虛擬機器，Azure Scheduled Events 會透過執行個體中繼資料服務 (instance metadata service) 提供客體內 (in-guest) 通知，告知即將發生的動作，例如重新開機，讓應用程式能夠進行連線清空 (drain)、建立檢查點 (checkpoint) 或容錯移轉 (fail over)。Maintenance Control 適用於 Azure Dedicated Hosts 和某些隔離的 VM 大小，讓管理員可以在定義的延遲期間內延後平台維護，以配合變更控制流程。SLA 定義了每項服務的每月正常執行時間或交易成功率目標。在架構多服務解決方案時，組合的可用性是各個相依項目相乘的結果。較高的可用性層級通常需要區域備援 (zone-redundant) 或多執行個體 (multi-instance) 的部署。例如，在一個區域內跨越多個可用性區域執行虛擬機器，會比單一 VM 或可用性設定組 (availability set) 獲得更高的 SLA。如果未達到 SLA，可以透過申請取得服務點數；在規定的時間內透過入口網站提交申請並附上證據（時間戳記、受影響的資源），並在 Service Health 中追蹤事件和事後檢討報告。

• 虛擬機器 (單一執行個體)
  • SLA 的關鍵要求：作業系統和資料碟使用 Premium SSD 或 Ultra Disk
  • 公告的 SLA (典型)：99.9%
  • 備註：適用於符合資格的大小和儲存體；未使用可用性設定組/區域
• 可用性設定組中的虛擬機器
  • SLA 的關鍵要求：兩個或更多執行個體，跨越容錯/更新網域
  • 公告的 SLA (典型)：99.95%
  • 備註：降低單一機架和更新網域的風險
• 跨可用性區域的虛擬機器
  • SLA 的關鍵要求：在一個區域內，跨越多個區域部署兩個或更多執行個體
  • 公告的 SLA (典型)：99.99%
  • 備註：無需跨區域容錯移轉即可達到最佳的區域內彈性
• Azure SQL Database (單一資料庫)
  • SLA 的關鍵要求：標準部署
  • 公告的 SLA (典型)：99.99%
  • 備註：區域備援可提升對區域性故障的彈性
• App Service (多執行個體)
  • SLA 的關鍵要求：兩個或更多執行個體
  • 公告的 SLA (典型)：99.95%
  • 備註：需要 Basic 或更高層級，並擁有多個執行個體

現代生命週期原則與 Azure Marketplace

Azure 服務遵循現代生命週期原則 (Modern Lifecycle Policy)，該原則強調持續的服務更新以及客戶保持最新狀態的責任。需要客戶採取行動的重大變更 (breaking changes) 會提前通知——對於線上服務，通常至少提前 12 個月——透過正式的棄用公告、Service Health 建議和文件更新來進行溝通。服務會提供淘汰時程、API 版本控制和遷移路徑，以便工作負載可以在符合企業治理的變更時間範圍內進行修復。這種持續交付模型利用了安全部署實踐，包括分階段推出和自動緩解措施。營運準備就緒意味著要追蹤服務建議、在預備生產環境中驗證新的執行階段或 SDK 版本，並使用功能旗標 (feature flags) 或藍綠部署模式 (blue-green patterns) 進行應用程式更新。安全性和合規性更新無需單獨的安裝週期即可送達，這縮短了曝險時間，同時也強調了可觀察性 (observability) 和發布紀律。Azure Marketplace 透過第三方解決方案擴展了平台：包括虛擬機器映像、受控應用程式、Kubernetes 應用程式和 SaaS 產品。這些產品透過您的 Azure 訂閱計費，提供多種選項，例如依用量計費 (pay-as-you-go)、年度/長期方案，以及自備授權 (bring-your-own-license, BYOL)。企業可以建立私有市集，只允許經核准的發行者或產品，套用 Azure Policy 來限制部署的範圍（例如區域、SKU、網路），並透過私下議價 (private offers) 協商自訂價格。網路虛擬設備（例如防火牆、負載平衡器）、資料平台、安全分析和可觀察性堆疊是常見的模式；這些解決方案的主要支援管道是發行者，而帳單則統一在 Azure 中處理。

• 虛擬機器映像 (NVA 或伺服器)
  • 部署模型：在您的 VNet 中使用 ARM 範本/VM
  • 計費模型：PAYG 或 BYOL
  • 使用案例範例：防火牆、WAF、IDS/IPS、套裝應用程式
  • 維運備註：您需要管理 VM 的生命週期、擴展和修補
• 受控應用程式
  • 部署模型：部署到您的訂閱中，由發行者管理
  • 計費模型：PAYG 加上管理費
  • 使用案例範例：提供統包式 (Turnkey) 解決方案，包含受控維運
  • 維運備註：發行者更新核心元件；您管理資料/設定
• Kubernetes 應用程式 (AKS 附加元件)
  • 部署模型：透過 Helm/ARM 部署到您的 AKS 叢集
  • 計費模型：PAYG 或 BYOL
  • 使用案例範例：Ingress 控制器、服務網格 (service meshes)、operators
  • 維運備註：您管理 AKS；發行者維護應用程式的容器映像
• SaaS
  • 部署模型：在發行者的租用戶中執行；與您的租用戶整合
  • 計費模型：訂閱/依用量計費
  • 使用案例範例：API、分析平台、安全性 SaaS
  • 維運備註：實現價值的時間最短；需要管理的基礎設施最少

實務問題：Coastal Outfitters：為季節性電子商務高峰期，將支援、健康狀態與市集解決方案投入營運

情境： Coastal Outfitters 營運一個託管於 Azure 的電子商務網站，該網站在月中大部分時間流量穩定，但在月底會有為期四天的流量激增。其架構使用 Azure Application Gateway、兩個基於 VM 的 Web 層，以及一個受控資料庫。安全性要求使用新一代防火牆，而營運團隊必須在流量激增期間保證 Web 層達到 99.99% 的可用性，並在部署過程中獲得主動式指導。

挑戰： 選擇合適的支援方案以獲得主動式架構指導、在治理規範下部署市集防火牆、在流量激增前提高區域運算配額，並實作符合 99.99% 可用性目標的健康狀態警示與事件工作流程。

建議方法：

1. 將訂閱升級至 Professional Direct 支援方案，以確保在生產環境部署期間獲得 24x7 的關鍵問題回應與主動式諮詢指導。
2. 將內建的 Support Request Contributor 角色指派給 NOC 群組，以便他們可以在沒有廣泛資源權限的情況下，開啟並管理支援票證。
3. 從 Azure Marketplace 部署 Palo Alto Networks 或 Fortinet 新一代防火牆至一個專用的中樞 VNet；利用私人市集，讓訂閱擁有者只能看到經核准且已協商的私人優惠。
4. 將兩個或多個 Web VM 放置在 Application Gateway 後方的不同可用性區域中，以滿足 99.99% 的 VM SLA；將作業系統/資料儲存在 Premium SSDs 上。
5. 在流量激增前兩週，提交「服務與訂閱限制 (配額)」請求，以增加所需 VM 系列的每個區域 vCPU 配額；為 Web 層增加容量保留，以保證突發容量。
6. 針對網站所在區域的服務問題、計劃性維護及健康狀態建議，設定 Azure Service Health 警示；將警示路由至一個動作群組，該群組透過電子郵件/簡訊通知待命人員，並透過 ITSM 連接器在 ServiceNow 中開啟事件。
7. 在 Web VM 上啟用 Azure Scheduled Events 處理，以便在主機維護期間優雅地清空連線；使用藍綠部署交換在預備環境中驗證容錯移轉行為。
8. 在 Runbook 中記錄 SLA 信用額度索賠工作流程，包括證據擷取（時間戳記、資源 ID、指標），並確保在未達到可用性目標時，於允許的期限內透過入口網站提出索賠。

Azure 基本原理： Professional Direct 結合了快速回應與主動式諮詢的優點，且無須承擔企業級 Unified 合約的開銷，非常適合單一關鍵生產工作負載。區域性 VM 以最少的執行個體數量將可用性層級提升至 99.99%，而 Premium SSDs 則滿足了單一執行個體的儲存需求。經策劃的私人市集與協商後的私人優惠，可確保安全設備的合規性與成本控制，且發行商支援仍然是處理 NVA 問題的第一線。提早增加配額與容量保留，可消除流量激增期間的部署阻力。Service Health 警示、排程事件處理，以及 SLA 索賠 Runbook，以清晰的職責和證據路徑完成了事件管理的閉環。

← 監視、自動化與管理 · 所有領域

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

瀏覽 Microsoft →