Azure Well-Architected Framework 是一種設計架構，可藉由協助其改善工作負載的品質：
- 具有復原性、可用性和可復原性。
- 達到您需要的安全程度。
- 提供足夠的投資報酬率。
- 支援負責任的開發和作業。
- 在可接受的時間範圍內完成其目的。
該架構是以卓越建築的五大支柱為基礎，這些支柱對應並映射到這些目標。 它們是：可靠性、安全性、成本優化、營運卓越，以及 效能效率。
每個支柱都提供建議的做法、風險考慮和取捨。 根據業務需求，設計決策必須跨所有要素進行平衡。 技術和可採取動作的指引已足夠廣泛，適用於所有工作負載，並套用至特定案例。 本指南以 Azure 為中心。
工作負載的架構與它的實作是不一樣的。 Well-Architected Framework 可以透過建築架構設計來奠定成功的基礎，但實施選擇取決於組織的業務需求與限制。
觀眾
Well-Architected 架構適用於負責改善工作負載和解決跨領域考慮的小組。
Well-Architected 架構可為任何參與工作負載生命周期的人員提供寶貴的見解和建議。 無論您在工作負載小組中扮演的角色為何，無論是架構設計人員、開發人員、操作員或業務項目關係人，如果您有權在工作負載範圍內做出決策，都可以從此架構中獲益。
不論貴組織的規模為何，本指南都很有用。 無論您是大型企業、小型企業或獨立軟體廠商的一部分，都可以更接近最佳設計。 此架構迎合各種組織結構和大小，確保所有工作負載使用者都能有效地使用其優點。
如果您要尋求透過集中式控件改善工作負載組合的指引，此內容可能無法完全套用。 建議您參閱 雲端採用架構。 如果您對在 Azure 上設計工作負載沒有既得利益，則此內容與您無關。
如需架構師角色和職責的相關信息，請參閱 架構師的基本概念 和 架構師的檢查清單。
目標
Well-Architected Framework 的主要目標是確保您在 Azure 上部署工作負載時能夠成功。
成功實作：架構完善的設計會導致實作成功。 鑒於概念涵蓋範圍廣度和深度，您很有能力做出明智的決策。
成功信賴：在 Azure 上部署的許多工作負載上，都可以看到經過證實的評量，以備份架構的原則。
瞭解取捨和風險：架構可協助您了解採用建議可能需要對其他要素做出選擇。 它強調權衡取捨，以及短期內可能想要解決的潛在風險。
隨著時間的推移進行優化：該架構旨在反覆使用，並作為不斷改進的工具。 根據指引評估工作負載的成熟度。 將評估視為隨著工作負載演進的動態評分，確保設計在符合商務目標的同時保持效能和效率。
架構的建置組塊
Well-Architected 架構是以分層方式結構化：支柱、工作負載和服務指南。
支柱
此架構的基礎在於支柱。 如果您沒有對這些要素的完整瞭解，後續層：工作負載層和服務指南可能無法完全理解。 每個支柱都會呈現下列元素：
設計原則。 提供良好設計的基礎，每個都有特定的目標。 這些原則也會描述建議的方法。
設計檢閱檢查清單。 檢查清單上的每個項目都會隨附一或多個 建議指南， 說明重要策略，以及 Azure 如何協助您達成建議。
雲端設計模式。 請務必瞭解與 相關的雲端設計模式。 這些要素會對應到它們直接支持的支柱。
取捨。 每個架構決策都需要一系列考慮。 這些 取捨 代表已承認和接受的妥協，這些妥協會平衡架構的各個層面。 使用此圖示
來標示取捨，並使用此圖示 
來標示風險。成熟度模型。 說明從簡單或基本建議開始採用 Azure Well-Architected Framework 的階段式方法。 隨著業務需求的發展，逐漸改善系統，從早期工作負載到成熟的業務關鍵性解決方案。
如需詳細資訊，請參閱 關於 Well-Architected 框架支柱。
工作負載
工作負載層表示支柱如何應用於特定類別的工作負載。 在初始設計階段，工作負載架構會根據公用程序進行區隔，而每個區段都代表優先順序或設計區域。 這些設計區域是工作負載類別特有的，可作為優化的重點。 Well-Architected Framework 包含數個工作負載。 請閱讀最符合您業務需求的內容。 您不需要閱讀與案例不一致之工作負載類別的工作負載指引。
從 開始，以瞭解方案背景。 重新整理時，請閱讀 設計原則，以瞭解工作負載如何採用要素指引。 然後，深入探討 設計領域，專注於技術決策點，並根據其提供後續建議。 工作負載指引還包括一項評估，以協助您評量投入生產的準備程度。
如需詳細資訊，請參閱 關於 Well-Architected 框架工作負載。
服務指南
服務指南在決定工作負載內的個別 Azure 元件時扮演重要角色。 他們概述達到卓越架構所需的重要特性和功能，並提供建議的設定，以建立強大的基礎。 雖然並非詳盡，但這些指南強調每個服務如何解決跨領域考慮和支援工作負載效率。
如需詳細資訊，請參閱 可用的指南。
設計要素
設計指南作為聚焦資源，提供執行框架關鍵策略的指示。 它們直接取材於支柱建議中定義的基礎方法，但有意跨越支柱，展示這些策略在實務上的互動。 設計指南不涵蓋整個建築歷程，而是聚焦於特定實務或選擇，為團隊提供明確且有針對性的指引，將 WAF 原則付諸實行。
欲了解更多資訊，請參閱 設計要點。
評估
Microsoft Azure Well-Architected 檢閱免費。 這是一份與核心檢查清單相關的問卷清單，用於評估您的設計選擇。 透過反覆執行追蹤您的分數，以識別可能的增強區域。
如需詳細資訊，請參閱 Azure Well-Architected 檢閱工具。
建議的學習程式
Well-Architected Framework 涵蓋適用於任何工作負載類別的最佳做法。 本指南不僅包含良好設計和取捨的基本準則，也包括將這些原則套用至架構元件。 我們承認閱讀這整份指南從頭到尾可能會讓人感到不堪重負。 請考慮遵循此學習路徑：
瞭解所有設計原則。 瞭解所有要素的設計原則和方法。 在設計開始時，瞭解良好的架構比瞭解如何建置它更重要。 根據每個原則，遵循相應的方式來制定您的設計策略。 這些方法不是選擇性的，必須納入考慮。
排定檢查清單專案的優先順序。 首先，只處理與工作負載和商務目標相關的檢查清單專案。 請考慮業務關鍵性、合規性需求和上市時間等因素。 請調整優先順序，以便在這些因素變更時改善工作負載品質。 暫緩與工作負載成功較不相關的清單項目。
準備好進行重要的權衡取捨。 查看支柱取捨的範例，了解優先順序如何使一個支柱優於另一个。 進行策略性設計取捨是決策的重要組成部分。
比對工作負載案例。 尋找符合您案例的工作負載指南，並遵循所有技術和作業領域的設計方法。 這些指南有助於強調最相關的考量。 如需詳細資訊，請參閱 Azure Well-Architected Framework 工作負載下所列的範例。
選取適當的 Azure 服務，並正確設定。 這些服務指南旨在支援工作負載內每個 Azure 元件的決策。
採用成熟度模型
請考慮採用階段式方法來使用 Azure Well-Architected Framework。 將架構的建議分類為容易達成或一開始必須達成的建議。 然後，隨著工作負載的商務需求發生變化，可逐步演進為可供生產使用的系統。 例如，採用的初始階段可以在其資金和開發程式中早期套用至工作負載，為良好的設計奠定堅實的基礎。 在開發週期的後期階段，成熟的協調階段可以應用於解決方案，最高層級則保留給 Always-On 的業務關鍵性解決方案。
Well-Architected Framework 包含成熟度模型。 它提供結構化課程和里程碑，讓工作負載小組能夠遵循。
階段式方法是在檢閱許多 Azure 客戶在其解決方案中套用架構之後開發的。 本指南適用於所有工作負載小組，從初創公司到成熟的企業。 新創公司使用模型來建立可以隨著時間推進而實施的基礎策略。 成熟的企業，其架構已經發展成熟，也可以採用此模型進一步優化其工作負載，並在各個小組之間建立共同的方法來衡量改進。 此外，合作夥伴也可以使用模型來評估工作負載的成熟度，並實作目標建議。
模型會依支柱分類，並分成五個層級。 雖然每個支柱中的層級都代表該支柱的獨特特性，但其中所有要素都有共同的主題：
| 成熟度階段 | 專注 | 策略 |
|---|---|---|
| 層級 1 | 在 Azure 上建立穩固的基礎 | 專注於運用 Azure 的核心和原生功能，同時利用成熟的雲端設計模式和最佳做法。 |
| 層級 2 | 建立工作負載資源 | 解決工作負載小組直接擁有之元件的技術挑戰，包括應用程式程式代碼、部署資產和作業程式。 |
| 層級 3 | 達到生產準備狀態 | 讓業務項目關係人參與決策，並考慮與其他支柱之間的取捨。 對於新的工作負載，這通常是進入生產環境之前的最後一個步驟。 |
| 層級 4 | 從生產環境學習 | 將焦點轉移到維護穩定的環境、管理變更，以及根據業務變更和生產學習來適應新需求。 |
| 層級 5 | 以靈活性迎接未來 | 爭取追求卓越的品質。 您擅長變化，因此可以應對新的市場條件和外部影響的變化，例如技術、業務需求或監管問題。 |
這些界限是建議的指導方針，不需要被視為嚴格的規則。 實際旅程將取決於您的組織目標和工作負載需求。
在每個層級中，探索標籤式檢視，深入了解該層級的策略重點。
本指南包含評估，可協助您找出符合目標成熟度層級的建議。 請在此處完成評估：Azure Well-Architected Framework Maturity Model Assessment。
採取務實的方法
請務必採用務實的方法，以避免分析癱瘓。 以下是一些主要考量：
評估實踐的價值。 我們建議的所有作法都能提供價值，但這些價值可能會根據您的團隊和目前的成熟度水平而有所不同。 過早實作某些做法可能會帶來小好處，而延遲實作其他做法可能會增加成本、複雜度和非策略性技術債務，因為您可能已經優化其他做法來補償。
優先安排那些提供立即和有意義效益，並且支持其他關鍵實踐的方法。
評估實務成本。 每個做法都有實作和運行的成本，包括財務成本、精力成本和複雜度成本。 這些成本可能會根據您的成熟度層級而有所不同。
如果在工作負載小組準備就緒之前採用做法，則實作成本會更高。
如果採用的做法太晚，會導致重新作業或整合困難，則實施和營運成本會更高。
如果營運成本超出其較高成熟度層級的價值，可能會停止做法。
根據需求，為您的成熟階段定義必要條件和結束準則。 排定較昂貴或較複雜的做法以供日後採用，且不會造成不必要的複雜度或作業負擔。
選擇實作順序時要刻意。 做法是相互相依的，實作的順序可能會造成重大差異。 有些做法是其他做法的建置組塊，而且可能會對下游做法的成本、精力和複雜度產生很大影響。 在規劃您的旅程時，請考慮從時間到達成結果的過程。
務實面對您的能力。 貴組織可以投入於實作和運行工作負荷的資源通常是有限的。
預估工作負載團隊在實作和操作上的容量。
成本是加總的。 隨著營運成本的增加，實作新做法的容量會下降。
取捨可能會產生商機成本。 現在選擇實施某些做法意味著推遲其他做法的實施。
相關連結
以下是一些開始使用 Well-Architected Framework 文件的資源：