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

Azure 企业基架：规范性订阅管理

  • 项目

注意

Azure 企业基架已集成到 Microsoft 云采用框架中。 本文中的内容现在以框架的就绪方法表示。 本文将于 2020 年初弃用。 若要开始使用新的过程，请参阅就绪方法概述、Azure 登陆区域和登录区域注意事项。

为了敏捷性和灵活性，企业越来越多地采用公有云。 它们依靠云的优势来产生营收和优化企业资源使用情况。 Microsoft Azure 提供多种不同的服务和功能，企业可以像构建块一样将它们组合，解决广泛的工作负荷与应用程序需求。

决定使用 Microsoft Azure 只是实现云优势的第一步。 第二步是了解企业如何有效使用 Azure，并确定解决以下问题所需的基线功能：

  • “我担心数据所有权；如何确保数据和系统符合法规要求？”
  • “怎么知道每个资源是否发挥了作用，以便可以准确地做出规划和预算？”
  • “我想确保我们在公有云中部署或执行的所有操作均将安全放在首位，应如何帮助实现这一点？”

不带任何防护措施的空白订阅，其前景是让人担忧的。 如果不在这方面有所作为，可能会给 Azure 过渡造成阻碍。

本文为技术专业人员提供一个起点，帮助他们解决监管需求，并在监管需求与敏捷性需求之间权衡利弊。 其中会介绍企业基架的概念，它可以引导组织以安全的方式实施和管理 Azure 环境。 本文为开发有效和高效的控件提供了框架。

监管需求

在过渡到 Azure 时，必须提前解决监管方面的问题，确保成功地在企业中利用云。 遗憾的是，建立全面监管系统所花费的时间和存在的官僚主义，意味着某些业务小组必须直接与提供商对话，而不与企业 IT 部门沟通。 如果资源未妥善管理，这种方法可能会导致企业受到损害。 公有云的特征 - 敏捷性、灵活性和基于消耗量的定价 - 对于需要快速满足客户（内部和外部）需求的业务小组而言非常重要。 但是，企业 IT 部门需要确保有效地保护数据和系统。

建造建筑物时，我们可以使用基架来打好建筑物的基础。 基架主导总体轮廓，为需要装载的更长久系统提供定位点。 企业基架也是如此：一套灵活的控制机制和 Azure 功能为环境提供结构，为公有云上生成的服务提供定位点。 它为构建者（IT 人员和业务小组）提供创建和附加新服务的基础，同时保持了交付速度。

该基架建立在我们与各种规模的客户交往时收获的实践经验基础之上。 这些客户既包括在云中开发解决方案的小型组织，也包括迁移工作负载和开发云原生解决方案的大型跨国企业和独立软件供应商。 企业基架采用灵活设计，为传统的 IT 工作负载和敏捷工作负载提供有针对性的支持；例如，开发人员可以基于 Azure 平台功能创建软件即服务 (SaaS) 应用程序。

企业基架可用作 Azure 中每个新订阅的基础。 它能使管理员确保工作负荷满足组织的最低监管要求，同时又不妨碍业务小组和开发人员尽快实现自身的目标。 我们的经验表明，这极大地加速（而非阻碍）了公有云的增长。

注意

Microsoft 在预览版中发布了名为 Azure 蓝图的新功能，借助此功能便可跨订阅和管理组打包、管理和部署通用映像、模板、策略和脚本。 此功能是基架作为参考模型的用途和将该模型部署到组织之间的桥梁。

下图显示了基架的组件。 基础依赖于管理层次结构和订阅的可靠计划。 支柱包括 Resource Manager 策略和强有力的命名标准。 基架的剩余部分是 Azure 核心功能和特性，它们可实现和连接安全且可管理的环境。

Enterprise scaffold

定义层次结构

基架的基础是从企业协议 (EA) 注册一直到订阅和资源组的层次结构和关系。 注册从合同的角度定义了 Azure 服务在贵公司内的形式和用途。 在企业协议中，可将环境进一步细分为部门、帐户、订阅和资源组，以与组织的结构相匹配。

Hierarchy

Azure 订阅是包含所有资源的基本单位。 它还定义 Azure 中的多种限制，例如核心数、虚拟网络数和其他资源数。 资源组用于进一步优化订阅模型，并实现更自然的资源分组。

