你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
云管理中的平台运营
跨越清单和可见性、运营符合性以及数据保护和恢复的云管理基线可为 IT 组合中的大多数工作负载提供级别充分的云管理。 但该基线很少足以支持整个项目组合。 本文提供云管理、组合运营中最常见的下一步介绍。
IT 项目组合中资产的快速研究重点介绍了受支持工作负载的现有模式。 在这些工作负载中，有一些常见的平台。 根据公司内部过去的技术决策，平台可能会有很大差异。
对于某些组织来说，严重依赖SQL Server、Oracle 或其他开源数据平台。 在其他组织中，这种共性可能源于虚拟机 (VM) 或容器的托管平台。 另外，其他组织可能对应用程序或企业资源规划 (ERP) 系统（如 SAP 或 Oracle）有共同的依赖性。
了解这些共性后，云管理团队可以专门提供对这些优先平台的更高级别的支持。
建立服务目录
平台运营的目标是创建可靠且可重复的解决方案，供云采用团队使用。 然后，云采用团队可以提供一个提供更高级别的业务承诺的平台。 这种承诺可能会减少停机的可能性或频率，从而提升可靠性。 如果出现系统故障，该承诺还有助于减少数据丢失量或恢复时间。 此类承诺通常包括持续提供一致运营来支持平台。
随着云管理团队建立与特定平台相关的更高级别的运营管理和专业化，他们将平台添加到不断增长的服务目录中。 服务目录在特定配置中提供自助服务平台部署，该配置遵循正在进行的平台操作。 在业务一致性对话期间，云管理和云策略团队可以为业务提出服务目录解决方案。 服务目录解决方案在受控、可重复的进程中提高了可靠性、运行时间和恢复承诺。
作为参考，有些组织会将早期的服务目录称为“批准列表”。 主要区别在于，服务目录与云卓越中心 (CCoE) 的持续性运营承诺一并提供。 批准的列表类似。 它提供团队可在云中使用的解决方案的预先批准列表。 但通常没有与已批准列表上的应用程序关联的操作权益。
与集中式 IT 和 CCoE 之间的争论很像的是，差异是其中一个重点争论对象。 服务目录的用途是有益的，而且其提供的运营、治理和安全护栏有助于加速创新。 在通过解决方案的操作、合规性和安全入口之前，批准的列表会阻碍创新。 这两种解决方案都是可行的，但也要求公司精细地决定优先执行顺序，以便在创新或符合性方面进行更多投资。
生成服务目录
云管理极少成功地在接收器上传递服务目录。 正确地开发目录需要跨中心 IT 团队或 CCoE 建立合作关系。 当 IT 组织达到 CCoE 成熟度级别时，此方法往往最成功，但可以更快地实现。
当云平台团队在 CCoE 模型中生成服务目录时，他们会生成所需的状态平台。 云治理和云安全团队会验证部署中的治理和符合性。 云管理团队要为该平台建立持续性运营。 云自动化团队要打包平台，以进行可缩放、可重复的部署。
打包平台后，云管理团队可以将其添加到不断扩充的服务目录中。 从那里，云采用团队在部署期间使用包或目录中的其他包。 在解决方案投入生产后，业务可以实现提高运营管理的额外优势，并有可能减少业务中断。
注意
构建服务目录需要付出大量精力和时间来处理多个团队。 使用服务目录或已批准列表作为门控机制会减慢创新速度。 当创新是优先事项时，请与其他采用工作并行开发服务目录。
定义你自己的平台运营
尽管管理工具和流程可以改进平台操作，但往往不足以实现所需的稳定性和可靠性状态。 真正的平台操作需要专注于卓越体系结构的支柱。 如果平台进一步投资运营属于合理行为，请在该平台成为任何服务目录的一部分之前，考虑以下五大支柱：
- 可靠性： 进行系统设计，使其从故障中恢复并继续正常运行。
- 安全性： 保护应用程序和数据免受威胁。
- 成本优化： 管理成本，将提供的价值最大化。
- 卓越运营： 遵循操作流程，让系统在生产环境中持续运行。
- 性能效率： 缩放系统，适应负载中的变化。
Microsoft Azure Well-Architected框架提供了一种评估特定工作负载是否符合这些支柱的方法，以改善整体运营。 可以将这些支柱应用于平台操作和工作负载操作。
特定平台入门
下一部分中讨论的平台是典型 Azure 客户普遍使用的一种平台，他们可以轻松证明对于平台运营的投资是合理的。 当云管理团队构建出平台运营要求或完整的服务目录时，往往就会开始使用这些平台。
PaaS 数据操作
数据通常是保证平台运营投资的第一个平台。 当数据托管在平台即服务 (PaaS) 环境中时，业务利益干系人倾向于请求降低恢复点目标 (RPO) 以尽可能减少数据丢失量。 根据应用程序的性质，他们可能还会请求减少目标恢复时间 (RTO)。 在任一情况下，支持基于 PaaS 的数据解决方案的体系结构都可以轻松地适应一些更高级别的管理支持。
在大多数情况下，即使对于非任务关键型应用程序，改进管理承诺的成本也很容易证明。 对平台运营的此类改进非常常见，但许多云管理团队将其视为增强基线，而不是真正的改进平台运营。
IaaS 数据操作
将数据托管在传统基础结构即服务 (IaaS) 解决方案中时，改进 RPO 和 RTO 的工作量可能会更高。 然而，业务利益干系人对实现更佳管理承诺的愿望很少会受到 PaaS 和 IaaS 决策的影响。 如有受到影响，了解架构中的根本差异可能会促使企业要求 PaaS 解决方案或承诺与 PaaS 解决方案上可用的内容相匹配。 考虑将任何 IaaS 数据平台现代化作为平台操作的第一步。
如果不选择实现现代化，云管理团队通常会将基于 IaaS 的数据平台的优先级划分为服务目录中的第一项必需服务。 为企业提供独立数据服务器和集群、高可用性数据解决方案等选择，使业务承诺对话更容易促进。 对运营改进和成本增加的基本了解有助于企业为其业务流程和支持工作负载做出最佳决策。
其他常见平台运营
除数据平台以外，虚拟机主机通常也是一种常见的运营改进平台。 云平台和云管理团队通常投资改进 VMware 主机或容器解决方案。 此类投资可以提高支持 VM 的主机的稳定性和可靠性，进而为工作负载提供动力。 在一个主机或容器上正确操作可以提高多个工作负载的 RPO 或 RTO。 此方法可创建改进的业务承诺，但可分配投资。 将改进的承诺和降低的成本进行结合论证，更容易证明改进云管理和平台运营的合理性。
后续步骤
在改进平台运营的同时，云管理团队还专注于改进前 20% 或更少的生产工作负载的工作负载操作。