统一混合云和多云运营

混合云是指混合使用本地/专用基础结构和公共云服务，而多云意味着同时使用多个云提供商。 如今，许多企业都有孤立的团队、分布式站点和分布在本地数据中心和各种云中的系统。 挑战是以安全、管理良好的方式统一这些环境，使云到边缘实现现代化。 本指南提供了一个规范性的端到端框架，用于将混合和多云环境与 Azure 作为中心控制平面进行统一和管理。

快速入门： Azure 混合和多云服务

我们介绍了 Azure 解决方案（如 Azure Arc、Azure Monitor、Azure Kubernetes 服务、Microsoft Fabric、Azure IoT 和 Azure Local）如何帮助统一控制和实现所有环境中的 IT 现代化。 目标是建立一个标准运作模型，以消除孤立，并在各地提供一致的实践。 我们详细介绍了如何在一个 Azure 驱动的策略下保护、管理和现代化从云到边缘的资源，统一以前隔离的团队和系统。

第一步是建立一个明确的混合和多云策略，使其符合业务目标并强调统一。 这种一致性可确保业务价值（敏捷性、复原能力、成本优化、创新）推动云采用，而不是临时决策。 此阶段的关键活动包括定义驱动程序和愿景、设置指导原则、确定云组合以及将 Azure 服务映射到目标。

1.为混合和多云定义业务驱动因素

首先确定组织采用混合和多云的原因。 业务驱动因素提供焦点，并确保该方法提供可衡量的价值。 这些驱动因素必须链接到具体的业务成果或关键绩效指标（KPI），以指导决策并防止分散的技术选择。 常见驱动程序包括：

• 供应商灵活性：减少对任何单一提供商的依赖，以缓解市场封锁，并允许进行成本优化和使用顶级优选服务。 例如，如果替代方法可以节省成本或提供独特的功能，请避免只依赖一个云的功能。
• 业务部门多样性：适应使用各种平台的不同团队、收购或子公司。 统一策略可防止运营孤岛，并在尊重现有投资的同时在所有环境中建立集中治理。
• 合规性和数据驻留：满足数据主权或特定安全控制法规要求。 对于必须保留在本地的工作负荷，请使用 Azure Local（Azure Stack HCI 现在是其中一部分）。 连接到适用于其他数据和应用程序的 Azure 云服务。
• 复原和灾难恢复：通过分发工作负载和建立多环境故障转移来提高可用性。 使用统一流程设计 Azure 和辅助环境（其他云或本地）之间的无缝恢复，以确保最短的停机时间。
• 性能优化：将工作负荷放置在靠近用户或数据源的位置，以减少延迟。 例如，在工厂位置部署 Azure 本地实例进行实时处理，同时通过 Azure 云服务保持集中协调。
• 现代化和创新：使用专门的云服务推动转型。 例如，根据需要使用 Azure 的 AI 服务和 Microsoft Fabric 分析，同时跨其他云集成数据和应用。
• 统一孤岛：消除基础结构、云和应用程序团队之间的内部孤岛。 建立常见的工具和流程，例如用于资源管理的 Azure Arc、用于可观测性的 Azure Monitor，以跨以前隔离的组创建共享可见性和协作。

对于每个业务驱动因素，请将其链接到特定的业务成果或 KPI。 例如，如果驱动程序“避免停机”，则结果可能是实现 99.99% 可用性。 如果“支持全球扩张”是推动因素，那么一年内可能会在某些新的地区开始运营。 如果统一孤岛是一个目标，则通过统一 IT 流程，结果可能是 20% 减少运营开销。 在结果中立足驱动因素可确保该策略侧重于提供可衡量的价值。 将这些驱动因素和所需结果清楚地记录在引导所有后续决策时。

2.为混合和多云创建清晰的视觉声明

制定简洁的视觉声明，描述混合/多云环境的目标状态以及成功的外观。 此愿景声明提供方向并帮助所有利益干系人了解最终目标。 愿景应阐明统一方法对组织的好处。 例如：

• “构建一个自适应云平台，以统一所有基础结构和团队，使任何应用都能在最能满足业务需求的位置运行。（强调灵活性和统一性。
• “通过多云复原提供 100% 运行时间的一致客户体验。（侧重于可靠性和连续性。
• “通过跨云和本地标准化 DevOps，将部署频率提高 50%。（侧重于敏捷性和流程改进。
• “在两年内将本地占用空间减少 50%，以降低成本，同时将云管理扩展到所有剩余的本地资产。（强调效率和云优先作。

3.为混合和多云建立成功指标

