你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure Well-Architected Framework 工作负载

在 Azure Well-Architected 框架的上下文中， 术语工作负载 是指应用程序资源、数据和支持基础结构的集合，这些资源、数据和支持基础结构协同工作以实现定义的业务成果。 工作负荷由组件以及开发和操作过程组成。

架构师设计工作负载，工作负载团队实现它们。 工作负载的设计和实施旨在满足功能性和非功能性业务需求。 工作负载可分为多种类型。

工作负载分类的典型条件包括：

• 工作负荷的实用工具、特征和使用模式，例如 Web 应用程序、批处理和实时分析。

• 关键有影响力的驱动因素，例如技术平台或与行业的一致性。

• 目标受众。 具有各种受众的解决方案示例包括企业内部业务线应用程序、购买的独立软件供应商 (ISV) 解决方案，或供公众使用的多租户软件即服务 (SaaS) 解决方案。

同一类中的工作负载可以共享相似之处，包括目标受众、合规性要求和技术堆栈。 Well-Architected 框架的五大支柱、其原则、清单和权衡与所有工作负荷类相关。

Well-Architected 框架的工作负载指南介绍了与特定工作负荷类相关的常见优先级和权衡。 在工作负载指南中，支柱指南适用于代表工作负荷优先级的技术设计原则和设计领域。 遵循建议来帮助设置成功的工作负载，并将其与 Well-Architected Framework 保持一致。

什么是 Well-Architected Framework 工作负载？

任何工作负载的设计和操作必须与五个体系结构支柱相抗衡：可靠性、安全性、成本优化、卓越运营和性能效率。

若要创建成功的工作负载，请根据基于以下理想 Well-Architected 框架原则进行开发。

Well-Architected Framework 工作负载：

• 具有为实现目标而定义和确定优先级的功能和非功能要求。
• 经过设计，你可以通过使用资源并合并设计模式和权衡来实现这些要求。
• 按照设计和用途的规范进行构建和操作。
• 以它实现其目的的充分程度来衡量。
• 可以适应其用途的改进或更改。
• 与需要一样可靠。
• 与需要一样安全。
• 提供足够的投资回报。
• 以负责任的方式开发和运营。
• 在可接受的时间段内实现其目的。

工作负荷团队与组织的中心团队之间的协作必须创建具有上述特征的工作负载。 以下部分介绍这些团队及其职能。

工作负载团队

创建一个工作负载团队，其中包含具有各种技术和业务学科的团队成员。 所有团队成员的主要关注点应该是工作负荷的成功。

工作负载团队成员的示例
应用程序安全工程师 业务利益干系人 云开发人员或软件工程师 云解决方案架构师 数据科学家或分析师 数据库管理员	DevOps 工程师 基础结构工程师 产品经理或所有者 质量保证 (QA) 工程师 支持团队成员

集中式团队和利益干系人

集中式团队通常支持工作负载团队。 它们为组织内的许多或所有云工作负载提供支持功能并应用治理。 集中团队专注于组织的成功，这在一定程度上是通过组织工作负载的成功实现的。 它们为工作负载提供服务、指导和护栏。

集中式团队和团队成员的示例
商业智能分析师 业务利益干系人 云卓越中心 (CCoE) 板 云平台团队 网络安全分析师 数据库管理员 企业架构师	财务分析师 基础结构工程师 法律和合规官员 网络工程师 采购专家 项目经理

Well-Architected Framework 工作负载团队专注于工作负载结果。 他们与集中团队成员的专门支持进行协调并从中受益。

共担责任模型

需要部署和使用工作负载才能提供价值。 作为工作负载团队的一员，你有责任以为组织创造价值的方式设计、实现和部署工作负载。

工作负载存在于组织的上下文中。 组织通常具有受管制的治理和权威角色。 工作负荷团队负责在组织的基础内设计、实施和部署工作负载。

根据 Azure 云采用框架，标准化工作负载的云资源。 严格应用标准化以提供受治理的平台，以帮助加入工作负载团队。 根据组织的云操作模型应用此治理。

可以使用 Azure 登陆区域来帮助执行标准化。 Azure 中提供了平台登陆区域和应用程序登陆区域。 在应用程序登陆区域中部署工作负载。

你的组织可能拥有严格规范的云平台产品/服务，并与 Azure 登陆区域完全一致。 或者你的组织可能有不同的采用策略或没有实现。 如果没有实现，工作负载团队几乎是完全自治的实体。

对于组织使用的任何平台和治理，必须将 Well-Architected Framework 的原则应用于工作负载。 Well-Architected 框架通常引用 Azure 登陆区域，但它不依赖于特定的平台实现。 Well-Architected 框架支柱、原则、清单和指南适用于所有云平台和大多数工作负载类型。

满足要求

在整个 Well-Architected 框架（如核心支柱和工作负载指南）中，建议与工作负载的义务一致。 建议通常并不意味着哪些团队成员或团队促成了这些义务。 你可以确定谁应该执行每个操作。 执行工作负载级映射，以确定团队与拓扑、工作负载类型和关键性相关的角色和职责。

