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

Azure 架构良好的框架工作负载

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

架构师设计工作负载，工作负荷团队实现这些工作负载。 工作负荷旨在实现功能和非功能性业务要求。 可将工作负荷分类为多种类型。

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

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

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

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

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

精心构建的框架的工作负荷指南描述了与特定工作负荷类相关的常见优先级和权衡。 在工作负荷指南中，支柱指南适用于表示工作负荷优先级的技术设计原则和设计领域。 按照建议操作，帮助设置成功的工作负载，并将其与精心构建的框架保持一致。

什么是架构良好的框架工作负载？

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

若要创建成功的工作负载，请根据基于以下理想的精心架构的框架原则开发它。

架构良好的框架工作负载：

• 具有定义并优先实现目标的功能和非功能要求。
• 经过设计，可以使用资源并整合设计模式和利弊来实现这些要求。
• 构建并运行到设计和用途的规范中。
• 衡量其实现目的的充分程度。
• 可以适应其用途的优化或更改。
• 和它一样可靠。
• 和它一样安全。
• 提供足够的投资回报。
• 负责开发和运营。
• 在可接受的时间段内完成其目的。

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

工作负载团队

创建具有各种技术和业务学科的团队成员的工作负荷团队。 所有团队成员的主要重点是工作负荷的成功。

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

集中式团队和利益干系人

集中式团队通常支持工作负荷团队。 它们为组织内的许多或所有云工作负荷提供支持功能并应用治理。 集中团队专注于组织的成功，这部分是由组织工作负荷的成功实现的。 它们为工作负荷提供服务、指导和防护措施。

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

架构良好的框架工作负荷团队侧重于工作负荷结果。 他们与集中式团队成员的专门支持进行协调并从中受益。

共担责任模型

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

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

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

可以使用 Azure 登陆区域来帮助实现标准化。 平台登陆区域和应用程序登陆区域在 Azure 中可用。 在应用程序登陆区域中部署工作负荷。

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

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

满足要求

在整个架构良好的框架（如核心支柱和工作负荷指南）中，建议与工作负荷的义务相吻合。 建议通常并不意味着团队成员或团队有助于履行这些义务。 可以确定应执行每个操作的人员。 执行工作负荷级映射，以确定团队的角色和职责与拓扑、工作负荷类型和关键性相关。

直接工作负荷团队处理大多数工作负荷要求。 一些要求是与集中团队共同努力处理的。 例如，实现选项可能基于集中式团队集的防护措施。 或者，集中式团队可能会专门处理实现选择。

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

了解约束

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

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

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

显式传达要求

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

了解平台团队与组织指令和工作负荷团队义务相关的义务时，可以按实际的期望和建议传达工作负荷要求。

传达常见工作负荷要求

每个平台伙伴关系都是不同的，但以下领域是共同责任对话中的常见主题：

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

查找统一的胜利

共同的责任不仅仅是权衡、约束和妥协。 平台团队通常具有高度专业化的技能和专用预算，这些预算可以扩展到单个工作负荷团队可以维持的工作量之外。 请考虑以下示例。

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

企业体系结构指南。 如果与企业体系结构团队的模式和做法保持一致，则可以节省时间和精力，因为团队已经简化了流程。 如果不进行谈判，也可以在合作关系中无法完成解决方案时防止返工。

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

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

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

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

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

分享成功和挑战

与其他团队共同负责也意味着分享工作负荷的成功和挑战。 当工作负荷满足其义务并获取预期价值时，请与合作伙伴团队共享该值。 告诉他们他们如何为工作负荷的成功做出贡献。 当工作负荷不履行其义务时，请分享不工作的内容，进行协作和重新调整以恢复正常状态。

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

努力实现持续改进

所有精心构建的框架支柱的主题都是持续改进。 采用渐进式思维模式。 你可以处理现有问题的新方法，采用新技术，解决新要求，或在新的约束下运行。 随着工作负荷随时间推移的提高，合作伙伴团队将采用相同的思维模式。 但是，每个改进机会也意味着更改，应该得到适当的管理过程的支持。

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

取得成功结果

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