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

查看并比较常见的云操作模型

根据操作模型当前的要求和约束，它们都特定于其支持的业务并且是唯一的。 但运营模型不是 雪花。 客户操作模型有几种常见模式；本文概述了四种最常见的模式。

操作模型比较

下图绘制了复杂度范围从最不复杂（分散式）到最复杂（全局操作）的常见操作模型。 下表根据其他几个属性的相对值对这些操作模型进行了比较。

重心或范围

云操作模型主要由两个因素驱动：

• 战略优先事项或动机
• 要管理的项目组合的范围

	分散式操作 (ops)	集中式操作 (ops)	企业操作 (ops)	分布式操作 (ops)
战略优先事项或动机	创新	控件	民主化	集成
项目组合范围	工作负载	登陆区域	云平台	全部的项目组合
工作负载环境	复杂程度高	复杂程度低	复杂程度中等	复杂程度中等或不定
登陆区域	空值	复杂程度高	中低复杂程度	复杂程度低
基础实用工具	空值	不适用或支持级别较低	集中式支持，支持级别较高	支持级别最高
云基础	空值	空值	混合基础、特定于提供商的基础或区域基础	分布式和同步

• 战略优先级或 动机：每个运营模型提供 云采用的典型战略动机。 但一些运营模型简化了特定的动机。

• 项目组合范围：项目组合范围标识特定操作模型设计支持的最大范围。 例如，集中式操作专为几个登陆区域而设计。 但运营模型决策可能会给组织造成运营风险。 尝试管理大型复杂项目组合时会产生操作风险。 这些项目组合在登陆区域设计中可能需要多个登陆区域或可变的复杂性。

重要

采用云通常会触发对当前运营模型的反思，并可能导致从一种通用运营模型转向另一种常见运营模型。 但云采用并不是唯一的触发因素。 业务重心和云采用范围可能会改变项目组合所需的支持方式。 在最匹配的操作模型中，也可能会出现其他转变。 当董事会或其他高管团队制定 5 到 10 年的商业计划时，这些计划通常包含一条调整操作模型的要求（明示或暗示）。 操作模型是指导决策的良好参考。 这些模型可能会更改或需要自定义以满足你的要求和约束。

责任一致性

许多团队和个人负责支持不同的功能。 但每个常见的运营模型都会将决策结果的最终责任分配给一个团队或个人。 这种方法会影响如何为操作模型提供资金，以及为每种功能提供哪种级别的支持。

	分散式操作	集中式操作	企业操作	分布式操作
业务一致性	工作负载团队	中央云策略	CCoE	不定 - 组建庞大的云策略团队？
云运营	工作负载团队	中央 IT	CCoE	基于项目组合分析 - 请参阅业务一致性和业务承诺
云治理	工作负载团队	中央 IT	CCoE	治理的多个层面
云安全	工作负载团队	安全操作中心 (SOC)	CCoE + SOC	混合 - 请参阅定义安全策略
云自动化和 DevOps	工作负载团队	中央 IT 或不适用	CCoE	基于项目组合分析 - 请参阅业务一致性和业务承诺

在 Azure 中加速实现操作模型

正如在定义操作模型中所讨论的那样，云采用框架的每种方法都提供了结构化的操作模型开发途径。 这些方法可帮助你克服在采用云操作模型时因存在差距而遇到的障碍。

下表概述了加速实现操作模型的方法。

	分散式操作	集中式操作	企业操作	分布式操作
起点	Azure 架构良好的框架 (WAF)	Azure 登陆区域：“从小规模开始”选项	Azure 登陆区域：CAF 企业规模	业务一致性
迭代	通过专注于工作负载，团队可以在 WAF 中循环访问。	“从小规模开始”选项要求对每种方法进行更多迭代，但可以在云采用工作成熟时进行。	如参考实现所示，未来的迭代通常侧重于少量地添加配置。	请查看 Azure 登陆区域实现选项，从最符合操作基线的选项入手。 应按照该选项的设计原则中规定的迭代途径操作。

分散运营

操作总是复杂的。 如果将操作范围限制为一个工作负荷或少量工作负载集合，则可以控制复杂性。 分散式操作是常见操作模型中最不复杂的一种。 在这种形式的操作中，所有工作负载都由专用工作负载团队独立运行。

