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

建立操作管理过程

  • 项目

随着企业开始在 Azure 中操作工作负载，下一步是建立操作管理和适应过程。 此过程枚举、实现和迭代评审并优化这些工作负载的操作状态。

操作适用性评审过程可确保整个工作负载组合满足对性能、可靠性和成本的业务承诺。 此过程协调中心 IT、云卓越中心和工作负载团队的工作，实现大规模卓越运营。

建立操作适用性评审的核心过程

创建操作适用性评审过程，以完全了解在生产环境中运行工作负载导致的问题，以及如何修复和解决这些问题。 本文概述了可供需要实现此目标的企业使用的高级操作适用性评审过程。

Microsoft 的操作适用性

从一开始，Microsoft 的许多团队就参与了 Azure 平台的开发。 对于大规模和复杂性高的项目，很难确保质量和一致性。 需要一个可靠的过程来定期枚举和实现基本的非功能要求。

Microsoft 遵循的流程构成了本文所述流程的基础。

了解角色和操作模型

操作管理是一门涉及公司多个角色的广泛学科。 根据组织操作模型，这些角色可以在矩阵环境中运行，在集中运营团队和分散运营团队之间进行多次切换。

  • “中心 IT/CCoE：”此集中式技术功能负责技术组合中所有技术资产的配置、运营、治理和安全性。
  • “云操作：”该操作功能是集中式技术组织中的一项功能，用于管理技术组合的运行状况和运营。 他们负责确保过程顺利运行，确保过程中每个相邻角色具有必要的工具，并且每个后续角色都应对此过程的预期负责。
  • “云策略：”提供业务知识以确定承诺并确定其优先级，来维护各种工作负载的操作要求。 此角色还会对补救成本与业务影响进行比较，推动补救决策的最后达成。
  • “工作负载团队：”负责开发和运营映射到特定支持应用程序、服务和基础结构（无论是本地还是云中）的工作负载。 该角色需要深入了解工作负载体系结构。

每个组织的运营模型确定上述角色的责任和日常活动：

  • “集中式运营：”中心 IT 部门对运营保有全部责任。 工作负载所有者可以输入操作和配置，但无法访问更改生产环境。 只有中心 IT 和云运营才能提供运营变更以提高操作适用性。
  • “分散运营：”工作负载团队对运营负有全责，通常是通过成熟的 CI/CD 管道和 DevOps 自动化进行。 在此模型中，没有对配置、操作、治理或安全性的中心支持。 这种操作方法超出了云采用框架的范围。 此操作模型应参阅 Azure Well-Architected Framework，了解操作指南。
  • “Enterprise 运营：”卓越云中心负责运营。 云运营和工作负载团队各自对操作适用性的特定方面负责。

评审目标

使用几个指标（可靠性、性能和成本）跨项目组合来评估操作适用性。 这些属性共同允许快速评估项目组合中所有资产的运行状况和适用性。 这些指标在操作管理的三个层级中进行评估。

操作提升

  • “操作基线(或增强基线)：”评估所有已部署资产的操作适用性，无论其功能如何。 这种广泛的操作视图允许进行全面更改和产生重大影响，但受限于缺乏对各个工作负载的体系结构的可见性。 云中部署的所有资源都应由操作基线覆盖，并定期获得云运营的支持。 某些环境可能需要更高程度的运营支持来满足增强基线的需求。
  • “平台操作：”评估集中式技术平台的操作适用性。 这种操作视图更加完善，因为它考虑到了平台的体系结构，以及解决方案更改将如何影响操作适用性。 对中心技术平台的更改会对支持的工作负载产生广泛的下游影响。 所有任务关键型平台都应获得中心 IT 团队的专门支持。
  • “工作负载操作：”评估单个工作负载的操作适用性。 这种操作视图最优化，当操作适用性改进需要更改工作负载的体系结构时，应考虑这一点。 工作负载操作应遵循 Azure Well-Architected Framework 的原则。 具有活跃 DevOps 周期的所有任务关键型工作负载应获得工作负载团队的专门支持。

操作适用性评审的目标是定期评估所有级别的操作是否适合。 然后，可以在适当的级别应用已识别的改进，以通知管理整个项目组合所需的更改。

作适用性评审过程

若要维护企业项目组合的性能和连续性，关键是实现操作适用性评审过程。

操作适用性评审过程概述

此过程大致分为两个阶段。 在“先决条件阶段”，需确定要求并将其映射到支持服务。 此阶段出现频率较低：也许每年出现一次，或者在引入新操作时出现。 先决条件阶段的输出在流阶段使用。 流阶段出现频率更高，例如每月一次。

先决条件阶段