每家企业都是独特的，使用上图中的层次结构可以在公司内部十分灵活地对 Azure 进行组织。 开始使用公有云时，对层次结构建模以反映公司的计费、资源管理和资源访问需求，这是首先要做出的、也是最重要的决策。

部门和帐户

EA 注册的三种常见模式为：

  • 功能模式：

    Diagram of the functional pattern.

  • 业务单位模式：

    Diagram of the business unit pattern.

  • 地理模式：

    Diagram of the geographic pattern.

虽然这些模式有其一席之地，但“业务单位”模式逐渐得到广泛采用，因为该模式可灵活建造组织的成本模型以及反映控制范围。 Microsoft 核心工程技术和操作组创建了一个有效的“业务单位”模式子集，该子集以“联邦”、“州”和“本地”为模型。 有关详细信息，请参阅组织订阅和资源组。

Azure 管理组

Microsoft 现在提供了另一种对层次结构进行建模的方式：Azure 管理组。 管理组比部门和帐户更灵活，且可嵌套多达六个级别。 借助管理组，可创建与账单层次结构分离的层次结构，专门用于有效管理资源。 管理组可反映出账单层次结构，企业通常以这种方式开始。 然而，管理组的强大之处在于，在你使用它们来为组织建模时，可将相关订阅组合在一起（无论它们在计费层次结构中的位置如何）并分配常见角色、策略和计划。 一些示例包括：

  • 生产与非生产。 某些企业创建管理组来识别其生产和非生产订阅。 管理组可让这些客户更轻松地管理角色和策略。 例如，非生产订阅可能会赋予开发人员“参与者”访问权限，但在生产订阅中，他们仅有“读者”访问权限。
  • 内部服务与外部服务。 企业通常对内部服务与面向客户的服务有不同的要求、策略和角色。

精心设计的管理组以及 Azure Policy 和策略计划是 Azure 有效治理的支柱。

Pretplate

决定部门和帐户（或管理组）时，你主要是评估如何安排 Azure 环境，以便与组织匹配。 然而，订阅才是真正的工作所在，此时的决策会影响安全性、可伸缩性和计费。 许多组织将以下模式用作指南：

  • 应用程序/服务：订阅代表应用程序或服务（应用程序组合）
  • 生命周期：订阅代表服务的生命周期，例如 Production 或 Development。
  • 部门：订阅代表组织中的部门。

前两种模式是最常用的模式，强烈建议使用这两种模式。 生命周期方法适用于大多数组织。 在这种情况下，一般建议先使用两个基本订阅（Production 和 Nonproduction），再使用资源组进一步分隔环境。

资源组

使用 Azure 资源管理器可将资源组织到有意义的组中，便于管理、记帐或自然关联。 资源组是具有相同生命周期的或共享某个属性（例如 All SQL servers 或 Application A）的资源的容器。

资源组无法进行嵌套，资源只能属于一个资源组。 某些操作可对资源组中的所有资源执行操作。 例如，删除某个资源组会删除该资源组中的所有资源。 类似于订阅，创建资源组时也存在常见模式，从“传统 IT”工作负载到“敏捷 IT”工作负载会有所不同：

  • “传统 IT”工作负载通常按同一生命周期中的项（例如某个应用程序）分组。 由于可按应用程序分组，因此可以管理每个应用程序。
  • “敏捷 IT”工作负载往往侧重面向外部客户的云应用程序。 资源组通常反映部署层（例如 Web 层、应用层）和管理层。

注意

了解工作负荷可帮助制定资源组策略。 这些模式可以混合搭配。 例如，共享服务资源组可以与敏捷工作负载资源组位于同一订阅中。

命名标准

基架的第一个支柱是一致的命名标准。 使用妥善设计的命名标准，可以在门户、帐单和脚本中识别资源。 你很可能已针对本地基础结构制定了现有命名标准。 将 Azure 添加到环境时，应该将这些命名标准扩展到 Azure 资源。

提示

关于命名约定：

  • 尽可能查看并采用云采用框架命名和标记指南。 本指南可帮助确定一套有意义的命名标准并提供了大量示例。
  • 使用资源管理器策略来帮助实施命名标准。

记住，以后更改名称比较难，因此现在花费几分钟即可省去以后的麻烦。