• 优先级：团队衡量创新，胜过集中控制或跨多个工作负载的标准化。
• 明显的优势：通过让工作负载和业务团队全权控制设计、生成和运营，最大程度提升创新速度。
• 明显的劣势：跨工作负载的标准化程度降低、通过共享服务实现的规模效益减小，以及集中治理的合规性工作一致性降低。
• 风险：此方法会在管理工作负载组合时引入风险。 工作负载团队可能有专门负责中央 IT 职能的专用团队。 某些组织（尤其是需要遵循第三方合规性要求的公司）将此操作模型视为高风险选项。
• 指导：分散式操作仅限于工作负载级别的决策。 Microsoft Azure Well-Architected Framework 支持在该范围内做出的决策。 云采用框架中的流程和指导可能会增加分散式操作所不需要的开销。

分散式操作的优势

• 成本管理：操作成本很容易映射到单个业务部门。 特定于工作负载的操作支持更大的工作负载优化。
• 责任：通常，为了将开销降至最低，这种形式的操作高度依赖自动化。 责任往往侧重于 DevOps 和发布管理管道。 此类操作支持在开发过程中更快地部署和更短的反馈周期。
• 标准化：使用源代码和部署管道将环境从发布到发布进行标准化。
• 操作支持：影响操作的决策仅与相应工作负载的需求有关，简化了操作决策。 DevOps 社区成员表示，由于操作范围更窄，操作支持是最简单的操作形式。
• 专业知识：这是为 DevOps 团队和开发团队赋能最重要的方式，他们在推动市场变革方面遇到的阻力最小。
• 登陆区域设计：无特定操作优势。
• 基础实用工具：无特定操作优势。
• 职责分离：无特定操作优势。

分散式操作的缺点

• 成本管理：更难计算企业成本。 缺少集中式治理团队，难以统一控制或优化成本。 如果规模较大，这种模型可能成本高昂，因为在部署的资产和人员分配方面，每个工作负载可能会有重复。
• 责任：缺少集中式支持意味着工作负载团队全权负责治理、安全、运营和变更管理。 如果这些任务尚未在代码评审和发布管道中自动执行，则缺乏支持是有问题的。
• 标准化：跨工作负载组合的标准化是可变且不一致的。
• 操作支持：跨多个工作负载创建最佳做法时，通常没有规模效益。
• 专业知识：在应用程序设计和配置过程中，团队成员在就治理、安全、运营和变更管理问题做出合乎道德的明智决策时，担负更大的责任。 请经常咨询 Microsoft Azure Well-Architected评审和 Azure Well-Architected框架，以提高所需的专业知识。
• 登陆区域设计：登陆区域不特定于工作负载，在此方法中不予考虑。
• 基础实用工具：跨工作负载共享的基础服务很少（如有），这降低了规模效益。
• 职责分离：对 DevOps 和开发团队的更高要求会增加这些团队提升的权限的使用。 如果需要职责分离，则可能需要对 DevOps 成熟度进行大量投资才能使用此方法。

集中运营

稳定状态的环境可能不需要关注体系结构或各个工作负载的不同操作需求。 对于主要由稳定状态的工作负载构成的技术环境，集中式操作往往是一种常态。 稳定状态的操作示例包括商用现货 (COTS) 应用程序，或发布节奏缓慢的完善的自定义应用程序。 如果变化率由定期的更新和补丁驱动，则集中式操作可能是一种有效的项目组合管理方法。

• 重点：重点是集中控制创新，并在现代云操作的文化转变中，衡量现有操作流程。
• 明显的优势：集中化带来了规模效益、最佳控制机制和标准化操作，很适合云环境。 这些环境需要特定的配置，用于将云操作集成到现有操作和流程中。 集中化对于有几百个工作负载且体系结构复杂度和合规性需求适中的组合来说最有利。
• 明显的劣势：根据大型工作负载组合的需求进行缩放，可能会给负责就生产工作负载问题做出操作决策的集中化团队施加巨大压力。 如果技术资产预计扩展到超过 1，000 个 VM、应用程序或数据源，则可以考虑在 18-24 个月内的企业模型。
• 风险：此方法将集中化限制到较少数量的订阅（通常是一个生产订阅）。 之后在云历程中重构时，将存在重大风险，可能会干扰采用计划。 为避免返工，可尝试关注分隔、环境边界、标识工具和其他基础元素。
• 指导：与“从小规模开始，然后进行扩展”开发速度一致的 Azure 登陆区域实现选项创建了一个合理的起点。 可以使用这些选项来加速采用工作。 但要取得成功，请制定明确的策略，以在可接受的风险容忍度内指导早期采用工作。 治理和管理方法有助于同时创建帮助完善操作的流程。 请遵循这些步骤，它们发挥着阶段关卡的作用，在风险随操作的成熟而增加之前，必须先完成这些步骤。

集中式操作的优点