此阶段中的步骤捕获了定期评审项目组合和任何任务关键型工作负载的要求。

  1. 确定关键业务操作。 根据达成的业务承诺确定企业的任务关键型业务操作。 业务操作独立于任何支持服务功能。 换句话说，业务操作代表企业需执行的实际活动，受一组 IT 服务的支持。

    术语“任务关键型”（或“业务关键型”）反映了在操作受阻对业务的严重影响。 例如，在线零售商可能有一项业务操作，例如“使客户能够将商品添加到购物车”或“处理信用卡付款”。如果上述任一操作失败，客户无法完成交易，则企业无法实现销售。

  2. 将操作映射到服务。 将关键业务操作映射到支持它们的 IT 服务(基线、平台或工作负载操作)。 还应确定支持关键业务功能所需的任何技术平台或工作负载，以将操作和服务映射到负责的团队。

  3. 分析服务依赖关系。 大多数业务操作需要在多个支持工作负载和技术平台之间协调。 必须了解每组支持资产之间的依赖关系,以及通过这些服务进行的任务关键型事务流。

    另外还应考虑本地服务和 Azure 服务之间的依赖关系。 在购物车示例中，库存库存管理服务可能托管在本地，并获取员工从物理仓库中输入的数据。 但是，它可能会将非本地数据存储在 Azure 服务（例如 Azure 存储）或数据库（例如 Azure Cosmos DB） 中。

这些活动输出的是一组适用于操作管理的“记分卡指标”。 记分卡度量可靠性、性能和成本等条件。 记分卡指标显示你期望服务满足的操作条件。

记分卡应该以简单的术语表述，方便业务负责人、云运营和工作负载团队进行有意义的讨论。 例如，可靠性记分卡指标可能会根据达成商定的 SLA 进行颜色编码。 绿色表示符合定义的 SLA，黄色表示不符合定义的条件但主动执行修正计划，红色表示不符合定义的条件且未执行计划或操作。

必须强调的是，这些指标应该直接反映业务需求。

服务评审阶段

服务评审阶段是操作适用性评审过程的核心。 它涉及到以下步骤：

  1. 衡量服务指标。 使用记分卡指标监视每个操作管理级别的性能，以确保服务符合业务承诺。 操作基线中的库存和可见性服务至关重要。 如果无法监视与业务承诺相关的资源组，请考虑相应的记分卡指标为红色。 在这种情况下，若要进行补救，第一步是实施适当的服务监视。 例如，如果企业预期某项服务在操作时的可用性为 99.99%，但尚未准备好生产遥测来衡量可用性，则应假定你不符合要求。

  2. 计划补救。 对于指标低于可接受阈值的每个业务承诺，请确定适当的运营团队以完成所需的修正。 该团队负责计算修正服务的成本，使操作达到可接受的水平。 如果修正问题的成本大于分配给该服务的预算，中心 IT/CCoE 应该与云策略团队一起评审，以评估新增投资。

  3. 实施补救。 云运营或工作负载团队接受修正计划后，请实施该计划。 每当评审记分卡指标时，请报告实施状态。

此过程是迭代的。 中心 IT/CCoE 团队负责管理流程，并报告云策略团队的进度。 该团队应定期会面，对现有修正项目进行评审，开始对新的工作负载进行基础评审，并跟踪企业的总记分卡。 若修正团队(云运营或工作负载操作)落后于计划或未能达到指标，该团队还应有权对其进行问责。

评审会议

建议定期评审操作适用性。 中心 IT/CCoE 和云运营团队需要参加评审。 鼓励云策略和工作负载运营团队参与但需具有可操作性。 例如，核心团队可能每月召开一次会议，以协调计划，并对各个运营团队进行问责。 每季度，云策略和所有工作负载团队可以加入以了解状态和指标。

此过程及会面的详细计划取决于具体需要。 建议从以下注意事项着手：

  • “集中式运营：”工作负载团队不太可能主动参与该过程，但应包含在任何报告中，以了解其可见性。
  • “分散运营：”云运营团队应该与工作负载团队分享用于改进技术平台运营的最佳做法。 工作负载团队应共享对各自工作负载的更改，以确定可应用于技术平台和操作基线的改进。
  • Azure Automanage。 Azure Automanage 可自动监视整个操作基线的操作应用性，并自动跨项目组合应用各种修正策略。
  • Azure 顾问。 Azure 顾问根据使用情况和配置提供个性化建议，以帮助优化资源。 默认情况下，此工具跨订阅提供建议，以改进操作基线。 还可以使用它来更精细地确定对技术平台或单个工作负载的改进。
  • Microsoft Azure Well-Architected Framework：改进工作负载操作或指导分散运营的指南。