本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 流程视角
流程带来了一致性，但它们也会不断演变，并且容易发生变化，因为每个项目都是独一无二的。当你反复运行该过程时，你将发现差距和改进空间，这些差距和改进空间可以在你失败、学习、采用和迭代时带来巨大的好处。这些变化可以带来新的想法或创新，项目和业务可以在未来利用这些想法或创新，这为增长提供了催化剂，带来了质量和团队信心。
迁移过程可能很复杂，因为它们跨越了以前可能没有关联的技术和边界。这种视角为大型迁移的具体要求提供了流程和指导。
## 为大规模迁移做准备
以下各节概述了确保您以明确的方向开始迁移之旅所需的核心原则，并得到利益相关者的支持，这对于迁移的成功至关重要。
**Contents**
+ [定义业务驱动因素并沟通时间表、范围和策略](#bus-drivers)
+ [定义清晰的升级路径以帮助消除障碍](#escalation)
+ [尽量减少不必要的更改](#change)
+ [尽早记录 end-to-end流程](#end-to-end)
+ [记录标准迁移模式和构件](#artifacts)
+ [为迁移元数据和状态建立单一事实来源](#metadata)
### 定义业务驱动因素并沟通时间表、范围和策略
在向进行大规模迁移时 AWS，您很快就会发现有很多方法可以迁移服务器。例如，可以：
+ 使用[AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html)重新托管工作负载。
+ 对您的应用程序进行容器化并将其托管在[亚马逊弹性容器服务 (Amazon ECS) 或亚马逊弹性](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) Kubernetes [服务 (Amaz](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) on EKS) 托管容器平台上。
+ 将您的工作负载重新设计为完全无服务器的应用程序。
要确定正确的迁移路径，务必从业务驱动因素向后推进。如果您的最终目标是提高业务灵活性，那么您可能会偏爱后两种模式，这两种模式涉及更高级别的转型。如果您的目标是在年底之前腾出数据中心，则可以选择重新托管工作负载，因为重新托管提供的速度很快。
大规模迁移通常涉及广泛的利益相关者，包括：
+ 应用程序所有者
+ 网络团队
+ 数据库管理员
+ 执行赞助商
关键是要确定迁移的业务驱动因素，并将该列表包含在文件中，例如迁移计划成员可以访问的项目章程。此外，还要创建与目标业务成果密切一致的关键绩效指标 (KPIs)。
例如，一位客户希望在 12 个月内迁移 2,000 台服务器，以实现撤出数据中心的目标业务成果。但是，他们的安全团队并未实现这一目标。结果是进行了数月的技术辩论，讨论是错过数据中心关闭日期，而是进一步实现应用程序现代化，还是先重新托管以实现数据中心及时关闭，然后对 AWS应用程序进行现代化改造。
### 定义清晰的升级路径以帮助消除障碍
大型云迁移计划通常涉及广泛的利益相关者。毕竟，您可能会更改已在本地托管了几十年的应用程序。每个利益相关者的优先事项相互矛盾是很常见的。
尽管所有优先事项都可能推动价值，但该计划的预算可能会有限，目标结果也可能明确。管理各种利益相关者并专注于目标业务成果可能具有挑战性。当你将其乘以迁移范围内的数百或数千个应用程序时，这一挑战就会变得更加复杂。此外，利益相关者可能会向不同的领导团队汇报，这些团队还有其他优先事项。考虑到这一点，除了清楚地记录目标业务结果外，还必须定义一个清晰的上报矩阵来帮助消除障碍。这可以节省大量时间，并有助于各团队朝着共同的目标协调一致。
证明这一点的一个例子是金融服务公司，其目标是在12个月内撤出其主数据中心。没有明确的授权或升级路径，这导致利益相关者无论时间和预算限制如何，都要制定他们想要的迁移路径。在向首席信息干事上报后，制定了明确的任务规定，并提供了要求作出必要决定的机制。
### 尽量减少不必要的更改
变化是件好事，但更多的变化意味着更多的风险。当大规模迁移的商业案例获得批准后，很可能有目标业务结果推动该计划，例如在特定日期之前腾出数据中心。虽然技术人员通常想重写所有内容以充分利用 AWS 服务，但这可能不是您的业务目标。
一位客户专注于将公司的整个网络规模基础架构迁移到为期两年。 AWS他们创建了为期两周的规则作为一种机制，以防止应用程序团队花费数月的时间重写应用程序。通过使用两周规则，当必须在多年内移动数百个应用程序时，客户能够以稳定的节奏维持长期迁移。有关更多信息，请参阅博客文章[《两周规则：在 10 天内重构云端应用程序》](https://aws.amazon.com/blogs/enterprise-strategy/the-two-week-rule-refactor-your-applications-for-the-cloud-in-10-days/)。
我们建议尽量减少任何与业务结果不一致的更改。相反，应建立机制来管理未来的项目中的这些额外更改。
### 尽早记录 end-to-end流程
在大型迁移计划的早期阶段，记录完整的迁移过程和所有权分配。本文档对于教育所有利益相关者了解迁移将如何进行以及他们的角色和职责非常重要。该文档还将帮助您了解可能发生问题的位置，并在迁移过程中提供流程的更新和迭代。
在迁移项目的开发过程中，请确保理解所有现有流程，并清楚地记录集成点和依赖关系。包括需要与外部流程所有者互动的地方，包括变更请求、服务请求、供应商支持以及网络和防火墙支持。了解流程后，我们建议在负责任、负责、咨询、知情（RACI）矩阵中记录所有权，以跟踪不同的活动。要完成该过程，请确定迁移的每个步骤所涉及的时间表，从而制定倒计时计划。倒计时计划通常从工作负载迁移切换日期和时间开始倒退。
这种记录方法对于一家跨国家用电器公司来说效果很好，该公司在不到一年的时间内 AWS 成功迁移到并退出了四个数据中心。他们有六个不同的组织团队和多个第三方参与，这带来了管理开销，导致了 back-and-forth决策和实施延迟。 AWS 专业服务团队与客户及其第三方一起确定了迁移活动的关键流程，并向各自的所有者记录了这些流程。由此产生的 RACI 矩阵得到了所有参与团队的共享和同意。使用 RACI 矩阵和升级矩阵，客户缓解了造成延误的障碍和问题。然后，他们得以提前离开数据中心。
在使用 RACI 和升级矩阵的另一个例子中，一家保险公司能够在不到 4 个月的时间内退出数据中心。客户了解并实施了责任共担模型，并遵循了详细的 RACI 矩阵来跟踪整个迁移过程中每个流程和活动的进度。因此，客户能够在实施的前12周内迁移超过350台服务器。
### 记录标准迁移模式和构件
可以把它看作是为实现创建曲奇工具。可重复使用的参考资料、文档、运行手册和模式是扩展的关键。这些记录了未来的迁移项目可以重复使用和避免的经验、学习、陷阱、问题和解决方案，从而大大加快了迁移速度。这些模式和工件也是一项投资，将有助于改善流程并指导未来的项目。
例如，一个客户正在执行为期一年的迁移，其中应用程序由三个不同的 SI AWS 合作伙伴迁移。在早期阶段，每个 AWS 合作伙伴都在使用自己的标准、操作手册和工件。这给客户团队带来了很多压力，因为同样的信息可以用不同的方式呈现给他们。在经历了这些早期的痛苦之后，客户建立了迁移中使用的所有文档和工件的中央所有权，并制定了提交建议更改的流程。这些资产包括以下内容：
+ 标准迁移流程和清单
+ 网络图样式和格式标准
+ 基于业务关键性的应用程序架构和安全标准
此外，这些文件和标准的变更每周都会发送给所有团队，并且要求每个合作伙伴确认收到并遵守任何变更。这极大地改善了迁移项目的沟通和一致性，当另一个业务部门开始进行单独的大规模迁移工作时，该团队得以采用现有的流程和文档，从而大大加快了他们的成功速度。
### 为迁移元数据和状态建立单一事实来源
在规划大规模迁移时，建立真实来源对于保持各个团队的协调一致并实现以数据为导向的决策非常重要。当你开始这个旅程时，你可能会发现许多可以使用的数据源，例如配置管理数据库 (CMDB)、应用程序性能监控工具、清单列表等。
或者，您可能会发现数据源很少，因此必须创建机制来捕获所需的数据。例如，您可能需要使用发现工具来发现技术信息，并调查 IT 领导者以获取业务信息。
将各种数据源聚合到可用于迁移的单个数据集中，这一点很重要。然后，您可以在实施期间使用单一事实来源来跟踪迁移情况。例如，您可以跟踪哪些服务器已迁移。
一家想要迁移所有工作负载的金融服务客户， AWS 专注于使用已提供的数据集规划迁移。该数据集存在关键差距，例如业务关键性和依赖性信息，因此该计划开始了发现活动。
在另一个例子中，同一行业的一家公司基于对服务器基础架构库存的 out-of-date了解，开始实施迁移浪潮。由于数据不正确，他们很快就开始看到迁移数量减少了。在这种情况下，应用程序所有者无法理解，这意味着他们无法及时找到测试人员。此外，数据与其应用程序团队已完成的停用不一致，因此服务器在运行时没有用于业务目的。
## 正在进行大规模迁移
在确定业务成果并向利益相关者传达战略之后，您可以着手规划如何将大规模迁移的范围划分为可持续的移民事件或浪潮。以下示例为制定波浪计划提供了关键指导。
**Contents**
+ [提前规划迁移浪潮，确保稳定流动](#plan-waves)
+ [将波浪实施和波浪计划作为独立的流程和团队保管](#separate)
+ [从小处着手，取得丰硕成果](#start-small)
+ [尽量减少转换窗口的数量](#cutover-numbers)
+ [快速失败、应用经验并进行迭代](#iterate)
+ [别忘了回顾展](#retrospective)
### 提前规划迁移浪潮，确保稳定流动
规划迁移是该计划最重要的阶段之一。俗话说：“如果你没有做好计划，你就会计划失败。” 随着团队对迁移情况变得更加积极主动，提前规划迁移浪潮可以使项目迅速进行。它可以帮助更轻松地扩大项目规模，并随着项目需求的增加和变得复杂而改善决策和预测。提前规划还可以提高团队适应变化的能力。
例如，一家大型金融服务客户正在制定数据中心退出计划。最初，客户按顺序规划迁移浪潮，先完成一轮迁移，然后再开始计划下一波迁移。这种方法减少了准备时间。当利益相关者得知他们的应用程序正在迁移到时 AWS，他们仍需要执行几个步骤才能开始迁移。这给该计划增加了严重的延迟。客户意识到这一点后，他们实施了以未来为重点的全面迁移规划流程，提前几个月计划了迁移浪潮。这为申请团队提供了足够的通知，让他们可以执行迁移前活动，例如通知 AWS 合作伙伴、许可分析等。然后，他们可以将这些任务从程序的关键路径中删除。
### 将波浪实施和波浪计划作为独立的流程和团队保管
当波浪规划和波浪实施团队分开时，这两个流程可以并行工作。通过沟通和协调，这可以避免因为没有足够的服务器或应用程序准备好达到预期的速度而减慢迁移速度。例如，迁移团队可能需要每周迁移 30 台服务器，但在当前浪潮中，只有 10 台服务器准备就绪。这种挑战通常是由以下原因造成的：
+ 迁移实施团队没有参与浪潮规划，在浪潮规划阶段收集的数据也不完整。在开始迁移之前，迁移实施团队必须收集更多的服务器数据。
+ 迁移实施计划在波浪计划之后立即开始，两者之间没有缓冲区。
必须提前计划波浪，并在准备和开始实施波浪之间留出缓冲区。同样重要的是要确保浪潮规划团队和迁移团队共同努力，收集正确的数据并避免返工。
### 从小处着手，取得丰硕成果
计划从小处着手，并在随后的每个波浪中提高迁移速度。最初的浪潮应该是一个少于 10 台服务器的小型应用程序。在后续浪潮中添加其他应用程序和服务器，从而提高您的全部迁移速度。优先考虑不太复杂或风险较低的应用程序，并按计划加快速度，让团队有时间适应合作和学习流程。此外，该团队可以识别并实施每个波浪的流程改进，这可以大大提高后期波浪的速度。
一位客户在一年内迁移了 1,300 多台服务器。通过试点迁移和几波较小的迁移开始，迁移团队得以确定多种方法来改善以后的迁移。例如，他们早些时候确定了新的数据中心网段。在流程的早期阶段，他们与防火墙团队合作，制定了允许与迁移工具进行通信的防火墙规则。这有助于防止在未来的浪潮中出现不必要的延迟。此外，该团队还能够开发脚本，以帮助他们在每个浪潮中实现更多发现和转换过程的自动化。从小处着手帮助团队专注于早期流程改进，并极大地增强了他们的信心。
### 尽量减少转换窗口的数量
大规模移民需要采取纪律严明的方法来推动规模。在某些领域过于灵活是大规模迁移的反模式。通过限制每周切换窗口的数量，在直接转换活动上花费的时间具有更高的价值。
例如，如果切换窗口过于灵活，则最终可能会有 20 个切换，每个切换包含五台服务器。相反，你可以有两个切换，每个 50 台服务器。由于每次转换的时间和精力相似，因此更少、更大的切换可以减轻调度的操作负担，并限制不必要的延迟。
一家大型科技公司正试图在合同到期之前迁出几个租赁的数据中心。错过到期时间将导致昂贵的短期续订条款。在迁移的早期，允许应用程序团队决定直到最后一刻的迁移时间表，包括在转换前几天出于任何原因选择退出迁移。这导致项目早期阶段出现了多次延误。通常，客户必须在最后一刻与其他应用团队协商才能填写。客户最终加强了规划纪律，但是这个早期的错误给迁移团队带来了持续的压力。总体时间表的延迟导致某些应用程序无法及时离开数据中心。
### 快速失败、应用经验并进行迭代
最初每次迁移都有陷阱。尽早失败有助于团队学习、理解瓶颈，并将吸取的教训应用于更大的浪潮。预计迁移的前几波浪潮将很缓慢，原因如下：
+ 团队成员正在适应彼此和流程。
+ 大型迁移通常涉及许多不同的工具和人员。
+ 集成、测试、失败、学习和持续改进 end-to-end流程需要时间。
在最初的几波浪潮中，问题很常见，而且是预料之中的。了解这一点并将其传达给整个组织很重要，因为有些团队可能不喜欢尝试新事物而失败。失败会使团队望而却步，成为未来迁移的障碍。确保每个人都明白最初的问题是工作的一部分，并鼓励每个人尝试失败，这是成功迁移的关键。
一家公司计划在 24-36 个月内迁移 10,000 多台服务器。为了实现这一目标，他们每月需要迁移近 300 台服务器。但是，这并不意味着他们从第一天起就迁移了 300 台服务器。前几波浪潮是学习浪潮，这样团队就可以了解事情是如何运作的，以及谁有权做什么。他们还确定了可以改善流程的集成，例如与CMDB集成，以及。 CyberArk他们利用学习浪潮来失败、改进和再次失败，从而完善了流程和自动化。6 个月后，他们每周能够迁移 120 多台服务器。
### 别忘了回顾展
这是敏捷过程的重要组成部分。这是团队沟通、调整、学习、同意和向前迈进的地方。最基本的回顾展是回顾过去，讨论发生了什么，确定哪些方面进展顺利，哪些需要改进。然后可以根据这些讨论进行改进。回顾展围绕着吸取教训的概念总结了一些形式或过程。回顾很重要，因为要实现大规模迁移成功的规模和速度，流程、工具和团队必须不断发展和改进。回顾可以在其中发挥重要作用。
传统的经验总结课程要等到计划结束后才会举行，因此这些经验教训通常不会在下一轮移民浪潮开始时得到回顾。对于大规模迁移，应将吸取的经验教训应用于下一波浪潮，并应成为浪潮规划过程的关键部分。
对于一位客户，每周举行回顾会，讨论和记录从切换中吸取的经验教训。在这些会议中，他们发现了从流程或自动化的角度来看还有精简空间的领域。这导致实施了包含特定活动、所有者和自动化脚本的倒计时时间表，以最大限度地减少转换期间的手动任务，包括验证第三方工具和安装Amazon CloudWatch 代理。
在另一家大型科技公司，该团队定期举行回顾展，以找出之前的迁移浪潮中存在的问题。这导致了流程、脚本和自动化的改进，使整个项目期间的平均迁移时间缩短了40％。
## 其他注意事项
大型移民计划必须将许多领域考虑在内。以下各节提供了有关必须考虑的其他事项的想法。
**Contents**
+ [边走边清理](#clean-up)
+ [为任何其他转换实施多个阶段](#phases)
### 边走边清理
如果迁移的成本是您预期的 10 倍，并且在关闭和清理用于迁移的资源之前，该项目才算完成，则该迁移就不算成功。这种清理应该是迁移后活动的一部分。它可确保您不会在环境中留下会增加成本的未使用的资源和服务。迁移后清理也是一种很好的安全实践，可以防止暴露您的环境的威胁和漏洞。
迁移到的两个关键结果 AWS 云 是节省成本和提高安全性。留下未使用的资源可能会破坏迁移到云的业务目的。未清理的最常见资源包括以下内容：
+ 测试数据
+ 测试数据库
+ 测试账户，包括防火墙规则、安全组和网络访问控制列表 (网络 ACL) IP 地址
+ 为测试而配置的端口
+ Amazon Elastic Block Store（Amazon EBS）卷
+ 快照
+ 复制（例如停止将数据从本地复制到 AWS）
+ 占用空间的文件（例如用于迁移的临时数据库备份）
+ 托管迁移工具的实例
举一个不良清理实践的例子，SI P AWS artners 在成功迁移后并未删除复制代理。 AWS 审计发现，已经迁移的复制服务器和 EBS 卷每月的成本为 20,000 美元。为了缓解这个问题， AWS 专业服务创建了一个自动审核流程，当陈旧的服务器还在被复制时，该流程会通知 SI AWS 合作伙伴。然后，SI AWS 合作伙伴可以对未使用和过时的实例采取行动。
对于未来的迁移，我们采用了一个流程，将迁移后的超级护理周期定义为48小时，以确保平台的顺利采用。然后，客户的基础架构团队提交了本地服务器的停用申请。据悉，停用请求获得批准后，相应浪潮的服务器将从应用程序迁移服务控制台中删除。
### 为任何其他转换实施多个阶段
在进行大规模迁移时，务必专注于核心目标，例如关闭数据中心或基础设施转型。在较小的迁移中，范围蔓延的影响可能微乎其微。但是，几天的额外工作量乘以可能的数千台服务器，可以为该程序增加大量时间。此外，额外的变更可能还需要更新支持团队的文档、流程和培训。
为了克服潜在的范围蔓延，您可以实施多阶段迁移方法。例如，如果您的目标是腾出数据中心，则第 1 阶段可能只包括 AWS 尽可能快地重新托管工作负载。重新托管工作负载后，第 2 阶段可以实施转型活动，而不会危及目标业务成果。
例如，一位客户计划在 12 个月后退出其数据中心。但是，他们的迁移包括其他转型活动，例如推出新的应用程序性能监控工具和升级操作系统。迁移范围内有 1,000 多台服务器，因此这些活动大大延迟了迁移。此外，这种方法需要在使用新工具方面进行培训。客户后来决定实施多阶段方法，最初的重点是重新托管。这提高了他们的迁移速度，降低了无法在数据中心关闭日期之前完成任务的风险。