• 成本管理：跨多个工作负载集中共享服务可产生规模效益并消除重复性的任务。 中央团队可以通过企业级的规模调整和规模优化来快速缩减成本。
• 责任：集中的专业知识和标准化可提高稳定性、提升操作性能并最大限度减少与变更相关的停机。 此方法可减轻专注于工作负载的团队的广泛技能压力。
• 标准化：一般而言，使用集中式模型时，标准化和操作成本最低，因为重复的系统或任务较少。
• 运营支持：通过降低复杂性和集中化操作，小型 IT 团队可以更轻松地支持运营。
• 专业知识： 通过集中支持团队，安全、风险、治理和运营方面的专家可以推动业务关键型决策。
• 登陆区域设计：中央 IT 可最大程度地减少登陆区域和订阅数，从而降低复杂性。 登陆区域设计往往模仿前面的数据中心设计，可缩短过渡时间。 随着采用过程的推进，共享资源可能会移到单独的订阅或平台基础中。
• 基础实用工具：将现有数据中心设计带入云，从而生成模拟本地工具和操作的基础共享服务。 如果本地操作是主要的操作模型，这可能是一个优势，但注意存在一些缺点。 本地操作可缩短转换时间，利用规模经济，并支持本地与云托管工作负载之间的一致操作流程。 此方法可以减少短期的复杂性和工作量，让较小的团队通过减少学习曲线来支持云运营。
• 职责分离：集中式操作的职责分离较为明确。 中心 IT 维护对生产环境的控制，并减少对其他团队的任何提升权限的需求。 此方法通过限制具有提升权限的帐户数来减少违规行为。

集中式操作的缺点

• 成本管理：中央团队并不总是那么了解工作负载体系结构，因此有时也无法在工作负载级别进行有效的优化。 这种缺乏了解限制了优化工作负载操作带来的成本节省量。 对工作负载体系结构没有全面的了解可能会影响集中式成本优化，进而影响架构良好的工作负载的性能、规模和其他支柱。 在将企业范围的成本更改应用于高调工作负载之前，中心 IT 团队应了解并完成 Microsoft Azure Well-Architected评审。
• 责任：将生产支持和访问集中化会给一些人员带来较大的操作负担，并给每位员工施加更大的压力。 施加在这些人身上的压力导致需要更深入地审查已部署的工作负载，从而验证是否符合详细的安全治理和合规性要求。
• 标准化：如果没有中央 IT 员工的线性调整，中央 IT 方法就难以调整标准化。
• 操作支持：此方法最大的缺点与用于衡量创新的重要规模和转变有关。
• 专业知识：在这种环境中，开发人员和 DevOps 专家面临贬值或受到太多约束的风险。
• 登陆区域设计：数据中心设计基于上述方法的约束（并不总是与云相关）。 遵循此方法会减少重新思考环境分隔的机会，增加创新机会。 缺乏登陆区域分段会增加违规的潜在影响、治理和合规性遵守的复杂性，并可能在云旅程中阻碍采用。 请参阅上面的风险部分。
• 基础实用工具：在数字化转型期间，云可能会成为主要的操作模型。 专为本地操作构建的中央工具减少了实现操作现代化的机会，提高了操作效率。 在采用过程中尽早选择不不实现操作现代化也是一种选择。 现代化可以通过在云采用过程中创建平台基础订阅来实现。 如果不进行高级规划，这项工作可能很复杂、成本高昂且耗时。
• 职责分离：中央运营通常遵循两种路径之一，两者都可能阻碍创新。
  • 选项 1：中央 IT 以外的团队获得有限的权限来开发模拟生产的环境。 此选项会阻碍试验。
  • 选项 2：团队在不受支持的环境中进行开发和测试。 此选项会阻碍部署过程，并减慢部署后的集成测试速度。

企业运营

企业操作是建议的所有云操作的目标状态。 企业操作通过简化决策和责任来平衡控制和创新之间的需求。 中央 IT 由更便利的云卓越中心或 CCoE 团队取代，它们可为工作负载团队提供支持。 CCoE 团队让工作负载团队对决策负责，而不是控制或限制其行为。 工作负载团队在明确定义的护栏内获得更多推动创新的权力并承担更大的责任。