请将命名标准集中在那些更常用和更常搜索的资源上。 例如，为清晰起见，所有资源组都应严格遵循标准。

资源标记

资源标记与命名标准紧密一致。 随着资源添加到订阅中，出于计费、管理和操作目的，对其进行逻辑分类变得日益重要。 有关详细信息，请参阅使用标记来组织 Azure 资源。

重要

标记可包含个人信息，并且可能属于 GDPR 法规的范围。 请仔细规划管理标记。 如果正在寻找有关 GDPR 的一般信息，请参阅Microsoft 服务信任门户的 GDPR 部分。

除了计费和管理外，还可通过多种方式使用标记。 标记通常用作自动化的一部分（请参阅后面的部分）。 如果不事先考虑，这可能会导致冲突。 最佳做法是标识企业级别的所有常用标记（例如 ApplicationOwner 和 CostCenter），并在使用自动化部署资源时以一致的方式应用这些标记。

Azure Policy 和计划

基架的第二个支柱涉及使用 Azure Policy 和计划来管理风险，具体方法是对订阅中的资源和服务强制实施规则（具有效果）。 Azure Policy 计划是策略的集合，旨在实现一个目标。 然后，将策略和计划分配到资源作用域，以开始强制实施这些策略。

与上文所述的管理组结合使用时，策略和计划的功能更强大。 管理组可将计划或策略分配给整个订阅集。

Resource Manager 策略的常见用途

策略和计划是功能强大的 Azure 工具。 策略允许公司为传统 IT 工作负载提供控制，从而为业务线应用程序提供稳定性，同时还允许更灵活的工作负载开发，例如开发客户应用程序而不会使企业面临额外风险。 策略的最常见模式包括：

  • 地域合规性和数据主权。 Azure 在世界各地拥有越来越多的区域。 企业通常需要确保特定作用域内的资源保留在某一地理区域内，以满足法规要求。
  • 避免公开服务器。 Azure Policy 可禁止部署某些资源类型。 通常会创建策略来拒绝在特定作用域内创建公共 IP，从而避免无意中向 Internet 公开服务器。
  • 成本管理和元数据。 资源标记通常用于将重要的账单数据添加到资源和资源组，例如 CostCenter 和 Owner 等。 这些标记对于准确计费和管理资源非常有用。 策略可强制将资源标记应用于所有已部署资源，使其更易于管理。

计划的常见用途

计划为企业提供了对逻辑策略进行分组并将它们作为单个实体进行跟踪的能力。 计划帮助企业解决敏捷工作负载和传统工作负载的需求。 计划的常见用途包括：

  • 启用 Microsoft Defender for Cloud 中的监视功能。 这是 Azure Policy 中的默认计划，也是计划的一个绝佳示例。 它可启用识别未加密的 SQL 数据库、虚拟机 (VM) 漏洞和更常见的安全相关需求的策略。
  • 特定于法规的计划。 企业通常对法规要求（如 HIPAA）通用的策略进行分组，以便有效跟踪这些控件的控制和符合性。
  • 资源类型和 SKU。 创建限制可部署资源类型以及可部署 SKU 的计划有助于控制成本，并可确保组织仅部署团队具有技能集和程序来支持的资源。

提示

我们建议始终使用计划定义，而不是策略定义。 将计划分配给作用域（如订阅或管理组）后，便可轻松将另一个策略添加到计划中，且无需更改任何分配。 这使了解所应用内容和跟踪符合性变得更加轻松。

策略和计划分配

创建策略并将其分组到逻辑计划后，必须将策略分配给作用域，例如管理组、订阅组或资源组。 通过分配，还可从策略分配中排除子作用域。 例如，如果拒绝在订阅中创建公共 IP，则可为连接到受保护外围网络的资源组创建具有排除项的分配。

azure-policyGitHub 存储库中提供了展示如何将策略和计划应用于 Azure 资源的示例。

标识和访问管理

采用公共云时要问的关键问题是“谁应该有权访问资源？”和“我如何控制这种访问？”。控制对 Azure 门户和资源的访问对于云中资产的长期安全至关重要。