直接工作负载团队处理大多数工作负载要求。 某些要求是作为与集中团队的共同努力来处理的。 例如，实现选项可能基于集中团队设置的护栏。 或者，集中式团队可能专门处理实现选项。

工作负荷团队必须与其他团队建立工作关系，以帮助对工作负载目标进行编码。 如果将组件或职责外包，则必须成功履行这些义务。

了解约束

集中式团队根据团队的核心功能和核心基础结构支持各种工作负载。 若要在组织规模上提供此支持，集中式团队可能会对提供的服务或基础结构实施统一性和约束。 在设计工作负载时，了解这些约束并尽可能与了解这些约束的企业架构师合作至关重要。 尽可能多地从以前的实现中学习。

每个平台治理实现都是不同的，但对于许多工作负载，以下约束是常见的：

• 云资源的允许列表
• 云资源的配置要求
• 云资源和跨界连接可用性的区域允许列表
• 工作时间以外的平台支持有限或无
• 修补要求
• 特定的中心辐射型实现，可驱动域名系统 (DNS) 和专用终结点实现
• 供应链控制要求

显式传达要求

如果工作负载要求面临约束或服务级别协议 (SLA) 未明确定义核心功能或基础结构产品/服务，请将这种情况视为一种风险。 若要解决此风险，工作负荷团队必须向其他团队说明问题如何影响工作负荷。 可能需要更改工作负载要求、设计或实现，或者更改基础结构产品/服务。

了解平台团队与组织指令相关的义务和工作负载团队的义务后，可以通过现实的期望和建议来传达工作负载要求。

传达常见工作负载要求

每个平台合作关系都不同，但以下方面是共同责任对话中的常见主题：

• 合规性和法律要求
• 网络细节，例如需要静态入口或出口 IP 地址
• 提供有效实时站点会审的可观测性要求
• 性能要求，例如网络吞吐量、云资源的可用性或区域可用性
• 从出口和入口角度对公共 Internet 访问的期望
• 服务级别目标 (提供给工作负荷用户的 SLO) 或 SLA
• 技术支持的可用性

查找统一的胜利

分担责任不仅仅是权衡、约束和妥协。 平台团队通常具有高度专业化的技能和专用预算，可以增加超出单个工作负荷团队可以承受的范围。 请考虑以下示例。

安全专家。 工作负荷可能具有安全的开发生命周期。 由于集中式安全团队在整个组织中大规模执行安全开发任务，因此它可能会执行超出工作范围的常规渗透测试。 它还可能有助于规划和执行事件响应策略。

企业体系结构指南。 如果与企业体系结构团队的模式和做法保持一致，则可以节省时间和精力，因为团队已经简化了流程。 如果无法在未协商的情况下在合作关系中实现解决方案，还可以防止返工。

大票支出。 平台团队通常托管的组件或服务对于单个工作负荷团队来说过于昂贵或管理过于广泛。 平台团队可以负担这些组件和服务，因为他们将成本分摊到工作负载之间。

通常，这些服务或集中式平台只是作为回显提供，因此它们有助于优化工作负载成本。 当它们作为退款提供时，由于规模经济和集中化，它们通常更便宜。

平台团队通常为工作负载团队提供各种活动的自助服务选项。 例如：

• 为自我引导式教育提供文档存储库
• 通过特定资源标记加入成本管理
• 通过正式的订阅-售货流程提供订阅

探索可能适合工作负荷的自助服务选项。

分享成功和挑战

与其他团队共担责任还意味着共享工作负载的成功和挑战。 当工作负载履行义务并获得预期价值时，请与合作伙伴团队共享。 告诉他们他们如何为工作负载的成功做出贡献。 如果工作负载未履行义务，请共享不起作用的内容，并协作并重新校准以恢复正常。

平台团队也有义务和成功标准。 你应期望合作伙伴告诉你工作负载是否适合产品/服务，或者它是否面临成为干扰邻居的风险。

努力实现持续改进

所有 Well-Architected 框架支柱的主题是持续改进。 采用渐进式思维模式。 可以处理现有问题的新方法、采用新技术、满足新要求或在新的约束下操作。 随着工作负荷的不断改进，合作伙伴团队的思维模式也一样。 但是，每个改进机会也意味着更改，应该得到适当的管理流程的支持。

工作负载团队有义务与平台团队就可能对平台团队的服务产生影响的工作负载要求的建议更改进行沟通。 同样，平台团队有义务将其工作负载合作伙伴纳入变更控制流程，并清楚地传达有影响力的平台更改。 与合作伙伴建立定期沟通节奏，了解和分享产品的发展方式。

取得成功成果

工作负载对用户、股东、监管机构、员工、卓越中心和首席体验官寄予厚望。 预期可以设置方向指南针旋转。 Well-Architected 框架通过为体系结构决策提供明确的合理化来提供与设计和实现相关的清晰性，以实现成功的结果。 开发成功的工作负载，并与组织分享该成功。