• 重点：重心是让技术决策民主化。 技术决策的民主化将以前由中央 IT 部门承担的责任转移到工作负载团队。 为了在重心上实现这种转变，决策变得不那么依赖人工运行的评审过程。 此方法支持使用云原生工具自动审查、治理和执行。
• 明显的优势：环境分隔和职责分离可以实现控制与创新的平衡。 集中式操作可维护需要提高合规性和稳定状态操作的工作负载或意味着安全风险更大的工作负载。 相反，此方法支持减少对需要更大创新的工作负载和环境的集中控制。 大型项目组合可能难以实现控制与创新的平衡。 利用这种灵活性，可以更轻松地缩放成千上万的工作负载，同时减轻操作负担。
• 明显的缺点：在本地运行的内容在企业云运营中可能无法正常工作。 这种操作方法需要在许多方面做出改变。 控制和责任的文化转变通常挑战性最大。 运营转变紧跟在文化转变之后，需要花费时间和不懈的努力来实施、完善和稳定。 在稳定的工作负载中，可能需要转变体系结构，而文化、运营和体系结构的转变又需要工具转变来提供力量和支持。 这些转变可能需要对主要的云提供商做出承诺。 在这些更改之前进行的采用工作可能需要大量返工，这超出了典型的重构工作范围。
• 风险：此方法要求管理层对变更策略做出承诺。 还需要技术团队做出承诺来克服学习障碍并交付所需的变更成果。 企业、CCoE 和中心 IT 以及工作负载团队之间的长期合作才能看到长期优势。
• 指导：Azure 登陆区域选项定义为 企业规模。 这些选项提供了参考实现，以演示技术更改如何使用 Azure 中的云原生工具交付。 企业规模方法可指导团队完成充分利用这些实现所需的运营和文化转变。 也可采用同样的方法调整参考体系结构来配置环境，以满足你的采用策略和合规性约束。 实现企业规模时，治理和管理方法可以帮助定义流程。 这些流程可以扩展合规性和运营功能，以满足运营需求。

企业操作的优势

• 成本管理：中央团队负责跨项目组合的优化，并让各个工作负载团队负责更深入的工作负载优化。 专注于工作负载的团队有权在决策产生负面成本影响时做出决策并提供明确性。 中央团队和工作负载团队共同为成本决策承担相应级别的责任。
• 责任：中央团队使用云原生工具来定义、强制实施并自动采取规范措施。 通过 CCoE 自动化和做法，可加快工作负载团队的工作。 工作负载团队能够推动创新，并在这些护栏内做出决策。
• 标准化：集中的规范措施和基础服务可在所有环境之间保持一致性。
• 操作支持：需要集中操作支持的工作负载被划分到具有稳定状态控制的环境中。 分隔和职责分离使工作负载团队能够对其自己的专用环境中的操作支持负责。 自动化云原生工具可为具有集中式操作支持的所有环境提供最低操作基线保证。
• 专业知识：集中安全、风险、治理和运营等核心服务可确保适当的中心专业知识。 清理流程和规范措施使工作负载团队能够做出更详细的决策。 这些决策扩大了人才集中的影响，无需随着技术规模线性调整员工的规模。
• 登陆区域设计：登陆区域设计可复制项目组合的需求，从而创建明确的安全、治理和责任边界。 在云中运行工作负载需要这些边界。 分隔做法不太可能与之前数据中心设计创建的约束类似。 在企业操作中，登陆区域设计不太复杂，因此可以更快地缩放并减少自助服务需求障碍。
• 基础实用工具：基础实用工具托管在单独的集中控制的订阅（称为平台基础）中。 然后，中心工具作为实用工具服务通过管道进入每个登陆区域。 将基础实用工具与登陆区域分离可以最大程度地提高一致性和规模效益。 这些实用工具还明确区分了集中管理的责任和工作负载级别的责任。
• 职责分离：在基础实用工具和登陆区域之间明确职责分工是该操作方法一大优势。 云原生工具和流程支持集中团队与工作负载团队之间的访问和适当的控制平衡。 此方法基于单个登陆区域的要求，以及登陆区域分隔区中托管的工作负载的要求。

企业操作的缺点