若要保护对资源的访问，首先要配置标识提供者，然后配置角色和访问权限。 连接到本地 Active Directory的 Microsoft Entra ID 是 Azure 中标识的基础。 但是，Microsoft Entra ID 与本地 Active Directory不同，了解 Microsoft Entra 租户是什么以及它与注册的关系非常重要。 查看 Azure 中的资源访问管理，深入了解 Microsoft Entra ID 和本地 Active Directory。 若要连接本地目录并将其同步到 Microsoft Entra ID，请在本地安装和配置 Microsoft Entra 连接 工具。

Diagram of an architecture that includes both Microsoft Entra ID and an on-premises Active Directory instance.

Azure 在最初发布时，对订阅的访问控制非常简单：可以向用户分配“管理员”角色或“共同管理员”角色。 有权访问此经典模型中的订阅意味着有权访问门户中的所有资源。 缺少精细控制导致需要衍生订阅来针对注册提供合理的访问控制级别。 现在不再需要衍生订阅。 借助 Azure 基于角色的访问控制 (RBAC)，可将用户分配给提供常见访问权限的标准角色，如“所有者”、“参与者”或“读者”，甚至还可创建自己的角色。

实施 Azure 基于角色的访问控制时，强烈建议执行以下做法：

  • 控制订阅的“管理员”和“共同管理员”角色，因为这些角色拥有广泛的权限。 如果订阅所有者需要管理 Azure 经典部署，则只需将其添加为共同管理员。
  • 使用管理组在多个订阅中分配角色，并减少在订阅级别对其进行管理的负担。
  • 将 Azure 用户添加到 Active Directory 中的组（例如 Application X Owners）。 使用同步组为组成员提供适当的权限来管理包含应用程序的资源组。
  • 遵循授予最低特权的原则，以便完成所需的工作。

重要

请考虑使用 Microsoft Entra Privileged Identity Management、 Azure 多重身份验证 和 Microsoft Entra 条件访问 功能，以便更好地提高对 Azure 订阅中的管理操作的安全性和可见性。 这些功能来自有效的 Microsoft Entra ID P1 或 P2 许可证（具体取决于该功能），以进一步保护和管理标识。 Microsoft Entra PIM 通过审批工作流启用实时管理访问权限，以及对管理员激活和活动进行完全审核。 Azure 多重身份验证是另一项重要功能，支持登录到 Azure 门户的双重验证。 与 Microsoft Entra 条件访问控制结合使用时，可以有效地管理泄露风险。

规划和准备标识及访问控制并遵循 Azure 标识管理最佳做法是可采用的最佳风险缓解策略之一，应将其视为每个部署的强制策略。

安全性

在采用云的过程中，传统上最大的阻碍之一是安全忧虑。 IT 风险管理员和安全部门需确保默认情况下 Azure 中的资源受保护且安全。 Azure 提供了一些功能，可使用这些功能来保护资源，同时检测和消除针对这些资源的威胁。

Microsoft Defender for Cloud

除高级威胁防护外，Microsoft Defender for Cloud 还提供了整个环境中资源安全状态的统一视图。 Defender for Cloud 是一个开放式平台，允许 Microsoft 合作伙伴创建可插入并增强其功能的软件。 Defender for Cloud 免费层的基线功能提供了评估和建议，可改进安全状况。 其付费层支持其他且有价值的功能，例如实时特权访问和自适应应用程序控制（允许列表）。

提示

Defender for Cloud 是一种功能强大的工具，它会定期进行改进，增加新功能，让你能够检测威胁并保护企业。 强烈建议始终启用 Defender for Cloud。

Azure 资源的锁

随着组织不断在订阅中添加核心服务，避免业务中断变得越来越重要。 在 Azure 订阅中执行的脚本或工具意外删除资源时，会发生一种常见的中断。 锁限制针对高价值资源（修改或删除这些资源会造成重大影响）的操作。 可以将锁应用于订阅、资源组或单个资源。 将锁应用于基本资源，如虚拟网络、网关、网络安全组和密钥存储帐户。

适用于 Azure 的安全 DevOps 工具包

