你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
查看和比较常见的云操作模型
运营模型是独一无二的，特定于他们支持的业务，具体取决于他们当前的要求和约束。 但是，操作模型不是雪花型模型。 客户作模型中有几个常见模式：本文概述了四种最常见的模式。
运营模式比较
下图根据复杂性范围（从最不复杂（分散）到最复杂（全球运营））映射常见操作模型。 下表根据其他几个属性的相对值比较同一运行模型。
优先级或范围
云作模型主要由两个因素驱动：
- 战略优先级或动机
- 要管理的投资组合的范围
| 分散式操作 (ops) | 集中式操作 (ops) | 企业操作 (ops) | 分布式操作 (ops) | |
|---|---|---|---|---|
| 战略优先事项或动机 | 创新 | 控制 | 民主化 | 整合 |
| 项目组合范围 | 工作量 | 登陆区域 | 云平台 | 完整作品集 |
| 工作负载环境 | 高复杂性 | 复杂性低 | 中等复杂性 | 中等或可变复杂性 |
| 登陆区域 | N/A | 高复杂性 | 中等到低复杂性 | 复杂性低 |
| 基础实用工具 | N/A | N/A 或低支持 | 集中和更多支持 | 支持级别最高 |
| 云基础 | N/A | N/A | 混合基础、特定于提供商的基础或区域基础 | 分布式和同步 |
项目组合范围：项目组合范围标识特定作模型设计支持的最大范围。 例如，集中式操作是为少数几个着陆区而设计的。 但运营模型决策可能会给组织造成运营风险。 尝试管理大型复杂投资组合时，会出现运营风险。 这些项目组合可能需要许多登陆区域或登陆区域设计中的可变复杂性。
重要
采用云计算通常会促使人们反思当前的运营模式，并可能导致从一个通用的运营模式转向另一个运营模式。 但云采用并不是唯一的触发因素。 业务优先级和云采用范围可以改变项目组合需要支持的方式。 在最匹配的操作模型中，也可能会出现其他转变。 当董事会或其他高管团队制定 5 到 10 年的业务计划时，这些计划通常包括调整运营模式的要求（明确或隐含）。 运营模式是指导决策的良好参考。 这些模型可能会更改或需要自定义以满足你的要求和约束。
责任一致性
许多团队和个人负责支持不同的功能。 但每个常见的作模型都会将决策结果的最终责任分配给一个团队或个人。 此方法会影响作模型的资金方式，以及为每个函数提供的支持级别。
| 分散式运营 | 集中式运营 | 企业操作 | 分布式操作 | |
|---|---|---|---|---|
| 业务一致性 | 工作负载团队 | 中央云策略 | CCoE | 可变 - 组建庞大的云策略团队？ |
| 云操作 | 工作负载团队 | 中央 IT | CCoE | 评估云管理 |
| 云治理 | 工作负载团队 | 中央 IT | CCoE | 多层治理 |
| 云安全 | 工作负载团队 | 安全运营中心（SOC）/ DevSecOps 职能 | CCoE + SOC | 混合 - 参见 定义安全策略 |
| 云自动化和 DevOps | 任务分配团队 | 中央 IT 或不适用 | CCoE | 评估云管理 |
加速 Azure 中的运营模型实现
如在 定义您的运营模型中讨论的那样，云采纳框架的每种方法都为开发您的运营模型提供了结构化路径。 这些方法可以帮助你克服阻碍，这些阻碍源于采用云操作模型的不足之处。
下表概述了加速您运营模型实现的方法。
| 分散式运营 | 集中式运营 | 企业操作 | 分布式操作 | |
|---|---|---|---|---|
| 起点 | Azure 架构良好的框架 (WAF) | Azure 登陆区域：“从小规模开始”选项 | Azure 登陆区域：CAF 企业规模 | 管理 Azure 云资产 |
| 迭代 | 专注于工作负载使团队能够在 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 自动化和做法，可加快工作负载团队的工作。 工作负载团队能够推动创新，并在这些护栏内做出决策。
- 标准化：集中防护栏和基础服务，在所有环境中创建一致性。
- 运营支持：需要集中运营支持的工作负荷被划分为具有稳定状态控制的环境。 职责分段和分离使工作负荷团队能够在自己的专用环境中对运营支持负责。 自动化云原生工具可为具有集中式操作支持的所有环境提供最低操作基线保证。
- 专业知识：集中核心服务，例如安全、风险、治理和运营，可确保适当的中心专业知识。 清理流程和规范措施使工作负载团队能够做出更详细的决策。 这些决定增强了专家的集中影响力，无需与技术规模线性增加员工。
- 登陆区域设计：登陆区域设计复制项目组合的需求，从而创建明确的安全、治理和责任边界。 在云中运行工作负载需要这些边界。 分段做法不太可能类似于前面数据中心设计创建的约束。 在企业运营中，登陆区域设计不太复杂，能够更快地缩放和降低自助服务需求的障碍。
- 基础实用程序：基础实用工具托管在单独的中央控制的订阅中，称为平台基础。 然后，中央工具作为实用工具服务通过管道进入每个登陆区域。 将基础公用事业与登陆区域分开可最大程度地提高一致性和规模经济性。 这些实用工具还明确区分了集中管理的责任和工作负载级别的责任。
- 职责分离：基本公用事业与登陆区域之间的职责明确分离是运营方法中最大的优势之一。 云原生工具和流程支持集中式团队和工作负荷团队之间的访问，并在控制权上实现适当平衡。 此方法基于单个登陆区域的要求，以及登陆区域分隔区中托管的工作负载的要求。
企业运营的缺点
- 成本管理：中央团队更依赖工作负载团队在登陆区域中进行生产更改。 这种转变增加了预算超支的风险，并放缓了实际支出调整的速度。 成本控制流程、明确的预算、自动化控制和定期评审必须提前到位，以避免成本意外。
- 责任：企业运营需要更大的文化和运营要求。 这些要求可确保中心团队和工作负荷团队之间的责任和责任明确。
- 传统的变更管理流程或变更咨询委员会（CABs）可能无法在此运营模型中达到所需的速度和平衡。 这些流程反映在安全扩展云采用的过程和流程的自动化中。
- 缺乏改变的承诺首先在谈判和责任协调中实现。 无法就责任变更达成一致，表明在短期云采用过程中可能需要中央 IT 运营模式。
- 标准化：缺乏集中化的规章制度投资或自动化系统，带来了标准化的风险，这些风险通过手动审查过程难以克服。 登陆区域和共享服务中的工作负荷之间的作依赖关系会产生更大的风险。 这些风险源自于升级周期中的标准化，或者是未来版本的基础实用工具。 在平台基础修订期间，所有受支持的着陆区域及其托管的工作负载需要进行改进测试，甚至自动化测试。
- 运维支持：通过自动化和集中化运维提供的运行基线可能足以满足低影响或低关键性工作负荷。 但是，对于复杂或高关键性工作负荷，可能需要工作负荷团队或其他形式的专用操作。 如果是这样，它可能会产生运营预算的转变，要求业务部门为这些形式的高级运营提供运营费用。 如果需要集中 IT 来保持对运营成本的唯一责任，则企业运营可能难以实施。
- 专业知识：中心 IT 团队成员可能被要求开发在自动化中心控制方面的专业知识，而这些控制以前是通过手动流程交付的。 此外，这些团队可能会掌握基础设施即代码的方法以定义环境，并了解分支、合并以及部署管道的流程。 至少，平台自动化团队可能需要决策技能来了解云卓越中心或中心运营团队做出的决策。 工作负荷团队可能需要开发与控制其决策的控件和流程相关的更多知识。
- 登陆区域设计：登陆区域设计依赖于基础实用工具。 工作负荷团队应了解设计中的内容以及禁止包含的内容。 这种理解可能有助于避免重复工作、错误或冲突。 若要提高灵活性，可以在登陆区架构中加入异常处理流程。
- 基础实用程序：集中基础实用工具需要时间。 这些实用设施或服务最终会考虑各种选项，并开发出能够扩展以满足不同应用计划的解决方案。 早期采用工作可能会发生延迟。 由于流程后期的加速和回避障碍措施，延迟可能会在长期内被抵消。
- 职责分离：确保职责明确分离需要成熟的标识管理流程。 在正确协调用户、组和加入和脱离活动时，可能会有更多相关的维护。 可能需要采用新的流程来适应通过提升的权限实现的实时访问。
分布式操作
现有作模型可能过于根深蒂固，无法让整个组织转向新的运营模型。 对于其他业务，全局运营和各种合规性要求可能会阻止特定业务部门进行更改。 在这种情况下，可能需要分布式操作方法。 这种方法是迄今为止最复杂的，因为它需要集成一个或多个前面提到的作模型。
尽管强烈建议不要这样做，但某些组织可能需要这种作方法。 这种方法主要与组织有松散的业务部门、不同的客户细分市场或区域运营基础的组织有关。
- 优先级：整合多个现有操作模型。
- 在过渡状态，重点是将整个组织迁移到前面提到的操作模型之一。
- 当组织规模过大或过于复杂，无法与单一运营模型保持一致时，需要采取长期的运营策略。
- 不同的优势：集成每个业务部门的常见运营模型元素。 此方法创建一种将运营单元分组到层次结构中的工具，以帮助它们通过一致的可重复流程来成熟运营。
- 明显的劣势：跨多个运营模型的一致性和标准化难以长时间保持。 这种作方法需要深入了解投资组合以及技术组合的各个部分如何运作。
- 风险：缺乏对主运营模型的承诺可能会导致团队之间的混乱。 如果无法与单一操作模型保持一致，请使用此操作模型。
- 指导：从全面审查投资组合开始。 尝试按国家运营模式（分散、集中或企业）对投资组合进行分组。
- 建立体现运营模式分组的管理组层次结构。 此安排包括针对区域、业务部门或其他标准的组织模式，将工作负载群集从最不常见的类别映射到最常见的类别。
- 评估工作负载与操作模型是否匹配，找出最相关的操作模型群集并从它入手。 对于节点和管理组层次结构下的所有工作负载，按照其相应操作模型的对应指导进行操作。
- 使用治理和管理方法查找常见的公司策略，包括层次结构的各个点所需的运营管理做法。 应用常见的 Azure 策略以自动执行共享企业策略。
- 使用各种部署测试 Azure 策略时，尝试在管理组层次结构中将其上移。 这些策略可以应用于许多工作负载，它们可能会发现共同之处和不同的操作需求。
- 随着时间的推移，此方法可能有助于定义一个能够跨多种运营模型进行扩展的模型。 此方法还可以通过一组常见策略和过程统一团队。
我们故意将此方法的优势和劣势留空。 完成项目组合的业务一致性后，请参阅上面的主要运营模型部分，以清楚地了解优点和缺点。
后续步骤
学习与运营模型相关的术语。 术语可帮助你了解运营模型如何适应企业规划的更大主题。
了解着陆区如何为任何云应用环境提供基本的构建模块。