你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
均衡竞争优先级
任何数字化转型的成功取决于业务和技术利益干系人平衡竞争优先级的能力。
与其他数字化转型一样，云采用在整个采用生命周期中都暴露了竞争的优先级。 与其他形式的转型一样，平衡这些优先事项的能力对实现业务价值产生了重大影响。 平衡这些相互竞争的优先级需要利益干系人之间公开和有时困难的对话，有时需要与个别参与者进行对话。
本文概述了每个方法的实现过程中经常讨论的一些相互竞争的优先级。 在制定云采用策略时，它可以帮助你为这些讨论做好准备。
以下部分与前面的云采用生命周期关系图中的流保持一致。 但是，必须认识到，云采用是一个迭代过程，而不是一个顺序的过程，这些竞争优先级可能会在云采用过程中的各个点重新出现。
云采用框架 方法的一般主题
整体解决方案和高级规划都是建立在一系列假设之上的，这些假设可能会随着时间的推移而不准确。 采用云通常是企业及其技术团队的新体验。 与大多数新体验一样，初步假设可能被证明是不正确的。
遵循经过验证的敏捷原则，即延迟技术决策，是该框架内大多数指导的首选方法。 此方法遵循一致的模式：建立一般结束状态，快速迁移到初始实现、测试和验证假设，并提前重构以解决错误假设。 这种发展思维最大限度地提高学习效果，并将业务价值的风险降到最低，但它需要能够忍受一定程度的不确定性。
与虚假假设相比，歧义有时可能更可怕或更危险。 尽管此框架在实现过程中优先学习和解决歧义问题，但许多情况要求团队确定基于分析或基于假设的方法的优先级。 以下部分至少提供了一个“扩展范围示例”，以说明何时第二次更深入的迭代可能很有价值。
策略阶段的平衡
战略方法的核心目标是在利益干系人之间发展一致。 定义后，对齐的战略位置将推动每个方法的行为，以确保技术决策与所需的业务成果保持一致。 促进利益干系人之间的一致性创造了一组共同的竞争优先级： 理由 深度与 业务影响时间。
竞争优先事项：
理由深度： 利益干系人通常需要深入的财务分析和完整的业务理由，然后才能适应战略方向。 遗憾的是，这种分析级别可能需要较长的时间段才能进行数据收集和分析。
业务影响时间： 相反，利益干系人通常负责在定义的时间范围内交付业务成果。 在技术工作开始之前，耗时的分析和评估可能会使这些结果面临风险。
最低范围： 查找正确的平衡需要流程的早期利益干系人讨论。 “策略”方法建议在此早期阶段限制一致性的范围。 在此建议的方法中，利益干系人重点就一组核心驱动因素、可衡量的成果以及关键业务理由达成一致。 然后，利益干系人应迅速承诺几个初始项目或试点，以推动所需的学习机会。
扩展范围示例： 如果初始业务分析指示对业务产生负面影响的高风险，利益干系人可能需要放慢速度，并在业务理由期间更谨慎地评估更深入的分析。
在规划阶段实现平衡
与在策略阶段一样，在规划阶段需要平衡初始规划深度与延迟的技术决策。
竞争优先事项：
云中技术实现的初始规划 深度通常基于许多假设。 尤其是当团队存在技能差距时，环境会受到发现差距的影响，或者工作负荷没有明确定义的体系结构结束状态。 所有这些假设在详细的云采用计划中都很常见。 需要试验、试点和定性分析才能验证或改进这些假设。
延迟的技术决策 基于以后做出技术决策的假设，更准确。 遵循敏捷产品规划原则有助于延迟技术决策，使其在正确的时间根据足够的信息进行。 但是，此方法在初始计划中产生更模糊。
最低范围： 建议敏捷的产品开发方法，以推动可管理计划内的提示操作。 计划方法建议执行以下步骤来实现此平衡：
- 使用自动化发现工具清点完整的数字资产，但使用增量合理化来规划未来 1 到 3 个月的工作量。
- 确保对组织进行适当协调，以便迅速行动。
- 为分配的团队创建技能准备计划。 使用策略和规划模板快速部署初始积压工作。
扩展的范围示例： 云采用计划的交付有时可能是为了响应时间敏感或影响重大的业务事件。 如果成功需要固定时间段内大量资产的移动，则上述步骤通常遵循更深入的规划工作。 在这些方案中取得成功的关键是计划足够多，然后计划完全参与。 此方法减少了规划会阻止业务成果的可能性。
在就绪阶段实现平衡
当团队准备进入云采用的第一步时，在采用时间和长期运营之间通常会有竞争的优先级。 团队可能会努力平衡，在做好手头的任务和妥善管理的任务之间取得平衡。 在传统 IT 环境中，这种挣扎是必要的，因为开发平台需要考虑实物资产和购置周期。 但是，当整个 IT 平台在代码中定义时，传统的开发策略（如重构）从一开始就需要很好地管理。
竞争优先事项：
长期运营： 组织通常被希望拥有满足与当前运营管理、治理和安全系统功能奇偶一的云环境所阻止。 在一项研究中，超过90%的组织需要支持才能摆脱这种心态。 此阻止程序可以创建数月的延迟、减缓或防止业务影响。
采用时间： 基于云的工具（如 Azure Policy、持续集成和持续交付（CI/CD）方法（如基础结构（代码（IaC）和管理组可以简化跨 IT 平台重构的过程。 此外，预定义登陆区域还提供建议，以加速针对已满足许多功能奇偶校验要求的环境的部署。 这些工具提供了在对长期运营的影响最小的情况下加快上市时间的机会。
最小范围：“就绪”方法概述了从快速采用到长期运营的直接途径。 此方法首先介绍了可用于重构环境的工具。 这些工具考虑到你的要求，并指导你选择预定义的登陆区域，每个区域都随 IaC 模型一起交付。 然后，可以在云采用过程中重构代码，以提高操作、安全性和管理。
扩展范围示例： 对于采用计划要求在云中托管超过 1,000 个资产（应用程序、基础结构或数据资产）的中期目标（在 24 个月内）的团队，我们建议更可靠的登陆区域视图。 在这些情况下，应在初始登陆区域对话期间考虑治理和管理方法。 但是，这种更深入的考虑往往会使云采用计划推延数周或数月。 为了尽量减少对业务结果的影响，采用团队应在云中试点实际工作负荷，同时创建更成熟的登陆区和中心体系结构解决方案。
在迁移阶段实现平衡
在迁移期间，采用团队通常假设工作负载将重新托管在云中的当前配置中。 此假设与前瞻性计划竞争，以重新架构每个工作负载，以更好地利用云功能。 这两个视图不是相互排斥的，当你使用通用过程管理它们时，这些视图可能是免费的。
竞争优先事项：
重新托管：组织通常将迁移等同于直接迁移方法，该方法副本 (replica)当前配置中的所有资产到云。 此方法在 IT 组合中几乎没有偏差。 这也是停用现有数据中心资产的最快方法。
重新架构： 使每个工作负荷的体系结构现代化可最大程度地提高跨成本、性能和操作的云采用价值。 但是，此方法速度较慢，通常需要访问每个应用程序的源代码。
最低范围： 在早期阶段规划期间，使用重新托管选项进行规划，并清楚地了解此选项基于初始业务假设，不是技术决策。 在 Migrate 方法中，云采用团队随后针对每个迁移的工作负荷挑战此假设。 此方法遵循每个工作负荷或工作负荷组的评估/迁移/提升方法来创建迁移工厂。 在评估阶段，采用团队会评估每个工作负荷的技术拟合和体系结构。 此评估的结果不会是单纯的直接迁移方法，因为体系结构中的许多组件往往会被选中进行重构和现代化。
扩展范围示例： 对于任务关键型或高敏感度工作负荷（如大型机或多层微服务应用程序），在评估阶段可能需要对工作负荷进行更彻底的评估。 在这些重新架构情况下，应使用 Azure 精心构建的评审和 Azure 良好架构框架 来优化评估期间的工作负荷要求。
在创新阶段实现平衡
真正的面向客户的创新经常在需要交付计划的功能集和实施客户同理心开发过程之间产生冲突的优先级。
竞争优先事项：
关注功能：初始创新计划基于现有数字资产和云功能提供满足客户需求的一组功能。 允许计划驱动技术实现，这很容易导致以功能为中心的开发工作。 这种方法通常会导致临时利益干系人满意，但降低了推动影响客户行为的创新的可能性。
客户同理心：初始计划是业务开发的重要组成部分，应包含在定期报告中。 但是，学习、衡量和构建以客户同理心作为目标，是创新努力中成功的更准确衡量标准。 专注于客户对功能更可能产生短期和长期客户满意度和业务影响。
最低范围： 创新方法说明了如何通过业务价值共识集成策略和计划。 然后，本指南介绍了云原生工具，这些工具可以加速每个创新规则和实现的最佳做法。 最后，流程改进部分演示了在跨云采用过程中遵循计划和策略时生成客户同理心的方法。 此方法侧重于通过尽可能少的技术提供创新。
扩展的范围示例： 创新有时依赖于任务关键型或高敏感度工作负荷。 当客户是内部用户时，在最早的迭代中，开发工作可能既具有任务关键性和高敏感度。 在这些方案中，采用团队应使用 Azure 精心构建的评审和 Azure 良好架构框架 来尽早评估高级体系结构设计。
在治理阶段实现平衡
云治理的做法是两个相互竞争的优先级之间的平衡：速度和敏捷性与治理良好的环境。 云治理团队专注于如何通过统一控制和最大限度减少变更，来评估和最大限度降低业务风险。 采用团队专注于推动业务成果，这需要新风险并从本质上创造变革。
竞争优先事项：
- 治理良好：每一个旨在最小化风险的控制措施都会阻止某些方面的变革或限制设计选项。 控制对于治理良好的环境是必不可少的。 但是，当控件设计并隔离部署时，它们可能会像它们旨在防止的风险一样有害。
- 速度和敏捷性：速度和敏捷性是数字经济中的基本业务要求。 两者都要求能够以最不影响创新或采用的方式推动变革。 但是，在没有治理的情况下推动变革时，它会产生新的风险，可能会以意外的方式损害业务。
最小范围：“治理”方法建议不要孤立地进行治理或采用。 此方法首先了解治理规则和有关业务风险、策略和流程的对话。 作为整个云采用的活跃参与者，治理团队可以实施一组最低安全措施，以解决云采用计划中的实际风险。 随着时间的推移，治理团队可以重构和扩展这些安全措施，以满足新的风险。 此方法将学习和创新最大化，同时将风险降到最低。
扩展范围示例： 当业务风险很高（尤其是在采用初期）时，云治理团队可能需要加快治理实现的扩展。 可以使用相同的指导和练习来添加此更高级别的治理，但可能需要更快。 在某些情况下，在开发第一个登陆区域时，甚至可能需要高级治理状态。
在管理阶段实现平衡
过去十年来，运营管理的 IT 业务模型不断发展。 随着硬件维护从 IT 的核心价值主张进一步移动，对运营管理的看法已经改变。 随着 IT 部门增加对实现业务价值的关注，运营管理团队因需要平衡无运营和低运营与广泛投资的需求相冲突。
竞争优先事项：
广泛投资组合：传统的运营管理方法是，在服务中断预防、快速恢复和环境监视方面进行同等投资。 这种方法可能很昂贵，有时会复制云供应商提供的支持产品。
无操作和低运营： 使用云原生操作工具将以前由员工交付的重复任务和重复任务降到最低。 减少这些操作依赖项可让员工以其他方式推动价值。 但是，在隔离中，此方法可能会导致子分析操作支持。
最小范围：“管理”方法建议建立云原生无运营基线。 确认无运营基线不能满足所有业务需求，请与业务合作，定义承诺并更好地调整投资。 扩展基线以满足所有工作负载的常见需求。 然后使平台团队或特定工作负载团队能够在管理良好的环境中维护管理良好的解决方案。
扩展范围示例： 在大多数环境中，少量工作负载的业务价值可证明 IT 部门对运营进行深度投资。 对于这些工作负载，IT 团队可能想要使用 Azure 精心构建的评审和 Azure 精心构建的框架来指导更深入的操作。
在组织阶段实现平衡
本文中所述的竞争性优先级反映了 IT 为快速和敏捷性提供业务需求的推动力。 组织图表或虚拟团队结构的更改中出现了相同的转变，为业务成果提供更好的支持。 当 IT 领导者反思团队结构时，通常会解决两个竞争优先事项：集中控制与委托控制。
竞争优先事项：
集中控制： 此操作模型侧重于强制实施刚性策略所需的所有控件的集中化。 在这种模式下，IT 团队阻碍了创新、速度和敏捷性的实现。 然而，IT 团队可以确保更高的稳定性、合规性和安全性。
委派的控制： 在此分布式操作模型中，假定每个 DevOps 团队或业务应用程序团队都将根据交付业务目标所需的解决方案提供自己的控制集。 在此模型中，IT 提供了帮助团队避免风险的准则，但尽可能减少强制实施的技术约束的数量。
最低范围： 大多数组织都会经历一组自然的演变。 “组织”方法概述了最常见的一系列演变。 我们建议团队尝试走向卓越云中心（CCoE）结构，以提供委托的控制方法。
扩展范围示例： 许多情况触发了集中控制的需求。 第三方合规要求和临时安全风险就是要求集中控制的两个示例。 在这些情况下，通常需要建立限制策略和严格的固定控制措施。 但是，为了使创新和采用能够继续，我们鼓励中心 IT 团队根据每个工作负荷的关键性和敏感度提供这些控制。 提供更少的控制环境，但范围或风险配置文件的减少允许灵活性，即使需要控制。
后续步骤
了解如何平衡迁移、创新和试验，以最大限度地提高云迁移的价值。