用于 Azure 的安全 DevOps 工具包 (AzSK) 是脚本、工具、扩展和自动化功能的集合，最初由 Microsoft 自己的 IT 团队创建，并通过 GitHub 以开源形式发布。 AzSK 满足了团队端到端 Azure 订阅和资源安全需求，这些团队使用广泛的自动化并顺利地将安全性集成到本机 DevOps 工作流中，有助于实现以下 6 个重点领域的安全 DevOps：

  • 保护订阅
  • 启用安全开发
  • 将安全性集成到 CI/CD 中
  • 连续保障
  • 警报和监视
  • 云风险管理

Overview diagram of the Secure DevOps Kit for Azure

AzSK 是一套丰富的工具、脚本和信息，它们是完整 Azure 管理计划的重要组成部分，将其整合到基架中对于支持组织的风险管理目标至关重要。

Azure 更新管理

为确保环境安全，可执行的关键任务之一是务必使用最新更新修补服务器。 虽然许多工具可实现这一点，但 Azure 提供了 Azure 更新管理解决方案，用于解决关键 OS 修补程序的识别和推出问题。 它使用 Azure 自动化，本指南后面的自动部分对此进行了介绍。

监视和警报

收集和分析遥测数据（可用于观察 Azure 订阅中所使用服务的活动、性能指标、运行状况和可用性）对于主动管理应用程序和基础结构至关重要，也是每个 Azure 订阅的基本需求。 每个 Azure 服务均以活动日志、指标和诊断日志的形式发出遥测数据。

  • 活动日志描述了对订阅中的资源执行的所有操作。
  • 指标是资源发出的描述资源性能和运行状况的数字信息。
  • 诊断日志由 Azure 服务发出，提供与该服务的操作相关的各种频繁生成的数据。

可在多个级别查看和处理此信息，并不断改进。 Azure 通过下图中列出的服务提供 Azure 资源的“共享”、“核心”和“深度”监视功能。

Diagram that depicts deep application monitoring, deep infrastructure monitoring, core monitoring, and shared capabilities.

共享功能

  • 警报：可从 Azure 资源收集每个日志、事件和指标，但由于无法获得关键条件和行为的通知，此数据仅可用于历史用途和取证。 Azure 警报会主动通知你在所有应用程序和基础结构中定义的条件。 可以跨日志、事件和指标创建警报规则，以使用操作组通知收件人组。 操作组还提供使用外部操作（如 Webhook）自动执行修复的功能，以运行 Azure 自动化 runbook 和 Azure Functions。

  • 仪表板：使用仪表板可聚合监视视图，并在资源和订阅间合并数据，从而提供整个企业范围内 Azure 资源遥测数据的视图。 可创建和配置自己的视图，并与他人共享。 例如，可为数据库管理员创建一个由各种磁贴组成的仪表板，以提供所有 Azure 数据库服务的信息，包括 Azure SQL 数据库、Azure Database for PostgreSQL 和 Azure Database for MySQL。

  • 指标资源管理器：指标是 Azure 资源生成的数值（例如 CPU 百分比或磁盘 I/O 指标），可提供对资源操作和性能的见解。 使用指标资源管理器，可定义感兴趣的指标并将其发送到 Log Analytics 进行聚合和分析。

核心监视

  • Azure Monitor：Azure Monitor 是一款核心平台服务，提供用于监视 Azure 资源的单一源。 Azure Monitor 的 Azure 门户界面为 Azure 中的所有监视功能提供了集中的突出显示点，包括 Application Insights、Log Analytics、网络监视、管理解决方案和服务映射的深度监视功能。 通过 Azure Monitor，可对来自整个云产业中 Azure 资源的指标和日志进行可视化、查询、路由、存档和执行操作。 除门户外，还可通过 Azure Monitor PowerShell Cmdlet、跨平台 CLI 或 Azure Monitor REST API 检索数据。

  • Azure 顾问：Azure 顾问会在你的订阅和环境中持续监视遥测数据。 它还会推荐对 Azure 资源进行成本优化并提高应用程序资源的性能、安全性和可用性的最佳做法。

  • Azure 服务运行状况：Azure 服务运行状况可识别 Azure 服务中可能影响应用程序的任何问题，并有助于规划计划性维护时段。

  • 活动日志：活动日志描述了对订阅中资源执行的所有操作。 它提供了一条审核线索，可确定对资源执行的任何 CRUD（创建、更新、删除）操作的“内容”、“人员”和“时间”。 活动日志事件存储在平台中，可在 90 天内进行查询。 可将活动日志引入 Log Analytics 中，以实现更长的保持期，并在多个资源中进行更深入的查询和分析。

