Azure 登陆区域设计原则

Azure 登陆区域概念体系结构普遍适用于任何 Azure 登陆区域过程或实现。 在体系结构的基础下，一组核心设计原则充当跨关键技术领域后续设计决策的指南针。

这些原则是有意的，旨在帮助你努力实现目标体系结构的最佳设计。 如果选择部署 Azure 登陆区域加速器的实现，或企业规模登陆区域代码库的任何版本，请通过应用本文介绍的设计原则来构建体系结构。

在实现中使用这些原则作为实现云技术优势的有用指南。 这种面向云或 云原生 方法表示组织的工作和技术选项的方式，传统技术方法通常不提供这些方法。

熟悉这些原则，以更好地了解其影响和与偏差相关的权衡。

设计偏差的影响

可能有理由偏离设计原则。 例如，组织要求可能会决定设计 Azure 环境的特定结果或方法。 在这种情况下，必须了解偏差对设计和未来作的影响。 仔细考虑每个原则所描述的权衡。

一般情况下，准备平衡要求和功能。 随着需求的变化以及从实现中汲取的经验，您的概念架构会不断演变和发展。 例如，使用预览服务和依赖于服务规划路线图可以有助于在采用期间消除技术障碍。

订阅民主化

订阅民主化提供了一种可缩放的方式来加速应用程序迁移和新应用程序开发。 此方法使工作负荷团队能够独立访问和管理 Azure 订阅，同时保持平台治理和运营防护措施。

1. 使用订阅作为管理单元。 订阅表示组织和管理 Azure 资源的基础边界。 将订阅分配给业务部门以支持工作负荷的设计、开发、测试和迁移。 这与业务需求和优先级保持一致，使项目组合所有者和工作负荷团队能够更快地提供价值。

2. 使用订阅分隔应用程序环境。 订阅还应该用于在软件开发生命周期（SDLC）（例如开发、测试和生产）中控制和隔离环境。 这种分离可改进治理，降低风险，并支持一致的工作负荷管理。 按照在 Azure 登陆区域中管理应用程序开发环境的指南进行作。

3. 启用自助订阅自动售货过程。 建立一个过程，使应用程序和服务团队能够以最少的摩擦请求和接收订阅。 自助服务模型或近自助服务模型可减少由手动审批和复杂的业务注销导致的延迟。 按照 订阅售货 中的指南简化预配并加速创新。

4. 提供多个订阅类型以支持不同的要求。 提供一系列针对不同工作负荷方案定制的订阅生产线。 这种灵活性使团队能够根据需要选择最合适的订阅类型。 请参阅 建立常见的订阅售货产品行。

5. 支持具有可缩放管理组层次结构的订阅。 使用定义完善的 管理组层次结构 有效地进行大规模运作、治理和安全订阅。 此层次结构可实现集中式策略强制实施和高效的多订阅组织。 遵循 Azure 登陆区域建议的层次结构和订阅设计注意事项和建议，确保一致性。

偏差的影响

• 共享管理与集中式操作。 实现此原则的一种方法将运营转移到业务部门和工作负荷团队。 这种重新分配使工作负荷所有者能够在平台基础的护栏内对其工作负荷拥有更多的控制和自主性。 需要中央运营的组织可能不希望将生产环境的控制权委托给工作负荷团队或业务部门。 这些组织可能需要修改其 资源组织 设计，使其偏离此原则。

• 运营模型不一致。 Azure 着陆区概念架构设计假定了一个特定的管理组和订阅层次结构，以用于所有运营管理订阅。 此层次结构可能与 作方法不一致。 随着组织的发展和发展，运营模型可能会发生变化。 将资源移到单独的订阅可能会导致复杂的技术迁移。 在提交方法之前，请查看 Align 指南。