除了愿景之外，定义 2-5 个关键的成功指标（KPI）来衡量进度。 上一步中的每个主要驱动程序都应映射到至少一个 KPI。 使其尽可能具体明确，并设定时间范围。 例如，如果敏捷性是驱动因素，则关键绩效指标可能包括在 12 个月内将所有环境中的基础设施预配时间从数周缩短到数小时。 如果成本优化是驱动因素，那么关键绩效指标可能是通过云突发和资源整合，将基础设施利用率提高 30%。 在采用突发之前评估数据出口和同步成本。 同时包括安全或符合性指标。 例如，设置一个目标，即 100% 载入和作用域内资源必须符合通过 Azure Policy 和 Defender for Cloud 测量的基线安全策略。

通过设置指标，可以创建成功的共享定义。 它使团队保持一致，并提供一种方法来跟踪混合/多云计划随时间推移的优势。

4.为混合和多云设置原则

确定要用于不同工作负荷的云或环境的指导原则。 明确的原则可防止随机或首选项驱动的选择增加复杂性。 它们还平衡了可移植性的愿望与云特定服务的优势。 制定准则，例如：

1. 确定云中性与特定于云的使用情况。 确定要构建云无关解决方案还是使用云原生服务。 对于每个工作负荷，确定可移植性是否至关重要。 例如，对于核心记录系统，可以使用任何位置运行的 Azure Kubernetes 服务、容器或数据库等技术确定中立性。 相比之下，对于面向客户的或创新项目，可以使用特定于云的 PaaS 服务（如 Azure Functions）来加速开发。

2. 尽可能将 Azure 用作统一层。 使 Azure 成为所有环境的集中管理和集成层。 计划通过 Azure 管理其他云，而不是为每个云维护并行工具集。 例如，如果在 AWS 中运行某些 VM，请通过 Arc 将它们加入 Azure，并通过 Azure Policy 强制实施策略，以便可以像 Azure 资源一样管理它们。 这种统一可确保无需使用每个云的本机管理工具。 Azure 成为整个 IT 资产的一致覆盖层。

3. 解释多云复杂性的合理性。 多云方法可以引入复杂性，例如多个技能集、不同的体系结构，以及云之间的数据出口费用等可能更高的成本。 将使用另一个云必须有明确理由作为一项原则。 对于新部署，默认为使用 Azure，除非有独特的功能或业务需求另有要求。 如果使用辅助云，请通过 Azure 集成并定期重新访问其必要性。 这种有意的立场避免了不同平台上的非托管孤立部署的蔓延。 如果开发人员建议使用不同的数据分析技术，他们必须有很强的理由并计划集成它。 否则，它们应使用 Azure 的分析产品/服务，例如 Microsoft Fabric。

这些原则为架构师和工程师提供了决策框架。 例如，选择数据库服务时，准则可能会引导他们使用 Azure 的 PaaS 数据库获取功能，而不是自动选取不符合策略的非 Azure 服务。 总体目标是鼓励使用 Azure 作为主干，尽量减少碎片，并仅在需要时接受多云元素。

5.为混合和多云选择云组合

决定哪些云平台（包括本地）应是策略的一部分，并从一开始就将 Azure 建立为中心管理中心：

1. 根据要求选择云组合。 评估业务和技术需求，以确定云平台的组合。 许多企业使用多个公有云来满足不同的需求或遗留投资。 记录应使用的平台以及原因。 此外，确定本地基础结构将发挥哪些作用。 例如，可以将 Azure 用于大多数工作负荷，并使用 Azure Local 为某些工厂控制系统维护本地系统。 具体。 确定任何必须保留在本地的关键工作负荷，并计划通过在 Azure Arc 上托管并载入管理，以及针对其他云的任何特殊情况来实现这些工作负载的现代化。 确保此规划组合与您的驱动因素（例如使用辅助云服务实现恢复能力或专业能力）相关联。

2. 使 Azure 成为所有环境的主控制平面。 明确指出，Azure 应充当跨所有云和本地管理资源的主要中心。 此决策具有战略意义，因为 Azure 通过 Azure Arc 和相关服务提供强大的混合管理。 通过将 AWS、Google Cloud 和本地资源投影到 Azure 进行管理，可以集中专业知识和工具。 实际上，这意味着应使用 Arc 从 Azure 管理 AWS 资源，而不是从 AWS 工具管理 Azure 资源。 Azure 的跨云服务（Arc，Microsoft Defender for Cloud，Azure Monitor）使它非常适合此中心角色，提供集成和一致性。

