常见运营模型
在本单元中，你将查看常见的运营模型，以了解哪种模型最符合 Tailwind Traders 叙述。 还将了解如何评估和映射最适合你的云采用计划的运营模型。 此信息将有助于选择最相关的 Azure 登陆区域，以开始构建云环境。
常见运营模型
在云采用工作中，有以下四种常见的运营模型。 学习这些常见运营模型可以塑造有关环境设计和配置的对话。 每个运营模型都映射到一个或多个 Azure 登陆区域，以加快初始部署。
以下特征有助于与一种常见运营模型保持一致：
策略优先级：当采用云时，创新、控制（优化运营）、大众化（自治）和集成都是重要的战略优先任务。 与执行层利益干系人交谈时，他们认为对贵公司而言，未来三到五年中最重要的因素是什么？
组织：人员的组织推动了部分运营决策。 你是否有一个小型 IT 团队来为所有项目组合提供支持？ 是否有专门负责安全、治理和运营等职能的独立团队？ 团队是否围绕具体的工作负载进行组织？ 你是否受（经审核员或其他合规性机构审查的）严格的第三方合规性标准约束？
项目组合范围：项目组合的大小和运营的重点是每个运营模型的重要注意事项。 你是否管理复杂的大型多云工作负载组合？ 单个云平台是否可以支持项目组合？ 是否所有工作负载都需要在单个生产订阅中运行？ 你是否重点关注特定于工作负载的操作，而没有中心支持？ 可在项目组合层次结构文章中详细了解这些术语。
问责（职责分离）：在技术方面，总有可能出错的地方。 这就是几乎没有团队注册 100% 运行时间 SLA 的原因。 当工作中断或未按预期执行时，谁负责救急？ 谁负责主动修复以最大程度地减少停机时间？ 谁负责云经济和持续预算？ 问责以及相关联的访问要求推动了一些环境设计决策。
标准化：将网络、标识和安全等基础实用工具标准化可节省有形成本，并减少专门针对各项工作的人力投入。 实用工具或共享资源的标准化有多重要？
运营优先级：在现代化运营中，运营团队通常会选择云优先服务作为运营支持的主要形式。 或者，如果现有的本地工具是团队需要的主要运营工具，那么云可以是扩展或辅助运营模型。 展望未来，你是否希望看到运营和支持工具都变为云优先？ 你是否会继续使用现有工具来扩展到云？ 是否正在寻找可以无缝混合公有云和私有云运营的统一运营方法？
平台开发速度：工作负载需要其自己的资产，这会创建直接的工作负载环境。 除了直接支持资产外，还有不同程度的前期投资。 你希望投入多大精力来构建和维护将跨工作负载共享的基础实用工具（如网络和标识）？ 应在投入多少前期工作来建立集中的云基础，以跨多个登陆区域共享这些实用工具？
分散运营
最简单的运营模型是完全分散的模型。 此模型高度关注独立工作负载，对集中运营的依赖性最小。 此模型也称为双模 IT 或分散 IT。
战略优先级：组织在认为创新优先于控制时通常会使用分散运营。 此模型在初创企业中很常见，在大型组织中也呈现日益增长的趋势。
组织：围绕工作负载或业务流程组织团队，这与其他三种运营模型形成对比。
项目组合范围：项目组合的范围也独立于工作负载级别。 组织完全分散时，该组织就不太可能投入大量时间来进行项目组合对齐的管理。
问责（职责分离）：工作负载团队全权负责运营、治理和安全决策。 分散运营没有共享的责任模型。
标准化：最佳做法和部署自动化（持续集成/持续交付管道）对于跨工作负载创建任何程度的标准化都至关重要。 但如果没有集中功能，标准化可能就不持久。
运营优先级：分散运营团队更有可能使用服务型软件 (SaaS) 或平台即服务 (PaaS) 工具来确定云优先运营的优先级，以自动化运营。
平台开发速度：分散运营可能会跨工作负载共享部署脚本，但不会或几乎不会跨工作负载共享中心资源。
集中运营
集中模型是 IT 中最常见的运营模型。 此模型高度关注仅由集中运营管理的受控生产环境。 集中运营专注于使用嵌入式基础实用工具的少量登陆区域。
对于非生产环境的管理，各组织的做法截然不同。 但在集中运营模型中，即使非生产环境也很可能受到治理和安全要求的约束。
战略优先级：当对业务的控制和业务稳定性比创新更重要时，组织常趋向于选择此模型。 大型组织或稳定组织通常使用集中运营。 当第三方合规性要求驱动环境决策时，此模型很常见。
组织：首先围绕职能或流程组织团队。 在较小的组织中，专注于安全、治理、运营和基础结构的团队成员属于中心 IT 部门。 随着组织的发展，这些职能部门可能会发散出专门负责每项职能的团队。
项目组合范围：集中运营团队倾向于重点关注一个或少量登陆区域。 在这些登陆区域内，组织将部署基础实用工具，以支持每个登陆区域中的工作负载组合。 当组织支持稳健云基础和多云项目组合时，此运营模型往往带来规模挑战。
问责（职责分离）：在此运营模型中，中心 IT 或中心运营团队通常会对生产中的所有资产负责。 职责分离往往重点关注环境隔离，这会让特定于工作负载的团队无法与生产资产进行交互。
标准化：跨工作负载的标准化可能要求很高。 但是，随着项目组合增长到跨越多个登陆区域或多个云平台，该标准化可能会崩溃，需要对环境进行重大修改。
运营优先级：当组织将其云运营模型视为辅助运营模型时，他们通常使用集中运营。 由于现有的本地或私有云运营是主要模型，因此这些组织往往会延续使用现有运营工具，并限制现代云优先运营工具的主要用法。
平台开发速度：中心运营团队通常需要通过从小规模开始的方法来处理常见实用工具。 随着时间的推移，该团队会致力于将同类最佳的解决方案构建到环境中。
企业运营
对于将整个数据中心或大型项目组合迁移到云的客户，企业模型比较合适。 企业运营重点关注将更多使用基础实用工具的登陆区域集中到一个平台基础。
战略优先级：企业模型重点关注决策大众化和委托责任，以平衡某些登陆区域的创新需求和其他登陆区域的严格控制。 这是战略优先级，适用于既需要保护现有利益，又需要推动创新以与市场变化保持同步的大型组织。
组织：企业运营为每个工作负载团队提供构建和运营能力。 工作负载团队按职能（如治理、安全和运营）划分。 专职的卓越云中心 (CCoE) 团队联合工作负载团队和支持团队，以协调活动并帮助确保云基础上的卓越运营。
项目组合范围：企业运营的范围集中在全面的云基础上，可确保集中基础实用工具且适用于所有登陆区域。 然后，可以部署登陆区域和专用工作负载环境，使用包含提供所有必需依赖项的云基础的自助服务容量。
问责（职责分离）：CCoE 团队负责维护必要的集中资源，并使整个项目组合可见。 中心运营或特定于工作负载的运营团队负责对单个工作负载进行日常支持。
标准化：在此运营模型中，标准化的要求最高。 集中云基础确保所有登陆区域设计领域的配置一致。 可靠的最佳做法倾向于自动部署所有工作负载。 此自动化允许在工作负载和资产级别实现进一步标准化。
运营优先级：企业运营模型需要云优先的运营方法。 第一方基于云的工具对于维护云中的集中运营至关重要。 这种类型的模型必须将云视为主要的运营模型才会有效。 组织将本地运营视为辅助运营，并且应它们包含在长期过渡计划中。
平台开发速度：为了鼓励实现快速增长的工作负载组合的治理、安全和运营，企业运营团队需要先实施企业解决方案，然后再采用它。
分布式运营
分布式模型是最复杂的运营形式。 它混合了其他模型。
此方法常见于以下情况：公司通过快速收购来发展壮大，产生前三种运营模型的分布式组合。 公司可能会长期处于这种状态。 但为了最大程度地减少冗余和提高运营效率，他们应考虑制定计划以过渡到一个较简单的模型。
战略优先级：当组织偏向于整合收购的业务单元而不是进行创新或控制时，会使用此模型。 这通常是未来迁移到更高效的运营模型所需的临时或过渡策略。 当组织想要维护自治并考虑近期退出策略时，此模型倾向于保持不变，这在私人股本或控股公司中很常见。
组织：组织的集中结构在运营模型中难以维护。 对于组织而言，在此过程的早期开始组建 CCoE 虚拟团队，以在组织中创建对运营的可见性和认知是明智的做法。
项目组合范围：分布式运营重点关注复杂的项目组合。 随着时间的推移，该重点可能会缩小，以应对更精细的项目组合级别。
问责（职责分离）：问责因业务部门而异。 从中心角度来看，职责分离难以实现。
标准化：在分布式运营模型中，实现标准化的第一步是清晰了解整个项目组合的数字资产。 数据驱动的方法首先是确定项目组合中倾向于集中或企业运营模型的共性。
运营优先级：此模型中的运营优先级以数据为中心。 使用专为统一运营而设计的工具来集中数据，可让 CCoE 团队在过渡或成熟工作期间指导和带领各个业务部门。 在强制执行一致的运营优先级之前，请评估工作负载操作的项目组合，以确保合适的工具和基线。
平台开发速度：评估工作负载操作的项目组合时，应确定可接受的平台开发速度，以使其与从小规模开始或企业规模方法一致。 确定方向的主数据点将取决于整个项目组合中最常用的运营管理方法。