深度应用程序监视

  • Application Insights：使用 Application Insights 可收集特定于应用程序的遥测数据，并可监视云或本地应用程序的性能、可用性和使用情况。 通过使用支持的 SDK 为多种语言（包括 .NET、JavaScript、Java、Node.js、Ruby 和 Python）检测应用程序。 Application Insights 事件已引入支持基础结构和安全性监视的同一 Log Analytics 数据存储中，从而可通过丰富的查询语言随着时间推移关联和聚合事件。

深度基础结构监视

  • Log Analytics：Log Analytics 在 Azure 监视中发挥了重要作用，具体表现在：从各种源收集遥测数据和其他数据，以及提供查询语言和分析引擎，用于了解应用程序和资源的运行情况。 可以通过快速的日志搜索和视图直接与 Log Analytics 数据交互，也可以在其他 Azure 服务（例如 Application Insights 或 Microsoft Defender for Cloud，可以将其数据存储在 Log Analytics 中）中使用分析工具。

  • 网络监视：使用 Azure 的网络监视服务可深入了解网络流量、性能、安全性、连接性和瓶颈。 精心规划的网络设计应包括配置 Azure 网络监视服务，如网络观察程序和 ExpressRoute 监视器。

  • 管理解决方案：管理解决方案是应用程序或服务的逻辑、见解和预定义 Log Analytics 查询的打包集。 它们依赖于 Log Analytics 并将其作为存储和分析事件数据的基础。 示例管理解决方案包括监视容器和 Azure SQL 数据库分析。

  • 服务映射：服务映射提供了一个图形视图，可查看基础结构组件及其在其他计算机和外部进程上的进程和相互依赖性。 它将事件、性能数据和管理解决方案集成到 Log Analytics 中。

提示

在创建单个警报之前，请创建一组可在 Azure 警报中使用的共享操作组并进行维护。 通过此操作可集中维护收件人列表的生命周期、通知发送方法（电子邮件、SMS 电话号码）和外部操作的 Webhook（Azure 自动化 runbook、Azure Functions 和逻辑应用、ITSM）。

成本管理

从本地云迁移到公有云时，要面临的主要变化之一是从资本支出（购买硬件）转换为运营支出（使用时支付服务费用）。 这种转变还需要更仔细地管理你的成本。 云的优势在于，当不需要服务时，只需将其关闭或重设大小，即可从根本上积极影响所使用服务的成本。 谨慎管理云中的成本是最佳做法，也是成熟客户的日常事务。

Microsoft 提供了多种工具来帮助你可视化、跟踪和管理成本。 我们还提供了全套 API，可用于自定义成本并将成本管理集成到自己的工具和仪表板中。 这些工具大致可分为 Azure 门户功能和外部功能。

Azure 门户功能

这些工具可提供有关成本的即时信息以及执行操作的功能。

  • 订阅资源成本：借助位于门户中的 Azure 成本管理 + 计费视图，可快速查看有关资源或资源组的成本和每日支出信息。
  • Azure 成本管理 + 计费：这样，你就可以管理和分析 Azure 支出以及你在其他公有云提供商上的支出。 功能丰富的免费层和付费层均可供选择。
  • Azure 预算和操作组：直到最近，了解某些内容的成本并对其采取措施，更多的是手动操作。 随着 Azure 预算及其 API 的引入，现在可创建在成本达到阈值时运行的操作。 例如，可以在 test 资源组的消耗达到其预算的 100% 时关闭它。
  • Azure 顾问：了解某些内容的成本仅完成了任务的一半，另一半在于了解如何处理该信息。 Azure 顾问为节省资金、提高可靠性甚至提高安全性要执行的操作提供了建议。

外部成本管理工具

  • Power BI Azure 使用见解：是否要为组织创建自己的可视化效果？ 如果是，则 Power BI 的 Azure 使用见解内容包是首选工具。 使用此内容包和 Power BI，可创建自定义可视化效果来表示组织，对成本进行更深入的分析，并添加其他数据源以进一步扩充。

  • Azure 使用 API：除有关预算、预留实例和市场费用的信息之外，使用 API 还允许以编程方式访问成本和使用情况数据。 这些 API 仅适用于 EA 注册和某些 Web Direct 订阅，但是借助它们可将成本数据集成到自己的工具和数据仓库中。 你还可以通过 Azure CLI 访问这些 API。

