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

应用设计原则和高级操作

  • 项目

头三项云管理规则介绍管理基线。 管理基线至少应包括标准业务承诺，以便最大程度地减少业务中断并在服务中断时更快恢复。 大多数管理基线都包含一个侧重于维护清单和可见性、操作合规性以及保护和恢复的规则。

管理基线的目的是创建一致的产品/服务，为所有受支持的工作负荷提供最低级别的业务承诺。 借助这个通用的、可重复管理产品/服务基线，团队可在尽量减少偏差的情况下提供高度优化的运营管理水平。 但是，该标准产品/服务可能不会为企业提供足够丰富的承诺。

下一部分中的关系图演示了超出管理基线的三种方法。

管理基线应满足项目组合中 80% 的最低临界工作负载所要求的最低承诺。 基线不得应用于任务关键型工作负载， 也不得应用于跨工作负载共享的常见平台。 这些工作负载需要专注于设计原则和高级操作。

高级操作选项

建议了三种路径来改进超出管理基线的业务承诺，如下图所示：

高级操作

增强型管理基线

如 Azure 管理指南所述，增强的管理基线使用云原生工具来提高运行时间并缩短恢复时间。 这些改进很显著，但又不如工作负载或平台专用化那样显著。 增强的管理基线的优点是，既显著降低，又显著缩短实现时间。

管理专用化

工作负载和平台运营的各个方面可能要求对设计和体系结构原则进行更改。 这些更改可能需要时间，并且可能导致运营开销增加。 若要减少需要此类投资的工作负荷的数目，可以使用能够对业务承诺提供足够改进的增强型管理基线。

对于需要增加投资来满足业务承诺的工作负载，操作专用化是关键。

管理专用化方面

专用化有两个方面：

  • 平台专用化：投资共享平台正在进行的操作，将投资分散到多个工作负载。
  • 工作负载专用化：投资特定工作负载正在进行的操作，通常保留给任务关键型工作负载。

中央 IT 团队或云卓越中心 (CCoE)

决定采用平台专用化还是工作负载专用化取决于每个工作负载的关键性和影响。 但是，这些决策也表明中央 IT 团队与 CCoE 组织模型之间更大的文化决策。

工作负荷专用化通常会触发文化变革。 传统 IT 和集中式 IT 都构建可大规模提供支持的生成过程。 对于管理基线、增强型基线，甚至是平台运营中的可重复服务，缩放支持更加可行。 工作负载专用化通常不进行缩放。 缺乏缩放能力使得集中式 IT 组织很难在不达到组织规模限制的情况下提供必要的支持。

或者，云卓越中心方法通过有目的的责任委派和选择性中心化进行缩放。 工作负载专用化往往能够与 CCoE 的委托责任方法更好地保持一致。

CCoE 中固有的角色协调概述如下：

  • 云平台团队帮助构建支持多个云采用团队的常见平台。
  • 云自动化团队将这些平台扩展到服务目录中的可部署资产中。
  • 云管理团队集中提供管理基线，并帮助支持对服务目录的使用。
  • 但是，业务部门（采用业务 DevOps 团队或云采用团队的形式）负责工作负载、管道或性能的日常操作。

至于协调管理领域，中央 IT 团队和 CCoE 模型通常可在平台专用化之上交付，在文化上的改变最小。 对于中央 IT 团队来说，在工作负载专用化上进行交付可能更加复杂。

管理专用化过程

在每个专用化中，通过严格的迭代的方法提供下面的四步流程。 此方法需要云采用专家、云平台专家、云自动化专家和云管理专家相互合作，来创建可行且明智的反馈循环。

  • 改进系统设计：改进常见系统（平台）或特定工作负载的设计，有效地尽量减少中断。
  • 自动修正：某些改进并不经济高效。 在这种情况下，自动修正和减少中断的影响可能更有意义。
  • 缩放解决方案：改进系统设计和自动修正后，可通过服务目录将这些更改扩展到整个环境。
  • 持续改进：可使用各种监视工具来发现增量改进，从而在系统设计、自动化和缩放的下一阶段中解决。

改进系统设计

若要改进任何常用平台的运营，改进系统设计是最有效的方法。 系统设计改进可帮助提高稳定性并减少业务中断。 单个系统的设计超出了在整个云采用框架中使用的环境视图的范围。

作为该框架的补充，Microsoft Azure 架构良好的框架提供了提高平台或特定工作负载的质量的指导原则。 该框架侧重于对卓越架构的五大支柱进行改进：

  • 成本优化： 管理成本，将提供的价值最大化。
  • 卓越运营： 遵循操作流程，让系统在生产环境中持续运行。
  • 性能效率： 缩放系统，适应负载中的变化。
  • 可靠性： 进行系统设计，使其从故障中恢复并继续正常运行。
  • 安全性： 保护应用程序和数据免受威胁。

大多数业务中断实际上是某种形式的技术欠债或体系结构缺陷。 对于现有部署，系统设计改进可以说是对现有技术欠债的清偿。 对于新部署，系统设计改进可以说是为了避免技术欠债。 下一部分演示如何处理无法或不该处理的技术债务。

要改进系统设计，请详细了解 Microsoft Azure 架构良好的框架。 在系统设计改进后，请回来阅读本文，看看是否有新的机会来进行改进并将改进扩展到整个环境。

自动修正

某些技术欠债无法或不应该处理。 解决问题的开销可能过于昂贵。 可进行规划，但项目持续时间可能很长。 业务中断可能不会造成重大的业务影响，但业务优先事项是进行快速恢复，而不是在复原能力上投入。

如果不需解决技术欠债，则通常情况下，下一步需进行自动修正。 使用 Azure 自动化和 Azure Monitor 来检测趋势并提供自动修正是最常用于自动修正的方法。

有关自动修正的指南，请参阅 Azure 自动化和警报。

通过服务目录扩展解决方案

平台专用化和平台运营的基石是管理良好的服务目录。 这是改进系统设计并将修正扩展到整个环境的方式。 云平台团队和云自动化团队可以合作创建适用于任何环境中的最常用平台的可重复解决方案。 但是，如果这些解决方案未得到一致的应用，那么云管理只能提供基线产品/服务。

对于任何已经过优化的平台，若要最大限度提高采用率并尽量降低维护开销，应将平台添加到服务目录。 目录中的每个应用程序在部署后可以通过服务目录供内部使用，也可以以市场产品/服务的形式供外部消费者使用。

若要了解如何发布到服务目录，请参阅有关如何发布到服务目录的系列文章。

持续改进

平台专用化和平台运营均依赖于采用、平台、自动化和管理团队之间的强大反馈循环。 这些反馈循环基于数据，使每个团队都能进行明智的决策。 如果希望平台运营能够实现长期业务承诺，必须使用特定于中心化平台的见解。 两个最常用的集中管理平台是容器和 SQL Server，因此可考虑查看以下文章，从持续改进数据收集开始：