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

均衡竞争优先级

任何数字化转型的成功取决于业务和技术利益干系人平衡竞争优先级的能力。

与其他数字化转型一样，云采用在整个采用生命周期中公开了相互竞争的优先级。 与其他形式的转型一样，平衡这些优先事项的能力对实现业务价值具有重大影响。 要平衡这些相互竞争的优先级，需要在利益干系人之间进行公开的、有时甚至是困难的对话，有时还需要与单个参与者进行对话。

本文概述了在实施每种方法的过程中经常讨论的一些竞争优先级。 它可以帮助你在制定云采用策略时为这些讨论做好准备。

以下部分与前面的云采用生命周期图中的流程保持一致。 但是，请务必认识到，云采用是一个迭代过程，而不是一个顺序的过程，这些相互竞争的优先级可能会在云采用旅程中的不同点重新出现。

云采用框架方法的一般主题

整体解决方案和高级规划都是基于一系列假设构建的，随着时间的推移，这些假设可能被证明是不准确的。 对于企业及其技术团队来说，采用云通常是一种新体验。 与大多数新体验一样，初始假设有可能被证明是不正确的。

遵循经过验证的敏捷原则，即延迟技术决策，是该框架内大多数指导的首选方法。 该方法遵循一致的模式：建立一般最终状态，快速移动到初始实现，测试和验证假设，并尽早重构以解决错误的假设。 这种发展思维最大限度地提高学习效果，并将业务价值的风险降到最低，但它需要能够忍受一定程度的不确定性。

模棱两可有时比虚假假设更可怕或更危险。 尽管此框架在实施过程中优先考虑学习和解决歧义问题，但许多情况要求团队确定基于分析或基于假设的方法的优先级。 以下部分提供了至少一个“扩展范围示例”，以说明何时第二个更深层次的迭代可能很有价值。

策略阶段的平衡

策略方法的核心目标是在利益干系人之间建立一致性。 定义后，一致的战略位置会推动每个方法的行为，以确保技术决策与所需的业务成果保持一致。 促进利益干系人之间的一致性创建了一组共同的竞争优先级： 理由深度 与 业务影响时间。

竞争优先事项：

• 理由深度： 利益干系人通常需要深入的财务分析和完整的业务理由，然后才能适应战略方向。 遗憾的是，该级别的分析可能需要较长的时间才能进行数据收集和分析。
• 时间到业务影响： 相反，利益干系人通常负责在定义的时间范围内交付业务成果。 耗时的分析和评估可能会使这些结果在技术工作开始之前处于危险中。

最小范围： 要找到正确的平衡点，需要在流程的早期进行利益干系人讨论。 “策略”方法建议在此早期阶段限制一致性的范围。 在此建议的方法中，利益干系人重点就一组核心驱动因素、可衡量的成果以及关键业务理由达成一致。 然后，利益干系人应快速致力于一些初始项目或试点，以推动所需的学习机会。

扩展范围示例： 如果初始业务分析表明存在对业务产生负面影响的高风险，利益干系人可能需要放慢速度，并在业务理由期间更谨慎地评估更深入的分析。

在规划阶段实现平衡

与在策略阶段一样，在规划阶段需要平衡初始规划的深度与延迟的技术决策。

竞争优先事项：

• 云中技术实现的初始规划深度通常基于许多假设。 尤其是在团队存在技能差距、环境存在发现差距或工作负载没有明确定义的体系结构最终状态时。 所有这些假设在详细的云采用计划中都很常见。 需要试验、试点和定性分析来验证或改进这些假设。
• 延迟的技术决策 基于以下假设：技术决策越晚，越准确。 遵循敏捷产品规划的原则有助于延迟技术决策，从而根据足够的信息在正确的时间做出这些决策。 但是，此方法会导致初始计划更加多义。

最小范围： 我们建议采用敏捷的产品开发方法，以在可管理的计划内推动快速操作。 计划方法建议执行以下步骤来实现此平衡：

1. 使用自动发现工具清点整个数字资产，但使用增量合理化来规划未来 1 到 3 个月的工作量。
2. 确保对组织进行适当协调，以便迅速行动。
3. 为分配的团队创建技能准备计划。 使用策略和规划模板快速部署初始积压工作。

扩展范围示例： 云采用计划的交付有时可能是为了响应时间敏感或影响重大的业务事件。 如果成功需要在固定时间段内移动大量资产，则前面的步骤通常会进行更深入的规划工作。 在这些方案中，成功的关键是规划足够多，然后规划全面参与。 此方法可降低规划阻止业务成果的可能性。

在就绪阶段实现平衡