作为长期且成熟的云用户的客户遵循特定的最佳做法：

  • 主动监视成本。 熟练 Azure 用户的组织会不断监视成本，并在需要采取措施。 某些组织甚至派人专门进行分析并对使用情况的更改提出建议，当这些人员首次找到已运行数月的未使用的 HDInsight 群集时，即可收回成本。
  • 使用 Azure 虚拟机预留实例。 管理云中成本的另一项关键原则是使用合适的工具来完成作业。 如果 IaaS VM 必须全天候运行，那么使用预留实例将能够节省大量资金。 权衡自动关闭 VM 和使用预留实例需要经验和分析。
  • 有效地使用自动化。 许多工作负载不需要每天运行。 每天将 VM 关闭 4 小时也可节省 15% 的成本。 自动化将很快收回成本。
  • 使用资源标记来提高可见性。 如本文档其他部分所述，使用资源标记可更好地分析成本。

成本管理是有效且高效运行公有云的核心策略。 成功的企业能够控制成本，使成本与实际需求相匹配，而不是过度购买和希望出现需求。

自动化

区分使用云提供程序组织成熟度的其中一项功能是其所包含的自动化水平。 自动化是永无止境的过程。 随着组织迁移到云，这是一个你需要投入资源和时间进行构建的领域。 自动化有许多用途，包括一致地推出资源（其中自动化直接与另一个核心基架概念“模板和 DevOps”相关联）以解决问题。 自动化将 Azure 基架的每个区域联结在一起。

从第一方工具（如 Azure 自动化、事件网格和 Azure CLI）到大量第三方工具（如 Terraform、Jenkins、Chef 和 Puppet），有多种工具可以帮助你构建此功能。 核心自动化工具包括 Azure 自动化、事件网格和 Azure Cloud Shell。

  • 通过 Azure 自动化，可使用 PowerShell 或 Python 创作 runbook，以自动执行流程，配置资源，甚至应用修补程序。 Azure 自动化具有广泛的跨平台功能，这些功能对部署来说不可或缺，但是过于广泛，在此不进行深入介绍。
  • 事件网格是一个完全托管的事件路由系统，可让你对 Azure 环境中的事件做出反应。 正如 Azure 自动化是成熟云组织的结缔组织，事件网格是良好自动化的结缔组织。 使用事件网格，可创建简单的无服务器操作，以便在创建新资源时向管理员发送电子邮件，并将该资源记录到数据库中。 相同的事件网格可在删除资源时通知，并从数据库中删除该项。
  • Azure Cloud Shell 是一个基于浏览器的交互式 shell，用于管理 Azure 中的资源。 它为 PowerShell 或 Bash 提供了完整的环境，可根据需要启动（并代为维护），以便拥有一致的环境来运行脚本。 Azure Cloud Shell 提供了对已安装其他关键工具的访问，以便自动化环境，包括 Azure CLI、Terraform 和越来越多的用于管理容器、数据库 (sqlcmd) 等的其他工具。

自动化是一项全职工作，它将迅速成为云团队中最重要的操作任务之一。 采用“自动化优先”方法的组织在使用 Azure 方面取得了更大的成功：

  • 管理成本：积极寻找机会并创建自动化以重设资源大小，纵向扩展或缩减并关闭未使用的资源。
  • 操作灵活性：使用自动化（以及模板和 DevOps），可获得一定程度的可重复性，从而提高可用性、增强安全性并使团队可专注于解决业务问题。

模板和 DevOps

如前文所述，组织的目标应是通过源代码控制的模板和脚本预配资源，并最大限度地减少环境的交互配置。 这种“基础结构即代码”的方法，以及用于持续部署的规范 DevOps 进程，可确保一致性并减少环境间的偏差。 几乎所有 Azure 资源都可通过 Azure 资源管理器 JSON 模板与 PowerShell 或 Azure 跨平台 CLI 和工具（如 HashiCorp 的 Terraform，该公司提供一流支持并与 Azure Cloud Shell 集成）部署。