• 缺少订阅售货流程和自动化。 如果您不提供订阅销售流程和相应的自动化服务，无论是自助服务还是非自助服务，应用程序和服务团队在为您的组织提供价值的过程中将会被延误，因为订阅需要为他们创建，并被放置在层次结构中的相应管理组中。 如果获取新订阅的过程很复杂，并且需要很长时间，应用程序和服务团队可能会选择通过替代计费帐户自行创建订阅，也可能在非托管或受管理Microsoft Entra 租户中创建订阅，这意味着影子 IT 现已存在。

策略驱动的治理

使用 Azure Policy 提供防护措施，并确保部署的应用程序符合组织的安全、治理和监管控制，这些控制与实施和配置工具无关。 Azure Policy 为平台团队提供了实现、强制实施、审核和控制 Azure 控制和数据平面作和配置所需的工具。 这样就可以通过自助服务过程 将订阅民主化，以便应用程序和服务团队能够快速为组织提供业务价值。

有关使用 Azure Policy 的详细信息，请查看 采用策略驱动的防护措施。

偏差的影响

增加了运营和管理开销。 如果不使用 Azure Policy 在环境中创建防护措施，则会增加维护合规性的作和管理开销。 Azure Policy 可帮助你限制并自动化你环境中所需的合规状态。

单个控件和管理平面

避免依赖于抽象层，例如客户开发的门户或工具。 最好为中央操作和工作负载操作提供一致的体验。 Azure 提供统一且一致的控制平面，可应用于所有 Azure 资源和预配通道，称为 Azure 资源管理器。 控制平面受基于角色的访问控制和策略驱动控件的约束。 可以使用此 Azure 控制平面建立一组标准化的策略和控制，用于管理整个企业资产。

偏差的影响

增加了集成复杂性。 采用多供应商方法的控制和管理平面可能会增加集成和功能支持的复杂性。 替换单个组件以实现“最佳品种”设计或多供应商操作工具具有限制，并可能由于固有依赖而引发意外错误。

如果您将现有工具的投资应用于操作、安全或治理，请查看 Azure 服务及任何相关依赖项。

以应用程序为中心的服务模型

侧重于以应用程序为中心的迁移和开发，而不是纯基础结构直接迁移，例如移动虚拟机。 设计选择不应区分旧应用程序和新应用程序、基础结构即服务（IaaS）应用程序或平台即服务（PaaS）应用程序。

无论服务模型如何，都努力为在 Azure 平台上部署的所有应用程序提供安全环境。

偏差的影响

• 提高了治理策略复杂性。 如果工作负荷与管理组层次结构 实现选项不同，则会增加治理策略和访问控制结构的复杂性，以控制环境。 示例包括偏离组织层次结构或按 Azure 服务分组。

• 增加运营开销。 这种权衡引入了意外的策略重复和异常的风险，这增加了操作和管理开销。

• 开发/测试/生产 是组织考虑的另一种常见方法。 有关详细信息，请参阅 如何处理 Azure 登陆区域体系结构中的“开发/测试/生产”工作负荷登陆区域。

与 Azure 本机设计和路线图对齐

尽可能使用 Azure 原生平台服务和功能。 此方法应与 Azure 平台路线图保持一致，以确保新功能在环境中可用。 Azure 平台路线图应有助于告知迁移策略和 Azure 登陆区域概念轨迹。

偏差的影响

增加了集成复杂性。 将第三方解决方案引入 Azure 环境可能导致对这些解决方案的依赖关系，以支持功能并与 Azure 第一方服务集成。

有时，将现有的第三方解决方案投资引入环境是不可避免的。 请仔细考虑这一原则及其权衡，以符合你的要求。

后续步骤

在查看本指南时，组织可能处于云旅程的不同阶段。 因此，为了实现上述结果，所需的措施和建议可能会有所不同。 若要了解云采用阶段的最佳下一步行动，请查看通往目标体系结构的路径。

若要选择正确的 Azure 登陆区域实现选项，请了解 Azure 登陆区域设计区域。