当团队准备进入云采用的第一步时，在采用时间和长期运营之间，通常会有相互竞争的优先级。 团队可能难以在很好地完成手头任务和妥善管理之间实现平衡。 在传统 IT 环境中，这种挣扎是必要的，因为开发平台需要考虑实物资产和购置周期。 但是，在代码中定义整个 IT 平台时，传统的开发策略（如重构）会减少从一开始就进行良好管理的需求。

竞争优先事项：

• 长期运营： 组织通常希望拥有满足与当前运营管理、治理和安全系统相等功能的云环境。 在一项研究中，超过 90% 的组织需要支持来克服这种思维模式。 此阻止程序可能会造成数月的延迟、减慢或阻止业务影响。
• 采用时间：基于云的工具（如Azure Policy、Azure 蓝图和管理组）可以简化整个 IT 平台的重构过程。 此外，预定义的登陆区域提供建议，以加速向已满足许多功能奇偶一性要求的环境部署。 这些工具提供了缩短上市时间的机会，同时对长期运营的影响最小。

最小范围：“就绪”方法概述了从快速采用到长期运营的直接途径。 此方法首先对可用于重构环境的工具进行基本介绍。 这些工具会考虑你的要求，并指导你选择预定义的登陆区域，每个登陆区域都提供基础结构即代码模型。 然后，可以在云采用过程中重构代码，以改善操作、安全性和管理。

扩展范围示例： 对于采用计划要求在 24 个月内 (中期目标) 托管超过 1，000 个资产 (云中) 应用程序、基础结构或数据资产的团队，我们建议使用更可靠的登陆区域视图。 在这些情况下，在初始登陆区域对话期间，应考虑治理和管理方法。 但是，这种更深入的考虑往往会使云采用计划推延数周或数月。 为了尽量减少对业务成果的影响，采用团队应在云中试点实际工作负载，同时创建更成熟的登陆区域和中央体系结构解决方案。

在迁移阶段实现平衡

在迁移期间，采用团队通常假设工作负载将在其当前配置中重新托管在云中。 此假设与前瞻性计划竞争，即重新架构每个工作负载，以更好地利用云功能。 这两个视图不是互斥的，在使用通用过程管理它们时，这两个视图是互为补充的。

竞争优先事项：

• 重新托管： 组织通常将迁移等同于 直接迁移 方法，该方法将所有资产复制到其当前配置中的云中。 此方法在 IT 项目组合中几乎没有偏差。 这也是停用现有数据中心资产的最快方法。
• 重新架构： 对每个工作负载的体系结构进行现代化改造可最大程度地提高云采用在成本、性能和运营方面的价值。 但是，此方法速度较慢，通常需要访问每个应用程序的源代码。

最小范围： 在早期规划期间，请使用重新托管选项进行规划，并清楚地了解，此选择基于初始业务假设，不是技术决策。 在迁移方法中，云采用团队随后会针对每个迁移的工作负载质疑此假设。 此方法遵循每个工作负荷或工作负荷组的评估/迁移/提升方法，以创建迁移工厂。 在评估阶段，采用团队会评估每个工作负载的技术拟合度和体系结构。 此评估的结果不会是单纯的直接迁移方法，因为体系结构中的许多组件往往会被选中进行重构和现代化。

扩展范围示例： 对于任务关键型或高敏感度工作负载（如大型机或多层微服务应用程序），可能需要在评估阶段对工作负载进行更全面的评估。 在这些重新架构情况下，应使用 Azure Well-Architected评审和 Azure Well-Architected框架 在评估期间优化工作负载要求。

在创新阶段实现平衡

真正面向客户的创新经常在需要交付计划的功能集与实施客户同理心开发过程之间产生冲突的优先级。

竞争优先事项：

• 关注功能：初始创新计划基于现有数字资产和云功能提供满足客户需求的一组功能。 很容易让计划推动技术实现，从而进行以功能为中心的开发工作。 这种方法通常会导致暂时的利益干系人满意度，但会降低推动影响客户行为的创新的可能性。
• 客户同理心：初始计划是业务开发的重要组成部分，应包含在定期报告中。 但是，以客户同理心为目标的学习、衡量和构建是衡量创新工作成功率的更准确指标。 将客户放在功能上更有可能产生短期和长期客户满意度和业务影响。

最小范围： 创新方法说明了如何通过业务价值共识来集成策略和计划。 然后，本指南介绍了云原生工具，这些工具可以加速每个规则的创新和实施最佳做法。 最后，流程改进部分演示了在云采用过程中尊重计划和策略的同时建立客户同理心的方法。 此方法侧重于使用尽可能少的技术来实现创新。

扩展范围示例： 创新有时依赖于任务关键型或高敏感度工作负载。 当客户是内部用户时，在最早迭代期间，开发工作可能既是任务关键型工作，也是高敏感度。 在这些方案中，采用团队应使用 Azure Well-Architected评审和 Azure Well-Architected框架 在早期评估高级体系结构设计。

