你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Well-Architected 框架是一种设计框架，可帮助其提高工作负荷的质量：
- 具有复原能力、可用性和可恢复性。
- 具有你需要的安全性。
- 提供足够的投资回报。
- 支持负责任的开发和操作。
- 在可接受的时间范围内完成其目的。
该框架建立在建筑卓越五大支柱之上，这些支柱映射到这些目标。 它们是：可靠性、安全、成本优化、卓越运营和 性能效率。
每个支柱都提供推荐的做法、风险考虑和权衡取舍。 考虑到业务需求，设计决策必须跨所有支柱进行平衡。 技术和可操作指南非常广泛，适用于所有工作负载，并适用于特定方案。 本指南以 Azure 为中心。
工作负荷体系结构与其实现不同。 Well-Architected 框架可以通过架构设计为成功奠定基础，但实现的选择取决于您组织的业务需求和限制。
观众
Well-Architected 框架适用于负责改进工作负载和解决跨领域问题的团队。
Well-Architected 框架为工作负荷生命周期中涉及的任何人提供有价值的见解和建议。 无论你在工作负荷团队中扮演什么角色，无论是架构师、开发人员、操作员还是业务利益干系人，如果你有权在工作负荷范围内做出决策，都可以从此框架中受益。
无论组织的规模如何，本指南都是有益的。 无论你是大型企业、小型企业还是独立软件供应商的一员，都可以更接近最佳设计。 该框架满足各种组织结构和规模的需求，确保所有工作负荷用户都可以有效地利用其优势。
如果要寻求通过集中控制改进工作负载组合的指导，则此内容可能无法完全应用。 建议参考 云采用框架。 如果对在 Azure 上设计工作负载没有既得利益，则此内容与你无关。
有关建筑师的角色和职责的信息，请参阅 架构师的基础知识 和 架构师的清单。
目标
Well-Architected Framework 的主要目标是在你将工作负载部署到 Azure 时，为你的成功做好准备。
成功实现：精心设计会导致成功实现。 鉴于概念覆盖范围的广度和深度，你可做出明智的决策。
对成功的信心：经过验证的评估已在 Azure 上部署的众多工作负荷中得到证明，可支持框架的基本原则。
了解权衡和风险：框架可帮助你了解采用建议可能需要针对其他支柱做出选择。 它突出了权衡利弊，以及可能需要在短期内应对的潜在风险。
随着时间推移优化：该框架旨在进行迭代使用，并用作持续改进的工具。 根据指导原则衡量工作负荷的成熟度。 将评估视为随工作负荷发展而变化的移动分数，确保设计在实现业务目标方面保持高效且有效。
框架的构建基块
Well-Architected 框架采用分层方法构建：支柱、工作负载和服务指南。
支柱
此框架的基础在于支柱。 如果没有对这些支柱的全面了解，后续层：工作负荷层和服务指南可能无法完全理解。 每个支柱都呈现以下元素：
设计原则。 提供良好的设计基础，每个设计都有一个特定的目标。 这些原则还描述了建议的方法。
设计评审清单。 清单中的每个项都附带一个或多个 建议指南，这些指南描述了关键策略以及 Azure 如何帮助你获得建议。
云设计模式。 请务必了解 云设计模式的相关内容。 它们被映射到它们直接支持的支柱。
权衡取舍。 每个体系结构决策都需要一系列注意事项。 这些权衡利弊表示认可和接受的妥协，这些妥协平衡了框架的各个方面。 此图标
指出权衡，此图标 
指出风险。成熟度模型。 介绍从简单或基本建议开始采用 Azure Well-Architected 框架的分阶段方法。 随着业务需求的发展，逐步改进系统，从早期阶段工作负载到成熟的业务关键型解决方案。
有关详细信息，请参阅关于 Well-Architected Framework 支柱。
工作量
工作负荷层表示支柱如何应用于特定的工作负荷类。 在初始设计阶段，工作负荷体系结构根据实用工具进行分段，每个段表示优先或设计区域。 这些设计领域特定于工作负荷类，充当优化的重点。 Well-Architected 框架包括多个工作负荷。 阅读与您的业务要求最为契合的文本。 无需阅读与方案不一致的工作负荷类的工作负荷指南。
利用开始来开始了解解决方案上下文。 作为新手，请阅读设计原则，以了解工作负荷如何采用支柱指南。 然后，深入了解专注于技术决策点以及后续建议的设计领域。 工作负荷指南还包括一项评估，可帮助你评估生产中的就绪情况。
有关详细信息，请参阅关于 Well-Architected Framework 工作负荷。
服务指南
服务指南在对工作负荷中的单个 Azure 组件做出决策方面发挥了关键作用。 它们概述了实现卓越体系结构所需的关键特性和功能，并提供建议的配置来建立强大的基础。 虽然并不详尽，但这些指南强调每个服务如何解决跨领域问题并支持工作负荷有效性。
有关详细信息，请参阅 可用指南。
评估
Microsoft Azure Well-Architected Review 免费提供。 它是一系列与支柱清单相关的问卷，用于评估你的设计选择。 通过迭代运行跟踪分数，以识别需要增强的领域。
有关详细信息，请参阅 Azure Well-Architected Review 工具。
建议的学习过程
Well-Architected Framework 涵盖适用于任何一类工作负荷的最佳做法。 本指南不仅包括良好设计和权衡的基本原则，还包括将这些原则应用于体系结构的组件。 我们承认，从头到尾阅读本指南可能会令人生畏。 请考虑遵循以下学习路径：
了解所有设计原则。 了解所有支柱的设计原则和方法。 在设计开始时，了解良好的体系结构比了解如何构建体系结构更重要。 在每个原则中，采用这些方法来制定您的设计策略。 这些方法不是可选的，必须考虑到这些方法。
确定清单项的优先级。 首先，仅处理与工作负荷和业务目标相关的清单项。 考虑业务关键性、合规性需求和上市时间等因素。 随着这些因素的变化，调整优先级以提高工作负荷质量。 推迟与工作负载成功关系不大的检查项。
显示 Well-Architected 框架清单的
准备好做出重要权衡。 看看支柱权衡的示例，看看优先顺序如何有利于一个支柱比另一个支柱。 做出战略设计权衡是决策的重要组成部分。
匹配工作负荷方案。 查找与方案匹配的工作负荷指南，并遵循所有技术和作领域的设计方法。 这些指南有助于突出显示最相关的注意事项。 有关详细信息，请参阅 Azure Well-Architected Framework 工作负载下列出的示例。
选择适当的 Azure 服务并对其进行正确配置。 这些服务指南旨在支持对工作负荷中的每个 Azure 组件做出决策。
采用成熟度模型
请考虑采用分阶段方法来使用 Azure Well-Architected Framework。 按照易于实现或必须最初实现的建议对框架的建议进行分类。 然后，随着工作负荷的业务需求发生变化，逐步改进生产就绪的系统。 例如，采用的初始阶段可能适用于处于资金和开发过程早期的工作负载，为良好的设计打下坚实基础。 成熟的一致性阶段可能适用于开发周期后面的解决方案，最高级别保留用于始终可用的业务关键型解决方案。
Well-Architected 框架包括成熟度模型。 它为工作团队提供结构化计划和里程碑。
分阶段方法是在查看 Azure 客户在其解决方案中应用框架的方式后开发的。 本指南适用于所有工作负荷团队，从初创公司到成熟企业。 创业公司使用模型来创建能够逐步实施的基础策略。 成熟企业（其体系结构已演变）还可以采用模型来进一步优化工作负荷，以采用一种共同方法来衡量团队中的改进。 此外，合作伙伴可以使用模型来评估工作负荷的成熟度并实施有针对性的建议。
该模型按支柱分类，分为五个级别。 虽然每个支柱中的级别都表示该支柱的独特特征，但其中所有支柱都有共同的主题：
| 成熟度阶段 | 焦点 | 策略 |
|---|---|---|
| 级别 1 | 在 Azure 上建立坚实的基础 | 专注于利用 Azure 的核心和本机功能，同时利用成熟的云设计模式和最佳做法。 |
| 二级 | 构建工作负载资源 | 解决由负载团队直接管理的组件的技术难题，包括应用程序代码、部署资产和操作过程。 |
| 级别 3 | 做好生产准备 | 让业务利益干系人参与决策，并考虑与其他支柱的权衡。 对于新工作负载，这通常是进入生产之前的最后一步。 |
| 级别 4 | 从生产中学习 | 转变重点，以保持稳定的环境、管理变更以及根据业务变化和生产学习适应新要求。 |
| 级别 5 | 以灵活性确保未来成功 | 追求理想质量。 你擅长变革，以便你可以处理新的市场条件和外部影响的变化，如技术、业务需求或监管问题。 |
这些边界是建议的准则，不需要将其视为严格的规则。 实际旅程将取决于组织目标和工作负荷要求。
在每个级别中，浏览突出显示每个级别的策略焦点的选项卡式视图。
本指南包括一项评估，可帮助你确定与目标成熟度级别相符的建议。 请在此处进行评估： Azure Well-Architected 框架成熟度模型评估。
采取务实的方法
采用务实的方法很重要，以避免分析瘫痪。 下面是一些关键注意事项：
评估做法的值。 我们建议提供价值的所有做法，但该值可能因团队和当前成熟度级别而异。 实施某些做法太早可能会带来很少的好处，而延迟实施其他做法可能会增加成本、复杂性和非战略性技术债务，因为你可能已经优化了其他做法来补偿。
确定提供即时、有意义的优势并启用其他关键做法的做法的优先级。
评估做法成本。 每个做法都有实施和作的成本，包括财务、工作量和复杂性成本。 这些成本可能因成熟度级别而异。
如果在工作负荷团队准备就绪之前采用做法，则实施成本将更高。
如果做法过于晚，则实施和运营成本将更高，从而导致返工或集成困难。
如果其运营成本超过在较高成熟度级别的价值，则这些做法可能会被中止。
根据要求，为成熟阶段定义了先决条件和退出条件。 优先考虑那些如果以后再采用会更加昂贵或复杂的做法，并避免产生不必要的复杂性或操作负担。
在选择实现序列时，请谨慎考虑。 做法是相互依赖的，其实施顺序可能会产生重大影响。 某些做法是其他做法的构建基块，可能会对下游做法的成本、工作量和复杂性产生很大影响。 在规划旅程时，请考虑实现成果所需的时间。
务实评估您的能力。 组织可用于实施和运行工作负载的资源通常有限。
估计团队的工作负荷以及实施和运作的能力。
成本是累加的。 随着运营成本的增加，实施新做法的能力会下降。
权衡可能导致机会成本。 选择现在要实施的做法意味着推迟其他做法。
相关链接
下面是一些开始使用 Well-Architected Framework 文档的资源：