你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
适合云管理的平台专用化
平台专用化是标准管理基线的扩展,这一点十分类似于增强型管理基线。 请查看下面的图和列表,其中显示了如何通过多种方式来扩展管理基线。 本文探讨平台专用化选项。
- 工作负荷运营: 最大的单工作负荷运营投资和最高的复原度。 建议对 20% 左右的可以推动业务价值产生的工作负荷进行工作负荷运营。 此专用化通常为重要性很高的工作负荷或关键工作负荷保留。
- 平台运营: 运营投资跨多个工作负荷。 复原能力的改进影响所有使用已定义平台的工作负荷。 建议对 20% 左右的重要性最高的平台进行平台运营。 此专用化通常为重要性为中到高的工作负荷保留。
- 增强型管理基线: 运营投资相对而言最低。 此专用化使用其他云原生运营工具和流程略微改进了业务承诺。
工作负荷和平台的运营都需要对设计和体系结构原则进行更改。 这些更改可能需要时间,并可能导致运营开销增加。 若要减少需要此类投资的工作负荷的数目,可以使用能够对业务承诺提供足够改进的增强型管理基线。
下表概述了在客户的增强型管理基线中常见的一些流程、工具和潜在效果:
进程 | 工具 | 目的 | 建议的管理级别 |
---|---|---|---|
改进系统设计 | Microsoft Azure 架构良好的框架 | 改进平台的体系结构设计,以便改进运营 | 空值 |
自动修正 | Azure 自动化 | 通过特定于平台的自动化来响应高级平台数据 | 平台运营 |
服务目录 | 托管应用程序中心 | 提供一个自助服务目录,其中包含符合组织标准的已审批解决方案 | 平台运营 |
容器性能 | 用于容器的 Azure Monitor | 对容器进行监视和诊断 | 平台运营 |
平台即服务 (PaaS) 数据性能 | Azure SQL 分析 | 针对 PaaS 数据库的监视和诊断 | 平台运营 |
基础结构即服务 (IaaS) 数据性能 | SQL Server 运行状况检查 | 针对 IaaS 数据库的监视和诊断 | 平台运营 |
概要流程
平台专用化要求以迭代方式严格执行以下四个流程: 本文后续部分对每个流程进行了更详细的说明。
- 改进系统设计: 改进常用系统或平台的设计,以有效方式尽量减少中断。
- 自动修正: 某些改进没有成本效益。 在这种情况下,自动进行修正并降低中断的影响可能更有意义。
- 扩展解决方案: 改进系统设计和自动修正以后,即可通过服务目录将这些更改扩展到整个环境。
- 持续改进: 可以使用不同监视工具来发现增量改进。 可以在下一轮系统设计、自动化和扩展过程中实施这些改进。
改进系统设计
若要改进任何常用平台的运营,改进系统设计是最有效的方法。 通过改进系统设计,可以提高稳定性,减少业务中断。 单个系统的设计超出了在整个云采用框架中使用的环境视图的范围。
作为该框架的补充,Microsoft Azure 架构良好的框架提供了提高平台或特定工作负载的质量的指导原则。 该框架侧重于对卓越架构的五大支柱进行改进:
- 成本优化: 管理成本,将提供的价值最大化。
- 卓越运营: 遵循操作流程,让系统在生产环境中持续运行。
- 性能效率: 缩放系统,适应负载中的变化。
- 可靠性: 进行系统设计,使其从故障中恢复并继续正常运行。
- 安全性: 保护应用程序和数据免受威胁。
技术债务和体系结构缺陷导致了大多数业务中断。 对于现有部署,系统设计改进可以说是对现有技术债务的清偿。 对于新的部署,这些改进可以说是为了避免技术债务。
接下来的“自动修正”标签介绍了如何通过相关方式来修正无法解决或不应解决的技术债务问题。
要改进系统设计,请详细了解 Microsoft Azure 架构良好的框架。
在系统设计改进以后,请回过头来阅读此文章,看看是否有新的需要改进并扩展到整个环境的东西。
自动修正
某些技术欠债无法解决。 解决方法可能因过于昂贵而无法纠正,或者可以进行计划,但项目持续时间过长。 可能业务中断没有造成明显的业务影响, 也可能从业务角度来看需要优先进行快速恢复,而不是投资于复原能力。
如果不需解决技术债务,则通常情况下,下一步会进行自动修正。 使用 Azure 自动化和 Azure Monitor 来检测趋势并提供自动修正是最常用于自动修正的方法。
有关自动修正的指南,请参阅 Azure 自动化和警报。
通过服务目录扩展解决方案
管理良好的服务目录是平台专用化和平台运营的基石。 使用目录是改进系统设计并将修正扩展到整个环境的方式。
云平台团队和云自动化团队可以合作创建适用于任何环境中的最常用平台的可重复解决方案。 但是,如果这些解决方案的使用方式不一致,则云管理只能提供基线产品/服务。
对于任何优化的平台,若要在尽量使用它的同时尽量降低其维护开销,则应将该平台添加到 Azure 服务目录。 目录中的每个应用程序在部署后可以通过服务目录供内部使用,也可以以市场产品/服务的形式供外部消费者使用。
若要了解如何发布到服务目录,请参阅有关如何发布到服务目录的系列文章。
从服务目录部署应用程序
- 在 Azure 门户中,转到“托管应用程序中心(预览)”。
- 在“浏览”窗格中,选择“服务目录应用程序”。
- 单击“+ 添加”,从公司的服务目录中选择一个应用程序定义。
你维护的任何托管应用程序都会显示。
管理服务目录应用程序
- 在 Azure 门户中,转到“托管应用程序中心(预览)”。
- 在“服务”窗格中,选择“服务目录应用程序”。
你维护的任何托管应用程序都会显示。
持续改进
平台专用化和平台运营均依赖于采用、平台、自动化和管理团队之间的强大反馈循环。 这些反馈循环基于数据,有助于每个团队进行明智的决策。 如果希望平台运营能够实现长期业务承诺,则必须使用特定于中心化平台的见解。
容器和 SQL Server 是两个最常用的集中管理平台。 可参阅以下文章,了解如何在这些平台上开始进行持续改进数据的收集: