你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
重构登陆区域
登陆区域是一个环境，用于托管通过代码提前预配的工作负载。 由于登陆区域基础结构是在代码中定义的，因此可以像任何其他代码库一样对其进行重构。 重构是修改或重组源代码以优化该代码的输出而不改变其目的或核心功能的过程。
就绪方法使用重构概念来加速迁移并消除常见的障碍。 就绪概述中的步骤讨论了一个过程，该过程从最适合你的托管功能的预定义登陆区域模板开始。 然后重构或添加到源代码以扩展登陆区域功能，通过改进的安全性、运营或治理来交付该功能。 下图说明了重构的概念。
图 1：登陆区域重构。
常见阻碍
当客户采用云计算时，登陆区域注意事项是阻碍采用和云相关业务成果的最常见因素。 客户倾向于以下两个阻碍因素之一。 不同的团队经常倾向于这两个阻碍因素之一，导致文化僵局，使采用变得困难。
这两个主要的阻碍因素都植根于一个信念，即云环境和现有的数据中心应该在运营、治理和安全方面达到或接近功能奇偶一致性。 这是一个明智的长期目标。 但难点来自于实现该目标的时机与交付业务结果所需的速度之间的微妙平衡。
阻碍因素：过早行动
为了达到当前数据中心的安全治理和运营的当前状态，花费了数年时间和大量的努力。 它还需要进行观察、学习和自定义，以满足该环境的唯一约束。 复制这些相同的过程和配置需要时间。 达到完全的功能奇偶一致性也可能导致环境在云中表现不佳。 这种奇偶校验方法通常还会导致云环境中出现大量计划外超支。 不要试图将当前状态需求应用于未来状态环境作为早期阶段的入口。 这种方法很少被证明是有利可图的。
图 2：过早行动是一个常见的障碍。
在上图中，客户的目标是在云中运行 100 个工作负载。 为此，客户可能会在准备将一个工作负载发布到生产环境之前，先部署他们的第一个工作负载，然后再部署他们的前十个左右的工作负载。 最终，他们将达到采用计划的目标，并在云中拥有可靠的项目组合。 但图片中的红色 X 显示了客户经常遇到的问题。 等待完全对齐可能会将第一个工作负载延迟数周、数月甚至数年。
阻碍因素：行动过迟
另一方面，行动过迟可能会对云采用工作的成功产生重大的长期影响。 如果团队要等到采用工作完成后才达到功能奇偶一致性，他们将遇到不必要的障碍，并且需要多次升级以保持工作正常进行。
图 3：行动过迟是一个常见的障碍。
与过早行动类似，在这张图中，客户为跨登陆区域达到企业就绪状态的等待时间过长。 由于等待时间过长，客户在环境中所能做的重构和扩展的数量将受到限制。 这些约束将限制他们推动持续成功的能力。
寻找平衡
为避免这些常见阻碍，建议采用基于结构良好的云采用计划的迭代方法，该方法可以最大程度地提高学习机会，并最大限度地缩短业务成功的时间。 重构和并行工作对于此方法至关重要。
警告
中期目标（24 个月以内）为在云中托管超过 1,000 项资产（应用程序、基础结构或数据资产）的采用团队使用重构方法极不可能成功。 学习曲线过高，时间线过紧，无法采用有机的方法获得技能。 需要较少自定义的更完整的起点是实现目标的更好途径。 你的实现合作伙伴可能会指导你完成更好的方法。
本文的其余部分将重点介绍一些可以实现重构方法，同时最大程度降低风险的关键约束。
理论
重构登陆区域的概念很简单，但需要有适当的防范措施才能执行。 上示概念概述了基本流程：
- 准备构建你的第一个登陆区域时，请从通过模板定义的初始登陆区域开始。
- 部署该登陆区域后，使用目录的
Enhance部分下的文章中的指南重构并添加到初始登陆区域。 - 重复检查和添加的过程，直到拥有满足安全性、运营和治理团队增强要求的企业就绪环境。
开发方法
基于重构的方法的优点是能够创建并行迭代路径以进行开发。 下图提供了两个并行迭代路径的示例：云采用和云平台。 两者都按照自己的进度发展，几乎不可能对任何一个团队的日常工作造成阻碍。 采用计划和重构防范措施的一致性，可能让各团队就有关未来状态依赖项的里程碑和明确性达成共识。
图 4：登陆区域并行迭代。
在上面的示例迭代路径中，云采用团队正在将其包含 100 个工作负载的项目组合迁移到云。 同时，云平台团队专注于领先云采用计划，以确保为这些工作负载准备好环境。
在此示例中，计划的迭代如下运行：
- 云平台团队通过部署初始登陆区域来启动开发工作。 该登陆区域允许云采用团队部署和开始测试其第一个工作负载。
- 为了准备好让云采用团队下次部署 10 个工作负载，云平台团队将继续进行重构和添加联网环境，将云视为外围网络。
- 安全团队需要先进行安全审查，采用团队才能发布其首个生产工作负载。 在采用团队部署前 10 个工作负载时，平台团队将继续定义和实施安全要求。
- 当第一个工作负载发布到生产环境时，两个团队都应该学到了足够的知识，可以准备建立更长期的共享服务模型。 集中核心服务体系结构将有助于使治理和运营团队保持一致。 集中核心服务将帮助采纳团队准备好扩展和发布后续的几批生产工作负载。
- 随着团队渐渐实现迁移 100 个工作负载的目标，该团队自然越来越接近卓越协作模型和团队结构的云中心。
配置企业就绪环境需要一点时间。 此方法不会消除该要求。 相反，此方法旨在消除早期阻碍，并为平台和采用团队提供共同学习的机会。
登陆区域重构防范措施
所有初始登陆区域模板都有限制。 重构期间的防范措施或策略应反映这些限制。 在开始登陆区域重构流程之前，与初始模板限制相比，了解云采用计划的长期要求以及候选工作负载的分类非常重要。
作为建立重构防范措施的示例，我们将比较前面示例中的开发方法和 CAF 迁移登陆区域蓝图。
- 根据 CAF 迁移登陆区域蓝图的假设，此初始登陆区域不适用于敏感数据或任务关键工作负载。 必须通过重构添加这些功能。
- 在此示例中，我们假设 100 个工作负载的项目组合同时需要任务关键和敏感数据托管功能。
为平衡这两个相互竞争的要求，采用团队和平台团队将同意并遵守以下条件：
- 云采用团队将优先处理无法访问敏感数据且不被视为任务关键的生产工作负载。
- 在生产发布之前，安全和运营团队将验证其与前述策略的一致性。
- 云平台团队将与安全和治理团队合作，以实现安全基线。 安全批准实现后，将清除采用团队，以迁移可访问某些敏感数据的工作负载。
- 云平台团队将与运营团队合作，以实现管理基线。 运营团队批准实现后，将清除采用团队，以迁移具有更高关键性级别的工作负载。
对于此示例，上一组约定的条件将允许采用团队开始其迁移工作。 它还可以帮助平台团队改进与其他团队的互动，共同建立长期企业就绪环境。
重构时满足长期要求
就绪方法中有关增强登陆区域的部分将有助于满足更长期的要求。 当云采用团队使用采用计划时，请查看扩展登陆区域来获取指导，帮助制定决策和重构，以满足各个团队不断发展的要求。
图 5：帮助并行登陆区域迭代的更深层次的方法。
扩展登陆区域的每个子部分都映射到上图中概述的其中一个添加项。 除了这些基本扩展外，此框架的更深入的方法（例如“治理”或“管理”）可帮助超越基本登陆区域的修改，实现长期规则。
后续步骤
若要开始重构过程，请开始使用 Azure 登陆区域。