• 成本管理：中央团队更依赖工作负载团队在登陆区域中进行生产更改。 这种转变会带来潜在的风险：预算超支以及合理调整实际支出的速度变慢。 成本控制流程、明确的预算、自动化控制和定期评审必须尽早落实，以免产生意外成本。
• 责任：企业操作需要更高的文化和操作要求。 这些要求可确保明确中央团队和工作负载团队之间的职责和责任。
• 传统的变更管理流程或变更咨询委员会 (CAB) 可能无法保持此操作模型中所需的节奏和平衡。 这些流程反映在自动执行可安全缩放云采用的流程和过程中。
• 缺乏变革的承诺首先在谈判和责任协调中实现。 无法就责任转变问题达成一致表明在短期的云采用工作期间可能需要中央 IT 操作模型。
• 标准化：在集中的规范措施或自动化领域缺少投资，会给标准化带来风险，通过手动评审过程更难以解决。 登陆区域中的工作负载和共享服务之间的操作依赖关系会带来更大的风险。 这些风险源于升级周期的标准化或基础实用工具的未来版本。 在修订平台基础期间，需要改进甚至自动测试所有受支持的登陆区域及其托管的工作负载。
• 操作支持：通过自动化和集中式操作提供的操作基线可能足以满足低影响或低关键性工作负载的需求。 但复杂或高关键性工作负载可能需要工作负荷团队或其他形式的专用操作。 如果是这样，它可能会导致运营预算的变化，要求业务部门为这些形式的高级运营提供运营费用。 如果需要中心 IT 来维护对运营成本的唯一责任，则企业运营可能难以实现。
• 专业知识：可能需要中心 IT 团队成员来培养在自动化以前通过手动流程提供的中央控制方面的专业知识。 此外，这些团队可能需要熟练运用基础结构即代码方法来定义环境，并了解分支、合并和部署管道。 至少，平台自动化团队可能需要决策技能来了解云卓越中心或中央运营团队做出的决策。 工作负载团队可能需要学习与影响决策的控制和流程相关的更多知识。
• 登陆区域设计：登陆区域设计依赖于基础实用工具。 工作负荷团队应了解设计中的内容以及禁止包含的内容。 了解这些内容有助于避免重复性工作、错误或冲突。 若要提高灵活性，可以将异常过程考虑在登陆区域设计中。
• 基础实用工具：集中基础实用工具需要一段时间。 这些实用工具最终会考虑各种选项，并制定可以进行缩放以满足各种采用计划的解决方案。 早期采用工作可能会发生延迟。 从长期来看，延迟可以被抵消，因为后面在此过程中可以提速并避免一些障碍。
• 职责分离：确保明确分隔职责需要成熟的标识管理过程。 与正确对齐用户、组以及加入和载入活动相关的维护可能更多。 可能需要采用新流程来适应通过提升的权限进行实时访问。

分布式运营

现有的操作模型可能过于根深蒂固，以至于整个组织无法转移到新的操作模型。 对于其他组织，全局操作和各种合规性要求可能会阻止特定业务部门做出改变。 在这种情况下，可能需要使用分发操作方法。 此方法是迄今为止最复杂的方法，因为它需要集成一个或多个前面提到的操作模型。

尽管我们不建议这样做，但某些组织可能需要此操作方法。 该方法主要涉及拥有松散的不同业务部门、不同客户群或区域运营的组织。

• 优先级：集成多个现有操作模型。
• 在过渡状态，重点是将整个组织迁移到前面提到的操作模型之一。
• 当组织太大或太复杂，不适合单个操作模型时，采用长期操作方法。
• 独特的优势：集成每个业务部门的常见运营模型元素。 此方法创建一个工具，用于将运营单位分组到层次结构中，从而使用一致的可重复流程帮助他们成熟运营。
• 明显的劣势：多个操作模型之间的一致性和标准化难以维持太长时间。 这种操作方法要求深入了解项目组合以及技术组合的各个部分的运作方式。
• 风险：缺少对主操作模型的承诺可能会导致团队之间发生混乱。 如果无法与单个操作模型对齐，请使用此操作模型。
• 指导：首先使用业务一致性文章中概述的方法对投资组合进行全面评审。 尝试按状态操作模型将组合分组（分散式、集中式或企业）。
• 开发反映操作模型分组的管理组层次结构。 这种安排包括区域、业务部门或其他条件的其他组织模式，这些模式将工作负载群集从最不常见到最常见的存储桶映射。
• 评估工作负载与操作模型是否匹配，找出最相关的操作模型群集并从它入手。 对于节点和管理组层次结构下的所有工作负载，按照其相应操作模型的对应指导进行操作。
• 使用治理和管理方法查找常见的公司策略，包括在层次结构的各个点所需的运营管理做法。 应用常见的 Azure 策略来自动执行共享的企业策略。
• 使用各种部署测试 Azure 策略时，请尝试将它们移到管理组层次结构中的较高位置。 这些策略可应用于多个工作负载，你可能会发现它们存在相同和不同的操作需求。
• 随着时间的推移，这种方法可能会帮助你定义一种可在各种操作模型之间进行缩放的模型。 此方法还可通过一组常见的策略和过程来统一各个团队。

我们故意将此方法的优势和劣势留空。 完成项目组合的业务调整后，请参阅上面的主要操作模型部分，了解相关优缺点。

后续步骤

了解与操作模型关联的术语。 你可借助术语来了解操作模型如何融入大型的企业规划主题。

运营模型术语

了解登陆区域如何为任何云采用环境提供基本的构建块。

什么是登陆区域？