使用 Azure 资源管理器模板的最佳做法等文章提供了使用 Azure DevOps 工具链将 DevOps 方法应用于 Azure 资源管理器模板的最佳做法和经验教训的精彩讨论。 花费时间和精力开发一套特定于组织需求的核心模板，并利用 DevOps 工具链（例如 Azure DevOps、Jenkins、Bamboo、TeamCity 和 Concourse）开发持续交付管道，专门用于生产和 QA 环境。 GitHub 上有一个大型的 Azure 快速入门模板库，可用于模板的起点，可以使用 Azure DevOps 快速创建基于云的交付管道。

作为生产订阅或资源组的最佳做法，目标应该是使用 Azure RBAC 安全性来默认禁用交互用户，以及使用基于服务主体的自动持续交付管道来预配所有资源，并提供所有应用程序代码。 任何管理员或开发人员都不应使用 Azure 门户以交互方式配置资源。 此级别的 DevOps 需要协同努力，并使用 Azure 基架的所有概念，提供一个一致且更安全的环境，以满足组织缩放需求。

提示

设计和开发复杂的 Azure 资源管理器模板时，使用链接模板来整理和重构单个 JSON 文件的复杂资源关系。 这样操作便可单独管理资源，让模板更具可读性、可测试性和可重用性。

Azure 是一个超大规模的云提供商。 将组织从本地服务器移动到云时，依赖云提供商和 SaaS 应用程序所使用的相同概念将有助于你的组织更高效地应对业务需求。

核心网络

Azure 基架参考模型的最后一个组件是贵组织如何以安全的方式访问 Azure 的核心。 对资源的访问可能是从内部（在企业网络中）或外部（通过 Internet）发起的。 组织中的用户经常会无意中将资源放在错误的位置，使其遭到恶意访问。 与对待本地设备一样，企业必须增设相应的控制机制，确保 Azure 用户做出正确的决策。 为了进行订阅监管，我们指定了可提供基本访问控制的核心资源。 这些核心资源包括：

  • 虚拟网络是子网的容器对象。 尽管严格意义上没有必要，但将应用程序连接到内部企业资源时往往要用到它。
  • 用户定义的路由使你可操作子网内的路由表，从而可通过网络虚拟设备或对等虚拟网络上的远程网关发送流量。
  • 虚拟网络对等互连使你可无缝连接两个或多个 Azure 中的虚拟网络，从而创建更复杂的中心辐射设计或共享服务网络。
  • 服务终结点。 过去，PaaS 服务依靠不同的方法来确保从虚拟网络访问这些资源。 服务终结点允许仅从连接的端点安全访问已启用的 PaaS 服务，提高了整体安全性。
  • 安全组是一组广泛的规则，通过安全组可允许或拒绝进/出 Azure 资源的入站和出站流量。 安全组由安全规则组成，可使用服务标记（定义常见 Azure 服务，如 Azure Key Vault 或 Azure SQL 数据库）和应用程序组（定义应用程序结构，例如 Web 服务器或应用程序服务器）进行扩充。

提示

使用网络安全组中的服务标记和应用程序安全组，可以：

  • 提高规则的可读性，这一点对于理解影响至关重要。
  • 在更大的子网中启用有效的微分段，减少蔓延并提高灵活性。

Azure 虚拟数据中心

Azure 通过我们广泛的合作伙伴网络提供了内部功能和第三方功能，为你提供有效的安全状态。 更重要的是，Microsoft 以 Azure 虚拟数据中心 (VDC) 的形式提供了最佳做法和指导。 从单个工作负载转向使用混合功能的多个工作负载时，VDC 指导会提供“窍门”，以便提供随 Azure 中工作负载的增长而增长的灵活网络。

后续步骤

监管对于 Azure 的成功至关重要。 本文阐述企业基架的技术实现，不过，对于宏观的流程以及组件之间的关系，只是一笔带过。 策略监管的流程是自顶向下实施的，由企业的目标决定。 为 Azure 创建的监管模型自然包括 IT 部门的主张，但更重要的是，它应该融入业务小组负责人以及安全和风险管理部门的有力表述。 最终，企业基架都应该缓解业务风险，帮助实现组织的使命和目标。

了解订阅治理后，接下来请查看 Azure 迁移就绪性最佳做法，了解如何实施这些建议。