没有任何系统是静态的。用户的需求、构建系统的团队的目标以及系统本身都在不断变化。考虑到变化的需求，您可以构建一个开发和生产流程，以便团队定期交付细微更改并快速获得有关这些更改的反馈。持续展示部署更改的能力有助于与利益相关方（包括负责系统的团队和系统用户）建立信任。使用 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"]],["最后更新时间 (UTC)：2024-09-02。"],[[["\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."]]
