Google 的跨職能專家團隊會驗證 Well-Architected 架構中的最佳化建議。團隊會根據 Google Cloud不斷擴展的功能、業界最佳做法、社群知識和您的意見回饋,精心策劃 Well-Architected 架構。如要查看 Well-Architected 架構的重大變更摘要,請參閱新功能。
這個架構適用於為雲端建構的應用程式,以及從地端遷移至混合雲部署項目和多雲端環境的工作負載。 Google Cloud
Well-Architected Framework 支柱和觀點
Well-Architected Framework 分為五大支柱,如下圖所示。我們也提供跨領域的觀點,著重於選定領域、產業和技術 (例如 AI 和機器學習 (ML)) 的建議。
沒有任何系統是靜態的。使用者需求、系統建構團隊的目標,以及系統本身都會不斷變化。請考量變更需求,建立開發和生產程序,讓團隊定期交付小規模變更,並快速取得這些變更的意見回饋。持續展現部署變更的能力,有助於贏得利害關係人的信任,包括負責系統的團隊和系統使用者。使用 DORA 的軟體交付指標,有助於團隊監控系統變更的速度、容易度和安全性。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2024-10-11 (世界標準時間)。"],[[["\u003cp\u003eThe Well-Architected Framework offers guidance for designing and operating secure, efficient, resilient, high-performing, and cost-effective cloud environments.\u003c/p\u003e\n"],["\u003cp\u003eThis framework is structured around five pillars: operational excellence, security, reliability, cost optimization, and performance optimization, and includes cross-pillar perspectives like AI and ML.\u003c/p\u003e\n"],["\u003cp\u003eKey principles of the framework include designing for change, documenting your architecture, simplifying your design with managed services, decoupling architecture, and using a stateless approach.\u003c/p\u003e\n"],["\u003cp\u003eThe Well-Architected Framework is applicable to cloud-native applications, workloads migrated from on-premises, hybrid cloud setups, and multi-cloud deployments.\u003c/p\u003e\n"],["\u003cp\u003eThe recommendations in the Well-Architected Framework are regularly validated by Google experts, updated to reflect new Google Cloud features and industry best practices, and a summary of these changes are available in the "What's new" section.\u003c/p\u003e\n"]]],[],null,["# Google Cloud Well-Architected Framework\n\n| To view all of the content in the Well-Architected Framework on a single page or to to get a PDF output of the content, see [View on one page](/architecture/framework/printable).\n\nThe Well-Architected Framework provides recommendations to help\narchitects, developers, administrators, and other cloud practitioners design and\noperate a cloud topology that's secure, efficient, resilient, high-performing,\nand cost-effective.\n\nA cross-functional team of experts at Google validates the recommendations in\nthe Well-Architected Framework. The team curates the Well-Architected Framework to\nreflect the expanding capabilities of Google Cloud, industry best practices,\ncommunity knowledge, and feedback from you. For a summary of the significant\nchanges to the Well-Architected Framework, see\n[What's new](/architecture/framework/whats-new).\n\nThe Well-Architected Framework is relevant to applications built for the cloud *and*\nfor workloads migrated from on-premises to Google Cloud, hybrid cloud\ndeployments, and multi-cloud environments.\n\nWell-Architected Framework pillars and perspectives\n---------------------------------------------------\n\nThe Well-Architected Framework is organized into five pillars, as\nshown in the following diagram. We also provide cross-pillar perspectives that\nfocus on recommendations for selected domains, industries, and technologies like\nAI and machine learning (ML).\n\n### Pillars\n\nconstruction [Operational excellence](/architecture/framework/operational-excellence)\n: Efficiently deploy, operate, monitor, and manage your cloud workloads.\n\nsecurity [Security, privacy, and compliance](/architecture/framework/security)\n: Maximize the security of your data and workloads in the cloud, design for\n privacy, and align with regulatory requirements and standards.\n\nrestore [Reliability](/architecture/framework/reliability)\n: Design and operate resilient and highly available workloads in the cloud.\n\npayment [Cost optimization](/architecture/framework/cost-optimization)\n: Maximize the business value of your investment in Google Cloud.\n\nspeed [Performance optimization](/architecture/framework/performance-optimization)\n: Design and tune your cloud resources for optimal performance.\n\n### Perspectives\n\nsaved_search [AI and ML](/architecture/framework/perspectives/ai-ml)\n: A cross-pillar view of recommendations that are specific to AI and ML\n workloads.\n\nsaved_search [Financial services industry (FSI)](/architecture/framework/perspectives/fsi)\n: A cross-pillar view of recommendations that are specific to FSI\n workloads.\n\nCore principles\n---------------\n\n\u003cbr /\u003e\n\nBefore you explore the recommendations in each pillar of the Well-Architected Framework,\nreview the following core principles:\n\n### Design for change\n\nNo system is static. The needs of its users, the goals of the team that builds\nthe system, and the system itself are constantly changing. With the need for change\nin mind, build a development and production process that enables teams to\nregularly deliver small changes and get fast feedback on those changes.\nConsistently demonstrating the ability to deploy changes helps to build trust\nwith stakeholders, including the teams responsible for the system, and the users\nof the system. Using\n[DORA's software delivery metrics](https://dora.dev/guides/dora-metrics-four-keys/)\ncan help your team monitor the speed, ease, and safety of making changes to the\nsystem.\n\n### Document your architecture\n\nWhen you start to move your workloads to the cloud or build your applications,\nlack of documentation about the system can be a major obstacle. Documentation\nis especially important for correctly visualizing the architecture of your\ncurrent deployments.\n\nQuality documentation isn't achieved by producing a specific\namount of documentation, but by how clear content is, how useful it is, and how\nit's maintained as the system changes.\n\nA properly documented cloud architecture establishes a common language and\nstandards, which enable cross-functional teams to communicate and collaborate\neffectively. The documentation also provides the information that's necessary to\nidentify and guide future design decisions. Documentation should be written with\nyour use cases in mind, to provide context for the design decisions.\n\nOver time, your design decisions will evolve and change. The change history\nprovides the context that your teams require to align initiatives, avoid\nduplication, and measure performance changes effectively over time. Change logs\nare particularly valuable when you onboard a new cloud architect who is not yet\nfamiliar with your current design, strategy, or history.\n\n[Analysis by DORA](https://dora.dev/capabilities/documentation-quality/)\nhas found a clear link between documentation quality and organizational\nperformance --- the organization's ability to meet their performance and\nprofitability goals.\n\n### Simplify your design and use fully managed services\n\nSimplicity is crucial for design. If your architecture is too complex to\nunderstand, it will be difficult to implement the design and manage it over\ntime. Where feasible, use fully managed services to minimize the risks, time,\nand effort associated with managing and maintaining baseline systems.\n\nIf you're already running your workloads in production, test with managed\nservices to see how they might help to reduce operational complexities. If\nyou're developing new workloads, then start simple, establish a minimal viable\nproduct (MVP), and resist the urge to over-engineer. You can identify\nexceptional use cases, iterate, and improve your systems incrementally over\ntime.\n\n### Decouple your architecture\n\n[Research from DORA](https://dora.dev/capabilities/loosely-coupled-teams/)\nshows that architecture is an important predictor for achieving continuous\ndelivery. Decoupling is a technique that's used to separate your applications\nand service components into smaller components that can operate independently.\nFor example, you might separate a monolithic application stack into individual\nservice components. In a loosely coupled architecture, an application can run\nits functions independently, regardless of the various dependencies.\n\nA decoupled architecture gives you increased flexibility to do the following:\n\n- Apply independent upgrades.\n- Enforce specific security controls.\n- Establish reliability goals for each subsystem.\n- Monitor health.\n- Granularly control performance and cost parameters.\n\nYou can start the decoupling process early in your design phase or incorporate\nit as part of your system upgrades as you scale.\n\n### Use a stateless architecture\n\nA stateless architecture can increase both the reliability and scalability of\nyour applications.\n\nStateful applications rely on various dependencies to perform tasks, such as\nlocal caching of data. Stateful applications often require additional mechanisms\nto capture progress and restart gracefully. Stateless applications can perform\ntasks without significant local dependencies by using shared storage or cached\nservices. A stateless architecture enables your applications to scale up quickly\nwith minimum boot dependencies. The applications can withstand hard restarts,\nhave lower downtime, and provide better performance for end users."]]