3. 设计统一的操作模型。 设想 IT运营在此混合/多云环境中应如何运行。 定义适用于所有环境的进程。 例如，策略应列出所有服务器（Azure VM、本地服务器、AWS EC2）的清单。 它们还应通过 Azure Arc 进行配置，并由 Azure Policy 管理 Azure 和 Arc 启用的资源。 对于 AWS 或 Google Cloud，请使用 Defender for Cloud 的多云连接器来展示安全姿态，因为合规性信息通过 Defender for Cloud 的多云连接器呈现，而不是通过直接分配 Azure Policy。 应在 GitHub Actions/Azure DevOps 中使用 CI/CD 管道，使用已批准的模板将应用程序部署到任何目标环境。 网络作应将 Azure 视为链接其他站点/云的中心，安全团队应使用 Microsoft Sentinel 来监视所有内容。 通过描述这一目标运营模式，你设定了统一运作必须取代各自为政的现象的预期，例如为每个云设置的单独运营团队。 它为组织准备日常工作的变化，并阐明了如何实现一致性。

4. 建立统一的团队以支持跨平台作业。 在规划技术的同时，考虑人为因素。 建立支持团队以培训和支持平台和工作负荷团队。 包括传统 IT 团队、云团队和安全团队的成员。 在 Azure 和云技能中培训本地 IT 人员，以便他们可以通过 Azure 的工具管理任何环境中的资源。 此方法表明你期望进行协作和跨培训。 在某些情况下，这可能意味着重新组织。 可以合并单独的云团队，或者拥有为所有业务部门提供服务的集中式平台。 将这一部分纳入战略，确保组织结构支持运营模型。

通过有意选择云组合并选择 Azure 作为定位点，为统一管理奠定了坚实的基础。 每个人都应该了解他们应该在其中运行的环境，以及 Azure 是如何将它们联系在一起的。 这种理解可以防止平台不受控制的扩散，并强化了先前的原则。

6. 将 Azure 混合和多云服务映射到目标

确定策略后，确定哪些 Azure 服务和技术有助于实现特定目标。 此识别方式在高级策略与可实施的实现之间创建了桥梁。 考虑技术堆栈的所有关键领域，并将其映射到 Azure 解决方案：

记录此映射可确保你的策略包括一个以 Azure 为中心的具体技术游戏计划。 它还有助于尽早识别技能差距和工具需求。 例如，如果计划使用 Microsoft Fabric 进行分析，则你知道你需要数据集成技能和 Power BI 专业知识。 如果 Azure Arc 是中心，您计划为运营团队在 Arc 上进行培训。这一步骤将您的战略意图转化为可实施的 Azure 服务以实现它。

策略结果

在此阶段结束时，应具有可捕获上述所有元素的混合/多云策略。 到目前为止，它应该总结你的决策：

• 业务驱动因素和范围：统一 IT运维、多云环境的运行时间要求、边缘计算的需求。
• 视觉声明：Azure 是主要平台和控制平面，集成其他云和本地系统以提供统一、敏捷的数字基础结构。
• 成功指标：可用性、部署速度、成本节省和合规性的特定目标。
• 指导原则：避免供应商锁定（默认为 Azure），在需要时使用云中性设计。
• 云组合：在哪些环境中使用（Azure、本地通过 Azure Local 和其他云），以及其原因。
• 关键技术：使用 Azure 和任何非 Azure 服务来实施该策略。

例如，以下是策略总结的一个示例摘录：

• 示例策略摘要：组织采用自适应混合/多云方法来统一 IT作，同时为每个需求使用最佳云功能。
• 司机：避免停机（目标 < 为 1 小时/年）。 满足欧盟数据驻地法律。 消除操作孤岛以提高效率（目标将运营支出减少20%）。
• 愿景：Azure 是集成所有其他环境的主要云和控制平面。 我们必须使用 Azure 和一个辅助云和 Azure 本地来提高全球覆盖范围，以满足本地需求。
• 云原则：采用 Azure 原生服务实现区分和速度。 除非有相当必要的要求，否则将默认新部署到 Azure。
• 云组合：目前将约 50% 的本地部署进行 Azure 本地现代化，40% 转为 Azure，10% 转为 AWS，以实现特定用例的现代化。 长期目标：70% 使用 Azure，其余的本地环境通过 Azure 本地服务运行，其他云仅限于特定用途。
• 关键 Azure 技术：用于统一资源管理的 Azure Arc。 用于端到端可见性和安全性的 Azure Monitor 和 Defender。 Azure Local 将云扩展到本地环境。 AKS 容器服务。 Microsoft Fabric 来统一数据分析。 适用于边缘设备的 Azure IoT。 用于统一身份的 Entra ID。 标准化的 Azure Pipelines 用于所有部署。 我们必须通过满足运行时间和部署频率目标的能力来衡量成功，同时在所有平台上保持严格的安全合规性。

让利益干系人批准这一战略简报可确保每个人在继续前进之前保持一致。 现在，您可以携带一个以 Azure 为重点的扎实策略开始详细的规划。

后续步骤