在治理阶段实现平衡

云治理的做法是在两个相互竞争的优先级之间取得平衡：速度和敏捷性与治理良好的环境。 云治理团队专注于如何通过统一控制和最大限度减少变更，来评估和最大限度降低业务风险。 采用团队专注于推动业务成果，这需要新风险并从本质上创造变革。

竞争优先事项：

• 治理良好：每一个旨在最小化风险的控制措施都会阻止某些方面的变革或限制设计选项。 控制对于治理良好的环境是必不可少的。 但是，当控件是单独设计和部署的时，它们可能具有破坏性，就像它们要防范的风险一样。
• 速度和敏捷性：速度和敏捷性是数字经济中的基本业务要求。 两者都要求能够以最不影响创新或采用的方式推动变革。 但是，当在没有治理的情况下推动变革时，就会产生新的风险，从而以意想不到的方式损害业务。

最小范围：“治理”方法建议不要孤立地进行治理或采用。 此方法首先了解治理规则，并就业务风险、策略和流程展开对话。 作为整个云采用的积极参与者，治理团队可以实施一组最少的安全措施来解决云采用计划中的有形风险。 随着时间的推移，治理团队可以重构和扩展这些安全措施，以应对新的风险。 此方法可最大程度地提高学习和创新，同时将风险降至最低。

扩展范围示例： 如果业务风险较高，尤其是在采用初期，云治理团队可能需要加快治理实现的扩展。 可以使用相同的指南和练习来添加更高级别的治理，但可能需要加快速度。 在某些情况下，在开发第一个登陆区域时，甚至可能需要高级治理状态。

在管理阶段实现平衡

在过去十年中，用于运营管理的 IT 业务模型不断发展。 随着硬件维护从 IT 的核心价值主张进一步转变，对运营管理的看法发生了转变。 随着 IT 部门更加注重交付业务价值，运营管理团队需要平衡无运营和低运营与广泛的投资。

竞争优先事项：

• 广泛投资组合：传统的运营管理方法是，在服务中断预防、快速恢复和环境监视方面进行同等投资。 这种方法可能很昂贵，有时与云供应商提供的支持产品重复。
• 无操作和低操作： 使用云原生操作工具将以前由员工交付的重复性任务和重复任务降到最低。 减少这些操作依赖项可让员工以其他方式推动价值。 但是，在隔离的情况下，此方法可能会导致低于标准的操作支持。

最小范围：“管理”方法建议建立云原生无运营基线。 确认无运营基线不能满足所有业务需求，请与业务合作，以定义承诺并更好地调整投资。 扩展基线以满足所有工作负载的常见需求。 然后使平台团队或特定工作负载团队能够在管理良好的环境中维护管理良好的解决方案。

扩展范围示例： 在大多数环境中，一小部分工作负载的业务价值证明 IT 对运营的深度投资是合理的。 对于这些工作负载，IT 团队可能需要使用 Azure Well-Architected评审和 Azure Well-Architected框架来指导更深入的操作。

在组织阶段实现平衡

本文中所述的竞争优先级反映了 IT 部门努力满足对速度和敏捷性的业务需求。 组织结构图或虚拟团队结构的更改也出现了同样的转变，以便为业务成果提供更好的支持。 当 IT 领导者反思团队结构时，通常会解决两个竞争优先事项：集中控制与委托控制。

竞争优先事项：

• 集中控制： 此操作模型侧重于强制实施刚性策略所需的所有控制措施的集中化。 在这种模式下，IT 团队阻碍了创新、速度和敏捷性的实现。 然而，IT 团队可以确保更高的稳定性、合规性和安全性。
• 委托的控件： 在此分布式运营模型中，假定每个 DevOps 团队或业务应用程序团队都将根据实现业务目标所需的解决方案提供自己的一组控制措施。 在此模型中，IT 提供了帮助团队避免风险的准则，但尽可能将强制技术约束的数量降至最低。

最小范围： 随着时间推移，大多数组织都会经历一系列自然的演变。 “组织”方法概述了最常见的一系列演变。 我们建议团队尝试 (CCoE) 结构向卓越云中心迈进，以提供委托的控制方法。

扩展范围示例： 许多情况都触发了集中控制的需求。 第三方合规要求和临时安全风险就是要求集中控制的两个示例。 在这些情况下，通常需要建立限制策略和严格的固定控制。 但是，为了继续创新和采用，我们鼓励中央 IT 团队根据每个工作负载的重要性和敏感性提供这些控制措施。 即使需要控制，但提供范围或风险配置文件减少的环境也能实现灵活性。

后续步骤

了解如何平衡迁移、创新和试验，以最大限度地提高云迁移的价值。

均衡项目组合