Well-Architected Framework 提供相關建議，協助架構師、開發人員、管理員和其他雲端從業人員，設計出安全、高效率、有韌性、高效能、具成本效益且符合永續發展原則的雲端拓撲並順利運作。
Google 的跨職能專家團隊會驗證 Well-Architected Framework 中的最佳化建議。團隊會根據 Google Cloud 的擴展功能、業界最佳做法、社群知識和您的意見回饋，精心策劃 Well-Architected Framework。 Google Cloud如要瞭解 Well-Architected Framework 的重大變更摘要，請參閱新功能。
Well-Architected Framework 適用於為雲端建構的應用程式和從地端部署遷移至 Google Cloud、混合雲部署項目和多雲端環境的工作負載。
Well-Architected Framework 的支柱和觀點
如以下架構圖所示，架構完善架構中的建議會依據支柱和跨支柱觀點分類。
Well-Architected Framework 中的支柱提供特定非功能性重點領域的原則和建議，包括安全性、可靠性、效能、成本、營運或永續發展。
Well-Architected Framework 中的「觀點」是針對特定技術、網域或產業，從跨支柱角度提出的建議。觀點中的建議與支柱中的一般原則和建議一致。
舉例來說，金融服務 (FS) 觀點建議採用符合資料落地法規要求的災難復原策略。這項 FS 專屬建議符合可靠性支柱的實際目標原則，因為資料落地規定會影響容錯移轉區域的選擇，進而影響復原目標。
支柱
- 卓越的營運成果
- 有效率地部署、執行、監控及管理雲端工作負載。
- 安全性、隱私權和法規遵循
- 在雲端中盡可能確保資料和工作負載安全無虞、在設計中融入隱私考量，並滿足監管需求和標準。
- 可靠性
- 設計出兼具靈活彈性與高可用性的工作負載，並在雲端中加以執行。
- 成本最佳化
- 讓您在 Google Cloud的投資發揮最大商業價值。
- 效能最佳化
- 設計及調整雲端資源，實現最高效能。
- eco Sustainability
- 建構及管理環保永續的雲端工作負載。
跨支柱觀點
核心原則
在深入瞭解 Well-Architected 架構各項支柱的建議前，請先查看下列核心原則：
因應變化而設計
沒有任何系統是靜態的。系統使用者需求、建構系統的團隊目標，以及系統本身都會不斷變化。請考量變更需求，建立開發和生產程序，讓團隊定期交付小幅變更，並快速取得這些變更的回饋。持續展現部署變更的能力，有助於與利害關係人建立信任關係，包括負責系統的團隊和系統使用者。使用 DORA 的軟體交付指標，有助於團隊監控系統變更的速度、容易度和安全性。
記錄您的架構
開始將工作負載遷移至雲端或建構應用程式時，缺乏系統相關文件可能會成為重大障礙。文件對於正確呈現目前部署作業的架構尤其重要。
優質技術文件並非指製作特定數量的文件，而是指內容是否清楚、實用，以及是否隨著系統變更持續維護。
妥善記錄雲端架構可建立通用語言和標準，讓跨職能團隊有效溝通及協作。此外，文件也提供必要資訊，協助識別及引導日後的設計決策。撰寫文件時，請考量您的用途，為設計決策提供背景資訊。
隨著時間推移，您的設計決策會不斷演進和變化。變更記錄可提供團隊所需的背景資訊，有助於協調各項計畫、避免重複作業，以及有效評估一段時間內的成效變化。當您啟用不熟悉目前設計、策略或記錄的新雲端架構師時，變更記錄特別有價值。
DORA 的分析發現，文件品質與組織成效之間有明顯關聯，也就是組織達成績效和獲利能力目標的能力。
簡化設計並使用全代管服務
設計時簡潔性至關重要。如果架構過於複雜而難以理解，設計的實作和長期管理就會很困難。盡可能使用全代管服務，盡量減少與管理及維護基準系統相關的風險、時間和精力。
如果您已在正式環境中執行工作負載，請使用受管理服務進行測試，瞭解這些服務如何協助減少作業複雜度。如果您正在開發新的工作負載，請從簡單的項目開始，建立最低可行產品 (MVP)，並避免過度設計。您可以找出特殊用途，隨著時間逐步疊代及改善系統。
分離式架構
DORA 的研究顯示，架構是實現持續交付的重要預測指標。解耦是一種技術，可將應用程式和服務元件分離成可獨立運作的小型元件。舉例來說，您可以將單體式應用程式堆疊分離成個別服務元件。在鬆耦合架構中，應用程式可以獨立執行其功能，不受各種依附元件影響。
分離式架構可提高彈性，讓您執行下列操作：
- 套用獨立升級。
- 強制執行特定安全控制措施。
- 為每個子系統設定可靠性目標。
- 監測健康狀況。
- 精細控管效能和成本參數。
您可以在設計階段初期開始解耦程序，或在擴大規模時，將解耦程序納入系統升級作業。
使用無狀態架構
無狀態架構可提高應用程式的可靠性和擴充性。
有狀態的應用程式會依賴各種依附元件執行工作，例如在本機快取資料。有狀態的應用程式通常需要額外機制，才能擷取進度並順利重新啟動。無狀態應用程式可使用共用儲存空間或快取服務執行工作，無須重要的本機依附元件。無狀態架構可讓應用程式以最少的啟動依附元件迅速調度資源。應用程式可承受硬體重新啟動、減少停機時間，並為使用者提供更優質的效能。